An exploit is not an exploit is not an exploit. Though many abusable web application vulnerabilities ostensibly come with the same goal in mind — namely, letting malicious jerks access all sorts of sensitive data — the various roads they take to reach that end are nearly as wide and varied as the types of software they attack.
Here's a look at three well-known web application vulnerabilities, how they work, and why stopping them early (read: during production) is crucial for the security of your users and the reputation of your product and company.
If you've been online at all in the last year or so, you've undoubtedly heard the word "Heartbleed" kicked around a few times. There's good reason for that: Major social media sites like Pinterest and Instagram felt the burn of Heartbleed before patching, as did several Google services like Gmail and Google Play. And that's just for starters.
How does a single vulnerability become so prolific? When it rides the coattails of OpenSSL, one of the most popular security toolkits in all of web app development. While the nuts and bolts are (of course) highly technical, here's a good high-level view of the vulnerability from Gizmodo: By continually requesting info from a server via the security toolkit, attackers could eventually get data worth keeping, such as passwords and personal photos.
Worse, the vulnerability lasted about two years from discovery to protection. It's since been patched — and if your products use OpenSSL, they most definitely should be — but countless people saw their personal info breached in the interim. Talk about scary.
A quick Google search of the term "SQL Injection Easy" returns a bunch of results. Moreover, the top link on the subject relays a warning best described as serious: "An SQL Injection can destroy your database."
To put it another way, SQL injection is no joke. At a high level, it looks a lot like Heartbleed in that attackers manipulate a server, causing it to hand out info it's not supposed to share. Here, however, the secret sauce comes in the form of web forms: If a sign-up page or similar input area doesn't include the correct security measures, data on the server an attacker interacts with is potentially at risk.
Protecting against injection once again shows the importance of paying attention to security from the beginning. The big thing is making sure your code is clean and protected before it ever hits the customer side; additionally, "sanitizing user-supplied data before using it in a query or command" is crucial to staying safe, as noted in the tutorial on preventing SQL attacks.
Cross-site scripting (also known as XSS) is one of those vulnerabilities that has been around forever. It's also a bit different from the previous two attacks listed here in how it works and whom it targets. Instead of going after a server, XSS is about the individual user — and that individual has to click some sort of malicious link in order for it to work. The results of that single click can be devastating.
As CA Veracode's breakdown of XSS says, an attacker can take remote control of a user's browser after a successful exploit and do a host of damage that includes seizing the victim's accounts and contributing to the spread of web worms.
Age hasn't made XSS any less common, either. At one point, 68 percent of all web apps were somehow exposed. While that number is much lower today, there are undoubtedly still countless variations of it causing trouble for companies and the end users who pay their light bills. That makes fixing it before it becomes a problem critical; anything less could make the people behind the app look like amateurs.
If there's a common thread among these attacks, it's that they can all be prevented by testing throughout the development of a project. There are countless variations of every security flaw described here — not to mention all the others causing trouble online these days. In a time when everyone's a techie, failing to address a commonly known problem can cause serious damage to a company's rep, deserved or not.
In other words, make sure your code is being tested all the time. Failure to do so will inevitably put everyone involved in a web app's life cycle at risk.
Photo Source: Wikimedia Commons