Mitigating the WASC Web Security Threat Classification with Apache: Part 3/Page 2
[previous] [next]
Mitigating the WASC Web Security Threat Classification with Apache: Part 3
Cross-Site Scripting
Cross-site Scripting (XSS) is an attack technique that forces a web site to echo attacker-supplied executable code, which loads in a user's browser. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.
When an attacker gets a user's browser to execute his code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify, and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his account hijacked (cookie theft), his browser redirected to another location, or possibly shown fraudulent content delivered by the web site he is visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site.
There are two types of Cross-site Scripting attacks: non-persistent and persistent. Non-persistent attacks require a user to visit a specially crafted link laced with malicious code. Upon visiting the link, the code embedded in the URL will be echoed and executed within the user's web browser. Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time.
Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to click on any link, just simply view the web page containing the code.
Cross-Site Scripting Examples
Persistent Attack
Many web sites host bulletin boards where registered users may post messages. A registered user is commonly tracked using a session ID cookie authorizing them to post. If an attacker were to post a message containing a specially crafted JavaScript, a user reading this message could have their cookies and their account compromised. This is shown in the following cookie-stealing code snippet:
Non-Persistent Attack
Many web portals offer a personalized view of a web site and greet a logged-in user with "Welcome,
In the preceding example, we see that the username Joe is stored in the URL. The resulting web page displays a "Welcome, Joe" message. If an attacker were to modify the username field in the URL, inserting a cookie-stealing JavaScript, it would be possible to gain control of the user's account.
A large percentage of people will be suspicious if they see JavaScript embedded in a URL, so most of the time an attacker will URL encode his malicious payload similar to the next example. The following is a URL-encoded example of a cookie-stealing URL:
Here is a decoded example of a cookie-stealing URL:
Apache Countermeasures for Cross-side Scripting Attacks
Client-side attacks such as XSS are extremely difficult to fully prevent from the web server side. This is the old chicken or the egg debate with regard to diagnosing who is responsible for a successful XSS attack. In order to be successful, both the web server and the client browser play a critical role. From the web server's perspective, they are responsible for the portion of this attack that allows an attacker to submit XSS data and then submit it back to other clients. So, we can help to mitigate the effectiveness of most XSS by identifying and blocking the attacker's attempts to upload the XSS data. As mentioned in a previous section, we can implement different Mod_Security filters to identify XSS data being uploaded to the server. Here are some additional filters:
Although these filters will detect a large number of XSS attacks, they are not foolproof. Due to the multitude of different scripting languages, it is possible for an attacker to create many different methods for implementing an XSS attack that would bypass these filters.
References
|
[previous] [next]
URL:
Find a programming school near you