Performing Concealed Actions on Behalf of the Administrator

In this section, I am referring to an attack that makes the system believe that the administrator performs certain actions.

In the most common and dangerous situation, the administrator has to make an HTTP GET request to perform actions. A frequent action is a deletion or other change to the status of a topic, branch, or message by following special links.

Such links appear next to the forum, message, or branch on the administrator's panel and usually look like the following:

• http://www.test.ru/forum/delete_topic.php?id=42554

• http://www.test.ru/forum/delete_forum.php?id=1235

In a well-designed authentication and authorization system, only the administrator can access these resources.

However, in most systems, the secondary authentication and authorization procedure is done transparently to the administrator for the administrator's and the users' convenience. (Remember, the secondary authentication and authorization procedure takes places after the primary one, which involves entering the login and the password.) For example, the secondary authentication and authorization procedure is done with the session ID stored in the user 's cookie, or HTTP Basic authentication takes place.

Suppose each user of a forum can add images with any URLs. This isn't a vulnerability per se. It can be a documented feature of the system. What's more, it is a common practice to implement such a feature.

Now, suppose a user pretends to add an image to his or her message but actually specifies one of the URLs listed previously:

http://www.test.ru/forum/delete_topic.php?id=42554

What happens if the authenticated and authorized administrator opens this message in his or her browser? If displaying images is enabled in the browser, it will request the image from that URL to display the message. In other words, the browser will request an URL that changes the status of a message on the server.

In addition, in most authenticating systems, the browser will send all the data necessary to authenticate the user. Because the request will be sent from the browser whose user is already authenticated and authorized as the administrator, the sent data will be the administrator's.

This means the authentication and authorization will be successful for this script if the system is based on authentication methods such as storing the user's session ID, login, or password in cookies or if it is based on the HTTP Basic authentication (or, perhaps, another authentication method). As a result, a script whose URL was embedded as an URL of an image performs actions as if it was executed by the system administrator.

This is how an attacker can make the system administrator unwittingly fulfil actions that require the administrator's rights. The only requirement of this attack is that the script should be available and take all parameters using the HTTP GET method.

I'd like to reiterate that the XSS vulnerability isn't necessary for this attack.

If the attacker can send a message with an added image directly to the system administrator, the targeted attack is possible.

In a more complicated case, in which a complex POST request is needed for certain actions but the XSS vulnerability is present, the attacker can exploit the vulnerability by creating an HTTP POST form with appropriate values of the action and hidden parameters and by sending the form using JavaScript tools to simulate the administrator's actions.

To launch a transparent attack, the attacker can exploit the XSS vulnerability to send an HTTP POST request containing an iframe element located in the invisible layer and specified as the target value of the form. The attacker also can launch a targeted attack on the administrator if he or she can send a message directly to the administrator.

In both cases, the value of the HTTP Referer header contains the address of the vulnerable site. This can be checked by a script of interest to the attacker.

Even if the site is free from the XSS vulnerability, the attacker can create a malicious HTML page that contains an HTTP POST or GET form with appropriate values of the action and hidden parameters and send the form using JavaScript tools.

The attacker would probably put this HTML page on a server under a fabricated pretext.

A more sophisticated attack could involve embedding a link to an image and configuring the malicious server so that it returns an HTML page containing the form described earlier, whose target should be an iframe element in the invisible layer. The form should also contain an image that would cover it entirely. As a result, the attack would be unnoticeable by the administrator.

In addition, the link to such a malicious HTML document can be foisted on the administrator through XSS vulnerabilities in other resources.

Note that this attack doesn't require the XSS vulnerability on the target site.