Valve and HackerOne: how not to handle vulnerability reports
I think Valve and HackerOne handled this poorly, but I think the author is partially at fault for repeatedly failing to communicate the issue clearly.I worked as a penetration tester for a while, and I had trouble understanding what the author was saying. The headline should have been that the steam mobile app makes requests to the plaintext HTTP URL (http://store.steampowered.com) instead of the TLS-authenticated URL (https://store.steampowered.com). Without TLS, an attacker can impersonate the Steam store server and steal credit cards or trick users into installing malicious apps.The author reported this as:>The vulnerability is that an attacker can perform a man in the middle attack by spoofing an HTTP request pretending to be from store.steampowered.com. While the client does check for an eventual HTTPS redirect, it can redirect to an HTTPS URL.There's so much ambiguity and missing information in that writeup:* Who does the attacker send an HTTP request to? I think the author meant to say an HTTP response.* In "it can redirect," does the word "it" refer to the "the client" or 
"redirect?"* I think "it can redirect to an HTTPS URL" was supposed to be "any HTTPS URL."* Why is the client vulnerable? What should they be doing instead?Also, the author's exploit scenario is to just make the Steam app load his portfolio page, which might have further muddled things. It sounds inconsequential that an attacker can trick Steam users into visiting a developer's portfolio page. It might have been a clearer report if the proof-of-concept redirected to a website that looked like the Steam store but had a warning saying, "I'm an evil copy of the Steam store that will steal your credit card number."