Web-based business services require trusted mechanisms by which money, sensitive information, or both can change hands. We know these as web applications; hackers know them as opportunities. To protect them, we must focus on web application security.
How complicated is web application security? You can get a sense by surfing to OWASP — the Open Web Application Security Project, which organizes security-relevant information, including exploits of all kinds.
This site maintains a top ten list of web application security vulnerabilities, and it’s clear at a glance that hackers have found a wide variety of security shortfalls:
From this list, we can ferret out a few underlying patterns in web application security.
Many vulnerabilities, quite simply, are the consequence of lousy programming in which exceptions, boundaries, credentials, etc., weren’t considered adequately. Sometimes administration issues — a failure to configure or update components properly — are at fault. Certain programming languages (C and C++, I’m looking at you) are designed in such a way as to be inherently harder to secure. A secure web application also requires a secure operational context (host servers, middleware, etc) but that’s not always the case.
So what do security professionals recommend to deal with this already-dizzying-and-still-growing array of web application security vulnerabilities?
Fortunately, there are many different web application security techniques. For organizations that roll their own web applications, it’s particularly important to dive into the root causes — the how and why vulnerabilities inadvertently get baked into the applications in the first place.
Secure coding practices are certainly a logical first step, and this is an area that has been studied extensively for decades, in which there is no shortage of expert insight for improving web application security. Threat modeling, for instance, can be used to identify clearly what the app is meant to do, how it goes about that, and therefore, where vulnerabilities are likely to exist.
Risk analysis empowers development teams not just to identify probable risks, but in some cases quantify the odds they will manifest and describe the possible outcomes if they do. Static analysis tracks the logic of code that isn’t actually executing, looking for shortfalls in data manipulation or algorithmic process before they get a chance to manifest in a production build. Obviously, the basic choice of programming language and development environment can go a long way toward improving security!
There are also many commercial solutions designed to automate some of the testing. “Black box” solutions don’t try to assess application code per se, but instead just treat the application in a monolithic way. These are typically known as “web application security scanners,” “vulnerability scanners,” “penetration testing tools,” etc., and work by simulating a running, active, environment. Once installed, they then stress-test an application for flaws in ways that real-world users presumably would. These flaws, once exposed in the reports the solution generates, can then be addressed by the development team.
“White box” solutions, on the other hand, do look into the structure and code of the application itself — evaluating to some extent how well implemented the secure coding best practices were by the engineers who built the application. For instance, static analysis (as described above) can be performed to automatically trace process execution and predict what should happen in an up-and-running application (that isn’t actually up and running), thus spotting clear web application security issues.
Another good testing idea is “fuzzing,” which basically just means hammering an application with many different kinds of data. That includes data of a completely inappropriate format for which the application was never designed, as well as random data that doesn’t make sense because it hasn’t got a format. This is a good way of revealing web application security flaws in an application via input that a normal human being (whether working in quality assessment or a typical user) might never even imagine, let alone carry out — but a hacker might.
In the case of applications that require a secure log-in process, let’s not forget web application security basics – it’s wise to try password crackers. These can train a spotlight on predictable issues, such as the strength of the password the application requires, whether it’s possible to break the authentication code in any of several commonplace ways, the minimum time interval between password entry attempts, or how many failed passwords can be entered before a user is locked out.
Looking ahead to the future of web application security, I’m afraid things are going to get worse before they get better. We are living in a time when endpoints are rapidly diversifying — traditional servers, desktops, and laptops are joined on business networks by tablets, smartphones, Internet of Things sensors, and even wearable tech like the Apple watch. Each is, in theory, a potential attack surface — and each contributes to the problem, by offering hackers new platforms from which to launch attacks on web applications.
When you consider also the popularity of offsite clouds, in which web applications are increasingly hosted, you begin to get a sense of just how challenging the area of web application security is likely to become. Security professionals will have to stay on their toes to keep up, strengthen their ties to web application developers, and continuously evolve the tools described above.