NOTES ON OFFENSIVE SECURITY
TheBug
Code
Rules applications
learn the hard way.
AN OFFENSIVE SECURITY CASEBOOK
The rule is short.
The proof follows.
Real findings, written as a collection of rules: what the application assumed, where that assumption failed, and what the evidence showed.
Each article follows one case from behavior to impact, with code models, diagrams, and the checks that should have been there.
Browse the casebook ↓Contents.
THE BUG CODEBrowse by mechanism, or follow the articles in order from 01 to 09.
Injection and server-side behavior
When input changes what the server parses, requests, or executes.
Server-side template injection
A template shall not promote its author.Server-side template injection: brace-free QWeb syntax passed the WAF, then exposed privileged database reads and writes.
Read the case study ↗RULE 02Path-only SSRF and error disclosure
An identifier shall not choose the route.Path-only SSRF: a product ID redirected a backend request to an internal staff directory, then a decoding error exposed the response.
Read the case study ↗RULE 03SAML XML external entity injection
A signature shall not vouch for what the parser swallowed.Unauthenticated XXE in SAML: local DTD reuse turned a signed error response into a server-file disclosure channel.
Read the case study ↗Identity and access
Who the caller is, and what that identity is allowed to do.
Account identity confusion
A valid token shall speak for one account only.Account impersonation through email normalization: distinct authenticated subjects resolved to the same application account.
Read the case study ↗RULE 05Missing cloud API authorization
A service shall not lend its privileges to strangers.Missing API authentication: cloud-identity-backed processing and a signed diagnostic link exposed internal error data.
Read the case study ↗RULE 06Invitation hijacking
An invitation shall admit its recipient. Nobody else.Privilege escalation through invitation hijacking: a missing recipient check assigned an administrator role to a different account.
Read the case study ↗Business logic and data exposure
Trusted calculations, searchable secrets, and unsafe storage.
Future-price manipulation
The shopper shall not set the clock.Pricing logic abuse: a guest-writable shopper context activated a scheduled future discount in the product response and basket.
Read the case study ↗RULE 08Wildcard identifier disclosure
A mask shall not answer questions about what it hides.LIKE-wildcard injection: a public leaderboard masked account numbers in its output but let search filters test the hidden digits.
Read the case study ↗RULE 09Password storage in cookies
Remember the device. Forget the password.Recoverable password storage: a remember-me cookie retained a Base64-encoded password for 180 days, readable by page scripts.
Read the case study ↗