Web Security: HTTP and Common Web Threats

• The lecture covers web security, focusing on HTTP, common web threats, login methods, and cookie security.

URL (Uniform Resource Locator)

• A reference to a resource that specifies its network location
• Format includes scheme, user info, host, port and path <scheme>://[user_info]@[host]:[port]/<path>
• <scheme> is the protocol to be used
• [user_info] is the user to log in to (Optional)
• <host> is the domain name or IP address
• [port] is the port to access via (Optional)
• <path> is the sequence of path segments separated by a slash (/)

HTTP (Hypertext Transfer Protocol)

• Visiting http://developer.mozilla.org/home.html to get request header
• Example of a browser request (header):
  • GET /home.html HTTP/1.1
  • Host: developer.mozilla.org
  • User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
  • Accepts various content types, languages and encoding
• GET = Operation Type
• Host = Domain Name
• User-Agent = Browser's type
• Accept = The types which this browser supports
• Accept-Language = The languages this browser prefers to (split by semicolon) (q: preference)
• Accept-Encoding = The encoding method the browser prefers to (to compress the objects)
• Referer = The webpage this user comes from.
• Connection = Whether close the connection after loading this page or not.
• Upgrade-Insecure-Requests = Whether upgrade to the secure version (https) or not.
• If-Modified-Since = The server sends back the requested resource, only if it has been modified after the date in the If-Modified-Since header.

HTTP Server Response

• Example of a server response:
  • HTTP/1.1 200 OK -> Status code
  • Content-Encoding: gzip -> How this object is compressed
  • Accept-Ranges: bytes
  • Cache-Control: max-age=604800 -> Set the parameters that control the cache. max-age: the maximum of time (second) to keep a cache.
  • Content-Type: text/html -> The type of the requested object
  • Content-Length: 606 -> The length of the payload (bytes).

Cookie Security

• Cookie 101 involves the server asking the browser to remember a file, called cookie.
• The server can read, modify, delete the cookie it stores.
• A server sends one or more Set-Cookie headers with the response
• Each Set-Cookie header sets a separate cookie
• Format: Set-Cookie: <cookie-name>=<cookie_value>; [other-attr]
• Set-Cookie example: id=alice; Expires=Fri, 28 Feb 2025, 08:00:00 GMT; Path=/docs; Domain=polyu.edu.hk; Secure; HttpOnly
• Cookie attributes:
  • Expires: Cookie will be deleted after this time
  • Path: Cookie will be sent only if the requested URL includes this path
  • Domain: Specifies the server that can receivethe cookie (sub-domains are OK)
  • Secure: Cookie must be sent by the browser via HTTPS
  • HttpOnly: It cannot be accessed by JavaScript
• HTTP Only can only be accessed when it reaches the server
• Every new web request to the server includes cookies
• If visiting polyu.edu.hk/docs and the cookie is not expired, the GET request looks like:
  • GET /docs/docs.html HTTP/2.0
  • Host: polyu.edu.hk
  • Cookie: id=alice; age=18

Web Application Security

• Developing a secure web application is crucial to prevent vulnerabilities
• Common attack vectors
  • Sniffing
  • Man-in-the-middle attack
  • Session hijacking
  • Cross-site scripting
  • Spoofing
  • Privacy breaches
  • Buffer overflows
  • Format string vulnerabilities
  • Directory traversal
  • Default account abuse
  • Sample applications with known flaws
  • Lack of input/output validation
  • Metacharacter exploitation
  • SQL injection

OWASP Top 10 in 2021

• OWASP (Open Worldwide Application Security Project) lists the most critical web application security risks
• Broken access control: Bypassing access control checks, e.g., by modifying the URL.
• Cryptographic failures: A site doesn't use or enforce TLS or supports weak encryption, allowing network monitoring
• Injection: E.g., SQL Injection
• Insecure design: E.g., Password Recovery Questions
• Security misconfiguration: E.g., Default passwords and insecure features enabled
• Vulnerable and outdated components using old dependencies with security weakness
• Identification and authentication failures, e.g., permitting brute-force attacks
• Software and data integrity failures on devices that do not verify updates via signed firmware
• Security logging and monitoring failures, failing to log critical operations.
• Server-Side Request Forgery (SSRF) flaws occur when a web application fetches a remote resource without validating the user-supplied URL.

Authentication

• Protect resources using authentication
• Ensures only authorized users can access sensitive data and functionalities.

Non-Native Log-in Support

• Requires interpretation by the server
• Example JSON data:

  {
  	"id": "123456",
  	"password": "abcdef"
  }
  

• Associated POST request:
  • POST /login.html HTTP/1.1
  • Host: polyu.edu.hk
  • Content-Type: application/x-www-form-urlencoded
  • Content-Length: 25
  • id=123456&password=abcdef

HTTP Native Login

• Server sends a 401 Unauthorized status with a WWW-Authenticate header
  • Defines the authentication method (e.g., Basic) and realm
• Example server response using curl:

  HTTP/1.1 401 Unauthorized
  Date: Sun, 02 Mar 2025 04:48:10 GMT
  Server: ATS/5.3.0
  WWW-Authenticate: Basic realm="COMP LOGIN"
  Content-Length: 381
  Content-Type: text/html; charset=iso-8859-1
  Connection: keep-alive
  

• Browser sends credentials in the Authorization header using Base64 encoding
• Authorization: Basic YWRtaW46YWRtaW4= for admin:admin
• Native login browser request:

  GET / HTTP/1.1
  Host: capstone.comp.polyu.edu.hk
  Authorization: Basic YWRtaW46YWRtaW4=
  User-Agent: curl/8.4.0
  Accept: */*
  

• Base64 encoding is reversible and thus insecure for transmitting credentials

HTTP Native Login Process

• Client sends a request and receives a 401 Unauthorized response
• The server uses the Authenticate: Basic realm=staging server to ask the user for login credentials.
• Authenticates the user and uses the Authentication header
• Authorization: Basic abaec62f4c5c1d, then checks the credentials
• Responds with 200 OK or, alternatively send a '401 Unauthorized.

Server-Side Configuration for HTTP Authorization

• Use .htaccess files to configure access to directories
• Use Apache configuration files (httpd.conf) to protect chosen history
• Example of .htaccess file contents:

AuthName "Access to the website"
AuthType Basic
AuthUserFile /path/to/.htpasswd
Require valid-user

• Each line in the .htpasswd file consists of a username and a hashed password separated by a colon
• admin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
• .htpasswd hashes:
• bcrypt (with salt): $2y$
• MD5 (with salt): $apr1$
• SHA1 (no salt): {SHA}
• Prefix + salt (BASE64) + hash (BASE64)
• The $ delimiter means the .htpasswd can be a different filename
• require valid-user specifies only uses in AuthUserFile can access
• Rules can be declared to only protect files
• Filename matched by regular expression

HTML-Based Login Forms

• A form that can be implemented in HTML (different from HTTP itself) with the following protocols
• HTTP (to TRANSMIT the information) through the web
• HTML (to FORMATthe webpages)
• Submits a GET or POST request to the server, and the server processes it
• With the server controlling whether one can access a file through HTTP Authorization is more flexible and works using JSON
• Programers define allowed actions

Sessions

• After authentication, sessions manage user login status
• Authorization headers do not have to keep being sent
• An HTML-based or JSON-based authentication form will manage
• There are Types of sessions
• Client-side
• Server-side

Server-Side Sessions

• When a user authenticates through HTTP, the server assigns a session identifier
• It is typically long
• Random number
• The server maps each "session states" and session ID's
• Server-set cookies determine the client
• Set-Cookie: MY_SESSION_ID=23192387db123f901a
• The session ID can be renamed by the programmer (Ex: MY_SESSION_ID

Server-Side Sessions in Spring Boot

• Uses session ID's and attributes to create string and username
• Invalidates a session using session data

Client-Side Sessions

• The server gives the user a cookie containing all session data without directly storing anything
• Encrypt with a key known to the server only
• Otherwise keep the session data as-is
• Encrypt with a key unique to the user
• All the cookie can be in plain-text with a MAC tag, as the user can not modify content of the "session data"

Session Hijacking

• Attackers can achieve session hijacking by stealing the value of a cookie header, reasons including
• Predicable session ID
• Unauthorized access to the browser by an unauthorized external party
• Intercepting unsecure content
• Browsers store cookies locally
• The cookie value is vulnerable through XSS or CSRF

Cookie Security

• Best to to use HTTPS only

No HTTP Only and Secure

• Secure must be sent via TLS, and must not be accessed by JavaScript
• Setting cookie name value

Secure (Cookie)

• Must be sent via TLS
• Setting the cookie path to /, domain to example.com, secure, name value, and expiry
• Cookies will not be sent if is HTTP
• Not setting cookie name value

HTTP Only

• Must not be able to be accessed by Javascript

Cross-Site Scripting (XSS)

• Vulnerable code allows external users to to input JS code to the message
• Allows access to cookies
• Can extract the cookies and store to another user set by GET
• Can be addressed through the use of HTTPOnly