Comments on: Hijacking Innocent Frames

By: Top Ten Web Hacking Techniques of 2008 : RootBrain.Com · The Best IT Security Training & Consulting · Pusat Pelatihan dan Konsultasi TI Terbaik di Yogyakarta

Mon, 14 May 2012 08:41:21 +0000

[...] Navigation Hijacking (Frame/Tab Injection Attacks) [...]

By: pdp

pdp — Thu, 24 Jun 2010 10:50:27 +0000

I’ve long realised that research should stay as a hobby. :) rather than means for making money. There are other more practical ways of earning your living.

By: The Rook (Michael Brooks)

The Rook (Michael Brooks) — Sun, 20 Jun 2010 20:56:47 +0000

Hey PDP people are ripping off your research! I guess its a complement of your visionary hacks :)

http://www.azarask.in/blog/pos.....ng-attack/

By: What’s new in web hacking techniques of 2008

What’s new in web hacking techniques of 2008 — Tue, 09 Feb 2010 05:37:06 +0000

[...] Navigation Hijacking (Frame/Tab Injection Attacks) [...]

By: Le migliori tecniche di Web Hacking del 2008 | lonerunners.net

Le migliori tecniche di Web Hacking del 2008 | lonerunners.net — Sun, 15 Mar 2009 17:21:35 +0000

[...] Navigation Hijacking (Frame/Tab Injection Attacks) [...]

By: Every Link You Click is Dangerous | GNUCITIZEN

Every Link You Click is Dangerous | GNUCITIZEN — Wed, 25 Feb 2009 13:50:06 +0000

[...] not an extremely devastating vulnerability but the issue, which I have reported here and also logged in Mozilla’s bugzilla 3 months ago, is still present and works quite well. [...]

By: Heuristic Delta :: Top 70 Hacking Methods :: http://blogs.heuristicdelta.com

Heuristic Delta :: Top 70 Hacking Methods :: http://blogs.heuristicdelta.com — Wed, 25 Feb 2009 07:45:29 +0000

[...] Navigation Hijacking (Frame/Tab Injection Attacks) [...]

By: polonus

polonus — Fri, 13 Feb 2009 22:14:15 +0000

Why is not there a decent online iFrame vulnerability scanner? We had Jutaky’s iFrame Detektor, but that has gone offline somehow…

Now we have to construct our own queries like feed this to Google, and see how your firekeeper flags this…

polonus

By: ??? » Blog Archive » What’s new in web hacking techniques of 2008

Tue, 03 Feb 2009 04:19:29 +0000

[...] Navigation Hijacking (Frame/Tab Injection Attacks) [...]

By: lavakumar

lavakumar — Mon, 15 Dec 2008 06:52:00 +0000

Your are right, looks like it only works from firebug…my bad.

By: pdp

pdp — Sat, 13 Dec 2008 18:58:16 +0000

hmmmmm, I don’t think that fuzzers will work for finding design bugs… overflows yes, but not design bugs.

By: paulos

paulos — Sat, 13 Dec 2008 17:20:44 +0000

Hello, yes you are right, there are many not discovered bugs, or just not released, design bugs in web browsers as you said. I think that the best way to detect/discover them all is just makeing more and more fuzzers, i am almost sure that there are many specific bugs :)

By: Friday Summary: 12-12-2008 | securosis.com

Friday Summary: 12-12-2008 | securosis.com — Sat, 13 Dec 2008 02:33:04 +0000

[...] numbers for no good reason. This type of scam is not hard to do, as this mini How-To discussion on GNUCitizen shows how simple psychological sleight-of-hand , when combined with a surfjacking attack, is an [...]

By: pdp

pdp — Fri, 12 Dec 2008 19:46:16 +0000

lavakumar, yes you can do that from Firebug but it wont work from a HTML page as far as I know, unless you are looking into some kind of a bug.

By: lattera

lattera — Fri, 12 Dec 2008 16:36:04 +0000

This attack isn’t new. In fact, it’s used in a standard called SCORM. SCORM requires a javascript API to be loaded in a parent frame (or window.opener if a pop-up). The javascript API must make calls in behalf of the SCORM module. The javascript API could do what it wants, including changing the location.href of another frame (or pop-up).

By: Matt

Matt — Fri, 12 Dec 2008 14:37:01 +0000

Good write up; it seems like in principle our issue is that scripts from a previous page are running on the current one. The solution may be something along the lines of my understanding of the Google Chrome model. When you leave a site, that page dies with the executable and a new one is created for your new site; no residual triggers are left to be fired.

By: lavakumar

lavakumar — Fri, 12 Dec 2008 13:02:54 +0000

Intresting post! I think other vectors also exist since same-origin-policy doesnt apply for the location object here. window.location normally returns the current URL of the window, so all data in URL can be stolen this way. I tried this in firebug:

w = window.open("http://gmail.com")
w.location = "https://gmail.com"
w.location = "https://gmail.com"

The second time I call w.location, it returns -

https://www.google.com/accounts/ServiceLogin?service=mail&passive=true&rm=false&continue=https%3A%2F%2Fmail.google.com%2Fmail%2F%3Fui%3Dhtml%26zy%3Dl&bsv=1k96igf4806cy&ss=1<mpl=default<mplcache=2

So even without redirecting to another fake website, we can get the session IDs if they are in the URL(even over SSL). Also most CSRF countermeasures add the unquie nonce to the URL (including ESAPI), this can also be used to bypass the anti-CRSF measures in selective cases.

By: pdp

pdp — Fri, 12 Dec 2008 07:22:39 +0000

I forgot to mention that there are other ways to detect when a user is logged on. think of dynamically generated css, image, swf and js files. all of them can be used to find the current user’s state.

By: Baston

Baston — Fri, 12 Dec 2008 07:20:14 +0000

Of course, using such a trick for other malicious purpose would work …. :o(

By: Baston

Baston — Fri, 12 Dec 2008 07:19:03 +0000

Add-on like “secure login” for Firefox or the “magic wand” connection of Opera could prevent such hack. As one doesn’t enter his credentials but they are fetch by the add-on if and only the page is the right one, the second login-dialogbox would not be filled ….
Or did i miss something ???