Attacking Via HTML Tags

Previously we discussed how a Cross-Site Request Forgery attack can occur without a Cross-Site Scripting breach or, as we called it, CSRF without XSS. CSRF attacks can also occur in conjunction with XSS breaches. Again, let's consider the example of Alice, who is logged into Site A, a site which she uses frequently and to which she has authorization information.

Remember that Alice doesn't always log out of Site A or clear her cookies when she's finished, which leaves her still authorized to make requests to Site A, as her authorization information for Site A is carried in the form of a cookie.

Again we need to assume that Alice has a bunch of other sites she likes to visit, too. One of them, Site B, allows users to post HTML tags. These factors make for easy attack tactics.

Example 1: Attacking Site A

In this scenario, Mallory is also logged on to Site A or can otherwise post unfiltered HTML tags to the Website, though he may not have the same privileges Alice does. For instance, Mallory may be an ordinary user and Alice an administrator or moderator.

Using that to her advantage, Mallory posts malicious HTML tags to Site A where Alice's web browser will see them. These can be any of the tags presented in the previous explanation, but since Mallory may not be an authenticated user on Site A her tags may be subject to filters. Only tags that can evade such filters (most often IMG tags) can be posted to Site A. Nonetheless, Alice's web browser makes any GET or POST requests to Site A that Mallory can trick the web browser into making.

The severity of the CSRF attack is dependent on the severity of the XSS vulnerability.

The level of filtering restricts Mallory's ability to post HTML tags to Site A. For example, a typical blogging or forum site usually allows users to post HTML fragments generated by a markup language like bbcode or RedCloth. The types of tags Mallory may be able to post through these markup languages are severely restricted. It may also be the case that if Site A implements a separation of what GET and POST requests can do, that Mallory won't be able to exploit the site via CSRF with an XSS attack.

Example 2: Attacking Site A from Site B

In this situation, Mallory wishes to attack Site A by exploiting another type of vulnerability (such as SQL injection), but she wishes to do so anonymously. This scenario isn't technically CSRF since there is no exploitation of assumed trust, but the same techniques as a CSRF attack are used.

Mallory has the ability to post malicious HTML on Site A. Alice also visits Site A but, depending on the details of the SQL injection attack, she doesn't necessarily have to be logged into Site A. Alice's web browser will see Mallory's malicious HTML tags and perform a malicious GET or POST request which will, in turn, perform the SQL injection attack. Since Mallory didn't actually perform the SQL injection attack on Site A, her IP address stays out of Site A's webserver logs.

It also may be possible for Mallory to go back after the attack and edit her malicious HTML tags to something innocent, further covering her tracks. To the administrators of Site A, it appears Alice has peformed an SQL injection attack. It will be difficult to uncover the fact that it was Mallory who first initiated the attack.

The SQL injection attack on Site A can also be performed from Site B. Since Mallory may have more control over the HTML tags on Site B, she may prefer to or be forced to perform the SQL injection attack from Site B. Once Alice visits Site B, her web browser will see Mallory's malicious HTML tags and perform the SQL injection attack on Site A. However, since the attack was performed from Site B, the HTTP referrer header will reflect this and may be saved by Site A's web server logs. Mallory may want to avoid this if Site B's identity is closely linked with her own.