Sonali Bank Ltd. Officer IT Exam: 2021প্রশ্ন ও সমাধান

Web caching stores a copy of previously-fetched web content (pages, images, API responses) closer to the user, so repeat requests are served without hitting the origin server again.

flowchart TD
    C([Client requests a page]) --> Ch{In cache and still fresh?}
    Ch -- Yes / Hit --> S1[Serve directly from cache]
    Ch -- No / Miss --> O[Fetch from origin server]
    O --> St[Store copy in cache]
    St --> S2[Serve to client]

Why we use it:

• Lower latency: the cache is physically/logically closer to the user - browser cache, ISP proxy, or CDN edge node - than the origin server, so retrieval is much faster.
• Reduced origin-server load: repeated requests for the same resource are absorbed by the cache instead of hitting the backend every time, preventing overload during traffic spikes.
• Lower bandwidth cost: less data needs to travel across the wider network for popular content.
• Better availability: cached content can sometimes still be served briefly even if the origin server goes down.

Common types: browser cache (client-side), reverse-proxy cache (e.g. Varnish), and CDN edge caching (e.g. Cloudflare, Akamai) - each trading some content freshness, controlled via HTTP headers like Cache-Control, ETag, Expires, for speed.

Exam takeaway: web caching stores and reuses responses to cut latency and origin load; freshness is managed via HTTP cache-control headers, and staleness is the main risk trade-off.

DDoS (Distributed Denial-of-Service): a flood of traffic from many compromised machines, a botnet, simultaneously overwhelms a target server/network's bandwidth, processing capacity, or connection table, so legitimate users cannot get service. Pattern: Attacker to Command-and-Control server to many Bots to a single Target.

SQL Injection: an attacker inserts malicious SQL fragments into an input field so the application's own query executes attacker-controlled logic.

Example - vulnerable code:

-- App builds: SELECT * FROM users WHERE username='<input>' AND password='<input>'
-- Attacker enters username: admin' --
SELECT * FROM users WHERE username='admin' --' AND password='anything'

The trailing comment marker hides the password check entirely, logging the attacker in as admin without knowing the password.

flowchart LR
    A[Malicious input injected] --> Q[App concatenates into SQL string]
    Q --> DB[(Database)]
    DB --> R[Returns admin row - login bypassed]

Mitigation for both:

Attack	Key defence
DDoS	Rate limiting, CDN/anycast, upstream scrubbing, auto-scaling
SQL Injection	Parameterized queries/prepared statements, input validation, least-privilege DB accounts, WAF

Exam takeaway: DDoS is a volumetric flood from many sources denying service; SQL Injection is unsanitized input altering a query's logic, fixed permanently only by parameterized queries, never by string concatenation plus escaping.