You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Jon Stevens <jo...@latchkey.com> on 2001/11/25 22:42:51 UTC
FW: Cross Site Scripting holes abound
Sigh.
-jon
------ Forwarded Message
From: <se...@devitry.com>
Date: 17 Nov 2001 02:05:53 -0000
To: bugtraq@securityfocus.com
Subject: Cross Site Scripting holes abound
Mailer: SecurityFocus
::: Summary ::::
Over a year and a half since CERT issued
warning on Cross Site Scripting, most dynamic
websites are _still_ not filtering user input. This
lets remote sites access to write scripts on vunlerable
sites, stealing cookies, performing actions on behalf
of user or modifying look of content on site. I did a
quick
check of the top 15 sites (and other sites I use) and
found holes in _most_ of them.
::: Sites Affected :::
http://www.microsoft.com/
http://www.msnbc.com/
http://www.oracle.com/
http://www.about.com/
http://www.doubleclick.net/
http://www.netscape.com/
http://www.paypal.com/
http://www.google.com/
... many more not listed....
::: Details ::::
In general, if you can replace any url parameter with
""><script>alert(document.cookie)</script>"
and you get an alert, the site may be vulnerable.
Samples and details listed at
http://www.devitry.com/security.html
The samples on the above site take it one step
futher and send the cookie data to another site.
Even https sites are vulnerable since cookie data
is available to javascript on page.
:::: Fix :::::
You should validate or filter all user input, including
hidden form fields and id's passed in url's before
the data is written out to the page. Any poorly
written script on your whole domain could give you
problems. (even old ones that do nothing like
testenv) Filtering or encoding is should be done
for ", >, < and sometimes '
You should monitor for "script" passed in url's to
your site... However, blocking in the url alone
is not good enough as the parameter could be passed
in "POST" data.
For sites that have your data, you should always
log out at the end of your session, and you should
not surf more then one site at a time.
::: Discussion :::
Most of these holes were discovered in a matter of
minutes. It takes more time just to find out the owner
of the site and explain to them why this is a problem.
Is there anyway to fix this on a more global basis?
While these types of holes are not instantly mass
exploitable, it is good (or bad, depending on how you
look at it) for targeting specify users and sites to
steal sessions and personal info.
-Dave deVitry
security@devitry.com
ps. microsoft.com exploit url withheld because they
think they are safer that way.
pps. all websites involved were contacted, but most
had no timely reply.
------ End of Forwarded Message
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cross Site Scripting holes abound
Posted by Danny Angus <da...@thought.co.uk>.
Don't bother despairing about microsoft, bask in the smug feeling that your
on the side of Right, and you've planted your banner on the moral high
ground. ;-)
> -----Original Message-----
> From: Jon Stevens [mailto:jon@latchkey.com]
> Sent: Sunday, November 25, 2001 9:43 PM
> To: general@jakarta.apache.org
> Subject: FW: Cross Site Scripting holes abound
>
>
> Sigh.
>
> -jon
>
> ------ Forwarded Message
> From: <se...@devitry.com>
> Date: 17 Nov 2001 02:05:53 -0000
> To: bugtraq@securityfocus.com
> Subject: Cross Site Scripting holes abound
>
> Mailer: SecurityFocus
>
> ::: Summary ::::
>
> Over a year and a half since CERT issued
> warning on Cross Site Scripting, most dynamic
> websites are _still_ not filtering user input. This
> lets remote sites access to write scripts on vunlerable
> sites, stealing cookies, performing actions on behalf
> of user or modifying look of content on site. I did a
> quick
> check of the top 15 sites (and other sites I use) and
> found holes in _most_ of them.
>
> ::: Sites Affected :::
>
> http://www.microsoft.com/
> http://www.msnbc.com/
> http://www.oracle.com/
> http://www.about.com/
> http://www.doubleclick.net/
> http://www.netscape.com/
> http://www.paypal.com/
> http://www.google.com/
> ... many more not listed....
>
> ::: Details ::::
>
> In general, if you can replace any url parameter with
> ""><script>alert(document.cookie)</script>"
> and you get an alert, the site may be vulnerable.
>
> Samples and details listed at
> http://www.devitry.com/security.html
>
> The samples on the above site take it one step
> futher and send the cookie data to another site.
>
> Even https sites are vulnerable since cookie data
> is available to javascript on page.
>
> :::: Fix :::::
>
> You should validate or filter all user input, including
> hidden form fields and id's passed in url's before
> the data is written out to the page. Any poorly
> written script on your whole domain could give you
> problems. (even old ones that do nothing like
> testenv) Filtering or encoding is should be done
> for ", >, < and sometimes '
>
> You should monitor for "script" passed in url's to
> your site... However, blocking in the url alone
> is not good enough as the parameter could be passed
> in "POST" data.
>
> For sites that have your data, you should always
> log out at the end of your session, and you should
> not surf more then one site at a time.
>
> ::: Discussion :::
>
> Most of these holes were discovered in a matter of
> minutes. It takes more time just to find out the owner
> of the site and explain to them why this is a problem.
> Is there anyway to fix this on a more global basis?
>
> While these types of holes are not instantly mass
> exploitable, it is good (or bad, depending on how you
> look at it) for targeting specify users and sites to
> steal sessions and personal info.
>
> -Dave deVitry
> security@devitry.com
>
> ps. microsoft.com exploit url withheld because they
> think they are safer that way.
>
> pps. all websites involved were contacted, but most
> had no timely reply.
>
>
> ------ End of Forwarded Message
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>