Content Spoofing

Posted in Technopedia, Application Security

Content spoofing is a type of exploit used by a malicious hackers to present a faked or modified Web site to the user as if it were legitimate. The intent is, typically, to defraud victims (as in phishing) although sometimes the purpose is simply to misrepresent an organization or an individual. Content spoofing often exploits an established trust relationship between a computer user and an organization.

Text Only Content Spoofing

A common approach to dynamically build pages involves passing the body or portions thereof into the page via a query string value. This approach is common on error pages, or sites providing story or news entries. The content specified in this parameter is later reflected into the page to provide the content for the page.

Example:

http://foo.example/news?id=123&title=Company+y+stock+goes+up+5+percent+on+news+of+sale

The "title" parameter in this example specifies the content that will appear in the HTML body for the news entries. If an attacker where to replace this content with something more sinister they might be able to falsify statements on the destination website.

Example:

http://foo.example/news?id=123title=Company+y+filing+for+bankrupcy+due+to+insider+corruption,+investors+urged+to+sell+by+finance+analyists...

Upon visiting this link the user would believe the content being displayed as legitimate. In this example the falsified content is directly reflected back on the same page, however it is possible this payload may persist and be displayed on a future page visited by that user.

Markup Reflected Content Spoofing

Content SpoofingSome 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". Unlike redirectors, 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 e-mail, instant messages, left on bulletin board postings, or forced upon users by a Cross-site Scripting attack [5]. 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, etc.

Example

Creating a spoofed press release. 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:

Code Snippet:

<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 example above 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:

Code Snippet:

<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. It is important to understand that if you are vulnerable to Cross-Site Scripting (XSS) you are likely vulnerable to content spoofing. Additionally you can be protected from XSS and still be vulnerable to Content Spoofing.
References:
http://tbtf.com/archive/11-17-98.html
http://projects.webappsec.org/URL-Redirector-Abuse
http://blog.wired.com/business/2009/01/wiredcom-imagev.html
http://projects.webappsec.org/Cross-Site-Scripting
http://projects.webappsec.org/Content-Spoofing

Share This

Comments (0)

Leave a comment

Please login to leave a comment. Optional login below.