Web Security, Authentication & Architecture: Servers, Tiers, Sessions & Attacks

TAKEAWAYS:

• Web servers act as intermediaries between clients and backend systems, processing HTTP requests/responses and hosting static/dynamic content.
• Tier architecture separates concerns: 2-tier (client-server) vs 3-tier (client-server-database) improves scalability and security.
• Authentication methods (anonymous, Windows, OAuth) control access, with OAuth2 being the industry standard for third-party logins.
• Sessions maintain user state via cookies, tokens, or server-side storage, critical for e-commerce (e.g., Daraz carts).
• Security threats (SQLi, XSS, CSRF) exploit input validation flaws; defenses include input sanitization, HTTPS, and CSRF tokens.
• Real-world ties: eSewa uses OAuth2 for secure payments, Ncell’s app employs 3-tier architecture for load balancing, and Daraz’s search relies on server-side session handling.

Core Concepts: Web Servers and Their Role

1. What is a Web Server?

A web server is software (e.g., Apache, Nginx, IIS) or hardware that:

• Hosts websites, serving static files (HTML, CSS, JS) and dynamic content (PHP, Python).
• Processes HTTP/HTTPS requests from clients (browsers, apps) and returns responses.
• Manages domains, SSL certificates, and load balancing across multiple servers.

How It Works (Step-by-Step Trace):

sequenceDiagram
    participant Client as Browser (User)
    participant Server as Web Server (e.g., Apache)
    participant App as Backend (PHP/Node.js)
    participant DB as Database (MySQL)

    Client->>Server: GET /products (HTTP Request)
    Server-->>Client: 200 OK (HTML)
    Client->>Server: POST /cart (Form Submission)
    Server->>App: Process data (e.g., validate input)
    App->>DB: INSERT INTO cart (SQL Query)
    DB-->>App: Success/Failure
    App-->>Server: Response (e.g., "Added to cart!")
    Server-->>Client: 200 OK (Dynamic HTML)

2. Key Functions of a Web Server

3. Tier Architecture: Separating Concerns

A. 2-Tier vs 3-Tier Architecture

Visual Comparison:

B. Why Use 3-Tier?

• Separation of Concerns: UI (client), logic (server), data (DB) are decoupled.
• Security: Sensitive data (e.g., passwords) never exposed to clients.
• Performance: Caching at the application tier reduces DB load.
• Real-World Example:
  • Pathao’s Ride-Hailing App:
    • Client Tier: Mobile app (displays routes, fares).
    • Application Tier: Node.js server (matches drivers, processes payments).
    • Database Tier: MongoDB (stores user locations, orders).

4. Authentication Methods

A. Anonymous Access

• Definition: No login required; public content only.
• Use Case: Blogs, news sites (e.g., Kathmandu Post).
• Risk: Vulnerable to DDoS if unprotected.

B. Integrated Windows Authentication (IWA)

• How It Works:
  1. User logs into Windows domain.
  2. Browser sends NTLM/Kerberos tokens to the server.
  3. Server validates against Active Directory.
• Use Case: Corporate intranets (e.g., NTC’s internal portal).
• Limitation: Only works within a Windows domain.

C. OAuth2 (Industry Standard)

• How It Works:

  sequenceDiagram
      participant User
      participant Client as App (e.g., Daraz)
      participant AuthServer as OAuth Provider (Google)
      participant ResourceServer as API (Daraz Backend)
  
      User->>Client: Login with Google
      Client->>AuthServer: Request Token
      AuthServer-->>Client: Token (if authorized)
      Client->>ResourceServer: Access API (with Token)
      ResourceServer-->>Client: User Data

• Real-World Example:
  • eSewa: Uses OAuth2 to let users log in via Facebook/Google.
  • Google Sign-In: Used by millions of apps worldwide.

D. Comparison Table

5. Sessions: Maintaining User State

How Sessions Work

1. User logs in → Server creates a session ID (stored in a cookie).
2. Session ID is sent with every request.
3. Server looks up user data (e.g., cart items, preferences) using the ID.

Example: Daraz Shopping Cart

sequenceDiagram
    participant User
    participant Daraz as Web Server
    participant DB as Database

    User->>Daraz: Login (credentials)
    Daraz->>DB: Create session (ID = "abc123")
    Daraz-->>User: Set Cookie (sessionID=abc123)
    User->>Daraz: Add item to cart (cookie included)
    Daraz->>DB: Update cart for session "abc123"

Session Storage Methods

6. Web Security Threats and Mitigations

A. Common Attacks

B. Real-World Example: SQLi Attack on a Bank

Scenario: A hacker inputs:

' OR '1'='1' --

into a login form’s username field. The query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1' --' AND password = '...'

→ All users are authenticated!

Mitigation:

# Python (Flask) example using parameterized queries
cursor.execute("SELECT * FROM users WHERE username = %s AND password = %s", (username, password))

7. Exam Tip: How to Score Full Marks

1. Diagrams Are Mandatory:

   • Draw 2-tier vs 3-tier architecture (label all layers).
   • Show HTTP request/response flow (method, status codes, headers).
   • Include OAuth2 sequence diagram (client → auth server → resource server).

2. Real-World Applications:

   • Tie session management to eSewa/Khalti (how they keep users logged in).
   • Relate 3-tier architecture to Ncell’s app (scaling during festivals).
   • Explain SQLi using a bank login scenario.

3. Common Pitfalls to Avoid:

   • ❌ Describing cookies vs sessions without comparing storage methods.
   • ❌ Forgetting HTTPS as a mitigation for MITM attacks.
   • ❌ Mixing up OAuth2 (delegated auth) with SAML (enterprise SSO).

4. Short-Answer Tips:

   • For "What is a web server?", list 3 functions (hosting, SSL, load balancing).
   • For "2-tier vs 3-tier", use a table with scalability/security columns.
   • For "session handling", explain cookies + server-side storage.