Mitigating the WASC Web Security Threat Classification with Apache: Part 3/Page 2
Mitigating the WASC Web Security Threat Classification with Apache: Part 3
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
Many web portals offer a personalized view of a web site and greet a logged-in user with "Welcome,
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.