We Suck At Security
Disclaimer: This is a rant. It meanders. It rambles. It contradicts itself. It uses mildly dirty words. It alternates clumsily between idealism, cynism, frustration, ignorance, and brilliance. Read at your own risk, and don't complain if you don't like what I have to say. Feel free to discuss, but don't complain. By the time you read this, I probably won't agree with me either.
We suck at security.
A few months ago, I ran across a copy of Lincoln D. Stein's Web Security FAQ. It's an awesome document that first showed up around 1994. I tried to track down the original version, and the best I could do was 1.1.4, which was published December 1995. I even went so far as to contact the guy and buy a copy of his book (1997). The "current" version of the FAQ is dated 3.1.2 February 2002.
I probably first read that FAQ in the late '90s, but I wasn't a security guy then. I was just a crappy web developer with an unhealthy love of animated GIFs. If you've never read this document, print out a copy and put it on your kitchen table. Not only will you get a kick out of it, but there are some very interesting lessons to be learned.
A high point:
Q33: What CGI scripts are known to contain security holes?
Just including this question shows how small and non-interactive the web was back then. Only two CGI scripts are named explicitly, but I find it particularly funny that FormMail is listed. FormMail is basically a script that allowed us to put contact forms on our websites, process the results, and send them to our email inboxes. Early versions had gnarly code execution bugs- the kind of thing you find in every "Hacker Training" course, but rarely find in the wild anymore. You'd think that such a dated script wouldn't be an issue today, wouldn't you? You'd be wrong.
FormMail has been revised and rewritten hundreds of times, in practically every language in use on the web. FormMail.php is now a common one, as is FormMail.cgi (AKA FormMail.pl), which is included by default with every site on every cPanel installation. Both are vulnerable to XSS. This has been known for years, but people are still using it. It's not caught by any of those PCI/Web Security scanners that regularly certify cPanel-hosted sites. I've reported it to cPanel, and it's not being fixed. It's not being removed. Bad coders are copying bad coding practices from fifteen year old scripts. Splendid.
These things aren't getting fixed, but do you think this is wholly the developers' fault? Dead wrong. This is our fault.
A recent post to the web security mailing list said "who would be 'stupid' enough to click a malicious link like bit.ly/xxxxx?" This bugs the hell out of me. bit.ly is a useful service. Somebody has to be stupid to use a useful service? I click bit.ly links every day. bit.ly has its share of problems, but if our "solution" is expecting people to not click a link we're going to fail. Expecting J. Random User to understand how bit.ly can be abused in order to not be "stupid" on the web is equally moronic. It's not his fault, the web is just designed very, very wrong.
And it's because we suck at security.
The biggest thing we're currently doing well? We're making some things easier to do right than do wrong. The code execution bugs of the 90s are indeed getting rarer, because most PHP programmers are taught to be scared of backticks, and are given libraries for interfacing with third-party applications (rather than being asked to run ImageMagick as a shell command). Sure, it still happens, and more than I'd like, but it's happening far less than it was. Let's take a lesson from that.
Side note: If you're a developer and you haven't played with the OWASP ESAPI yet, why not make your life simpler while making your code more secure? Wave of the future, man.
Specifically, the issues I like to talk about here are what I call the "application boundary bugs". These are the things like CSRF, XSS, Clickjacking, even that stupid "XSHM" one that was "released" last week. In these attacks, the exploit stems from a webapp forcing a browser to do something to another webapp. Why does it work? Because cross-domain communication is a common, legitimate, insane, and unnecessarily necessary thing for a website to do.
You know what would fix that? Putting hard boundaries on web applications. Not this Same-Origin Policy bullshit, which is regularly bypassed with ease by attackers and developers alike. Not this zone crap, which makes the outdated assumption that the sensitivity of data is related to where it's found on the network. We need boundaries that cannot be crossed under any circumstances. They need to be defined by websites, opt-in today, opt-out tomorrow, mandatory down the road, extremely easy to implement correctly, and extremely difficult to implement wrong. Let's find a solution.
It's easy to blame poor coding practices, poor site maintenance, backwards compatibility, or weird browser quirks for the issues we're dealing with today, but frankly, that's bullshit. Every party, be he browser (or plugin) designer, security appliance vendor, web developer, user, UX guy, security guy, or alcoholic vagrant (okay, those last two are pretty much the same thing), has some role to play here. My biggest complaint with this entire situation really has nothing to do with security: it is the "Somebody Else's Problem" attitude. This is everybody's problem. Whichever party you are, suck it up and be the one to handle it. Fix it for your users, your customers, or yourself. Have your marketing department spin it however they like. Charge people for a "premium" package. Please, just start fixing things. Let's fix them right. Let's fix them permanently.
NoScript is a perfect example of the "wrong" fix. Not to say it isn't useful. Today, it's a necessity, but it shouldn't be a long-term solution. It plugs countless specific holes, but does not address the major design issues around the web. On the other hand, if you've played with Request Policy, it cleanly solves CSRF, XSS, (some) history theft, and other issues. It renders the web virtually unuseable in the process, but it absolutely does solve those problems.
It's not all bad news- we're starting to get some other solutions. Mozilla's Content Security Policy may turn out to be the best thing to happen to web security in years, but it's complex, and it does very little for CSRF. There's a proposed "Origin" header to prevent CSRF, but frankly, it won't help unless it's insanely easy to enable and enforce. X-Frame-Options is great, but still pretty rough. None of these feel like complete "solutions."
Seriously, we're hackers. Hackers are supposed to be guys who can do, break, and fix anything.
What a delusional bunch we are.
We suck at security.
A few months ago, I ran across a copy of Lincoln D. Stein's Web Security FAQ. It's an awesome document that first showed up around 1994. I tried to track down the original version, and the best I could do was 1.1.4, which was published December 1995. I even went so far as to contact the guy and buy a copy of his book (1997). The "current" version of the FAQ is dated 3.1.2 February 2002.
I probably first read that FAQ in the late '90s, but I wasn't a security guy then. I was just a crappy web developer with an unhealthy love of animated GIFs. If you've never read this document, print out a copy and put it on your kitchen table. Not only will you get a kick out of it, but there are some very interesting lessons to be learned.
A high point:
Q33: What CGI scripts are known to contain security holes?
Just including this question shows how small and non-interactive the web was back then. Only two CGI scripts are named explicitly, but I find it particularly funny that FormMail is listed. FormMail is basically a script that allowed us to put contact forms on our websites, process the results, and send them to our email inboxes. Early versions had gnarly code execution bugs- the kind of thing you find in every "Hacker Training" course, but rarely find in the wild anymore. You'd think that such a dated script wouldn't be an issue today, wouldn't you? You'd be wrong.
FormMail has been revised and rewritten hundreds of times, in practically every language in use on the web. FormMail.php is now a common one, as is FormMail.cgi (AKA FormMail.pl), which is included by default with every site on every cPanel installation. Both are vulnerable to XSS. This has been known for years, but people are still using it. It's not caught by any of those PCI/Web Security scanners that regularly certify cPanel-hosted sites. I've reported it to cPanel, and it's not being fixed. It's not being removed. Bad coders are copying bad coding practices from fifteen year old scripts. Splendid.
These things aren't getting fixed, but do you think this is wholly the developers' fault? Dead wrong. This is our fault.
A recent post to the web security mailing list said "who would be 'stupid' enough to click a malicious link like bit.ly/xxxxx?" This bugs the hell out of me. bit.ly is a useful service. Somebody has to be stupid to use a useful service? I click bit.ly links every day. bit.ly has its share of problems, but if our "solution" is expecting people to not click a link we're going to fail. Expecting J. Random User to understand how bit.ly can be abused in order to not be "stupid" on the web is equally moronic. It's not his fault, the web is just designed very, very wrong.
And it's because we suck at security.
The biggest thing we're currently doing well? We're making some things easier to do right than do wrong. The code execution bugs of the 90s are indeed getting rarer, because most PHP programmers are taught to be scared of backticks, and are given libraries for interfacing with third-party applications (rather than being asked to run ImageMagick as a shell command). Sure, it still happens, and more than I'd like, but it's happening far less than it was. Let's take a lesson from that.
Side note: If you're a developer and you haven't played with the OWASP ESAPI yet, why not make your life simpler while making your code more secure? Wave of the future, man.
Specifically, the issues I like to talk about here are what I call the "application boundary bugs". These are the things like CSRF, XSS, Clickjacking, even that stupid "XSHM" one that was "released" last week. In these attacks, the exploit stems from a webapp forcing a browser to do something to another webapp. Why does it work? Because cross-domain communication is a common, legitimate, insane, and unnecessarily necessary thing for a website to do.
You know what would fix that? Putting hard boundaries on web applications. Not this Same-Origin Policy bullshit, which is regularly bypassed with ease by attackers and developers alike. Not this zone crap, which makes the outdated assumption that the sensitivity of data is related to where it's found on the network. We need boundaries that cannot be crossed under any circumstances. They need to be defined by websites, opt-in today, opt-out tomorrow, mandatory down the road, extremely easy to implement correctly, and extremely difficult to implement wrong. Let's find a solution.
It's easy to blame poor coding practices, poor site maintenance, backwards compatibility, or weird browser quirks for the issues we're dealing with today, but frankly, that's bullshit. Every party, be he browser (or plugin) designer, security appliance vendor, web developer, user, UX guy, security guy, or alcoholic vagrant (okay, those last two are pretty much the same thing), has some role to play here. My biggest complaint with this entire situation really has nothing to do with security: it is the "Somebody Else's Problem" attitude. This is everybody's problem. Whichever party you are, suck it up and be the one to handle it. Fix it for your users, your customers, or yourself. Have your marketing department spin it however they like. Charge people for a "premium" package. Please, just start fixing things. Let's fix them right. Let's fix them permanently.
NoScript is a perfect example of the "wrong" fix. Not to say it isn't useful. Today, it's a necessity, but it shouldn't be a long-term solution. It plugs countless specific holes, but does not address the major design issues around the web. On the other hand, if you've played with Request Policy, it cleanly solves CSRF, XSS, (some) history theft, and other issues. It renders the web virtually unuseable in the process, but it absolutely does solve those problems.
It's not all bad news- we're starting to get some other solutions. Mozilla's Content Security Policy may turn out to be the best thing to happen to web security in years, but it's complex, and it does very little for CSRF. There's a proposed "Origin" header to prevent CSRF, but frankly, it won't help unless it's insanely easy to enable and enforce. X-Frame-Options is great, but still pretty rough. None of these feel like complete "solutions."
Seriously, we're hackers. Hackers are supposed to be guys who can do, break, and fix anything.
What a delusional bunch we are.
Labels: rants
posted by mckt at
12:38 AM
4 Comments:
Yep, the amount of suck at security we have scares me at times. We should make it legal to penetration test anyone anytime anywhere. We should train and teach about security in schools. We should be more careful with our data. etc, etc
People won't, though, and that's part of what's so frustrating.
By
Jon S., At
February 5, 2010 11:31 PM
I fully agree with the underlying idea of the rant. Not the "we suck at security" part as "we" is an over-generalization, but rather the idea that the "prevention" methods being performed nowadays are completely aimed in the wrong direction.
I see people everyday saying how great NoScript is and "don't click a link someone sends you". What?! Most of the internet is run on JavaScript today, and if nobody ever sends me links how the hell am I supposed to find all the cool stuff out on them internets?!
I, unlike those outlined in the rant, have taken the initiative in my company (PHP web development) to set programming guidelines to perform correct security practices. You won't find a "function/method" that has been limited. There is no "don't use exec() or ``". The rule that I have in place is, validate/sanitize your data! When it comes to web-development, SQLi/XSS/LFI/RFI/etc. occur because of bad data, period! Why do you need to say "don't use this function, it's unsafe" when you can just say "make sure 'rm' doesn't get used in the system()" call? (this is a very summarized implementation, by the way. our practice is way bigger as we strip out 'ps' too =P)
I agree with Jon S.'s comment as well. It needs to be taught in schools. High School, not as much (most high school kids would use it for the wrong reasons). College, most definitely. The only course offered at my college was network security which dealt 90% with encryption algorithms and "what is the definition of virus".
It would be fun to make penetration testing legal for anyone/anytime/anywhere, but after a year or two of that there won't be anything left to hack (hopefully) =P and we'd all be out of a job (and then a few years later, the same problem will come back).
Knowing people today it's going to keep on the path it's on for just about ever. For some reason, people think it's easier to create a workaround for a problem than to just "fix the problem". Well at least it provides me with job security =]
By
Anonymous, At
February 6, 2010 6:42 AM
"We should make it legal to penetration test anyone anytime anywhere. "
This would open up a lot of loopholes. From where I stand as a novice (so much so that I don't really count as that) greyish hat it's a brilliant idea. When I see a hole, I want to probe it to see if it really is as gaping as it looks. Unfortunately I can see legal pentests used as an excuse for serious black hat work.
By
Nick, At
February 6, 2010 8:58 AM
The world has a disproportionate amount of suck in it - and it isn't just security. Banking, government, ... ?
- Management minimizes security because it cuts into profits, which is why the business is there in the first place, ie steal underwear = profit. As long as they are doing the minimum to keep "compliance" at bay, they're happy. The concept of security being a business differentiator and positioning a company as a thought leader is too progressive for them to handle.
- Users don't care because they don't feel they have anything to protect ("I've just got some pictures and mp3's on my computer") or "I don't click dumb shit". And if they do get a virus, they call one of us "hey dude, I got a virus, can you come fix my computer?"
- I'd like to think coders care, but most probably don't (I'm sure some do). They get paid the same regardless. Way back when I worked for a dev company it was # of lines of functional code a day that mattered. And if they do care, they may not have the skill to do it properly. Circle back around to the mgmt point #1 above and the cost of training.
At the end of the day, the best you can do is show people their mistakes and explain why their stupid. But stupid people don't understand their stupid so you're stuck.
By
frizille, At
February 10, 2010 7:30 AM
Post a Comment
Subscribe to Post Comments [Atom]
<< Home