5 ms·

So you're saying that poorly-designed applications wouldn't work properly sometimes.

by windsurfer 13y ago

mherkender 13y ago
Poorly designed applications like this one? https://accounts.google.com/Logout https://accounts.google.com/Logout
- jodrellblank 13y ago
  Yes. What's your point? Google must be incapable of poor design? Everything a big company does is good?
  - mherkender 13y ago
    I wanted to know what HN consensus was on this sort of thing, because it seems to me this is not something that inexperienced programmers do (like SQL injection). Also, full disclosure: I work for Google.
- windsurfer 13y ago
  Yes. Imagine if everyone put the following code on their sites: <iframe src="https://accounts.google.com/Logout" width="0" height="0" ></iframe>
  - snikch 13y ago
    I believe that would be the point of <meta http-equiv="X-Frame-Options" content="deny">
    - codygman 13y ago
      That's like trying to duct tape your arm back on after losing a fight with a chainsaw.
    - mike-cardwell 13y ago
      <img src="https://accounts.google.com/Logout" https://accounts.google.com/Logout" style="display:none"> "X-Frame-Options" is used to defend against click-jacking attacks, not to defend against CSRF.
  - mike-cardwell 13y ago
    You could do the same with a POST by just running the following in a hidden iframe on your site: <form id="form" method="post" action="https://accounts.google.com/Logout"></form> <script>$('#form').submit()</script> The correct way of dealing with this issue is to rely on CSRF tokens.
hnriot 13y ago
this isn't poorly designed, there are the web specs and then there's the web itself and if it works then the spec need updating, there's no law that post should be used for session state, that was just someone writing it into an RFC, the fact that GET works just fine and a significant population of web apps use GET that way makes it reality more than any spec does.
- windsurfer 13y ago
  Read a bit more about how this is a problem at http://abielinski.com/logout http://abielinski.com/logout
  - codygman 13y ago
    You got me :) This is the very essence of the problem.
  - ben0x539 13y ago
    Sweet, RequestPolicy protected me. ;)
- codygman 13y ago
  Just because using GET to do destructive things "works" doesn't mean the spec should be changed to allow it. By your logic, we should just get rid of all requests except GET. Someone sends you a link, you click it, it loads in your web browser telling you that you've sent them $5000. That is why POST, PUT, OPTIONS, and all the other methods exist. This is most certainly poorly designed. Just because most web apps and web app developers suck doesn't mean that the freaking HTTP Standard should be changed. Just no... please stop.

So you're saying that poorly-designed applications wouldn't work properly sometimes.

mherkender 13y ago

Poorly designed applications like this one? https://accounts.google.com/Logout https://accounts.google.com/Logout

jodrellblank 13y ago
Yes. What's your point? Google must be incapable of poor design? Everything a big company does is good?
- mherkender 13y ago
  I wanted to know what HN consensus was on this sort of thing, because it seems to me this is not something that inexperienced programmers do (like SQL injection). Also, full disclosure: I work for Google.
windsurfer 13y ago
Yes. Imagine if everyone put the following code on their sites: <iframe src="https://accounts.google.com/Logout" width="0" height="0" ></iframe>
- snikch 13y ago
  I believe that would be the point of <meta http-equiv="X-Frame-Options" content="deny">
  - codygman 13y ago
    That's like trying to duct tape your arm back on after losing a fight with a chainsaw.
  - mike-cardwell 13y ago
    <img src="https://accounts.google.com/Logout" https://accounts.google.com/Logout" style="display:none"> "X-Frame-Options" is used to defend against click-jacking attacks, not to defend against CSRF.
- mike-cardwell 13y ago
  You could do the same with a POST by just running the following in a hidden iframe on your site: <form id="form" method="post" action="https://accounts.google.com/Logout"></form> <script>$('#form').submit()</script> The correct way of dealing with this issue is to rely on CSRF tokens.

hnriot 13y ago

this isn't poorly designed, there are the web specs and then there's the web itself and if it works then the spec need updating, there's no law that post should be used for session state, that was just someone writing it into an RFC, the fact that GET works just fine and a significant population of web apps use GET that way makes it reality more than any spec does.

windsurfer 13y ago
Read a bit more about how this is a problem at http://abielinski.com/logout http://abielinski.com/logout
- codygman 13y ago
  You got me :) This is the very essence of the problem.
- ben0x539 13y ago
  Sweet, RequestPolicy protected me. ;)
codygman 13y ago
Just because using GET to do destructive things "works" doesn't mean the spec should be changed to allow it. By your logic, we should just get rid of all requests except GET. Someone sends you a link, you click it, it loads in your web browser telling you that you've sent them $5000. That is why POST, PUT, OPTIONS, and all the other methods exist. This is most certainly poorly designed. Just because most web apps and web app developers suck doesn't mean that the freaking HTTP Standard should be changed. Just no... please stop.