The Danger of the Vulnerability

If you aren't an expert in security issues, you might think that JavaScript code can do no harm.

Of course, a JavaScript script cannot be dangerous. I'm not talking about vulnerabilities in browsers that can be exploited using JavaScript. First, browser vulnerabilities are beyond the scope of this book. Second, it doesn't matter, on which site a JavaScript script exploiting a browser vulnerability is executed; therefore, the XSS vulnerability isn't related to browser vulnerabilities.

The only case, in which XSS could be related to browser vulnerabilities, is when exploitation of browser vulnerabilities requires powers available only to the target site. The XSS vulnerability can be used for the following actions:

• Defacing a site, that is, changing the appearance of a target HTML page and deluding its users

• Obtaining a user 's cookie in the context of a target site

• Collecting statistics

• Performing concealed actions on behalf of the system administrator

• Fixing a session

The danger of changing the appearance of a target HTML page is obvious, and I won't comment on it here.

The most dangerous and common exploitation of the XSS vulnerability is obtaining a user's cookie in the context of a target site. In many authentication and authorization systems, cookies contain enough information for the attacker to obtain the access rights of a target user in the system. For example, a cookie can contain an unencrypted password, its hash, and a session ID. When a password is stored unencrypted, the situation is clear and doesn't need comments.

When a password hash is stored, the attacker can try to find the password from the hash. If the attacker is successful, he or she will have the disclosed password.

However, the attacker doesn't always need to know the password to authenticate in the system. If authentication in a system compares the hash of the original password with the value stored in the user's cookie, the attacker would just insert the stolen hash into his or her cookie.

A similar situation takes place when a cookie stores a session ID. To obtain the rights of the owner of the ID, the attacker would insert the ID into his or her cookie. In other words, if authentication in a system is based on COOKIE parameters and the user, whose COOKIE values were intercepted in the context of a vulnerable site, was authenticated in the system at that moment, an attacker can obtain this user's access rights by replacing his or her COOKIE values with the user's COOKIE values in the context of this site.

Because it is possible to intercept COOKIE parameters of the administrator of a site, forum, or chat, the attacker can exploit this vulnerability to obtain the administrator's access rights. With these rights, the attacker has many possibilities for investigating the system, obtaining additional information about the system and its users, and, perhaps, obtaining confidential information stored in the system.

Thus, the XSS vulnerability can allow the attacker to gain control over the system.

Exploitation of the XSS vulnerability to collect statistics deserves mentioning. Statistics about users can be collected in many parameters available through JavaScript. The collected data might contain confidential information that could allow the attacker to gain control over the server.

Performing concealed actions means that an attacker can use the XSS vulnerability to make the system administrator (or moderator) perform certain actions without the administrator's knowledge of them. The actions can be performed on behalf of the administrator (if he or she is currently authorized as the administrator), using his or her browser, and from his or her IP address. In other words, it will be possible to simulate the administrator's actions transparently to the administrator.

I will now explain each use of the XSS vulnerability thoroughly.