CS5331 Web Security

No lecture on Week 3. Focus on attacks on web sessions.

HTTP initially started off as a simple stateless protocol for server scalability. This means authentication needs to be established during each connection, which can be achieved either via:

• Cookie - basic authentication as HTTP header
  • Defined by RFC-6265, for authentication, personalization, tracking
  • Can be read/write by Javascript,
• Store session ID as URL parameter
• Hidden HTML elements, e.g. <input type="hidden" value="xxx"/> which can be read by CGI program via stdin

One point of vulnerability during an account compromise is to fetch session cookies via the filesystem, e.g. Mozilla Firefox in Windows stores the cookies in a cookies.sqlite database located in [HOME_DIR]\AppData\Roaming\Mozilla\Firefox\Profiles\[RANDOM_STR].default-release\.

Some mitigations:

• Sanitize inputs and check integrity (e.g. digital signing)
• Store in cookie instead of URL, which will be stored in browser log
• Encryption and randomization of dynamic session ID
• Use solutions employed in actively deployed solutions, e.g. Chrome, Firefox

Basically cross-site request forgery (CSRF), which triggers when user is logged in to a legitimate site, and a malicious website requests a browser to make a HTTP request, e.g.

<img src="http://cross-site.com/"></img>

Another alternative mode of attack is via session feeding (inject attacker's session), as well as "drive-by pharming" (Stamm, 2007).

CSRF defence by checking the HTTP referrer header of the request (Referer or HTTP Origin) / random numbers in all steps of transaction. Additionally using graphical turing test to check if a human initiated the request.

In the end, the access control mechanism in a browser should only allow the same site to run its javascript, etc. This gives rise to the Same-Origin Policy (SOP): scripts from one origin can only access objects and services from the same origin. During current deprecation via SOP, browsers can have inconsistent handling of SOP policies across different resources, e.g. cookies (even on different subdirectories), clipboard, browser history, geolocation. Sidetrack to secure clipboard using a secure OS, Qubes OS.

Main takeaway: different services should be nested within their own subdomain, instead of different subdirectory.

Other related stuff includes:

• CORS and Access-Control-Allow-Origin
• JSONP (JSON with padding) is restricted and unsafe
• postMessage() cross-frame communication channel

We can define a strictly weaker (compared to network attacker) threat model as a web attacker, which by definition owns a valid domain with SSL certificate, can entice victims to visit the site, and cannot intercept/read traffic for other sites (i.e. browser is assumed bug-free).

Sidenote, good resource for external events: NUS Computing Events.

Other stuff:

• Non-persistent (reflected) XSS, by embedding HTML that sends out GET request with, say, cookies embedded in the URL
• Persistent XSS, by uploading XSS to vulnerable web application
• DOM-based XSS
• Mutation XSS

Same content as CS3235 Lecture 2.

Foundation of secure channel using SSL.

• HTTPS downgrade attack (HSTS, preloading)
• CORS vulnerability
• Mixed content
  • Distinguish between active and passive mixed content
  • Use of protocol-relative URLs, e.g. //example.com/img.gif
  • Use of Content Security Policy: upgrade-insecure-requests; to request browser to upgrade protocol for insecure HTTP
• Typical vector via UI to trick users instead

Root CA is not a recommended method, since every certificate signed will be trusted in the client browser. The trust anchor is the union of all CAs, i.e. certification only as strong as the weakest root CA.

• DigiNotar breach...?
• Possible method to reduce attack surface: replace encryption over TCP/IP, with encryption over serial...?
• Defenses against compromised certificates:
  • Revocation
  • Pinning (HTTP Public-Key-Pins header)
  • Transparency (open framework for publicly auditing all SSL certificates, see this)
  • PFS

Some implementation errors:

• Lack of insecure sub-resource loading alerts
• Forgery of certificates, e.g. mishandling of null-byte in common name
• Unicode impersonation problem
• Timing side-channels, e.g. Lucky Thirteen crypto attack

Contact information: liangzk@comp.nus.edu.sg

For web security stuff, consider reading up on OWASP. Regarding new top 10 vulnerabilities, now to consider broken access controls, crypto failures and injection attacks. "Principle of easiest penetration", which also includes data and people (rubber hose cryptanalysis).

Approach: Read the code and understand the architectural components + intercomponent communication protocols.

Adminstrative:

• Module details on Canvas
• In-class tests and quizzes + assignments
• Project: Choose target platform/codebase and list of reference attacks
• Mailing list at cs5331ta@googlegroups.com with consultation over Teams

• Exposure of kernel interfaces via Internet Explorer
• Google Chrome was designed with OS principles in mind (some comic book?), has interesting ideas
• Python has an in-built webserver implementation (python3 -m http.server --cgi 80)
• CGI in essence, if enabled for the webserver, runs the specific program. See this sample program. An example CGI program, using Bash, which prints when CGI program is called via HTTP:

./cgi-bin/dynamic.cgi

#!/bin/sh
echo "Content-Type: text/html"
echo "<document><head></head><body><h1>Hello</h1>"
echo $*  # pass URL arguments via command line args
echo "</body></document>"

• Static HTML evolved into dynamic HTML using CGI, followed by active HTML using Javascript, etc.