At work I have been participating in a cyber security war games event where each week new challenges are posted. They focus on
OWASP Top 10 web application security flaws. It has been fun because we get to actually exploit the flaws in an application hosted for the war games, instead of just reading about them or watching a presentation.
I think these types of vulnerabilities are something any web developer should be aware of, even if you do not deal with security on a daily basis, so when you are coding something that could be vulnerable you at least recognize it and can do more research, more testing, ask an expert, etc.
I have needed two tools to complete the challenges. First, I used
Firebug to inspect HTML, JavaScript, and cookies. Second, I used the proxy server that is part of
Burp Suite. The idea is that your browser sends requests to the proxy and the proxy forwards them on to the real destination, but before the proxy forwards them you have a chance to view/change the request.
Below are my notes plus more research I have done, mostly focusing on how to prevent them in the first place. After all, I am supposed to be learning how to write more secure code not how to be a hacker.
SQL Injection
A
SQL Injection attack can occur when a web application accepts user input and uses it as part of a SQL query. If the input is not properly filtered, then the attacker can provide partial SQL instead of valid input and obtain information they do not have access to.
A common example is: ' OR '1'='1
The best way to prevent this type of attack is to use
prepared statements combined with the
principal of least privilege and
white-list input validation.
Broken Authentication And Session Management
Broken authentication and session management can be exploited when, for example, user credentials are not encrypted (encoding is not the same as encryption) in an HTTP request or passwords are not properly hashed in a database or sessions do not timeout. These would lead to an attacker being able to access someone else's account.
There is not a single best practice here as there are many attack vectors, but OWASP provides detailed cheat sheets for
authentication and
session management that should be read in their entirety.
Cross-site Scripting (XSS)
An
XSS attack can occur when a web application accepts user input and includes it in a page that will be seen by other users. If the input is not properly filtered, then the attacker can insert code that will send user credentials to them (like a form submitted to another website).
A common, demonstrative example is: <INPUT TYPE="BUTTON" ONCLICK="alert('XSS')"/>
The best ways to prevent this type of attack are to escape HTML, JavaScript JSON, CSS, and URL inputs.
Insecure Direct Object References
Insecure direct object references can be exploited by an attacker who changes a parameter value that refers to a system object, to a value for a different system object they do not have access to. This might mean changing a parameter in a URL or using the proxy to change data in the HTTP request.
The best way to prevent this type of attack is to use indirect object references and have the application map from the indirect object reference to the actual key. If you must expose direct object references, then verify, for each object reference, that the user is authorized for that object.
Cross-site Request Forgery (CSRF)
A
CSRF attack can occur when a user, whom is authenticated with a third site, visits an attacker's site (or a site which was the victim of his XSS attack) and a hidden, forged HTTP request is submitted to the third site. Because the user is authenticated with the third site already, their browser will automatically send their session cookie along with the forged request and it will be indistinguishable from a legitimate request.
CSRF seems to be particularly effective when the user falls victim to the attack just by loading a page. The XSS code might not even be visible to the user. An image source from a URL would do this, or for a HTTP POST a hidden form will achieve the same thing:
<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0" />
<form name="csrf" action="
http://example.com/app/transferFunds" method="post">
<input type='hidden' name='amount' value='1500'>
<input type='hidden' name='
destinationAccount' value='
attackersAcct#'>
</form>
<script>document.csrf.submit();</script>
Preventing CSRF requires including an unpredictable token with each HTTP request. It must, at least, be unique to a session. It it usually included in a hidden field so it will be included in the body of the HTTP request, thus being less exposed than in the URL itself. A CAPTCHA can also be helpful in determining if a request came from a real user.
Insecure Cryptographic Storage
Like with broken authentication and session management,
insecure cryptographic storage is a broad category
of application mistakes that can be exploited. Attackers can, for example, find encryption keys, gain access to a database that automatically decrypts data, or a weak encryption algorithm is used.
To protect against this kind of vulnerability, there are several steps to take:
1. Sensitive data should be encrypted if it is stored long-term, and the key should be stored separately
2. Strong, standard encryption algorithms should be used along with proper
key management
3. Passwords should be hashed and a
salt should be used
4. Never store unnecessary data
5. Infrastructure credentials like passwords in a config file should be protected with file system permissions
Failure To Restrict URL Access
An application that
fails to restrict URL access gives anonymous users access to pages that should be protected. The attacker might guess an admin URL or even change the CSS in their browser to show something that was hidden.
To prevent these types of attacks, the application needs to always verify that the user is authorized and not just hide links and buttons that they are unauthorized for. Authentication and authorization policies can be role-based to minimize the effort of maintaining them. They should be easily configurable and not hard-coded.
Invalid Redirects And Forwards
Invalid redirects and forwards occur when an attacker links to a site's redirect page and specifies the redirect as a malicious site that contains
malware or does
phishing.
If you cannot avoid using redirects and forwards, then check that the supplied destination parameter is valid and authorized for the user. Destination parameters can also be a value that is mapped to a URL on the server.
