[159745] in North American Network Operators' Group
Re: Suggestions for the future on your web site: (was cookies, and
daemon@ATHENA.MIT.EDU (Matt Palmer)
Sat Jan 19 18:09:00 2013
Date: Sat, 19 Jan 2013 14:45:31 +1100
From: Matt Palmer <mpalmer@hezmatt.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <20130117145559.27BDF566@resin13.mta.everyone.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Thu, Jan 17, 2013 at 02:55:59PM -0800, Scott Weeks wrote:
> ------- mpalmer@hezmatt.org wrote: -------
> From: Matt Palmer <mpalmer@hezmatt.org>
> [Cookies on stat.ripe.net]
>
> On Wed, Jan 16, 2013 at 11:36:25AM -0800, Shrdlu wrote:
> > The cookie stays around for a YEAR (if I let it), and has the
> > following stuff:
>
> CSRF protection is one of the few valid uses of a cookie.
> <snip>
> By the way, if anyone *does* know of a good and reliable way to prevent CSRF
> without the need for any cookies or persistent server-side session state,
> I'd love to know how. Ten minutes with Google hasn't provided any useful
> information.
> -----------------------------------------
>
> But, if I understand correctly, it only only if you are authenticated can
> anything bad be made to happen:
>
> https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
[...]
> So, if someone is just looking around, why is the cookie needed?
Primarily abuse prevention. If I can get a few thousand people to do
something resource-heavy (or otherwise abusive, such as send an e-mail
somewhere) within a short period of time, I can conscript a whole army of
unwitting accomplices into my dastardly plan. It isn't hard to drop exploit
code on a few hundred pre-scouted vulnerable sites for drive-by
conscription.
- Matt
