Application Security: Cross-site scripting (XSS)

Professional web development standards are very high nowadays. It doesn’t matter how big your team or budget. Application Security is extremely important for project of any size. Huge software companies may even have separate departments working on security tasks only. There are manual code review of existing solutions, automation of scanning for well-known vulnerabilities by special tools, writing unit and integration tests, research the cases, implementation of modern approaches. On the other hand, if you are sole developer in your startup (or even single contributor at all), you have to spend some time playing this role as well.

Sources of the harmful code

Cross-site scripting or XSS is the most widely exploited security hole in Web. At first sight, it seems not very dangerous for Application Security, because there is no obvious way to harm the system or damage the data on the server side. Generally, the main goal of XSS attack is to execute custom JavaScript code in the browser of the user. To be executed, that code have to pass into the page in some way. There are 2 options for hacker to achieve it. First, and the most known, is saving JavaScript code as a part of Web 2.0 content on the server side provided by users of the service. E.g., comments on the forum. Such content is not trusted, so, should be filtered for danger HTML tags or even strip them at all. Otherwise, hacker may put any JavaScript code into script tag or other more sophisticated place. Another way to inject code into the page is reflection. It means reflection against dynamic server page or web-service endpoint. Usually, a code is going inside HTTP parameter or even as part of URL. If server doesn’t catch such case, the code may be transferred back to the browser and executed under specific circumstances.


There are several places where XSS code may be applied. The simplest way is to put the code right into the page. There may be a bit of logic execute at once or a function, which execution is delayed till some event happened. E.g., mouse_click or mouse_over. As it’s a well-known method, it’s probably secured first of all. Hacker may use DOM to place his code into attribute of some tag allowed by the system. E.g., attributes for tag may not be filtered carefully. There is Application Security problem that should be fixed anyway. As you can see, it’s not enough to avoid HTML tags only. Generally, it needs to escape all occurrences of 6 characters: <, >, &, ”, ’ and /.


XSS code may not just change presentation of the data in unauthorized way. It can redirect browser to incorrect page or another web site completely. E.g., automatic redirect to another service on specific forums by harmful comments, that looks even worse than regular spam. It’s possible to get any information are saved on the client side. That become more important nowadays, because modern client applications are rich and hold a lot of information cached locally. First of all, there are cookies, that may be sent to a hacker’s system. To avoid such kinds of attack it needs to use HttpOnly flag.

There is HP Fortify tool widely used to scan web applications for places in the code are danger at line of XSS and other attacks. The reports produced by the system contains the list of such points in code with description and further steps how to fix the issue.


Read also

Comments are closed.