Top tip for any all companies: when someone with a good reputation and a background says you're doing it really wrong, and then half of the nerdy internet agrees, listen to them. It'll save a lot of trouble later on.
I wish I was surprised that Tesco haven't fixed the XSS attack, but it's probably languished in management hell for a few weeks until it's deemed necessary. Bolt the stable door before the horse does a runner.
More than that, even if a single person without any reputation reports a security issue, there should be some standard mechanism in the company to evaluate it and fix the problem if it's real.
I also have a feeling sometimes the security team never gets to read it. The guy managing their twitter account has probably no clue of even what's going on. His supervisor is too lazy to look into this further and asks him to send a template "we are secure" response. I really feel like security@website.com should become a standard for researchers to be able to at least talk to someone who understands what they are doing.
Perhaps with some formalized amnesty? If I go to the trouble of contacting you to tell you you've got a security problem, do not threaten to call the police or FBI on me. I've had that happen once, and I've tended to stay away from contacting places even when I saw they had a clear security violation, because
a) I'm not sure how they'll react (will they claim I'm trying to extort them?)
b) there's never any clear way to contact a company beyond calling/emailing 'customer support'.
Occasionally I've tried to poke around my linkedin network to see if I had a connection at company X to reach out to their dev team and notify them of something, but I've never been successful that way (but also haven't pushed the issue much).
I think the best solution would be for more companies to publish a page on their website telling people what to do if they find a security problem, like GitHub and 37signals do (Google and Facebook also offer a bounty).
I guess a problem with this is stating where the line is drawn. It might be difficult to promise not to sue well-intentioned researchers without reducing their ability to sue people with malicious intentions.
Companies that have security pages and contact details are also companies that understand the importance of security issues. the problem here is that most companies do not understand the issue and tend to react defensively
One solution might be using an agent - setup a clearing house for security issues run by a couple of trusted people. You log the issue, the clearing house gets in touch with the company and gives them access to the issue details.
It keeps the person reporting the issue one step away from the company and any potential trouble.
Once the company acknowledges and fixes the issue it is made public with an optional credit
If they don't acknowledge the issue it becomes public anyway after x days.
Why is anyone putting anything in a cookie besides a [protected] session ID? I can store your account details (the ID my store uses to identify you, your first name for dispaly on pages) in the session object on the server and access them when my store page scripts need them. Why does anyone need any of this in a cookie? I don't get it...
It's a fundamental property of user-facing apps that you can't trust anything provided by a user (or anything that can impersonate a user.) Got some input that you're gonna store in the database? Use the database sanitizing functions to clean it up before putting it in the database. Going to display some of that back to the user? Pull it out of the database and HTML encode it before putting it in the page.
Is it just blind trust in users that keeps web dev people doing this? Or is it truly lack of comprehension? Either way it's incompetence.
It appears to be how things are done in a number of frameworks. In a bizarre parallel to mgkimsal's comment, whenever I've asked about it, I've been told I just don't get web programming.
To my mind, the term cookie implies some sort of opaque handle. I give it to you, you give it back to me. It doesn't contain data, it's just a handle.
A base64 encoded 128-bit number also solves the problem of "omg, our cookies are so long we need a separate domain for static assets to reduce our bandwidth".
Rails claims its CookieStore will "greatly increase the speed of the application" relative to other stores (the guide mentions a file store and a database store) [1]. The cookie is a base64 encoded hash serialization (i.e. completely reversible by the client), but "to prevent session hash tampering, a digest is calculated from the session with a server-side secret and inserted into the end of the cookie."
I've not seen or performed myself any measurements of these claims. I have seen it suggested that CookieStore is the default because it is simpler in not requiring a database table, and not for any performance benefit. Without measuring, I can only guess the difference is dwarfed by the typical page load time.
Possibly OT, but a security story/rant all the same. I worked on a project where web session information was managed by a java/php dance. PHP serving the front end would ask a Java web service for a session token (or pass a session token in to validate it). The Java web service would generate a new session token by add a row to a database and returning a string of characters. The string of characters was the auto increment ID of the database row, encrypted with a key. When the Java web service got the token again, it would decrypt it to see if it matched a valid row ID in the database. The token was sent down in a web cookie.
I was then asked to also use this same 'session management' approach on something with far more sensitive financial information (the original use case was arguably already something sensitive, although not directly tied to financial records). I refused, and explained why. I was told I didn't understand security. I suggested tying the row to a random ID and using that. I was told that 'random generators aren't really random - you need to understand how computers and processors work to know that'. It took me 5 months from when I first brought this up as a security concern to someone above me actually understanding the problem - not necessarily agreeing with my conclusion that it was unsafe, but at least understanding why it could be unsafe. BTW, none of my nominal colleagues took it - or me - seriously - cause after all, I only did PHP - it doesn't even have threads (that was an actual quote from someone).
The problem was if someone managed to decrypt the cookie value, they'd immediately see it was a number like 109826374. Trying again a few minutes later, they'd see 109826379, etc. Yes, potentially hard to decrypt in the first place (or to know that it was encrypted), but if done, devastatingly easy to assume another identity.
I was continually told I didn't understand web security, or computers, or programming, because I was new to the company, and developers far more senior than me had developed this (at this point I'd been doing web development for almost 8 years, and had already made my fair share of stupid/dumb security mistakes, so I recognized this one instantly).
Finally someone 'got' it when I pointed out that dozens of people had come and gone, had access to the code, but more importantly, had had access to the encryption key. It hadn't been changed. Ever. I asked how they could ensure that people weren't already using that key to decrypt and take over accounts - there'd be no way they could actually identify if that was even happening. I think the immediate answer was to plan to rotate the encryption key on a regular basis, but I left soon after that (for more reasons than just this, but this was illustrative of how I was interacting with the place). Having values in a cookie that are tied to directly manipulatable database values simply isn't a good idea, even if the cookie is encrypted, and you certainly wouldn't want financial records stored with this as the primary (only?) means of security.
Was some of the failure my fault? Possibly. I may have come across as arrogant, or 'know it all', or whatever. I'd sent detailed tech emails to people outlining the issue. I'd had friendly lunch conversations. I'd demonstrated how it was possible. Nothing worked. And that was frustrating, and led me to coin my own phrase - "It doesn't matter what you say, it matters how you're seen when you say it".
I went through some similar situations. Early on, one of the very senior developers -- and one of the smartest guys at the place -- figured out that I knew what I was talking about. Sometimes I might raise a concern out of ignorance, but even then, I was asking good questions.
When things moved from simply "compromise" or "somewhat ugly" to an outright risk, occasionally I'd have to escalate past a senior developer or architect to this guy.
It rubbed some people the wrong way, but over time, when they learned that I wasn't doing it out of ego but simply out of concern, most of them at least partially got over this.
P.S. Fortunately, many of them were already fairly seasoned and "battle scarred" and had themselves learned to focus on what mattered. As often as not, my concern was an irritant as much as anything because of the additional time and attention it would demand of already loaded schedules. I reserved escalations for real risks and/or long term implications, to minimize this.
I think the main problem with this scheme is encrypting without authentication. You need to authenticate the data not encrypt it! (you can use a HMAC scheme for this) Encrypting is useful if you don't want clients to see the ID but that is not really a problem. For comparison Rails using the scheme by default for its session storage. http://guides.rubyonrails.org/security.html#session-storage Also, it is kind of pointless to have a HMAC cookie scheme and still use a database :) The point of a HMAC cookie scheme is to avoid using a database.
But the problem of not rotating keys is also something that is commonly overlooked. Rails doesn't even have an option to rotate keys which is slightly annoying. It would be nice to introduce a new key without invalidating every session. For example someone might leave the company. You could introduce the new key for a day then revoke the old key which would be much more seamless [but more risky if you believe they are going to attack straight away. since they could continue to use a compromised session after the old keys have been revoked].
The biggest problem with the scheme described is what you point out: encryption is not authentication. They are designed to provide two entirely different guarantees (confidentiality vs. integrity).
To provide a more concrete attack scenerio: if they used CBC encryption and stored the IV with the encrypted value (both very common practices with block cipher crypto), it would be trivial to spoof any user id by flipping IV bits.
On a more general note, the main problem appears to be basic lack of cryptographic knowledge. These "experienced developers" need to buy a crypto book and read it. Talented mathematicians have already solved their "problems" with academic rigor (in this scenario, using HMAC).
Right... I was assuming in this case that the message size would be < 1 block considering it's just a database id. In that case you'd have to modify the IV to flip id bits.
It's definitely way too easy to get crypto wrong especially if you don't have the basic cryptographic knowledge as you note. I think it is much better for developers to just try and use existing proven solutions and not try to make their own crypto solutions. I've worked on one project where it was possible to use the sessions that came with the web server (tomcat) which were implemented securely. however, instead we decided to do extra work to roll our own sessions which were implemented incorrectly using the database rand() function.
Good point. I may have even thought of that all those years ago, but I can't remember that far back. I eventually was just appalled that something so basic (and basically flawed) would be so sacrosanct and beyond discussion. Even after demonstrating - "look, if I have this key, I can identify as a different user" - I was essentially dismissed as a crank. At some point you get a label, and regardless of the validity of what you say, you're ignored, and that's a lesson I learned the hard way.
IIRC, doing any sort of validation on the PHP side was deemed to be too computationally expensive (you know, cause it's PHP) but somehow calling a webservice over a network that then connected to a database across a network as well was somehow 'performant'. An HMAC approach on the PHP side could have been done just fine, but I think it would have left the Java guys with less control over the process (which brings up again that this was less technical and more political).
I brought up the problem with a hard-coded encryption key where I used to work (the same key was shipped to every client site for data encryption). The problem was basically swept under the rug -- kind of the same scenario you ran into, claiming 'only people who knew the problem would be a risk'.
Eventually they hired Microsoft to bring in their project analysis team and the hard-coded key became problem #1! Fortunately for me, I'd learned long before that 'I told you so' never goes over well in the workplace -- I kept my sense of smug satisfaction to myself.
I've asked myself that a lot over the years. A friend of mine started there several years ago with me, took a different path, and is still there, as a senior dev/tech/depthead/something (a tech bigwig). I just don't think I was cut out to play/work in such a large organization (even though it means missing out on a lot of the financial perks that come with that sort of employment).
I might try to go up the chain a bit higher faster than I did. I tried to play along with following the standard 'chain of command' (as best as I could find). However, I took the opposite approach with another problem I found (it wasn't just me - when I showed it to other people they basically agreed it was an operational problem too - made us look bad to potential customers). I went to the top (as he invited dialogue) but it quickly became a bit of a hooha that was never adequately resolved - I'd rocked the boat, was threatened vaguely (not physically, just with dismissal) by a senior company officer, and apparently became a marked man because of that.
So... I guess in retrospect, I'm not sure what I'd do differently. Not work at a large company? I don't want to swear off them entirely - never say never and all that - but there's far more politics involved in working at large companies (well, the couple I've been at or seen inside) than I was comfortable (capable of?) dealing with.
You'll need to find out what your work style is - do you enjoy working on teams? Or do you prefer to work solo? I don't mind teams, but need to have more autonomy/control when the time calls for it, and I've never been in that situation. It's made all the more frustrating when you have 'corporate HR' stuff telling you to 'take ownership of a problem', and 'take responsibility for things'. Fine, but when I have no authority over any resources to make that happen, it ends up just being a 'take the blame for other peoples' crap' sort of situation.
I've been self-employed for the past several years, and while I'd like to do something else eventually, I enjoy probably 80% of what I'm doing now, instead of, say, 40-50% at traditional 'employement' situations. Again - never say never - I may work for someone else again in a traditional capacity, but it'd have to offer something more/different than what I have now. I'm at mgkimsal@gmail.com if you have more questions :)
This is not a warning to avoid large corporations, just an observation ...
When you work at BigCo, your daily activities and your goals involve operating the machine that BigCo is, and becoming part of that machine. You may be a programmer, or software engineer, or technical staff member, or Sales Guy or Web Dude[1]. You may code in some language or collate TPS reports. But your main job is to serve the machine, regardless of what the machine produces.
At SmallCo success is defined and recognizable by shipping, internally or externally. At BigCo success is defined and recognizable by how many people know you, and how many weeks of vacation your grade is given.
Do you work at BigCo or SmallCo? William Least Heat Moon, in Blue Highways[2], had a rule for guessing whether a restaurant was going to be good or generic, and that was to count wall calendars; the more calendars, the better the restaurant[3].
You can recognize BigCo by sheer physical size, but also by walking around the cubes and counting company certificates on cube walls. The more certificates of relationship training, management training and Microsoft training that you find, the Bigger the Co. Those certificates are there because those employees are learning and demonstrating the skills of operating, and being a cog in, BigCo.
You can also recognize how far into the machine individuals have progressed, by measuring the ratio of animal books[4] to certificates.
there was already some sort of expiration time - a session key from 2 months ago wasn't valid. Expiring the keys to coincide with aged/invalid sessions would have been 'good enough'.
No.... forget that, it wouldn't. It would have been better, but not good enough.
Having something that is an understandable identifier in the cookie is just bad. Crack the key, and when the identifier is 187644, and the next one two minutes later is 187663, you can pretty much guess how to take over accounts. Crack the key when the identifier is qo8GbwieYKK7d3hs92ujvn65CgD and you are pretty dead in the water without brute forcing. This is the point I was trying to make to them, and what I got back was variations on 'random isn't really random'. Somehow identifiers 187644 followed by 187645 seemed infinitely more secure than qo8GbwieYKK7d3hs92ujvn65CgD followed by 7f6Dhj23CNHS8927gfodop289jz because of an encryption key - that never got changed.
Those points on the tech aren't as important as the people issues. I have been through what you describe so often and so many times, very familiar situation
When I applied to capgemni(A big I.T company) the graduate recruitment website returned my password in plaintext over email which shocked me because they're ment to be I.T experts that do government and corporate i.t projects. Although this was a year ago, is there a way to formally complain about this?
I wish I was surprised that Tesco haven't fixed the XSS attack, but it's probably languished in management hell for a few weeks until it's deemed necessary. Bolt the stable door before the horse does a runner.