[WEB SECURITY] (XSS via file extension) XSS-Phishing on Financial Sites
arian.evans at anachronic.com
Tue Jun 27 13:32:45 EDT 2006
Responding to the list here b/c several maybe be interested.
You know, I did not pay attention to the tags in use before;
I just tried doing this in a typical forum:
And it does not work.
I've gotten this working many times before, but most recently
for bypassing whitelisting via a regex (e.g.- where they allow
a .gif but not a .js type situation), but where I supplied the
escaping syntax, so more or less classic xss.
But I've gotten this working before, *exactly* like the
above link that doesn't work.
So either something has changed in the browser or I'm really
missing something here. Let me see if I can get to one of the
products I had this working on later today and check the source.
I remember running into differences between on and off-domain
content, maybe this was only where it was locally embedded.
Either way, I had multiple of these working darn it.
Strange, my bad, I should have posted working examples. I'll
go dig some more. Anything change in IE this year over the
previous 2 years regarding how it handles script w/a different
extension like .[image]?
> >> -----Original Message-----
> >> From: RSnake [mailto:rsnake at shocking.com]
> >> Sure, it's being treated as an HTML document because the MIME
> >> type is being ignored since the JPEG header is missing.
> > Right, that's what I was saying, for things that IE is natively
> > set to handle in Windows shell extensions (and only those things)
> > IE does it's magic byte header detection, then treats as a doc.
> > Else IE/windows launches the mapped application to handle
> the extension.
> >> But that's not really much of an exploit since it requires the user
> >> to click on it first.
> > *Nah, not at all.*
> > There are tons of functions in applications, from thumbnail previews
> > to avatars to folder icons, that web-based apps like Document
> > Management Systems (DMSes) use. In the case of thumbnail views,
> > this is automatic, in the case of avatars/folder icons, whatever,
> > it's still user supplied but not *ONE* windows based system I've
> > ever tested validates file type (and only one unix system I've
> > tested does this). One windows-based system had a client-side
> > activeX control for validating file type, but a proxy fixed that
> > pretty easily.
> > Now, again, in the case of a DMS system (or web-based fax system
> > where users click on bmps and pngs all day) there is no social
> > engineering required for the click, or perhaps more precisely the
> > behavior is already patterned, but below I was referring to
> > transparent execution of the script in a page.
> > 1) Embed full script
> > -or-
> > 2) Directive:payload if already being rendered in a script (e.g.
> > moving custom avatar)
> >>> http://www.anachronic.com/xss/scriptalert.jpg
> >>> Anywhere you can embed/reference an image, IE will execute
> >>> script types it understands for image (any) extensions it has
> >>> native shell extension handling configured to use itself for.
> >>> If you can get the image to 'render' inline of an existing script,
> >>> you may be able to get away with a simple directive as such:
> >>> http://www.anachronic.com/xss/shortalert.jpg
> >>> It's quite fun, and most web-based DMSes are vulnerable to
> >>> this type of abuse, say *nothing* of the zillions of sites
> >>> that allow custom avatars.
> >>> This is definitely something the browser could kabosh
> >>> short-term, though long term you'd think DMS systems would
> >>> want to validate all user supplied data, including the
> >>> /documents/ themselves.
> > -ae
> > The Web Security Mailing List:
> > http://www.webappsec.org/lists/websecurity/
> > The Web Security Mailing List Archives:
> > http://www.webappsec.org/lists/websecurity/archive/
> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
The Web Security Mailing List:
The Web Security Mailing List Archives:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
More information about the websecurity