CROSS-SITE SCRIPTING: SESSION ID THEFT

Week Nine ↓

 Popularly known as “XSS” or “CSS” attacks, this application-level session hijacking attack is used to gain unauthorized access via client-side scripts. This is achieved by exploiting vulnerabilities in web applications with dynamically generated web pages. One of such vulnerabilities is unvalidated input where a client input is not validated before being processed by a web application and backend server (Oriyano, 2016). An attacker can exploit this flaw to perform a Cross-site scripting attack. An attacker could achieve this by injecting malicious JavaScript, VBScript, HTML, ActiveX requests to be executed. The crafted link then runs and completes the instructions made by the attacker. Some common motives of XSS attacks include; data theft, redirecting to a malicious server, exploiting user privileges, interfering with session information.

 

XSS attacks come in two main forms presented below:

Stored XSS attacks: In these attacks, web applications allow attackers store data on target servers, comment fields, message forum. “Once this happens, their data

will be part of the site, and when a subsequent visitor comes to the site, they

inadvertently run the same data” (Oriyano, 2016). This type of XSS attacks are also called Persistent or Type-I XSS attacks.

Reflected XSS attacks: Here, Injected script is bounced or reflected off a webserver as an error message, search result or some other response. The attack is done via another route which could be via email or some other website. A browser executable code is injected within a single HTTP response upon clicking a link. The injected code travels to the vulnerable web site and the attack is reflected to the user’s browser, the code which reflects the attack back to the user’s browser is executed. This type of XSS attacks are also called Non-Persistent or Type-II XSS. Reflected XSS attacks are relatively easier to carry out.

Xssed.com is an online archive of VSS vulnerable websites.

Countermeasures

All cookies, headers, form fields query string and other parameters should be validated against a specification of some sort;

Web application firewalls should be used to block execution of malicious script;

XSS attacks are not dependent on HTTPS/HTTP connections, in essence, trust no website;

Test for XSS flaws in applications before they are rolled out;

Scripts could be signed using asymmetric cryptographic keys to ascertain the authenticity of the script.

REFERENCE

Sean-Philip Oriyano. (April, 2016). CEH v9: Certified Ethical Hacker Version 9 Study Guide, Edition 3.

Video Credit: Danscourses. Sept 28, 2012