| home / reviews / web_attacks_apache3 |
|
|
|
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 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
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
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:
References
|
| home / reviews / web_attacks_apache3 |
| ||||||||||||||||||||
URL:
