
This book is a practical guide to discovering and exploiting security flaws in web applications. The authors explain each category of vulnerability using real-world examples, screen shots and code extracts. The book is extremely practical in focus, and describes in detail the steps involved in detecting and exploiting each kind of security weakness found within a variety of applications such as online banking, e-commerce and other web applications. The topics covered include bypassing login mechanisms, injecting code, exploiting logic flaws and compromising other users. Because every web application is different, attacking them entails bringing to bear various general principles, techniques and experience in an imaginative way. The most successful hackers go beyond this, and find ways to automate their bespoke attacks. This handbook describes a proven methodology that combines the virtues of human intelligence and computerized brute force, often with devastating results. The authors are professional penetration testers who have been involved in web application security for nearly a decade. They have presented training courses at the Black Hat security conferences throughout the world. Under the alias "PortSwigger", Dafydd developed the popular Burp Suite of web application hack tools.
Also more to your question, "The Browser Hacker's Handbook" and "The Web Application Hacker's Handbook" I also think are really helpful in understanding how browsers work. Sadly a not better documented subject.
Visiting the list of APIs on Mozilla's website is also helpful.
I 100% agree that people shouldn't design systems this way, and if I were still a pentester, I'd write it up if I found it. But if the implementation correctly checked the domain and verified it was https:// (and maybe did some cert pinning), I couldn't justify anything higher than low severity.
We've kind of gone way into the weeds on my made up example, but it was initially in response to this:
>> > I think the author is partially at fault for repeatedly failing to communicate the issue clearly.
> I disagree. The first sentence of the report includes "HTTP", "man in the middle attack" and "store.steampowered.com" ... If that isn't clear to someone, they are not sufficiently trained to triage vulnerability reports.
I just disagree with the idea that any plaintext HTTP request in an app inherently is a vulnerability.
Matasano used to mail it to all their potential candidates and told them to read chapters N throgh M.
Unfortunately I've forgotten the values of N and M, so just read the whole thing. It's worth the time.