<story><title>Valve and HackerOne: how not to handle vulnerability reports</title><url>https://blog.jakegealer.me/valve-a/</url></story><parent_chain></parent_chain><comment><author>mtlynch</author><text>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.&lt;p&gt;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 (&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;store.steampowered.com&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;store.steampowered.com&lt;/a&gt;) instead of the TLS-authenticated URL (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;store.steampowered.com&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;store.steampowered.com&lt;/a&gt;). Without TLS, an attacker can impersonate the Steam store server and steal credit cards or trick users into installing malicious apps.&lt;p&gt;The author reported this as:&lt;p&gt;&amp;gt;&lt;i&gt;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.&lt;/i&gt;&lt;p&gt;There&amp;#x27;s so much ambiguity and missing information in that writeup:&lt;p&gt;* Who does the attacker send an HTTP request to? I think the author meant to say an HTTP &lt;i&gt;response&lt;/i&gt;.&lt;p&gt;* In &amp;quot;it can redirect,&amp;quot; does the word &amp;quot;it&amp;quot; refer to the &amp;quot;the client&amp;quot; or 
&amp;quot;redirect?&amp;quot;&lt;p&gt;* I think &amp;quot;it can redirect to &lt;i&gt;an&lt;/i&gt; HTTPS URL&amp;quot; was supposed to be &amp;quot;&lt;i&gt;any&lt;/i&gt; HTTPS URL.&amp;quot;&lt;p&gt;* &lt;i&gt;Why&lt;/i&gt; is the client vulnerable? What should they be doing instead?&lt;p&gt;Also, the author&amp;#x27;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&amp;#x27;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, &amp;quot;I&amp;#x27;m an evil copy of the Steam store that will steal your credit card number.&amp;quot;</text></comment>
<story><title>Valve and HackerOne: how not to handle vulnerability reports</title><url>https://blog.jakegealer.me/valve-a/</url></story><parent_chain></parent_chain><comment><author>Saaster</author><text>Companies receive so many &amp;quot;First, you have to be on the other side of this airtight hatch, then you...&amp;quot; reports that anything that looks even remotely like it will just get summarily closed. My personal favorite ones start with some form of &amp;quot;I copied the user&amp;#x27;s cookies from device A&amp;#x27;s file-system, and...&amp;quot;&lt;p&gt;Just some suggestion on how to report these kind of things, because there is an actual underlying issue here worth fixing. It&amp;#x27;s good that you didn&amp;#x27;t mention the reverse proxy. Next, don&amp;#x27;t say &amp;quot;spoofing an HTTP request&amp;quot; in your first sentence of the report, that&amp;#x27;s an immediate red flag. If you have access to spoof something on the network, it&amp;#x27;s already not an issue for 99% of people and an instant low priority. Instead, say &amp;quot;Steam insecurely relies on a redirect response to upgrade the hosted content from HTTP to HTTPS, instead of directly establishing the HTTPS connection&amp;quot;. How this can be exploited is now much more general than just being a spoofing issue, with both the problem and solution clearly stated.</text></comment>