#cross scripting

Categories of Cross-site Scripting

Cross-site scripting is a Web-based security vulnerability in which a user instead of a Web application is attacked. During such an attack, a vulnerable Web application is exploited to deliver malicious content to users via script. This content can include HTML or JavaScript code and appear as a persistent, a reflective or non-persistent, or a DOM-based attack.

Reflective - Reflective cross-site scripting vulnerabilities occur when a Web application reflects part of an HTTP request back to the user without first sanitizing it. A common way this happens is when the malicious code is included as a GET or POST parameter. In order for an attacker to exploit a reflective Cross-site Scripting vulnerability, the attacker must somehow entice a victim into initiating the request from his or her own browser, for example, by clicking on a malicious link in an email.

Persistent - Persistent cross-site scripting vulnerabilities occur when a Web application stores user-generated data and then later displays this data back to the users of the application. This is common for many Web applications such as wikis, online forums, and social networking sites. If this data is not properly sanitized before being displayed in the client browser, then any user of the application can potentially become a victim. Persistent cross-site Scripting vulnerabilities are more dangerous than reflective ones since the attacker does not have to entice other users of the Web application into performing any suspicious actions.

DOM-based - DOM-based cross-site scripting vulnerabilities usually affect applications that perform client-side processing of user input using JavaScript. Many applications rely on pages that contain client-side scripts that dynamically generate HTML content. Based on certain user input, these pages modify their HTML without any interaction with the server. A DOM-based Cross-site scripting exists when it is possible for an attacker to inject a malicious script through such a page without submitting any data to the server. This time, unlike for other types of Cross-site Scripting, it is the client-side script that is responsible for not properly sanitizing the user input, rather than the server.

Consequences of Cross-site Scripting Vulnerabilities

Altering the response HTML - Since the malicious code executes in the context of the victim user’s session, it has access to all the DOM elements on the page that is affected by the Cross-site scripting vulnerability. By altering the DOM, elements of the Web page can be hidden or removed, and new elements can be added, effectively modifying the appearance of the page.

Hijacking sessions - An attacker can execute any client-side code, such as JavaScript, within the browser, which allows the attacker to access the victim user’s session token stored in a cookie. This can enable the attacker to hijack the victim’s session on the vulnerable application.

Instantiating ActiveX controls - An attacker can manipulate ActiveX controls to gain greater access to a victim user’s local machine than is normally allowed. Note that ActiveX components typically require user approval before running.

Performing background HTTP requests - An attacker can cause the victim user to make requests to other pages within the Web application, to other unrelated Web applications, and even to applications located behind the victim’s firewall. Such requests can occur without the victim knowing about them.

Arbitrary code execution - The attacker can inject exploits targeted at unpatched vulnerabilities in Web browsers and their plugins.

Preventing Cross-site Scripting Vulnerabilities:

To prevent Cross-site Scripting vulnerabilities, you should URLEncode all user input that is returned as part of URLs. This will convert ?, &, /, <, >, and spaces to their respective URL encoded equals. Additionally, you should HTMLEncode all user input returned as part of HTML. This will also convert special characters into their respective HTML encoded equals. Last but not the least, you should convert all user input to a single character encoding before parsing. This applies to Single/Double Hex Encoding, Unicode Encoding, and UTF-8 Parsing.

In order to avoid Cross-site Scripting vulnerabilities, you can perform the following actions:

URLEncode all user input returned as part of URLs (convert ?, &, /, <, >, and spaces to their respective URL encoded equals).

HTMLEncode all user input returned as part of HTML.

Convert all user input to a single character encoding before parsing.

Mekanisme pertahanan menghadapi serangan ini adalah dengan melakukan validasi input sebelum menampilkan data apapun yang di-generateoleh pengguna. Jangan percayai apapun data yang dikirim oleh pengguna.

Stored XSS

Stored XSS lebih jarang ditemui dan dampak serangannya lebih besar. Sebuah serangan stored XSS dapat berakibat pada seluruh pengguna. Stored XSS terjadi saat pengguna diizinkan untuk memasukkan data yang akan ditampilkan kembali. Contohnya adalah pada message board, buku tamu, dll. Penyerang memasukkan kode HTML atau client script code lainnya pada posting mereka.

Serangan ini lebih menakutkan. Mekanisme pertahanannya sama dengan reflected XSS: jika pengguna diizinkan untuk memasukkan data, lakukan validasi sebelum disimpan pada aplikasi.