How to read an application you did not write
That is five passes over the same code, each with one question. It finds more than reading it once with all five in your head.
- Follow the data. Where does untrusted input enter, and what language does it end up inside — SQL, HTML, a shell, a URL, a file path?
- List the state-changing routes. Each one needs authentication, authorisation of the object, and a CSRF defence.
- Check the identity code. How are passwords stored, how are sessions made and ended, what does a failed login say?
- Look at the configuration. Cookies, headers, CORS, error output, and anything in the source that looks like a key.
- Ask what the server can reach. Anything that fetches a URL, opens a file or runs a command on somebody else’s say-so.
Naming a finding
"This is insecure" starts an argument. A location, a mechanism, a consequence and a fix starts a pull request — and the consequence is the part that gets it prioritised.
{
where: "GET /api/orders/:id",
what: "idor — any logged-in user can read any order",
how: "an attacker increments the id and exports the customer base",
fix: "scope the query by req.user.customerId, and answer 404 when it misses",
}What this lab is
One application, described as data: its routes, its cookies, its headers, how it stores passwords, what it does with uploads, and one feature that fetches a URL. Nine problems are in there, one for each of the main lessons in this course. Write the reviewer that finds them.