Maciej Stachowiak wrote on 1/16/2009 4:40 PM:
> Such hotlinking is probably using a GET request, so no Origin header
> would be sent. I believe it is also outside the scope of the CSRF
> protection and cross-origin data sharing goals of Origin. The Referer
> header is still usable for hotlinking
On Jan 16, 2009, at 9:02 AM, Bil Corry wrote:
Maciej Stachowiak wrote on 1/15/2009 10:40 PM:
CONCLUSION: We should use a single Origin header with the name and
semantics of the Access-Control Origin header for both its
Access-Control purpose and for redirect defense. The differences in
the
Maciej Stachowiak wrote on 1/15/2009 10:40 PM:
> CONCLUSION: We should use a single Origin header with the name and
> semantics of the Access-Control Origin header for both its
> Access-Control purpose and for redirect defense. The differences in the
> HTML5 version are not worth the cost of a ve
Hixie said the position I expressed was a little unclear, so I'd like
to clarify briefly:
1) FACT: The HTML5 version of the CSRF-defense header (currently
called 'XXX-Origin' as a temporary measure) is specified not to be
sent for GET requests.
1.a) FACT: As a result, it does not pro
On Jan 15, 2009, at 7:24 AM, Bil Corry wrote:
Maciej Stachowiak wrote on 1/15/2009 12:47 AM:
So one thing to keep in mind is that any POST-based form would not be
vulnerable to this kind of attack unless the victim site actually
submits a form to an untrusted site. There is no way for a GET
On Thu, Jan 15, 2009 at 7:24 AM, Bil Corry wrote:
> Using XSS, an attacker could change the target of a login form to a MitM site,
If your site has XSS, there is nothing a CSRF defense can do to help you.
On Wed, Jan 14, 2009 at 10:47 PM, Maciej Stachowiak wrote:
> So one thing to keep in mind
Maciej Stachowiak wrote on 1/15/2009 12:47 AM:
> So one thing to keep in mind is that any POST-based form would not be
> vulnerable to this kind of attack unless the victim site actually
> submits a form to an untrusted site. There is no way for a GET request
> to be redirected to a POST, and it
On Jan 14, 2009, at 5:32 PM, Bil Corry wrote:
Maciej Stachowiak wrote on 1/14/2009 6:14 PM:
Why does the CSRF defense header need to change on redirect?
Because to the site on the far end, it would appear the request came
from somewhere it didn't, effectively hiding the real source of th
Maciej Stachowiak wrote on 1/14/2009 6:14 PM:
> Why does the CSRF defense header need to change on redirect?
Because to the site on the far end, it would appear the request came from
somewhere it didn't, effectively hiding the real source of the request. This
probably explains it better:
---
On Jan 14, 2009, at 3:45 PM, Bil Corry wrote:
Adrian Bateman wrote on 1/14/2009 3:18 PM:
I actually don't think that the generic name is a problem as long
as the
CSRF solution uses a different name for a different meaning. The
value really
is an Origin and could potentially be used for mo
Adrian Bateman wrote on 1/14/2009 3:18 PM:
> I actually don't think that the generic name is a problem as long as the
> CSRF solution uses a different name for a different meaning. The value really
> is an Origin and could potentially be used for more than just participation
> in the Access Contr
On January 14, 2009 11:45 AM, Anne van Kesteren [mailto:ann...@opera.com] wrote:
> On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry wrote:
> > Jonas Sicking wrote on 1/14/2009 12:53 PM:
> >> The problem I think is that the current name, 'Origin', is extremely
> >> generic and so it's likely to cause
On Wed, Jan 14, 2009 at 11:45 AM, Anne van Kesteren wrote:
> On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry wrote:
>>
>> Jonas Sicking wrote on 1/14/2009 12:53 PM:
>>>
>>> The problem I think is that the current name, 'Origin', is extremely
>>> generic and so it's likely to cause confusion once
On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry wrote:
Jonas Sicking wrote on 1/14/2009 12:53 PM:
The problem I think is that the current name, 'Origin', is extremely
generic and so it's likely to cause confusion once we get other
headers containing origins.
That said, I do understand that thi
Jonas Sicking wrote on 1/14/2009 12:53 PM:
> The problem I think is that the current name, 'Origin', is extremely
> generic and so it's likely to cause confusion once we get other
> headers containing origins.
>
> That said, I do understand that this is a very late change for you
> guys. Develo
On Wed, 14 Jan 2009 19:53:42 +0100, Jonas Sicking wrote:
What do other people think?
If we really think they should be different (and at least Adam Barth
suggests that might not be needed) I would really like to rename this
header to make it consistent with the rest of the API. (Of course
On Wed, Jan 14, 2009 at 8:00 AM, Adrian Bateman wrote:
> I wanted to let the WG members know that we have completed our support for
> Access-Control in IE8 for the Simple Cross-Site Access Request. We support
> the Access-Control-Allow-Origin: * wildcard as we did in Beta 2 but in the
> next p
I wanted to let the WG members know that we have completed our support for
Access-Control in IE8 for the Simple Cross-Site Access Request. We support the
Access-Control-Allow-Origin: * wildcard as we did in Beta 2 but in the next
public release of IE8, our Release Candidate, we have also added
18 matches
Mail list logo
