Saturday, December 31st, 2005

Cross-Site Phishing

Category: Security

Eric Pascarello suggests another risk of running Javascript from another domain: Using Javascript to fake a login page.

Spoofing of a web page to get your information is so common. I see in my inbox that your —(insert bank, shopping site, etc) account is going to be removed if you do not verify your information. You look at the link and it says something like Anyone stupid enough will click on the link sees the look and feel of ebay and fills out the form. Bye (sic.) to your account information. Now this same basic principal can be applied to site.

A malicious external script might produce a fake GMail login screen. In the story here, it adds GMail to a new frame:

How did they get his password? Well it ends up that the cheese page had some code sitting there that noticed if a user was not active for an extended period of time so it opened up a framed page with gmail in one of the frames. Since cross browser scripting was enabled. The cheese page changed the properties of the form to post to the cheese server logging the username and password. After the data was recorded, the user was redirected to gmail and the rest is history in this fake story.

Of course, most users would ask, “Why is there a GMail login page in my browser?”. In Eric’s story, the user is distracted by a phone call. Other times, it could possibly happen if the user returned to the background tab. It might not trick many users, but even if it catches one person out, that’s a serious problem. The scenario here is further evidence that people need to take care with cross-domain scripting.

Posted by Michael Mahemoff at 7:04 pm

3.8 rating from 71 votes


Comments feed

As utopian as many Web 2.0 followers wish the web to be, the truth is that any and every little hole will get exploited. I guess I would love to have some way to define a difference between the stuff that ought to be protected and the that which shouldn’t. Imagine an HTML property that would allow or disallow cross-site scripting. Oh, well…

Comment by Chuck — January 3, 2006

[…] I’m working on a new Greasemonkey script and with the recent discovery of cross-domain access to JSON data, I figured the same technique would be a good way to bring in JavaScript libraries that can be useful in your Greasemonkey scripts.  The only hitch is that you have to trust the host of the libraries you want to bring in… else it’s possible to cause harm to your users. […]

Pingback by » Blog Archive » Loading External JavaScript Libraries in Greasemonkey — January 4, 2006

even making a mail id in i’m not able to donload the tibco gi file

Comment by dolphin — February 20, 2006

[…] Source: Ajaxian » 2005 » December ] RSS feed for comments on this post. TrackBack URI lonny.paul is © Theron Parlin. Benevolence theme by Theron Parlin. Syndicate entriesusing RSS and Comments (RSS). This theme contains valid XHTML and CSS. Powered by WordPress 2.0-RC3. […]

Pingback by » Cross-domain JavaScript and it’s evils… lonny.paul Technology defined: a fusion of Marketing and eCommerce with a hint of legal eagle — April 22, 2006

Good site.

Comment by bedava mp3 — May 22, 2006

A hard and fast rule of course being never, ever head to a website using the clickable links in your inbox. If you know the site referenced, just visit the top level of its domain and go from there. Lots of grief would be avoided if others were not so trusting. Thanks for the post.

Comment by Bill Ellingsworth — August 2, 2007

What do you know…A widget is always bound to an HTML element so. This will typically be a div, but can really be anything (depending on the widget). We take the Dojo approach of leveraging custom attributes in order to do all of the wiring. now about phishing i m not sure…

Gee interesting… i need to go walk the dog..later bud!

Comment by Lost puppy — October 6, 2007

Leave a comment

You must be logged in to post a comment.