Web Security

Web security is something you need to think about if you are building a web site or a web application. I wish I could say that all security problems that web sites have are found and automated defense systems are developed so there are no security problems anymore and you don’t have to worry about it, but unfortunately, the opposite of that is the case. As more and more people put stuff on the web, it is getting harder and harder to make sure that all the security issues are covered. Web applications get more complicated as web browsers get more complicated, and all of that complexity means that there are a lot of things to think about to make a secure web application. I will briefly present the two biggest attacks: Cross-Site Scripting, Cross-Site Request Forgery. These attacks have been the chart-topping vulnerabilities for at least five years.

Cross-Site Scripting

If you are an attacker who wants to attack someone’s online account and read their e-mail or steal money from their banking account, then you are most likely going to use Cross-Site Scripting (XSS or CSS), which is the most popular type of web attack in the world. If you don’t know what XSS is, you don’t know anything about web security.

So what is XSS? It is a vulnerability that web sites have, where the attack can inject script into your session and basically drive the site using JavaScript. There are several different types of XSS vulnerabilities. First, there is Reflected XSS, which means that the server is taking some data from the request URL and that data appears in the response. There is Stored XSS, which means that the data is actually coming out of the database and then appearing in your document, and there are some other advanced types of XSS.

Let’s look at the basic XSS, Reflected XSS. This is how the attack works. The attacker somehow gets an introduction to the user; the user visits a malicious URL that is crafted by the attacker. That page has a link to a victim web site that is vulnerable to XSS. Once you click on it, the victim server takes the malicious data from the crafted URL and echoes it back to the user. Then the user runs the malicious code on the origin of the victim site. This means that any private data associated with your session with the victim server is at risk. So the attacker can do something like steal your e-mail and send it to the attacker’s server.

Now let’s talk about Stored XSS. Stored XSS vulnerability means that you are not just echoing something from the query parameter into your output, but you actually are taking out some data from the database that is malicious and putting into your output. The way this attack might work is that the attacker has its own account on the victim server and posts some comment that contains malicious script. The script is downloaded when a user views the post and the script will execute on the origin of the victim server which enables the attacker to get session cookie data from the user.

Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF), also known as a one-click attack or session riding, is a way to trick a server into processing a request that is not intended by the user. Say that you log in to your banking web site. Then the browser is going to setup a session for that site and a session cookie will be sent in all subsequent requests. The user now visits the attacker’s web site which contains malicious code and it will be able to send the user authentication cookie with a valid request, so the attacker can execute a transaction from the users account to its own account.

But there are three mechanisms to defend against CSRF: Secret Validation Token, Referer Validation and Custom HTTP Header. Secret Validation Token is the most popular way of defending against CSRF, and probably the best way. Basically what you do is you come up with a hard-to-guess secret and attach it to all requests, then the site has to check all request for the token and decide whether or not to accept the request. Another way to prevent CSRF attacks is to use the Referer header, which gets attached to every request that was initiated by a web site. The web site that receives the request checks the Referer header and if it sees its own URL, the request is accepted. However, it is not used often because of privacy issues. Finally there is one more way to block CSRF, the Custom Header Defense. This defense uses the XMLHttpRequest header to comply with the same-origin policy. But it can only be used for web sites that use a single domain.

Reference:

[1] Cross Site Scripting Explained, Amit Klein

[2] Robust Defenses for Cross-Site Request Forgery, Barth et al.

[3] http://en.wikipedia.org/wiki/Cross-site_scripting

[4] http://en.wikipedia.org/wiki/Cross-site_request_forgery