4 ms·

> If you replaced it with anything but a https://.steampowered.com https://.steampowered.com, the app would refuse to load the URL, so I don't see the vulnera

> If you replaced it with anything but a https://*.steampowered.com https://*.steampowered.com, the app would refuse to load the URL, so I don't see the vulnerability. I’m going to take this as what the intention was when designing this solution. > 3. App verifies that the domain ends with "steampowered.com" and starts with "https://" https://" I’m going to take this to be what would have actually been coded in this solution. I’m now going to register notsteampowered.com, and bypass the bug in the code to deliver an exploit over https. This solution is fragile. Why not just do the whole thing over TLS to begin with and avoid this vulnerability in the first place?

mtlynch 7y ago
>I’m now going to register notsteampowered.com, and bypass the bug in the code to deliver an exploit over https. Yeah, that's a good point. That's my mistake in spitballing, but the vulnerability wouldn't exist in an implementation that properly checked the domain. Again, I 100% agree with you that it's fragile and not a good idea. I wouldn't design a system this way, and I would flag it if I reviewed an app that did this. I was just objecting to the idea that the discovery of any plaintext HTTP request is a bounty-worthy vulnerability.