WebFund 2024F Lecture 21

Video

Video from the lecture for November 28, 2024 is now available:

• video
• auto-generated captions

Notes

Lecture 21
----------

Web Security

What are the goals of computer security?
 - confidentiality, integrity, availability (CIA)
 - (entity authentication)

What does this mean in the context of web applications?
 - make sure web apps stay up (keep running)  <-- availability
 - ensure data stored in a web app isn't corrupted <-- integrity
 - ensure data and services are only provided to authorized entities <--- confidentiality

What have we done mostly right wrt security?
 - secure password storage
 - sessions with expiration and strong session IDs
 - proper parameterization of database queries (avoiding SQL injection vulnerabilities)

What is SQL injection?
 - attacker is able to execute arbitrary SQL queries by "injecting" malicious inputs to the application

Approaches to avoiding SQL injection is to sanitize inputs
 - escape/quote characters like ";"
    - this is very hard to do in general, very error prone
 - separate definition of SQL command from user inputs
    - this is much better, very safe
    - done right, no way for attacker to turn malicious input into SQL code


SQL injection is just one example of the general class of code injection attacks
 - attacker provides input to an application that is meant to be treated as data
   but gets interpreted as code, typically running in a privileged context


Classic examples of code injection are buffer overflow attacks
  - typically in C code, but can come up in any code that uses a C library
  - C by default doesn't do proper bounds checking on arrays
     - very easy to write data outside the bounds of an array
  - if you know how memory is laid out, you can overwrite key bits of data
    (pointers, esp return stack pointer) that then allow an attacker to take over the program,
    control how it executes
    
Modern systems have many defenses against buffer overflow and related memory corruption attacks
 - stack canaries
 - ASLR (address space layout randomization)
 - no-execute memory

Web code is mostly written in languages that automatically manage memory
 - so there isn't much opportunity for memory corruption attacks
 - however, there are MANY opportunities for code injection attacks, they just use different code!

Wherever you have a code execution engine, you have an opportunity for code injection.

Where do we have code execution engines?
 - client-side JavaScript, HTML, CSS, WebAssembly
 - server-side JavaScript (or whatever other language is running)
 - server-side SQL

code injection vulnerabilities in server-side SQL are common (SQL Injection)
code injection vulns in server-side JavaScript are rare (require use of eval mostly)
  - i.e., construct a string and then run it as JavaScript code
  - was much bigger of an issue when JSON parsing was done using regular JavaScript


client-side code is VERY vulnerable to code injection attacks because "code" is dynamically constructed and naturally co-exists with untrustworthy data

cross-site scripting attacks (XSS) are a well-known class of web application vulns
 - but XSS attacks don't have to be cross-site and don't have to involve scripting!
 - better thought of as code injection attacks at the level of HTML/CSS/JavaScript
   - but with a server component

The classic template for XSS:
 * a malicious user uploads content to a web server
 * victim accesses web app and is compromised

Vuln arises because attacker can send malicious data to their target VIA THE WEB SERVER


In authdemo2, how could we potentially perform an XSS attack?
 - student could upload an assignment with embedded HTML/CSS/JavaScript
 - when instructor/admin views submissions (/list), the malicious payload executes
    - maybe sends all submissions to attacker?

How do you mitigate vulnerabilities in client-side code?
 - filter <--- make sure untrusted input fits a safe pattern
               (e.g., student IDs are all numeric digits)
 - escape <--- transform characters that could allow code to be injected into safe forms

To prevent HTML from being inserted, you have to prevent tags from being inserted
 - and tags are formed using <>
 - so you replace < with < and > with >