- From: Kornel Lesinski <kornel@geekhood.net>
- Date: Sun, 28 Oct 2007 19:48:58 -0000
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "public-html@w3.org" <public-html@w3.org>
On Fri, 26 Oct 2007 13:04:31 +0100, Julian Reschke <julian.reschke@gmx.de> wrote: > I'd like to understand why POST was selected for that. POST is an unsafe > method, and it shouldn't be sent without the consent of the user -- in > particular not if the target is on a different server. OTOH ping is all about creating side-effects, and only non-safe methods should cause them. I too was initially shocked that this might be a "CSRF-heaven", but after a second thought I think changing method won't noticeably improve security: * any website can automatically POST a form using script to any other website, and this can't be blocked without breaking lots of legitimate websites (sadly the worst offenders are banks providing easy-to-integrate payment gateways) * any website can trick user into clicking submit button that sends POST to another site (image buttons or CSS can disguise button as a link) * sites trying to filter-out any unsafe HTML from user input can either do it right (only allow known safe elements, attributes and their values) or are doomed to fail. There are sooo mind-numbingly many ways for injecting scripts (http://ha.ckers.org/xss.html) that <a ping> isn't even interesting. * ping doesn't allow sending any payload. This severly limits usefulness of it for CSRF attacks and makes it easy for websites to protect against it. Therefore I think using GET or HEAD for <a ping> won't make a difference -- in every case where <a ping> could be abused, other mechanism could be abused easier and with better (for attacker) results. The root cause why using POST is unsafe is CSRF, and there should be a separate effort dealing with that (covering all cases, not only ping). -- regards, Kornel Lesinski
Received on Sunday, 28 October 2007 19:49:29 UTC