Here's some more data showing an announcement for
150.182.208.0/20 originated by 26347
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
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?
-Grant
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
> 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.
Most browsers accept any and all cookies by default.
Many browsers can be configured into three states (1) accept anything (2) reject third-party cookies (3) reject all cookies.
Many browsers can be configured to specifically accept or reject by domain (or have an add-in to do that) and the default can be either accept or (if reject) can nag you whether to accept/reject and remember that choice.
Advertizing agency browsers (such as the Android Advertizing Platform) default to accept and send anything to anyone, and you have the choice to either (1) accept and send anything to anyone or (2) accept and send only to the Advertizing Agency.
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
Hello Scott,
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. 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.
Regards
John
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.
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...
just for clarity, i believe that the issues with requiring cookies only
affects www.ris.ripe.net and not the entire *.ripe.net site(s). Im not
one of the developers however i believe they endeavour to keep the use
of cookies to a minimum with current and future development.
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 AMTo 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.
Thank you for this feedback, i'll pass it onto to the developers.
Regards
John
[Cookies on stat.ripe.net]
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
..
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. 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.
..
> 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
?
Doing that - into a user state DB of sone sort, either external or in middleware, is routine...
George William Herbert
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
I'm talking about multimillion user sites...
I designed the hosting infrastructure for one and have been a consulting architect later in the site lifecycle for several others...
George William Herbert