HTTP Protocols and Security

HTTP Protocols and Security

http 1.0

TCP connections cannot be reused. Servers close connections after responding to requests.

http 1.1

Keep-alive is enabled by default. Connections are reused, avoiding the overhead of creating and closing connections. HTTP requests happen one after another without repeating connections. To detect response end:

  1. Content-Length header field (static data with known size)
  2. Transfer-Encoding: chunked (dynamic data)

HTTP 2

  1. HTTP/2 uses multiplexing. Each request gets an ID. Multiple requests can run on one connection. Requests can mix randomly. The receiver uses request IDs to separate them into different server requests.

  2. TCP connections need warming up. They check if data transfers successfully first, then slowly increase speed. For instant concurrent connections, servers get slow. It’s better to use one established connection that supports instant concurrent requests through stream-based packet separation (like UDP but without those overheads).

  3. Header compression. Both sides cache a header table to avoid repetition and reduce transmission size.

HTTPS

Adds SSL protocol on top of HTTP. HTTPS needs 12 packets total: TCP’s 3 packets plus 9 SSL handshake packets. This greatly increases man-in-the-middle attack costs. HTTPS only encrypts HTTP layer content.

Common Status Codes

301 - Moved Permanently: Resource moved to new URI permanently. Use the new URI from now on.

302 - Found: Temporary redirect. Like 301 but the new URL is temporary.

303 - See Other

When 301, 302, or 303 responses return, almost all browsers change POST to GET and delete request body. Then they send the request again automatically.

400 - Bad Request 401 - Unauthorized 403 - Forbidden 404 - Not Found 500 - Internal Server Error 503 - Service Unavailable 504 - Gateway Timeout

Common Headers

ETag: An identifier for an object like a URL. When an HTML file changes, its ETag changes too. ETag works like Last-Modified to help web servers check if objects changed. You get an ETag on first request. On next request, the browser sends the ETag to the server. The server compares it with current ETag to see if the file changed.

Last-Modified: Web server’s view of when an object was last modified. File modification time, dynamic page generation time, etc.

Request Methods

GET sends one TCP packet. Browser sends HTTP headers and data together. Server responds 200 and returns data. Idempotent - multiple requests give same result.

POST sends two TCP packets. Browser sends headers first. Server responds 100. Browser sends data. Server responds 200 and returns data. Not idempotent.

HEAD works like GET except the server cannot return message body. HEAD response headers should match GET response headers.

Security

XSS

Vulnerability that allows malicious users to inject code into website pages. Prevention:

  1. HttpOnly cookies
  2. Input validation
  3. Output validation

CSRF

Cross-site request forgery. Attacker tricks user to visit a page that executes operations in third-party site under user’s identity. Prevention:

  1. Check referer for same-site requests
  2. CSRF tokens
  3. Custom validation headers
  4. Captcha

Man-in-the-middle attacks

Use HTTPS encryption.

SQL injection

Core idea is parameterized input. Solutions:

  1. Prepared statements, reuse execution plans
  2. Stored procedures, reuse execution plans
  3. Frontend character checks

Side-channel attacks

Suppose your browser opens Site A and logs in. Cookies store session ID. Then you open Site B accidentally. This site runs malicious code immediately. The code calls Site A’s API to get Site A’s data because it can ride Site A’s session cookie. This data contains user privacy. So Site A’s private information gets stolen by Site B’s code. This happens from cross-origin access.

Secure Cross-Origin

JSONP: Uses script tags for callbacks. Execute callback functions in JavaScript to get data. Drawback: Can only send GET requests, cannot carry cookies.

CORS: Cross-origin AJAX automatically adds origin parameter. Server uses this origin to decide authorization. If response includes Access-Control-Allow-Origin header, cross-origin request succeeds. Otherwise it fails.