On Sun, 2010-04-04 at 14:06 +0300, Eddy Nigg wrote:
> On 04/04/2010 01:49 PM, Matt McCutchen:
> >> Which is simply another user input (modifiable by the user).
> >>
> > That's irrelevant. The Referer is an effective XSRF defense because a
> > malicious site cannot spoof a Launchpad referrer
On 04/04/2010 01:49 PM, Matt McCutchen:
Which is simply another user input (modifiable by the user).
That's irrelevant. The Referer is an effective XSRF defense because a
malicious site cannot spoof a Launchpad referrer when sending a request
to Launchpad.
Huuu? And why not?
See t
On Sun, 2010-04-04 at 13:07 +0300, Eddy Nigg wrote:
> On 04/04/2010 07:44 AM, Matt McCutchen:
> > Such configurations are uncommon, but they are not intrinsically
> > unreasonable. Sites that put parameters in URI path components are
> > likely to keep the same approach for their write requests.
On 04/04/2010 07:44 AM, Matt McCutchen:
Such configurations are uncommon, but they are not intrinsically
unreasonable. Sites that put parameters in URI path components are
likely to keep the same approach for their write requests. For example,
but for Launchpad's refusal of client-initiated ren
On Wed, 2010-03-31 at 18:48 +0300, Eddy Nigg wrote:
> On 03/31/2010 04:45 PM, Kai Engert:
> > == snip quote begin ==
> > E.g., the attacker would send:
> >
> > GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
> > X-Ignore-This:
> >
> > And the server uses the victim's account
5 matches
Mail list logo