On Wed, 23 Jan 2008 07:27:16 -0000, Ian Hickson <[EMAIL PROTECTED]> wrote:
HTML5 doesn't say anything about whether a referer should be sent with
the POST generated by <a ping>. There is a new attack vector <a ping>
opens (as currently being discussed on mozilla.dev.platform) that would
be blocked if the referer were not sent.
Fixed. I also said to not include Cookies or HTTP auth headers.
Legitimate uses can always include whatever information they want in the
ping=""
attribute's value itself.
Doesn't that kill use of ping for tracking ad clicks? I think ad providers
want to have cookies to track individual users across domains, and site
that serves <a> is unable to provide that. Maybe ping could allow only
cookies with a certain name/naming scheme?
I don't think that attack vector discussed on mozilla.dev.platform should
be taken so seriously. In my opinion case when <a ping> enables attack
(instead of being just one of countless possible attack vectors) is very
very unlikely:
- If site accepts data from GET as well as POST (e.g. is using PHP's
register_globals), then <a ping> is not needed at all -- a better attack
can be performed with simple <img src> or <a href>.
- If site allows HTML from untrusted source and allows ping to slip
through, it is very likely that the site can be tricked to allow other
potentially dangerous attributes or scripts.
- Because not all browsers/proxies/firewalls send Referer header,
public-facing websites have to accept POSTs without Referer, so forbidding
Referer for <a ping> may not increase security and even make it harder to
protect against CSRF.
OTOH Referer can help save bandwidth. Without it page may need to include
its own URL in every <a ping> attribute. On pages with lots of links
(portals, directories) this can noticeably increases size of HTML.
Maybe these problems could be solved with an additional HTTP header in the
ping request? e.g.:
X-Ping: from="http://example.com/here";, to="http://example.com/there";
This would make it easy to protect against unwanted ping-originated
requests (one could configure server or set up application firewall to
filter pings), and URL in <a ping> wouldn't have to contain copies of
page's URL and href.
--
regards, Kornel Lesiński
