3 ms·
I'm not sure server-side request forgery needs to be its own category where request forgery covers things from all sides. Server-side attacks are more common a
by dspillett 5y ago
I'm not sure server-side request forgery needs to be its own category where request forgery covers things from all sides.
Server-side attacks are more common as systems get more complex and have many moving parts that need be able to trust each other (in microservice architectures for instance), but failing to account for forgery at all levels is more a security-in-depth failure (fitting in the new very vague “insecure design” category?).
Unless I'm misunderstanding what is being meant here, which is far from impossible!
- billyhoffman 5y agoI mentally bucket Server-side request forgery separately from Client-side request forgery because of who it impacts. - With SSRF, I'm tricking your server-side system into requesting and returning to me something it shouldn't (local/intranet files, local/intranet network responses, the EC2 instance metadata endpoint). As a developer, SSRF can leak my app/infra/data/secrets to an outside attacker - With CSRF, I'm tricking a legit user into performing an authenticated action an existing application allows. Much closer to automated click-jacking.