Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On Wed, Jan 23, 2013 at 01:20:07PM +0100, . wrote: CAPTCHAS are a defense in depth that reduce the number of spam incidents to a number manageable by humans. No, they do not. If you had actually bothered to read the links that I provided, or simply to pay attention over the last several years, you would know that captchas are not any kind of defense at all. They're like holding up tissue paper in front of a tank: worthless. (Yes, yes, I'm well aware that many people will claim that *their* captchas work. They're wrong, of course: their captchas are just as worthless as everyone else's. They simply haven't been competently attacked yet. And relying on either the ineptness or the laziness of attackers is a very poor security strategy.) ---rsk
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On Thu, Jan 24, 2013 at 5:48 AM, Rich Kulawiec r...@gsp.org wrote: On Wed, Jan 23, 2013 at 01:20:07PM +0100, . wrote: CAPTCHAS are a defense in depth that reduce the number of spam incidents to a number manageable by humans. No, they do not. If you had actually bothered to read the links that I provided, or simply to pay attention over the last several years, you would know that captchas are not any kind of defense at all. They're like holding up tissue paper in front of a tank: worthless. (Yes, yes, I'm well aware that many people will claim that *their* captchas work. They're wrong, of course: their captchas are just as worthless as everyone else's. They simply haven't been competently attacked yet. And relying on either the ineptness or the laziness of attackers is a very poor security strategy.) ---rsk It's true that relying on the laziness of attackers is statistically useful, but as soon as one becomes an interesting enough target that the professionals aim, then professional grade tools (which walz through captchas more effectively than normal users can, by far) make them useless. I disagree that they're entirely ineffective. The famous Wiley cartoon (found also in the frontspiece of the original Firewalls book...) You have to be this tall to storm the castle does apply. But knowing the relative height and availability of storm-the-captcha tools is important. They are out there, pros use them all the time, they are entirely effective. -- -george william herbert george.herb...@gmail.com
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On 13-01-24 13:52, George Herbert wrote: It's true that relying on the laziness of attackers is statistically useful, but as soon as one becomes an interesting enough target that the professionals aim, then professional grade tools (which walz through captchas more effectively than normal users can, by far) make them useless. This is true. However, if CAPTCHAS stop the bulk of casual hacking attempts because the simple hacking scripts just flag that site as not worth the effort and move onto the next, then the site manager has to deal with far fewer true hacking attempts (those which are determined to get in or hurt your web site). It is better to have a tent with holes in the screen door than no screen door. If the damaged screen door still prevents 90% of mosquitoes from getting in, it does let you chase down and kill those that do get in. Just because a security technique is not bullet proof does not mean it isn't useful.
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On Thu, Jan 24, 2013 at 04:43:47PM -0500, Jean-Francois Mezei wrote: It is better to have a tent with holes in the screen door than no screen door. If the damaged screen door still prevents 90% of mosquitoes from getting in, it does let you chase down and kill those that do get in. I get this argument, but it seems to miss the point I was trying to make earlier. This isn't like a screen door with holes in it, but more like a screen door with holes in it and a trick hinge that, from time to time, bounces back and whacks the humans entering right in the nose. To resort to plain language instead of overworked metaphor, the problem with CAPTCHAs is that they're increasingly easier for computers to solve than they are for humans. This is perverse, because the whole reason they were introduced was that they were _hard_ for computers but _easy_ for humans. The latter part was a key design goal, and we are increasingly ditching it in favour of just using a CAPTCHA because they're what we think works. (Of course, this is really just a special case of the usual problems in HCI when security becomes an issue. We have this kind of problem with passwords too.) A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On Thu, Jan 24, 2013 at 8:48 AM, Rich Kulawiec r...@gsp.org wrote: (Yes, yes, I'm well aware that many people will claim that *their* captchas work. They're wrong, of course: their captchas are just as worthless as everyone else's. They simply haven't been competently attacked yet. And relying on either the ineptness or the laziness of attackers is a very poor security strategy.) So by this logic, the locks on your house (car/work/letterbox/cellphone/etc) are worthless too. Does that mean you leave your house unlocked? Scott.
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On 1/23/13, Rich Kulawiec r...@gsp.org wrote: On Mon, Jan 21, 2013 at 02:23:53AM -0600, Jimmy Hess wrote: Once again: captchas have zero security value. They either defend (a) resources worth attacking or (b) resources not worth attacking. If it's (a) then they can and will be defeated as soon as someone chooses to trouble themselves to do so. If it's (b) then they're not worth the effort to deploy. See, for example: See, you don't show they're not worth the effort to deploy in case (a). The CAPTCHA _might_ be attacked, only if the attacker perceives the value of resources worth attacking as higher than what the attacker believes the sum of their cost of the effort that will be required to defeat all the barriers resisting attack. The return on defeating the CAPTCHA, without defeat on other measures, will be pretty much zero, if it is reinforcing other security measures. And of course, you can revise the CAPTCHA, if your monitoring finds that it has been defeated, and abuse starts to occur, so the attacker has to break it again. It takes much less time commitment to develop new variations on a CAPTCHA than it it does to defeat novel variations. Now I'll grant that captchas aren't as miserably stupid as constructs like user at example dot com [1] but they really are worthless the [1] Such constructs are based on the proposition that spammers capable of writing and deploying sophisticated malware, operating enormous botnets, maintaining massive address databases, etc., are somehow mysteriously incapable of writing ... No, they are based on the proposition, that the obfuscation is unique enough to avoid detection, and spammers frequently search for something particularly obvious (e-mail addresses that don't require extra CPU cycles spent on trying many de-obfuscation techniques to parse). Any particular obfuscation would obviously lose value, if it became used frequently. I believe the specific one 'user at example dot com' is well-known due to its obviousness and use by certain Mail archive to HTML software, and therefore -- I would not recommend that particular method. For obfuscation methods to be most effective at blocking address harvesting, they should be novel, non-obvious. eg ' Email to username and atsign, this domain: example, dot, and then com. ' Of course... if any obfuscation method becomes very popular, or frequently used by a large number of documents (E.g. list archives of many/large public mailing lists), and the obfuscation technique will automatically become worthless, just because mailing list archives are such an attractive target for address harvesting, and a consistent obfuscation method for many addresses -- means the value of defeating that method becomes significant. -- -J
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On Mon, Jan 21, 2013 at 02:23:53AM -0600, Jimmy Hess wrote: that sort of abuse is likely need to be protected against via a captcha challenge as well, Once again: captchas have zero security value. They either defend (a) resources worth attacking or (b) resources not worth attacking. If it's (a) then they can and will be defeated as soon as someone chooses to trouble themselves to do so. If it's (b) then they're not worth the effort to deploy. See, for example: http://www.freedom-to-tinker.com/blog/ed-felten/2008/09/02/cheap-captcha-solving-changes-security-game http://www.physorg.com/news/2011-11-stanford-outsmart-captcha-codes.html http://arstechnica.com/news.ars/post/20080415-gone-in-60-seconds-spambot-cracks-livehotmail-captcha.html http://cintruder.sourceforge.net/ http://arstechnica.com/security/2012/05/google-recaptcha-brought-to-its-knees/ http://www.troyhunt.com/2012/01/breaking-captcha-with-automated-humans.html http://it.slashdot.org/article.pl?sid=08/10/14/1442213 Now I'll grant that captchas aren't as miserably stupid as constructs like user at example dot com [1] but they really are worthless the moment they're confronted by even a modestly clueful/resourceful adversary. ---rsk [1] Such constructs are based on the proposition that spammers capable of writing and deploying sophisticated malware, operating enormous botnets, maintaining massive address databases, etc., are somehow mysteriously incapable of writing perl -pe 's/[ ]+dot[ ]+/./g; s/[ ]+at[ ]*/@/g; print $_, \n;' and similar trivial bits of deobfuscation code.
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On 23 January 2013 09:45, Rich Kulawiec r...@gsp.org wrote: On Mon, Jan 21, 2013 at 02:23:53AM -0600, Jimmy Hess wrote: that sort of abuse is likely need to be protected against via a captcha challenge as well, Once again: captchas have zero security value. They either defend (a) resources worth attacking or (b) resources not worth attacking. If it's (a) then they can and will be defeated as soon as someone chooses to trouble themselves to do so. If it's (b) then they're not worth the effort to deploy. See, for example: CAPTCHAS are a defense in depth that reduce the number of spam incidents to a number manageable by humans. Not all bot writers have the same quality. A lot of them are crappy. Because of this, maybe are worth the effort. -- -- ℱin del ℳensaje.
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On Mon, 21 Jan 2013 23:23:16 -0500, Jean-Francois Mezei said: This article may be of interest: http://arstechnica.com/security/2013/01/canadian-student-expelled-for-playing-security-white-hat/ Basically, a Montreal student, developping mobile software to interface with schools system found a bug. Reported it. And when he tested to see if the bug had been fixed, got caugh and was expelled. I the context of this thread, they found a vulnerability in the web site's archutecture that allowed the to access any student's records. This is the perfect type of incident you can bring to your boss to justify proper architecture/security for your web site. How would you react if it was your company's name in the headline ? The interesting part is where the same people who were totally unaware that they had a major security hole until it was pointed out to them were also able to issue a very fast blanket denial that any student's information was in fact compromised. Sure, you can check your logs for the footprint of the attack - but apparently this wasn't actually being done before the student mentioned it to them. pgpD1goSCpTQ_.pgp Description: PGP signature
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On 1/21/13, Matt Palmer mpal...@hezmatt.org wrote: Nonce on the server is a scalability hazard (as previously discussed). You It's not really a scalability hazard. Not if its purpose is to protect a data driven operation, or the sending of an e-mail; in reality, that sort of abuse is likely need to be protected against via a captcha challenge as well, requiring scalability hazards such as performing image processing operations on the fly The logistical challenge with a nonce, is ensuring that the server generated and stored a long enough list of nonces for request load; you need to make sure that you never give out the same nonce twice, and you make sure you wipe out old sets of of nonces frequently, and then the only really hard part: when a nonce is used, you persist the fact that it is no longer valid. So you come to consider, the bottleneck: Persisting the fact that nonce X was used versus Sending this e-mail message orPosting entries to the database to complete the operation this form is supposed to do The operation this form is supposed to do will normally be the larger scalability hazard, usually involving more complicated database operations, than some nonce record maintenance. can't put a timestamp in a one-way hash, because then you've got to hash all possible valid timestamps to make sure that the hash the user gave you isn't one you'll accept. No, but you can use codevalue = at_timestamp:SHA1(secret:at_timestamp:submission_id:formaction:client ip) If current_time - at_timestamp X : require_resubmission The problem with this method, though, is that the only thing that stops the attacker from retrieving the entire chunk of data out of your form and Yeah... about that... if they can do that, they can surely steal a cookie, which persists, beyond the time the form is displayed in a browser. The adversary may be able to get the actual site to set the cookie in the unwitting user's browser by using an invisible IFRAME or other techniques, including ones to set a cookie for a different domain, circumventing the use of cookie as abuse prevention methods. The cookie is also susceptible to replay attack if something such as the client IP address is not a factor. Which is decidedly more user-friendly than most people implement, but suffers from the problem that some subset of your userbase is going to be using a connection that doesn't have a stable IP address, and it won't take That would be quite unusual, and would break many applications for that user... Although there is nothing mutually exclusive about cookies and other methods. It is possible to set a cookie to be used as an additional factor, after detecting that the user's IP address might be unstable. I just realised that I may have been insufficiently clear in my original request. I'm not looking for *any* solution to the CSRF problem that doesn't involve cookies; I'm after a solution that has a better cost/benefit than cookies. How about the issue that: cookies don't necessarily address CSRF? Cookies are OK for storing user preferences, but not to authenticate that the user actually authorized that their browser make that HTTP request. The user can have been browsing the form legitimately. The user unwittingly opens a malicious web page in another window, after having accessed the form recently. The required cookie is already set: the user might even have a logged in session, with an authentication cookie set in the browser. The malicious page can abuse an already-logged-in session by sending a POST request to it. Or have persuaded the user to login, while the malicious page is still in memory, and able to make quiet discrete POST requests. Cross-site POST operations are allowed operations; and the cookie was already set. On the other hand... a value in the form presented, should be protected against the malicious site, by the same origin policy. So perhaps if you need to use a value in the form anyways, the cookie is redundant -- -JH
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On 21 January 2013 07:19, Matt Palmer mpal...@hezmatt.org wrote: ... If the form is submitted without the correct POST value, if their IP address changed, or after too many seconds since the timestamp, then redisplay the form to the user, with a request for them to visually inspect and confirm the submission. Which is decidedly more user-friendly than most people implement, but suffers from the problem that some subset of your userbase is going to be using a connection that doesn't have a stable IP address, and it won't take too many random please re-confirm the form submission you made requests before the user gives your site the finger and goes to find something better to do. You want to stop the CSRF problem, but you want to support a user making the login in a IP, and submiting a delete account button *the next second* from a different IP. then you want this solution to be better cost effective than cookies. Maybe ask the user his password. form method=post input type=hidden name=id_user value=33 input type=hidden name=action value=delete_user input type=submit value=Delete user pFor this action you must provide the password. /p input type=password name=password value= /from Even if this request come from a IP in china, you can allow it. -- -- ℱin del ℳensaje.
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On 21 January 2013 09:26, . oscar.vi...@gmail.com wrote: On 21 January 2013 07:19, Matt Palmer mpal...@hezmatt.org wrote: ... If the form is submitted without the correct POST value, if their IP address changed, or after too many seconds since the timestamp, then redisplay the form to the user, with a request for them to visually inspect and confirm the submission. Which is decidedly more user-friendly than most people implement, but suffers from the problem that some subset of your userbase is going to be using a connection that doesn't have a stable IP address, and it won't take too many random please re-confirm the form submission you made requests before the user gives your site the finger and goes to find something better to do. You want to stop the CSRF problem, but you want to support a user making the login in a IP, and submiting a delete account button *the next second* from a different IP. then you want this solution to be better cost effective than cookies. Maybe ask the user his password. form method=post input type=hidden name=id_user value=33 input type=hidden name=action value=delete_user input type=submit value=Delete user pFor this action you must provide the password. /p input type=password name=password value= /from Even if this request come from a IP in china, you can allow it. So this solution can be read has: - Do nothing to avoid CSRF. - Except for destructive actions, where you ask for the password. -- -- ℱin del ℳensaje.
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
--- jfmezei_na...@vaxination.ca wrote: From: Jean-Francois Mezei jfmezei_na...@vaxination.ca Either way, you still need to have either a cookie or a hidden form [...] But ONLY when needing to do a transaction. As I originally mentioned why force a cookie just to look around: no cookie, no lookie. :-( scott
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
This article may be of interest: http://arstechnica.com/security/2013/01/canadian-student-expelled-for-playing-security-white-hat/ Basically, a Montreal student, developping mobile software to interface with schools system found a bug. Reported it. And when he tested to see if the bug had been fixed, got caugh and was expelled. I the context of this thread, they found a vulnerability in the web site's archutecture that allowed the to access any student's records. This is the perfect type of incident you can bring to your boss to justify proper architecture/security for your web site. How would you react if it was your company's name in the headline ?
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On Sat, Jan 19, 2013 at 03:54:37PM -0800, George Herbert wrote: On Jan 18, 2013, at 7:52 PM, Matt Palmer mpal...@hezmatt.org wrote: On Fri, Jan 18, 2013 at 09:41:41AM +0100, . wrote: On 17 January 2013 23:38, Matt Palmer mpal...@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
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On Jan 20, 2013, at 11:51 AM, Matt Palmer mpal...@hezmatt.org wrote: On Sat, Jan 19, 2013 at 03:54:37PM -0800, George Herbert wrote: On Jan 18, 2013, at 7:52 PM, Matt Palmer mpal...@hezmatt.org wrote: 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. 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 Sent from my iPhone
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On Sat, Jan 19, 2013 at 06:33:33PM -0600, Jimmy Hess wrote: On 1/18/13, Matt Palmer mpal...@hezmatt.org wrote: 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 You can prevent this without cookies. Include a canary value in the form; either a nonce stored on the server, or a hash of a secret key, timestamp, form ID, URL, and the client's IP address. Nonce on the server is a scalability hazard (as previously discussed). You can't put a timestamp in a one-way hash, because then you've got to hash all possible valid timestamps to make sure that the hash the user gave you isn't one you'll accept. You *can* put all those details into the form, then generate a HMAC (or symmetrically encrypt those details) to prevent tampering, but without server-side storage -- again, scalability hazard -- you can't prevent replay attacks (for as long as the timestamp is valid). The problem with this method, though, is that the only thing that stops the attacker from retrieving the entire chunk of data out of your form and tricking the client into submitting it is the client IP address. Now, you've got a decent idea here: If the form is submitted without the correct POST value, if their IP address changed, or after too many seconds since the timestamp, then redisplay the form to the user, with a request for them to visually inspect and confirm the submission. Which is decidedly more user-friendly than most people implement, but suffers from the problem that some subset of your userbase is going to be using a connection that doesn't have a stable IP address, and it won't take too many random please re-confirm the form submission you made requests before the user gives your site the finger and goes to find something better to do. I just realised that I may have been insufficiently clear in my original request. I'm not looking for *any* solution to the CSRF problem that doesn't involve cookies; I'm after a solution that has a better cost/benefit than cookies. Things that require me to worry (more) about scalability are out, as are things that annoy a larger percentage of my userbase than cookies (at least with cookies, I can say you're not accepting cookies, please turn them on, whereas with randomly resubmitting forms, I can't say please stop changing your IP address because that might not even be the problem). - Matt
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On 13-01-21 01:19, Matt Palmer wrote: Things that require me to worry (more) about scalability are out, as are things that annoy a larger percentage of my userbase than cookies (at least with cookies, I can say you're not accepting cookies, please turn them on, whereas with randomly resubmitting forms, I can't say please stop changing your IP address because that might not even be the problem). There comes a poimt when the user confirms the order where you have to store the data on your server. And store the credit card, send the transaction, store authorisation etc. If a person needs to login before proceeding, you will need to store some info in a server side database to indicate a valid session and timestamp of last transaction (so you can time out sessions at the server level) You need to update this record everytime the user does a transaction to reset the timeout and keep the session alive. Might as well store cart information in it too as more and more items are added. One advantage of server side storage is that you have a record of users abandonning their transactions, can look at possible trends that pont to something that causes customers to go away before completing transaction. This would be important informatioon to help improve the shopping experience. Either way, you still need to have either a cookie or a hidden form field for some session ID token. Advantage of cookie is that you can switch to a static page (when you display standard shipping iformation for instancem or a help page, and you don't have to convert all those pages to a form that sends the session ID as a hidden field.
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On Thu, Jan 17, 2013 at 02:55:59PM -0800, Scott Weeks wrote: --- mpal...@hezmatt.org wrote: --- From: Matt Palmer mpal...@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
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On Fri, Jan 18, 2013 at 09:41:41AM +0100, . wrote: On 17 January 2013 23:38, Matt Palmer mpal...@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
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On Jan 18, 2013, at 7:52 PM, Matt Palmer mpal...@hezmatt.org wrote: On Fri, Jan 18, 2013 at 09:41:41AM +0100, . wrote: On 17 January 2013 23:38, Matt Palmer mpal...@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... George William Herbert Sent from my iPhone
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On 1/18/13, Matt Palmer mpal...@hezmatt.org wrote: 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 You can prevent this without cookies. Include a canary value in the form; either a nonce stored on the server, or a hash of a secret key, timestamp, form ID, URL, and the client's IP address. If the form is submitted without the correct POST value, if their IP address changed, or after too many seconds since the timestamp, then redisplay the form to the user, with a request for them to visually inspect and confirm the submission. exploit code on a few hundred pre-scouted vulnerable sites for drive-by - Matt -- -JH
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On 17 January 2013 23:38, Matt Palmer mpal...@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. 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. -- -- ℱin del ℳensaje.
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On 1/16/13 8:36 PM, Shrdlu wrote: 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... 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 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. Thank you for this feedback, i'll pass it onto to the developers. Regards John
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
[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
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
--- mpal...@hezmatt.org wrote: --- From: Matt Palmer mpal...@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 CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data. For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request. In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website. So, if someone is just looking around, why is the cookie needed? scott
