3 ms·
It's frequently scarier than that. I've seen applications do the right thing by IDs and queries, but then attempt to audit access and not correctly escape or sa
by buro9 11y ago
It's frequently scarier than that. I've seen applications do the right thing by IDs and queries, but then attempt to audit access and not correctly escape or sanitise HTTP headers.
Literally, every single piece of information that an application receives is not to be trusted. Even if it's something you think you have set and have full control of (a cookie value), you're wrong... you have no control, and attackers can and will manipulate every field or property to gain a foothold.
- buro9 11y agoActually, case in point... X-Forwarded-For. This is not in a spec, people are using it as an unofficial standard. But so long as your edge removes it and then sets it... you're good. Except Google are doing their page speed optimisation thing in the style of the Opera Mini proxy, but for Chrome users on Android. Google have chosen to populate X-Forwarded-For, so any website that wants to audit the IP address of an end user now has to read this untrusted header. So devs will realise this, look at the header, stop stripping it at the edge, and start trusting what is essentially a string that anyone can set.
- xena 11y agoI like the way IRC networks handle this, they use a pre-connection protocol verb called WEBIRC (de-facto standard documented here: http://git.io/vBLYp http://git.io/vBLYp) that also enforces a whitelist of ip address + password combination. This stops most abuse of this feature. Maybe HTTP servers should have something similar.