On Wed, 13 Feb 2008, Kornel Lesinski wrote:
That's interesting. In that case attack outlined on Mozilla's list is
even less likely to succeed than I thought. So maybe a less abusive
approach would suffice:
* if ping is cross-domain, always send Referer
* if ping originates from the same
On Tue, 12 Feb 2008 21:54:25 -, Philip Taylor [EMAIL PROTECTED] wrote:
It's quite a different situation when the Referer is used as a security
measure in deciding to trust a user's request, where false negatives can
have significant consequences (like editing data via cross-site request
Ian Hickson wrote:
This e-mail is a response to all the recent ping= feedback.
I carefully took into account all the feedback mentioned below, as well as
past feedback and comments outside these mailing lists. In response to
these comments, I've made Referer: be #PING for all pings, and
This e-mail is a response to all the recent ping= feedback.
I carefully took into account all the feedback mentioned below, as well as
past feedback and comments outside these mailing lists. In response to
these comments, I've made Referer: be #PING for all pings, and added
Ping-From and
On Feb 2, 2008 8:59 PM, dolphinling [EMAIL PROTECTED] wrote:
Cookies and authentication headers I'm ambivalent about; no one's made a
persuasive case either way for them, and I haven't looked myself.
dolphinling
http://dolphinling.net/
The ability to log pings according to session data
On Feb 2, 2008 9:59 PM, dolphinling [EMAIL PROTECTED] wrote:
Ian Hickson wrote:
On Fri, 1 Feb 2008, Julian Reschke wrote:
Ian Hickson wrote:
What do people think of this idea:
We make Referer always have the value PING.
Referer takes a relative reference, or a URI. Not a good idea.
Darin Fisher wrote:
It's true that the Ping-From/To headers carry the important information,
but I suspect that sending a Referer header is nice for servers that
happen to receive unsolicited pings. Server logs will likely store the
value of the Referer header, and this way, site admins can
On Feb 1, 2008 2:45 PM, Julian Reschke [EMAIL PROTECTED] wrote:
Ian Hickson wrote:
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
On Fri, 1 Feb 2008, Julian Reschke wrote:
Ian Hickson wrote:
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
Ian Hickson wrote:
Interesting.
I see two ways forward here. One would be to redefine Referer to remove
the relative URI thing, since, to my knowledge at least, nobody uses it.
That's IMHO not sufficient reason to remove it. It's not broken.
The other is that we can define the magic value
Perhaps this has been suggested before, but another option is to use a
new verb, such as PING, instead of GET when making the request.
Servers unaware of the ping attribute will likely ignore this verb,
mitigating the request-forgery attack vector.
Adam
On Feb 2, 2008 2:13 PM, Julian Reschke
Ian Hickson wrote:
On Fri, 1 Feb 2008, Julian Reschke wrote:
Ian Hickson wrote:
What do people think of this idea:
We make Referer always have the value PING.
Referer takes a relative reference, or a URI. Not a good idea.
Interesting.
I see two ways forward here. One would be to redefine
On Fri, 01 Feb 2008 02:03:01 +0100, Darin Fisher [EMAIL PROTECTED] wrote:
I suppose that X-Ping-From/To should be striped (like Referer) when one
of those values is HTTPS and the ping attribute is non-HTTPS?
Given that HTML5 is now on standards track lets make it Ping-From and
Ping-To.
Ian Hickson wrote:
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.
What do people think of this idea:
We make
On Jan 30, 2008 12:33 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 23 Jan 2008, Darin Fisher wrote:
HTTP auth headers may be required to access the internet (e.g., to pass
a request through a proxy server), so this should only apply to the
Authorization request header, right?
On
On Wed, 23 Jan 2008, Darin Fisher wrote:
HTTP auth headers may be required to access the internet (e.g., to pass
a request through a proxy server), so this should only apply to the
Authorization request header, right?
On Thu, 24 Jan 2008, Kornel Lesinski wrote:
I don't think that attack
HTTP auth headers may be required to access the internet (e.g., to pass a
request through a proxy server), so this should only apply to the
Authorization request header, right?
-Darin
On Jan 22, 2008 11:27 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Tue, 22 Jan 2008, dolphinling 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.
--
The attack vector relies on the
On Tue, 22 Jan 2008, dolphinling 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.
19 matches
Mail list logo
