Local law in EU which I assumed that most knew about http://www.cookielaw.org/about-this-message.aspx

this says what you must do if you want to feed the client a cookie. it does not mandate feeding them a cookie. in fact, it would seem to suggest that you might do so only if you really must. randy

Don't most browsers accept all cookies by default without asking the user?

no idea, but i think most browsers today block at least third party cookies by default. randy

On Jan 12, 2013, at 8:50 PM, Andrew Latham <lathama@gmail.com> wrote:

On Sat, Jan 12, 2013 at 11:06 PM, Randy Bush <randy@psg.com> wrote:

...

...

RIPE needs to fix on their web site:

"Please turn on the cookies on your browser to view this site."

It doesn't have to be this way...

it should not be this way

randy

Local law in EU which I assumed that most knew about http://www.cookielaw.org/about-this-message.aspx

The law requires notification _IF_ you use cookies. It does _NOT_ require use of cookies which is what I believe the original objections were. Owen

On 1/16/2013 9:40 AM, john wrote:

I took a look at this site and unfortunately the use of cookies is very ingrained into the code. Removing the requirement breaks all functionality of www.ris.ripe.net and changing the functionality would require a rewrite of the site.

Sooner or later, you'll get to a place where you consider a major update, and perhaps then you'll consider emulating NANOG's site. However...

Our intention is that http://stat.ripe.net/ will replace all functionality currently under www.ris.ripe.net. If RIPEstat doesn't provide the functionality you are looking for, please request it by emailing us at stat@ripe.net.

I was curious, and I went to look at it. Please consider using some other color than lovely amber yellow you've chosen. It's very pretty, and exhausting to look at for any length of time. I'm a HUGE fan of gray scales, and of text. I see that you want a cookie when I want to look at one of the videos, but blocking it doesn't hurt me. Here's where you did something right. The video plays on my (pretty old) Firefox, which has no Flash (hooray!). The cookie stays around for a YEAR (if I let it), and has the following stuff: Name: stat-csrftoken Content: 7f12a95b8e274ab940287407a14fc348 Host: stat.ripe.net Path: / Send For: Any type of connection Expires: Wednesday, January 15, 2014 11:29:34 AM To your credit, you only ask once, but you ought to ask zero times. The site's not bad, but please consider changing the yellow to black. Less beauty, more utility. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. Brian W. Kernighan

[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:

Name: stat-csrftoken Content: 7f12a95b8e274ab940287407a14fc348

[...]

To your credit, you only ask once, but you ought to ask zero times.

CSRF protection is one of the few valid uses of a cookie. It shouldn't need to be set on every page, though, and it should be cleared immediately after the form submission. It's typically a lot easier in the site code just to set it once and be done with it. 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. - Matt

On Fri, Jan 18, 2013 at 09:41:41AM +0100, . wrote:

On 17 January 2013 23:38, Matt Palmer <mpalmer@hezmatt.org> wrote: ..

...

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.

I think many people create <forms> with a secret code that is different and hopefully can't be predicted by the attackers.

<form method="post"> <input type="hidden" name="id_user" value="33"> <input type="hidden" name="action" value="delete_user"> <input type="hidden" name="secret" value="5ebe2294ecd0e0f08eab7690d2a6ee69"> <input type="submit" value="Delete user"> </from>

The easy way to do this is to generate secret from the md5 if time in miliseconds + a salt string, and store the secret generated serverside.

Storing any state server-side is a really bad idea for scalability and reliability.

But if you don't want to store this secret key anywhere in the server, you can relie in security by obscurity, and generate it by a predictible algorithm, like md5( year + "_SALT_" + id_user +day_of_year). A attacker can figure out the algorithm, or it can be leaked, but if your site is small, and don't protect anything important, it will stop the 100% of the attackers anyway.

It doesn't even have to be broken -- it isn't going to take long for an attacker to notice that your "security token" doesn't change every time, and work out how often it does change, then plan their attacks around that. If you make the change frequency greater, then you're increasing the risk of rejecting valid submissions when the token rolls over. To avoid that, you need to start checking against a set of token values, which need to be recalculated every time or stored somewhere for use later. It's not particularly surprising that people go instead for the quick and easy "drop in a cookie and compare the value with the form submission" option. And by the way, I wouldn't be so confident about being small avoiding the miscreants. Those "Pay us $1k or we'll DoS you off the Internet and send you broke" scam merchants are going after smaller and smaller targets, as there's more of them and they're completely unable to afford other effective forms of protection. - Matt

On Sat, Jan 19, 2013 at 03:54:37PM -0800, George Herbert wrote:

On Jan 18, 2013, at 7:52 PM, Matt Palmer <mpalmer@hezmatt.org> wrote:

...

On Fri, Jan 18, 2013 at 09:41:41AM +0100, . wrote:

...

On 17 January 2013 23:38, Matt Palmer <mpalmer@hezmatt.org> wrote: ..

...

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.

I think many people create <forms> with a secret code that is different and hopefully can't be predicted by the attackers.

<form method="post"> <input type="hidden" name="id_user" value="33"> <input type="hidden" name="action" value="delete_user"> <input type="hidden" name="secret" value="5ebe2294ecd0e0f08eab7690d2a6ee69"> <input type="submit" value="Delete user"> </from>

The easy way to do this is to generate secret from the md5 if time in miliseconds + a salt string, and store the secret generated serverside.

Storing any state server-side is a really bad idea for scalability and reliability.

?

Doing that - into a user state DB of sone sort, either external or in middleware, is routine...

It may be routine, but it is an additional point of failure, and it is also an additional scaling bottleneck. If all you ever run are tiny sites with little chance of ever seeing big loads, sure, stick it in a DB somewhere. But if you ever think (or even hope) that your site will take off one day, it pays to think about these things and reduce the number of fires to put out by one. - Matt