On Mon, Feb 27, 2012 at 6:17 PM, Richard Lynch <c...@l-i-e.com> wrote:
> On Fri, February 24, 2012 4:48 pm, Ronald Chmara wrote: > > On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield > > <la...@garfieldtech.com> wrote: > >>> To me, it's just a request for some content, and in a REST API > >>> that's > >>> read-only, I just don't care if the consumer sends their request as > >>> GET or POST. I'll cheerfully give them what they wanted. > >> Except that per HTTP, GET and POST are completely different > >> operations. One > >> is idempotent and cacheable, the other is not idempotent and not > >> cacheable. > >> I very much care which someone is using. > > > > People exploiting security would *never* think of > > caching/replaying/modifying a POST request, that's just totally > > unimaginable! It would take, like HUGE computational effort to like, > > cURL it or just type it out! > > You missed the totally newbie way, or at least a way to demonstrate > the issue to somebody who simply doesn't understand the issue: > Save the HTML form to your hard drive. > Edit it in Notepad (et al) to make up whatever value="xyz" you want. > Open it in your browser using "Open File..." and pick the file. > Submit the FORM. > > I had to do this several times for non-technical bosses or students > who simply refused to believe that it was TRIVIAL to forge POST > requests... > > Once they saw it in action, the light bulb goes "on" and you can say: > I can also script this to repeat the same thing a million times with > form-letter substitution, and then they understand it *is* trivial. > > Maybe I just had dense bosses/students, or I was bad at explaining the > idea, but it worked for me... > > changing the method in curl is even easier. you both missed the fact that Larry is aware of the fact that POST is forge-able. there are cases when you can improve your security model (even by a little bit) if you don't allow the method to be interchangeable. for example: if I have an XSS vulnerability on bugs.php.net, it is much easier for me to trick the devs clicking on the link if the said vuln is exploitable through GET. if it can only be exploited through POST, I have to set up a page somewhere with a POST form, pointing to the vulnerable url, and ask the said devs to visit that url and submit the form (or have javascript enabled, so that I can submit if for them). exploiting the reflected vulnerabilities is much easier if you can do it through GET. ps: if you don't know what did Larry mean by the Idempotent method, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1 -- Ferenc Kovács @Tyr43l - http://tyrael.hu
