3 posts tagged with "Mass Assignment"

Proof of exploitability, or it didn't happen​

One of the most pervasive problems in cybersecurity is false positives. Organisations receive dozens of bogus vulnerability reports about their websites every day, and security teams burn hours trudging through the noise that automated scanners generate. Worse, CISOs can't prioritise what actually matters, because a false positive is so often hard to tell apart from a real finding.

How did we go so wrong? The ingredient missing from a false positive is proof of exploitability, and a rigorous one at that. Proof of exploitability, also called chain-of-attack proof, is one of the most important elements of any vulnerability report. Without it, a penetration testing report isn't worth your money. Reliable bug bounty platforms like HackerOne place heavy emphasis on proving a vulnerability is exploitable; without that ingredient, a report simply doesn't have a case.

Most downstream consequences of prompt injections in agentic systems are caused by confused deputy problems, where an AI model treats untrusted input as authoritative instructions. Since there's no solution for prompt injection (yet), AI agents are now entering deterministic, provenance-based trust models using integrity labels to defend against untrusted (potentially malicious) actors influencing actions. But every label-based security system lives or dies on one question: when something claims to be trusted, who's actually vouching for it? Get that part right and you have SPF, DKIM, TLS, decades of infrastructure that just works. Get it wrong and you have spoofed email, forged certs, and a rather unpleasant afternoon.

In March 2012, Egor Homakov performed one of the most famous exploits in application security history: he acquired write rights to Ruby on Rails's GitHub repository and committed directly to its master branch. The commit is still visible for all to see (here). How was Homakov able to do this? He exploited a vulnerability in GitHub's API that allowed him to overwrite arbitrary server-side properties. Specifically, he bound his own SSH key to the profile of another user with commit rights to Ruby on Rails's repository.