In the beginning – when the web was a dark and primitive space full of ‘under construction’ signs, flaming Java applet logos and faux-mechanical hit counters – a proto-web developer crawled from the World Wide Web’s primordial tag soup and ushered in the future by hooking-up a company database to a company website.
The website was no longer a document, it was an application; complex, sophisticated, interactive, up-to-date, personalised, useful even.
Not long after this epiphany occurred a proto-hacker emerged from the same tag soup, took one look at this fine new creation and tried to attack the company database through the website with a SQL injection attack.
And so it’s been ever since.
On the surface, modern websites have as little in common with their early nineties forebears as a 3D Pixar animation has with a magic lantern show. Under the surface though it’s a different story; the technology has changed but the basic underlying concepts haven’t and neither, sadly, have the most common types of vulnerability.
Ever since websites sprouted input fields, hackers have used them to try their luck.
Instead of entering whatever it is the website is expecting users to type into the input field – a username and password on a login page for example – hackers can try entering code instead; SQL commands for attacking the database or HTML, CSS, Javascript or XSLT for attacking the structure of the site’s pages (so-called XSS or cross-site scripting.)
If websites are properly coded then anything anyone enters in an input field is scrubbed and cleaned until it can do no harm. If websites were properly coded then SQL injection and XSS attacks would have disappeared long ago.
Content distribution giant Akamai has just released its most recent State of the Internet Security Report and it includes a section on web application attack activity.
Top of the list for Q1 2016? SQL injection.
The second and third items on the list, Local File Inclusion and XSS (Cross-site scripting), are as old as the hills too. In fact, if you removed the dates from the report the only clue you’d have about what year the web application attack section was referring to, or even what decade, is the presence of 2014’s Shellshock vulnerability.
And just to be clear, that’s not a criticism of the report. Far from it.
As we edge ever closer to peak hype, with every new vulnerability getting its own logo and PR makeover, we need an injection of perspective.
The Akamai report reminds us that coding a website so it’s protected from the kinds of attack it’s most likely to face is an old story. It’s mostly, about doing some quite basic but unglamorous hard yards, thoroughly.
These attack vectors have remained effective due to coding issues that continue to crop up in websites. [SQL injection] is a problem that can be solved through coding techniques that include security checks. In the rush to move applications to the web layer, however, many companies still do not check for SQLi vulnerabilities and thus leave themselves vulnerable to attack.
SQL injection can be killed stone dead by the simple expedient of using parameterised database queries – but only if you have the discipline to use them everywhere, all the time.
XSS can be eliminated by correctly ‘escaping’ a website’s output (ensuring it’s interpreted as content rather than as language syntax) – but only if you use the right escape syntax, and only if you do it all the time.
That SQL injection, XSS and their ilk have clung to the web like stalactites for all this time has nothing to do with some fiendish inherent mystery or the elite skills of hackers; their staying power is testament to the fact that making a site that isn’t vulnerable takes a bit more time, effort and attention than making one that isn’t.
Albert
Is fear of SQL injection the motivation for web forms having those annoyingly unreasonable restrictions on text input, for example not allowing periods where they’re commonly used in written communication (e.g. after abbreviations in street addresses)? Made all the more frustrating by the lack of useful error messages when input is rejected (is that just plain bad programming, or an attempt to avoid giving clues to attackers?).
Mark Stockley
No, that’s just bad user experience design.
William
Sometimes there are already set standards for different types of information to be collected such as the U.S. Postal Service specifically states do not use punctuation, with exception of a dash in the zip code, because machines do not need grammatically correct punctuation to recognize address abbreviations. Punctuation actually slows down and causes errors in high speed OCR operations handling approx 8-20 mail pieces a second depending on level of sorting. (Sorry, occupational hazard I used to work for the postal service.)
However, I do agree with you on the inherit problem of cookie cutter forms that all use the same copy & paste bootstrap code. Just like the security problems created by the Internet of Things (IoT) where people buy a connected item and expect 100% security the moment they open the package. This same mentality is manifesting itself in application and website development. Just because you downloaded, or possibly purchased, a sophisticated point & click Development kit for a platform does not mean you will get 100% secure code. Another problem this method creates is when an organization becomes so dependent on the kit/environment they end up changing their requirements or processes based on the restrictions of code generated, or provide in included libraries. This is where I get really irritated in particular concerning email address validation, but I digress.
Developers need to develop code to fit their requirements rather than conforming to the ideas, and libility exposure limitations, of the people that created the development kit/environment.
Mark
No, and again no. Devs are not security experts. They are good at a few things, but are expected to be masters at many disciplines, security being one of them. They can’t do it. The issue lies squarely with the technology providers. Take SQL. Simply setting the default to disallow multiple statements or executing external programs would shut the door on the majority of SQL injection attacks. If there is a best practise then embed it in the technology. If you need to bypass it for any reason, if there is an edge case, allow an exception clause. Stop relying on the developer to get it right. Because they wont.
Mark Stockley
I agree that technology providers have a significant role to play – languages, frameworks and databases can and should make doing The Right Thing the path of least resistance.
Organisation also has a critical role to play too; it is clearly possible to organise or reorganise your resources in a way that produces secure code – look at WordPress, IE or IIS.
That said, we are where we are and the technology stack is not going to transform itself into something better overnight developers are bright people. It’s just not good enough for developers (and the people who manage them) to wash their hands of their responsibilities.
And the point of my article is that defending against the majority of the threats you’ll actually face as a web developer – variations on SQLi and XSS – does not take expertise, it takes good habits.
If I was interviewing a developer for a job and they said they couldn’t be expected to write code that was resilient to SQLi, XSS and LFI they simply wouldn’t get the job.
Bryan
Thank you Mark (Stockley). Well stated.
Bryan
No, no, and again no. Saying “developers are not security experts” only gives them carte blanche to code lazy shortcuts and blithely (dis)regard security as “someone else’s problem.” Granted, it’s partly because they’re not often enough given proper direction or held accountable. “Stop relying on the developer…” That’s the problem; if the dev can’t ensure solid code, who will?
Security must be a global thought process; no one link in the chain can bear that sort of responsibility, because it won’t. In the practical world, few of us are “security experts,” but I’m nonetheless expected to keep my servers running no matter what caliber of code I’m forced to run on them.
If a dev is expected to master many disciplines, then anticipating *all* user input should be one of them. Simply saying “the app works, I can’t plan user input” is a copout. Good code *expects* to be attacked or abused and is structured accordingly.
Major software providers are major because they already build security into their products. Apache and SQL wouldn’t still be around if the default behavior was to invite bad guys.
If it’s difficult to carry groceries into the house, just leave your front door unlocked all the time–or better yet, wide open–then you never need to fumble for the key at all.
No.
Jay Dee
As someone who constantly has to work with WordPress… I deal with this constantly!