Module 4 of 5
Untrusted input
Input becomes dangerous when a program interprets it instead of storing it. This module covers injection, cross-site scripting, server-side request forgery, unsafe parsers and deserializers, and file paths.
Every vulnerability in this module has the same shape. A value arrives from outside, the application hands it to something that interprets text (a SQL engine, a shell, a browser, a URL fetcher, a deserializer, the file system), and the value changes what that interpreter does. The attacker never breaks a lock. They write a sentence in a language the application did not realize it was speaking.
The five lessons take one interpreter at a time: SQL and the shell, the browser, outbound HTTP, parsers and object deserializers, and paths and archives. Each one shows the vulnerable code running against a simulated target, the fix that removes the ambiguity rather than filtering for bad characters, and where that fix stops working. By the end you should be able to look at any place where input meets an interpreter and say which part of the input is data, which part could become structure, and what keeps them apart.
Lessons
- 4.aInjection and parameterizationWhy does string-built SQL or shell turn input into code, and what actually stops it?20 min
- 4.bXSS and output encodingHow does untrusted text become script in a browser, and which layers stop it?18 min
- 4.cServer-side request forgeryHow does a URL fetcher become a path into your internal network, and how do you design one that is not?23 min
- 4.dParsers and deserializationWhy can parsing a request body run code or grant privileges, and how do you parse so that it cannot?23 min
- 4.eFiles and pathsHow does a file name from a request reach files it should not, and how do you keep paths, archives and uploads contained?21 min