HTTP – Strike 2

CSE 598 Advanced Security of the Web

Fish Wang

Fall 2026

A simple web app

• Users
• Login, logout
• Different permissions
• Content serving
• Users (or users with different permissions) see their own content

​

• Attackers will want to…
• Login as other users (or higher-permission users)
• Access other users’ data
• They usually do not know the implementation of the web app

2

Web Applications

• Early web was intentionally designed to allow organizations to offer access to a database via the web
• Basis of GET and POST also confirm this
• GET “SHOULD NOT have the significance of taking an action other than retrieval”
• Safe and idempotent
• POST
• Annotation of existing resources; posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles, providing a block of data, such as the result of submitting a form, to a data-handling process; and extending a database through an append operation

3

Web Applications

• Server-side code to dynamically create an HTML response
• How does this differ from a website?
• In the HTTP protocol we've looked at so far, each request is distinct
• Server has client IP address and User-Agent

​

4

Maintaining State

• HTTP is a stateless protocol
• However, to write a web application we would like to maintain states and link requests together
• The goal is to create a “session” so that the web application can link requests to the same user
• Allows authentication
• Rich, full applications
• How to implement sessions in HTTP?
• Embedding information in URLs
• Using hidden fields in forms
• Using cookies

5

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

​

HTTP Basic Authentication

• The server replies to an unauthorized request with an HTTP 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?

​

HTTP 1.1 Authentication

• Defines an additional authentication scheme based on cryptographic digests (RFC 2617, replacing RFC2069)
• 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 must have access to clear-text user passwords

​

A closer look at HTTP 1.1 Authentication

• An example from RFC 2617
• Username: Mufasa
• Password: Circle Of Life
• URL: http://www.nowhere.org/dir/index.html

​

9

A closer look: Server response

HTTP/1.0 401 Unauthorized

Server: HTTPd/0.9

Date: Sun, 10 Apr 2014 20:26:47 GMT

WWW-Authenticate: Digest realm="testrealm@host.com",

qop="auth,auth-int",

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

opaque="5ccc069c403ebaf9f0171e9517f40e41"

Content-Type: text/html

Content-Length: 153

10

A closer look: Client request

GET /dir/index.html HTTP/1.0

Host: localhost

Authorization: Digest username="Mufasa",

realm="testrealm@host.com",

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

uri="/dir/index.html",

qop=auth,

nc=00000001,

cnonce="0a4f113b",

response="6629fae49393a05397450978507c4ef1",

opaque="5ccc069c403ebaf9f0171e9517f40e41"

11

Authentication only; no integrity protection

Generating the response

HA1 = MD5("Mufasa:testrealm@host.com:Circle Of Life")

= 939e7578ed9e3c518a452acee763bce9

HA2 = MD5("GET:/dir/index.html")

= 39aff3a2bab6126f332b942af96d3366

Res = MD5("939e7578ed9e3c518a452acee763bce9:

dcd98b7102dd2f0e8b11d0f600bfb0c093:

00000001:0a4f113b:auth:

39aff3a2bab6126f332b942af96d3366")

= 6629fae49393a05397450978507c4ef1

12

nonce

cnonce

Security Issues (Strike 2)

13

Potential threats

• Missing authentication
• Credential leaks
• Client side & server side
• Replay attacks: Attackers may replay captured traffic
• Credential bruteforcing

14

Missing authentication

• Authentication is only applied on certain paths
• Force navigation: Do not expect attackers to follow your planned navigation path
• Authentication is only applied on certain HTTP methods
• Some uncommon HTTP methods might lack authentication
• IP-based authentication using untrusted sources of client IPs

​

15

Basic auth

• Basic auth is not encryption, so any credentials submitted via basic auth can be sniffed

16

Encoding errors

• Authenticated = finding a record of the user-provided username and password in a database
• Registration may allow usernames with different encodings (UTF-16 vs ASCII), but authentication only conducts username matching in one encoding
• Leading to credential record overwrite

17

HTTP digest nonce replay

• The security of Digest Access Authentication relies on nonce
• How can we defend against a direct authentication replay attack?
• The nonce and opaque should be IP and timestamp relevant
• Attackers should not be able to generate good nonces
• The server should remove used or expired nonces (if states are maintained on the server side)

18

Credential bruteforcing

• How to guess the credentials?
• Enumeration
• Dictionary attack

​

• How to defend?
• Intentionally vague error messages
• Rate limiting against bruteforce attacks
• Be careful about timing side channels (usually not a big concern unless in special occasions)

​

19

Embedding Information in Cookies

20

Embedding Information in Cookies

• Cookies are state information passed between a web server and a user agent
• Server initiates the start of a session by asking the user agent to store a cookie
• Server or user agent can terminate the session
• Cookies are first defined by Netscape while attempting to create an ecommerce application
• RFC 2109 (February 1997) describes the first standardization attempt for cookies
• RFC 2965 (October 2000) tried to standardize cookies 2.0
• RFC 6265 (April 2011) describes the actual use of cookies in the modern web and is the best reference

21

Embedding Information in Cookies

• Cookies are name-value pairs
• Name and its value are seperated by “=”
• Pairs are separated by “;”
• Server includes the "Set-Cookie" header field in an HTTP response
• Set-Cookie: USER=foo;
• User agent will then send the cookie back to the server using the "Cookie" header on further requests to the server
• Cookie: USER=foo;

​

22

Embedding Information in Cookies

• Server can ask for multiple cookies to be stored on the client, using multiple “Set-Cookie” headers
• Set-Cookie: USER=foo;
• Set-Cookie: lang=en-us;

​

23

Embedding Information in Cookies

• Server can send several attributes on the cookie, these attributes are included in the Set-Cookie header line, after the cookie itself, separated by “;”
• Path
• Specifies the path of the URI of the web server that the cookies are valid
• Domain
• Specifies the subdomains that the cookie is valid
• Expires or Max-Age
• Used to define the lifetime of the cookie, or how long the cookie should be valid
• HttpOnly
• Specifies that the cookie should not be accessible to client-side scripts
• Secure
• Specifies that the cookie should only be sent over secure connections

24

Embedding Information in Cookies

• Example cookie headers from curl request to www.google.com
• curl -v http://www.google.com

25

• __Secure-STRP=ANmZwa1ZnzmMQKw2IW1oNVxQSVwSEgkIE2Eu8mbvCVgIhpwBMpEm_0sVk8AXcqlCY-KZEWEIdFGKkYm18iWJHAuvHOuD51C4xbGx; expires=Thu, 17-Sep-2026 22:44:51 GMT; path=/; domain=.google.com; Secure; SameSite=strict
• expires is set to a few hours after this request
• path is / which means to send this cookie to all subpaths of www.google.com/
• domain is .google.com, which means to send this cookie to all subdomains of .google.com
• Includes www.google.com, drive.google.com, …

​

26

• __Secure-STRP=ANmZwa1ZnzmMQKw2IW1oNVxQSVwSEgkIE2Eu8mbvCVgIhpwBMpEm_0sVk8AXcqlCY-KZEWEIdFGKkYm18iWJHAuvHOuD51C4xbGx; expires=Thu, 17-Sep-2026 22:44:51 GMT; path=/; domain=.google.com; Secure; SameSite=strict; HttpOnly
• HttpOnly is a security feature, which means only send this cookie in HTTP, do not allow JavaScript code to access the cookie

​

• Why is getting the cookie in JavaScript bad?
• Sensitive cookies might get stolen

27

Embedding Information in Cookies

• The server can request the deletion of cookies by setting the “expires” cookie attribute to a date in the past
• User agent should then delete cookie with that name
• Set-Cookie: USER=foo; expires=Thu, 1-Jan-2015 16:11:12 GMT;�User agent will then delete the cookie with name "USER" that is associated with this domain

28

Embedding Information in Cookies

• User agent is responsible for following the server's policies
• Expiring cookies
• Restricting cookies to the proper domains and paths

​

• However, user agent is free to delete cookies at any time
• Space/storage restrictions
• User decides to clear the cookies

29

Modern Sessions

• Sessions are used to represent a time-limited interaction of a user with a web server
• There is no concept of a “session” at the HTTP level, and therefore it must be implemented at the web application level
• Using cookies
• Using URL parameters
• Using hidden form fields
• In the most common use of sessions, the server generates a unique (random and unguessable) session ID and sends it to the user agent as a cookie
• On subsequent requests, user agent sends the session ID to the server, and the server uses the session ID to index the server's session information

30

Designing Web Applications

• In the early days of the web, one would write a “web application” by writing a custom web server that received HTTP requests, ran custom code based on the URL path and query data, and returned a dynamically created HTML page
• The drawback here is that one would have to keep the web server up-to-date with the latest HTTP changes (HTTP/1.1 spec is 175 pages)
• Generally decided that it was a good idea to separate the concerns into a web server, which accepted HTTP request and forwarded relevant requests to a web application
• Could develop a web application without worrying about HTTP

31

Security Issues (Strike 3)

32

Cookies are in plaintext

• Cookies are transmitted in plaintext; developers must encrypt the secret cookies by themselves
• Cookies can be stolen (and replayed)
• … by network sniffers
• … by cross-site scripting (XSS) attacks
• … by browser plugins
• … by attackers on local machines

33

Cookies can be set by attackers

• Set-cookie: admin=1

​

• How about…
• Set-cookie: admin=740a9433bfa1

​

• Defense
• Always verify the integrity of the cookies that your web app uses

34

Cookie integrity

• How to protect against modified cookies?

​

​

• How to protect against replayed cookies?

35

Fabricating your cookie (a)

• Attackers can look at or modify cookies
• Solution: Encrypting the cookie or checking a digest of the cookie

36

Fabricating your cookie (b)

• Encrypted cookies
• Bit-flipping attack
• Length-extension attack

37

Fabricating your cookie (c)

• Cookie MAC (message authentication code)
• Generate a hash for the cookie content
• Length-extension attack
• Cryptography is hard… don’t homebrew your own crypto!

38

Session IDs

• Session IDs can be in cookies, HTML forms, or part of the URL
• Differences? Differences in security?
• Some paths in a web app may transfer session IDs from a URL to cookies
• Session IDs are sometimes predictable
• session_id=1, session_id=2, …
• Repeated session IDs
• Weak PRNG for session ID generation
• Session IDs (together with the sessions) must properly invalidate
• Logging out
• Expired sessions

39

Session lifetimes

• Consider a website with both normal users and admins, when should a session be invalidated?
• Logging out
• Expiry
• Password change
• Permission change
• Special cookies (e.g., admin = 1) must be invalidated when the session is invalidated
• How?
• Cookie mixing is extremely critical but difficult to spot

40

Session fixation

• Web app A wants to redirect its users to web app B with certain session IDs
• How?
• http://webappb.com/redirect_from_app_a?username=joe&password=secr3t
• http://webappb.com/redirect_from_app_a?session_id=xxxxxx

41

Web cache

• How would you implement a cache for web pages?
• As a middle box?

42

Cache and secret pages

• Session-specific content should not be exposed to other sessions
• Secret pages can be cached, but can only be served to the same session
• Sensitive pages should never be cached
• Cache-Control: private/no-store

​

43

Questions?

44