Comment by driverdan | Hacker News Reader

Comment by driverdan | Hacker News Reader

They're not new attact vectors but I enjoy Egor's posts and call outs. If you're a web dev making these mistakes then you need to take the time to learn about basic web security. You can't count on frameworks to abstract it all away for you, you have to understand how it works.

The same CSRF rules apply to GET and POST requests. If you're using proper CSRF protection it doesn't really matter if you do a GET or POST. The only real difference is that GET requests will be visible to every piece of hardware between the user and your server whether you're using SSL or not and will most likely be logged. Also you can upload files via POST.

While it's easier to make users send harmful GET requests by putting the URL in an image you can simply use JS to POST a hidden form. Thinking POST is inherently more secure is a false assumption. Both are equally vulnerable to CSRF.

Just FYI, the entire HTTP request is encrypted with SSL, including the URL. Otherwise https://www.google.com/?q=sensitive+query would be pretty pointless!

Oops, you're right. The only data exposed would be the hostname and port. Any query data would be encrypted.

I am not 100% convinced. I would have thought GET would be slightly less secure than POST. You use the JS example. If I were running NoScript or something where JS didn't work someone could use <img src="follow?username=value" > and it would run. While if it used POST, it would be slightly more secure (for a user being exploited).

It's entirely possible I mis-understand the whole thing and please correct me if I am wrong (and explain why).

Are you sure that ssl exposes url? I was under the impression that the connection handshake happened before any of the rest of the http protocol.

you just rewrote my post in other words. Of course I know how to send POST and I call this a little bit "new" vector only because even good developers(check showcases to make sure) use 'match' and forget to specify :via. And it looks OK to them because they miss the point - all GET requests skip protect_from_forgery filter in Rails - this is how it works.

>If you're a web dev making these mistakes then you need to take the time to learn about basic web security.

Honestly, I didn't say it loudly but I meant it. Not understanding GET/POST makes person low skilled dev.

> all GET requests skip protect_from_forgery filter in Rails

Now that's interesting, I wasn't aware of that. It makes sense due to the Rails convention being GET is only for fetching data. So this does make GET more insecure than POST for Rails.

Reply on news.ycombinator.com