Synergies in Application Security Vulnerabilities: Part I
As a self-proclaimed tech-junkie and a professional penetration tester, I have often been asked, “What is the most critical vulnerability you have come across?” The difficulty in answering a question like this is that the severity of a vulnerability depends on the context of the attack–discovering a DOM-based Cross-Site Scripting vulnerability in an otherwise secure application may earn a hacker bragging rights amongst his or her peers, but the finding might not be useful for exploiting sensitive data. Similarly, two simpler vulnerabilities used together could give someone full control over an entire application.
Here are a few common vulnerabilities that work well together:
Cross-Site Request Forgery + Method Interchange
Cross-Site Request Forgery (CSRF) is an attack in which hackers trick a victim into loading a page that contains a malicious request. Hackers can leverage this vulnerability to unintentionally send requests to the server of a different application. For example, if your bank’s web application was vulnerable to CSRF, an attacker could create a malicious blog where the comment submission button caused you to transfer money from your account. As the unsuspecting victim, you would be confused as to why your comment didn’t post on the blog and just keep clicking away ☺. Typically, a synchronizer token is used to identify genuine requests and prevent this vulnerability.
Method interchange is a vulnerability in which HTTP POST requests can be sent as HTTP GET requests and vice versa. The presence of method interchange opens up new attack vectors for CSRF, as many web frameworks have default protection against POST requests but do not have default protection against GET requests. As a result, many of the out-of-box security mechanisms meant to protect against CSRF can be bypassed by having a victim click on a malicious URL…. Food for thought next time someone sends you an email that looks something like this:
Session Fixation + Cross-Site Scripting (Bonus points for not setting the HttpOnly flag on Cookies)
Session Fixation is a fairly common, lower severity vulnerability. Generally speaking, session fixation occurs when the pre-authentication session cookie is the same as the post-authentication session cookie. If an attacker can grab ahold of the pre-authentication session cookie, then once the user authenticates, the attacker will have access to the user’s session.
If an application is vulnerable to cross-site scripting, the attacker can simply inject some custom JavaScript that sets the user’s session cookie–allowing the attacker to fixate the victim’s session. The HttpOnly flag can be used to protect against this attack, as cookies set with the HttpOnly flag cannot be accessed by client-side scripts. That being said, HttpOnly flags are typically not set by default, and many developers overlook this seemingly minor detail.
Username Harvesting + Overly Restrictive Lockout Mechanisms
Username harvesting/enumeration is a very common low-risk vulnerability that allows attackers to determine valid usernames for an application. An attacker with enough time on his hands can simply iterate through a large payload of possible user IDs and generate a pretty comprehensive list of valid IDs.
Overly restrictive lockout mechanisms can cause users to be locked out after a few incorrect login attempts. Putting both of these vulnerabilities together, an attacker could potentially enumerate a full list of users and run an automated script that continually sends login requests to the server. This would effectively lock every user out of the application, leading to a user-level denial of service attack that would severely cripple the application. Of course, in this attack, the attacker doesn’t gain any privileged user information, but it could cost the company that owns the application millions of dollars. Something to think about next time you rub a hacker the wrong way :P.
SQL Injection + Client Side Hashing
Okay, let’s be real for a moment: if you’re pen-testing an application and find SQL injection, then you’ve pretty much won. You have gained bragging rights amongst your peers and deserve to be garlanded in a festive parade by your clients, who would have otherwise been featured in a cable news special regarding their “CRITICAL CYBER SECURITY LEAK”. SQL injection is a security vulnerability in which an attacker is able to escape out of a SQL database query string and inject malicious code, effectively gaining direct database access. In the application security world, SQL injection is considered to be one of the most serious attacks, yet ironically enough, OWASP consistently ranks it as one of the most common web application vulnerabilities.
One of the ways to protect passwords from database breaches is password hashing, in which the application appends a few random characters to the user-inputted password (to maximize entropy) and then sends the new string through a hashing algorithm. This ensures that even if a password store is compromised, at least the passwords are not discernible to the hacker… well, unless they are being hashed on the client side. If the password is being hashed on the client side, then that means that a hashed password is being sent to the server and an attacker can use the hashed password datastore to effectively impersonate every user on the application. Or depending on his/her mood, the attacker could just destroy the whole database table.
The Bottom Line
The tech-world today is accelerating at an incredibly rapid rate. Every day, more and more zero-day vulnerabilities are exposed and new attack vectors are created. The previously held belief that having no critical vulnerabilities equates to a secure environment has become a myth. It has become increasingly important for companies to harden their application against all vulnerabilities, regardless of the severity.
Let us know what your thoughts are by posting a comment below! We would love to hear about different vulnerabilities that you may have encountered which work well together. Particularly insightful responses will be featured in Part II!
