Understanding Cross-Frame Scripting

websec.jpg

 

There’s a lot of confusion around Cross-frame Scripting.

 

I’ve seen a number of online resources that describe it as just another type of Cross-site scripting, which only makes sense if you also misunderstand Cross-site scripting.

 

A significant part of the misunderstanding comes from authoritative sources being unclear at best—if not outright incorrect—in how they explain the issue:

 

Cross-Frame Scripting (XFS) is a method of exploiting Cross-site Scripting (XSS). In an XFS attack, the attacker exploits a specific cross-frame-scripting bug in a web browser to access private data on a third-party website. ~ OWASP

This is a noble pass, but three things are wrong with this opening: a) you shouldn’t use the term you’re defining as part of its definition, b) we brought in XSS when it was unnecessary (and confusing) to do so, and c) at the end of these two sentences we still don’t know what XFS is.

 

Clarity

 

Let’s be more plain and direct in our language:

 

  1. Cross-site Scripting can best be thought of as “Forced JavaScript Execution”. The attacker either stores or reflects malicious JavaScript on a vulnerable website, which is then executed by the victim.
  2. Cross-frame Scripting is best conceptualized as “Data Leakage Through Frame Embed”. It’s a browser bug that allows an attacker to embed a victim’s site in their own, within a frame, and then spy on what’s done on the victim site (like logging in).

Notice how different these are. One is basically arbitrary code execution, while the other is data leakage through what’s far more similar to a phishing attack.

 

Another way to see how distinct they are is to consider the defenses. With XSS the solution is input validation and output sanitization. With XFS the common advice is frame-busting and hoping your users aren’t using broken browsers to visit malicious websites.

 

Big difference.

Summary

  1. XSS is about forced code execution due to a vulnerability on your website
  2. XFS is about phishing-style data leakage via someone embedding your site into a malicious page through an iFrame

About HP Fortify on Demand

 

HP Fortify on Demand is a cloud-based application security solution. We perform multiple types of manual and automated security testing, including web assessments, mobile application assessments, thick client testing, ERP testing, etc.--and we do it both statically and dynamically, both in the cloud and on-premise.

 

Ping us with any thoughts, questions, or comments.

 

: :
 
Daniel Miessler is a Practice Principal with Fortify on Demand based out of San Francisco, California. His areas of expertise are web and mobile application security testing and building application security programs for the Global and Fortune 100. He can be reached at daniel.miessler@hp.com and on Twitter at @danielmiessler

Tags: webappsec| XSRF| XSS
Labels: webappsec| xsrf| XSS
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
http://www.danielmiessler.com/about
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.