We did NOT come up with the term “frame injection” (just do a Google search), neither did we claim we came up with a new technique. The only reason why there has been some media interest is because Google is something everyone can relate to.

Thanks a lot for your feedback again btw.

The reason the address bar reflects new url in a traditional url redirection attack is because the redirection is direct one (i.e. @page level).

Since in this case the the functionality of the frame is to load an external url- which is abused to load an arbitrary page inside that frame, it will never show up in address bar (not even for the legitimate page).

I repeat, an attacker is not injecting any frame into victim’s webpage. Only the content of the existing frame changes as the domain is not restricted. Then how can one call it frame “Injection”?

I think the debate may be endless. Instead i give it up here. Feel free to call it anything you want.

None the less, not a bad catch (just that it has been overhyped to reflect as a new kind of attack). I have always appreciated GNU Citizen for their innovations, but i cannot give credit for this one atleast.

It is called frame injection because the third-party content is inserted via a dynamically generated frame. Check the ‘frame’ tags in the source code for more info.

@Daniel: I’m actually against creating new vulnerability names, it just complicates things. The only reason I mentioned the term “frame injection” is because: 1) it’s NOT a new term. 2) the filtering solution needed is different to the one required for “pure” XSS/HTMLi vulnerabilities as the attacker doesn’t need to inject “dangerous” characters. At least generally speaking.

Instead of loading Fake Gmail page, you can load any page instead. The following loads yahoo :P

http://mail.google.com/imgres?...../yahoo.com

Can some one please explain me the rationale for calling it a frame injection?

bye
frank

I know it’s the rage at the moment to think up new and exciting names for vulnerabilities, but let’s try and keep this simple.

When we did the OWASP Top 10, we decided it would be easier to group them all under the same banner; Injection Flaws

http://www.owasp.org/index.php/Injection_Flaws

Take the example of a frame injection vuln. If you already know what URLs should be allowed to be inserted, then you should reject anything other than that. For instance, you could add the list of the trusted URLs in the backend DB, and assign a different ID to each of them. So that the URL only takes IDs as an argument. i.e.:

https://www.site.foo/index.php?targetframe=1

If ‘targetframe’ is assigned an integer value which doesn’t exist in the DB, then no frame is inserted whatsoever. The beauty is that the attacker cannot now manipulate the inserted frames. However, some sites cannot predict what URLs should be allowed to be inserted as frames. An example is the Google Images frame injection problem mentioned before.