3

I've received a recent security review of a website which mentioned it had a cross frame scripting vulnerability. In short, it mentioned that a malicious site could load the page up in an iframe, fooling the user to think the are on the legitimate page for the application, while overlaying controls and such to gather data and do other malicious activity. But I have also heard that an XFS is when an XSS attack is used to inject an iframe into your application pointing at a malicious site which then allows the malicious site loaded in the frame to gather data from those using your application as well as other malicious activities.

So, are these both cross frame scripting attacks because they both use iframes as a key element? Or is only the first attack an XFS while the second one is considered a version of XSS using iframes?

P.S. XSS and CSRF both have tags, is there a reason XFS doesn't?

Jedi
  • 3,906
  • 2
  • 24
  • 42
Lawtonfogle
  • 981
  • 7
  • 11

2 Answers2

5

Though this being an old question, I'm adding an answer for future viewers.

"Cross-Frame Scripting" is basically data leakage that can happen when an attacker embeds a victim's website into a frame within their own website and monitor/spy on the activities does on the framed website. An attacker can register a JavaScript listener which listens to all key events on the page. The spying is possible because, the (buggy) browser notifies the listener of key events even from the framed victim's webpage. Thus, the attacker can embed the victim's login page in their website (in an iframe) and thus obtain the login credentials of an innocent victim.

"Cross-Site Scripting", on the other hand is actually more of a forced JavaScript execution where an attacker injects/reflects malicious JavaScript which is then executed on the client's browser.

XFS prevention revolves around frame-busting or adding x-frame-options in HTTP headers, equal to either DENY (informing the browser to never frame the website) or sameorigin (frame only if in the same context). XSS prevention, however, is more concerned with input sanitization.

That being said, in the scenario you described, the first case is an example of an XFS attack, while the latter can be considered as an example of an XSS attack involving frames.

Shubham Mittal
  • 151
  • 1
  • 2
4

A vulnerability does not exists until someone creates a Proof of Concept or method of exploiting a given software defect.

"Cross-Frame Scripting" does not exist, and is a horrible name. That being said OWASP has a disorganized entry for Cross-Frame Scripting.

Frames have scripting rights and protections granted by the Same-Origin Policy. A script executing on a parent cannot read the contents of a child iframe that is of another domain. iframes can be useful in exploiting XSS, but so are <form> and <input> tags.

This tool is probably reporting clickjacking, which can be exploited with or without JavaScript. To prevent clickjacking just add the HTTP header element: x-frame-options: sameorigin. It is very easy for a poorly written security tool to report the lack of x-frame-options as a vulnerability without taking into consideration if its actually exploitable.

(XSS and CSRF have tags on security.se because they are real. "XFS" is a mistake and there will never be this tag on security.se.)

rook
  • 46,916
  • 10
  • 92
  • 181