[clug] Drive-By Pharming Attack Could Hit Home Networks

Michael Cohen michael.cohen at netspeed.com.au
Sat Feb 17 22:19:43 GMT 2007

On Sat, Feb 17, 2007 at 03:41:44PM +0100, Kim Holburn wrote:
> If a javascript got the router interface opened in an invisible  
> iframe and somehow got an enter or a click to the iframe after the  
> password manager filled in the details?

  Thats the whole point of the javascript security model (if it works that is).
  JS is not supposed to have access to windows or iframes which open to a
  different domain from where it came from, otherwise you could do same with
  internet banking sites, or any other log in pages. 

  From time to time people find vulnerabilities in this model, but they are
  more implementation problems than fundamental problems with the security
  model. Occassionally the model gets in the way too - especially when trying
  to implement single sign on type stuff from different domains. It assumes
  that domains are security boundaries - i.e. all scripts hosted by a certain
  domain are to be trusted with the same data, this fails for example:

  1) When a site is spead across a number of domains (e.g. sister sites in
  iframes etc)

  2) When a single site hosts code from multiple sources - not all of which are
  trusted - e.g. if a site uses the /~usersname/ convension to host different
  usernames - one users js can access another users frames (because they both
  share the same domain). This type of problem is called cross site scripting
  (XSS) - which in its widest form means how to get scripting to cross site

  For example if a forum software is vulnerable to XSS, one user may be able to
  post to the forum some JS which get users cookies and sends then off. Then
  every user that views that post in the forum becomes compromised - this is
  becuase the script runs in the same domain as the forum.


More information about the linux mailing list