You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Clinton Gormley <cl...@traveljury.com> on 2006/10/06 16:35:22 UTC
XSS evasion
I'm testing my current site for XSS vulnerabilities, and I came across
this one on:
http://ha.ckers.org/xss.html
----------------------------
IMG Embedded commands part II - this is more scary because there are
absolutely no identifiers that make it look suspicious other than it is
not hosted on your own domain. The vector uses a 302 or 304 (others work
too) to redirect the image back to a command. So a normal <IMG
SRC="http://badguy.com/a.jpg"> could actually be an attack vector to run
commands as the user who views the image link. Here is the .htaccess
(under Apache) line to accomplish the vector
----------------------------
Now this is an interesting one... How would you avoid this? Only take
parameters from the POST data? Any other ideas?
Clint
________________________________________________________________________
Clinton Gormley clinton@traveljury.com
www.TravelJury.com - For travellers, By travellers
Re: Fwd: XSS evasion
Posted by Chris Shiflett <sh...@php.net>.
Clinton Gormley wrote:
> If the input that you are wanting to display is (eg) a surname,
> then certainly, escaping will serve your purposes. However, if
> you are wanting your user to be able to input HTML and then
> view it as HTML, escaping isn't sufficient. The combination is
> required.
That XSS is fundamentally an escaping problem does not mean escaping is
a substitute for filtering, nor vice versa. (Filter input; escape
output.) I wasn't suggesting otherwise.
Escaping preserves data. If you want HTML to be interpreted, then it's
markup, not data that you want to preserve. As I said, the approach you
described for HTML::StripScripts::Parser sounds pretty good for this,
but any technique that tries to solve XSS with filtering alone is
error-prone, because it doesn't address the root cause of the problem.
This can't be avoided in some cases, but that doesn't make it a "yes and
no" issue.
Hope that helps.
Chris
--
Chris Shiflett
http://shiflett.org/
Re: Fwd: XSS evasion
Posted by Clinton Gormley <cl...@traveljury.com>.
> This sounds like a good approach, but it's worth noting that XSS is
> fundamentally an escaping problem, not a filtering one. Nitesh Dhanjani
> discusses this a bit here:
>
> http://oreillynet.com/onlamp/blog/2005/10/repeat_after_me_lack_of__outpu.html
>
Yes and no. From the article:
-----------------
Therefore, I frequently come across situations where developers fix XSS
problems by attempting to filter out meta-characters (<, >, /, “, ‘,
etc). At times, if an exhaustive list of meta-characters is used, it
does solve the problem, but it makes the application less friendly to
the end user – a large set of characters are deemed forbidden.
------------------
If the input that you are wanting to display is (eg) a surname, then
certainly, escaping will serve your purposes. However, if you are
wanting your user to be able to input HTML and then view it as HTML,
escaping isn't sufficient. The combination is required.
________________________________________________________________________
Clinton Gormley clinton@traveljury.com
www.TravelJury.com - For travellers, By travellers
Re: Fwd: XSS evasion
Posted by Chris Shiflett <sh...@php.net>.
Clinton Gormley wrote:
> HTML::StripScripts::Parser has a default deny everything approach,
> and reconstructs the HTML fed to it, so unless it makes sense as
> html, it doesn't get passed through and reconstructed.
This sounds like a good approach, but it's worth noting that XSS is
fundamentally an escaping problem, not a filtering one. Nitesh Dhanjani
discusses this a bit here:
http://oreillynet.com/onlamp/blog/2005/10/repeat_after_me_lack_of__outpu.html
Chris
--
Chris Shiflett
http://shiflett.org/
Re: Fwd: XSS evasion
Posted by Clinton Gormley <cl...@traveljury.com>.
> HTML::Scrubber is not really broken. The problem is that the
> documentation leads the user to do broken things, as was shown with
> Planet Plagger. It is possible to make a secure HTML::Scrubber config,
> but you need to default deny everything and then only allow a select
> list of tags and attributes - and you need to really think about that
> list. The underlying problem, which I suspect HTML::Stripscripts shares
> is that HTML::Parser thinks that the attribute "foo=bar" is different
> than the attribute "foo.=bar" (RSnake covers this kind of evasion in his
> document fairly well) and your browser thinks that everthing non
> alphanumeric before the equals sign is junk.
HTML::StripScripts::Parser has a default deny everything approach, and
reconstructs the HTML fed to it, so unless it makes sense as html, it
doesn't get passed through and reconstructed.
I tried out loads of different forms of XSS attacks from RSnake's site,
and they were all neutered by StripScripts, including the 'foo.=' form.
> So without actually
> sitting down and auditing HTML::Stripscripts I'd say it probably _can_
> be used safely, but odds are most people won't.
Again, without actually auditing it but based on my experience of
configuring and using it, I would say that with the default settings of
HTML::StripScripts::Parser, you'd be pretty safe, but that you could
configure it so that it would NOT be safe.
Clint
Re: Fwd: XSS evasion
Posted by mock <mo...@mailchannels.com>.
On Fri, Oct 06, 2006 at 07:25:06PM +0200, Clinton Gormley wrote:
> On Fri, 2006-10-06 at 18:48 +0200, Hendrik Van Belleghem wrote:
> > "mock" talked about XSS at this years YAPC::Europe in Birmingham a few
> > weeks ago. He had quite a few examples. His slides are at
> > http://sketchfactory.com/static/mvc.pdf (More Vulnerable Code).
> > It goes without saying that it would be a bit unwise to test the URLs
> > mentioned in the talk.
>
> He briefly mentions HTML::Scrubber in there. I am using
> HTML::Stripscripts::Parser, which also makes sure that tags are nested
> properly.
>
> Anybody have any view on these (or other) modules?
>
> Clint
>
HTML::Scrubber is not really broken. The problem is that the
documentation leads the user to do broken things, as was shown with
Planet Plagger. It is possible to make a secure HTML::Scrubber config,
but you need to default deny everything and then only allow a select
list of tags and attributes - and you need to really think about that
list. The underlying problem, which I suspect HTML::Stripscripts shares
is that HTML::Parser thinks that the attribute "foo=bar" is different
than the attribute "foo.=bar" (RSnake covers this kind of evasion in his
document fairly well) and your browser thinks that everthing non
alphanumeric before the equals sign is junk. So without actually
sitting down and auditing HTML::Stripscripts I'd say it probably _can_
be used safely, but odds are most people won't.
As an aside, I'm not sure that it's completely public knowledge outside
people who read my site and people who saw my talk, but CSRF can be
performed from feeds (RSS, Atom). So you need to defang any feeds that
will be shown to a logged in user otherwise there's the possibility of
doing various bad things(tm). There's also the obvious problem with
javascript in feeds as well...
Finally, if you're near Tokyo this November, Martin Johns is going to be
presenting what looks like a really good talk on CSRF, with some new
mitigation techniques and a fair bit of new work on the problem at
PacSec (http://pacsec.jp/speakers.html).
mock
Re: Fwd: XSS evasion
Posted by Clinton Gormley <cl...@traveljury.com>.
On Fri, 2006-10-06 at 18:48 +0200, Hendrik Van Belleghem wrote:
> "mock" talked about XSS at this years YAPC::Europe in Birmingham a few
> weeks ago. He had quite a few examples. His slides are at
> http://sketchfactory.com/static/mvc.pdf (More Vulnerable Code).
> It goes without saying that it would be a bit unwise to test the URLs
> mentioned in the talk.
He briefly mentions HTML::Scrubber in there. I am using
HTML::Stripscripts::Parser, which also makes sure that tags are nested
properly.
Anybody have any view on these (or other) modules?
Clint
Fwd: XSS evasion
Posted by Hendrik Van Belleghem <he...@gmail.com>.
"mock" talked about XSS at this years YAPC::Europe in Birmingham a few
weeks ago. He had quite a few examples. His slides are at
http://sketchfactory.com/static/mvc.pdf (More Vulnerable Code).
It goes without saying that it would be a bit unwise to test the URLs
mentioned in the talk.
my 2 cents
Hendrik
On 10/6/06, Jonathan Vanasco <mo...@2xlp.com> wrote:
>
> On Oct 6, 2006, at 10:35 AM, Clinton Gormley wrote:
>
> > I'm testing my current site for XSS vulnerabilities, and I came across
> > this one on:
> >
> > http://ha.ckers.org/xss.html
>
> well, not MP related but
>
> if you let users embed flash / etc in profile pages, make sure you
> strip object tags -- just use the embed
>
> also add
> allowScriptAccess="never"
> allownetworking="internal"
>
> without that, you can use getURL from within flash to call arbitrary
> code
>
> most social networks have. but i *think* friendster still hasn't
> done it yet.. there's a popular hack amongst east-asian teens right
> now to include a flash file onto their profile pages that includes an
> external JS which alters the DOM tree to skin it any-which-way they
> want.
>
>
> // Jonathan Vanasco
>
> | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - -
> | FindMeOn.com - The cure for Multiple Web Personality Disorder
> | Web Identity Management and 3D Social Networking
> | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - -
> | RoadSound.com - Tools For Bands, Stuff For Fans
> | Collaborative Online Management And Syndication Tools
> | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - -
>
>
>
--
Hendrik Van Belleghem
Spine - The backbone for your website - http://spine.sf.net
--
Hendrik Van Belleghem
Spine - The backbone for your website - http://spine.sf.net
Re: XSS evasion
Posted by Jonathan Vanasco <mo...@2xlp.com>.
On Oct 6, 2006, at 10:35 AM, Clinton Gormley wrote:
> I'm testing my current site for XSS vulnerabilities, and I came across
> this one on:
>
> http://ha.ckers.org/xss.html
well, not MP related but
if you let users embed flash / etc in profile pages, make sure you
strip object tags -- just use the embed
also add
allowScriptAccess="never"
allownetworking="internal"
without that, you can use getURL from within flash to call arbitrary
code
most social networks have. but i *think* friendster still hasn't
done it yet.. there's a popular hack amongst east-asian teens right
now to include a flash file onto their profile pages that includes an
external JS which alters the DOM tree to skin it any-which-way they
want.
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
CSRF (Was: XSS evasion)
Posted by Chris Shiflett <sh...@php.net>.
Clinton Gormley wrote:
> Really good article, Chris:
> http://shiflett.org/articles/security-corner-dec2004
>
> I really like the solution of using tokens.
Thanks! :-)
It's worth noting that this safeguard is rendered ineffective if you
have XSS vulnerabilities, thanks to Ajax. Malicious JavaScript can
request the page with the token, parse the response, and submit the CSRF
attack with the proper token, all from the client (victim).
I've been doing some research on using Ajax in this way from other domains:
http://shiflett.org/archive/250
http://shiflett.org/archive/263
http://shiflett.org/archive/267
Hope others find this stuff as interesting as I do.
Chris
--
Chris Shiflett
http://shiflett.org/
Re: XSS evasion
Posted by Clinton Gormley <cl...@traveljury.com>.
> That's part of it, but it's not a complete solution.
>
> That particular attack vector is called CSRF, cross-site request
> forgeries. RSnake's XSS cheatsheet demonstrates using XSS on your own
> site to launch the attack, but it can also be launched from any other
> web site where your users visit.
>
Really good article, Chris:
http://shiflett.org/articles/security-corner-dec2004
I really like the solution of using tokens.
Clint
Re: XSS evasion
Posted by Chris Shiflett <sh...@php.net>.
Clinton Gormley wrote:
> How would you avoid this? Only take parameters from the
> POST data?
That's part of it, but it's not a complete solution.
That particular attack vector is called CSRF, cross-site request
forgeries. RSnake's XSS cheatsheet demonstrates using XSS on your own
site to launch the attack, but it can also be launched from any other
web site where your users visit.
Something I think RSnake fails to mention is that CSRF safeguards fail
when a XSS vulnerability exists, so it's important to protect against both.
Hope that helps.
Chris
--
Chris Shiflett
http://shiflett.org/
CSRF (Was: XSS evasion)
Posted by Chris Shiflett <sh...@php.net>.
Clinton Gormley wrote:
> 3) Instead of serving the image, the server at www.malicious-site.com
> issues a 302 HTTP Status code which redirects Joe Bloggs to
> http://my.website.com/change_password?new_password=abcde
>
> So his password gets changed, because this is coming from a live
> session, the request his from his own browser and sends the session
> cookie, and he doesn't see the image because it the return page isn't
> an image.
By the way, this is why section 9.1.1 of RFC 2616 states the following:
"In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action other
than retrieval. These methods ought to be considered "safe". This allows
user agents to represent other methods, such as POST, PUT and DELETE, in
a special way, so that the user is made aware of the fact that a
possibly unsafe action is being requested."
Chris
--
Chris Shiflett
http://shiflett.org/
Re: CSRF (Was: XSS evasion)
Posted by Jonathan <mo...@2xlp.com>.
Sorry for the OT ness of this thread---
I spent the better part of the past 2 days trying to do a 1pass
content filtering on xss attacks-- including flash. breaking down
every piece of user input 2x wasn't nice on my server load.
I liked HTML::TagFilter, but it was making broken tags and I couldn't
push the new tag defaults into it.
So thanks to Clinton Gormley for helping me decide on
HTML::StripScripts::Parser -- which does facilitate tag defaults--
albeit in an awkward manner.
Clinton also made a nice skeleton of a wrapper for me to get a
feeling for, saving me a large bit of the learning curve.
In any event, what follows is code that will rewrite user input of
'embed' tags for flash and replace in allowScriptAccess='never' and
allowNetworking='internal' (object tags are not whitelisted for this )
if you let people embed flash onto your site, you will probably want
to read the code below.
==========
use strict;
use warnings;
package Wrapper::StripScriptsParser;
use base 'HTML::StripScripts::Parser';
use HTML::Entities();
sub new {
my $proto = shift;
my $self = $proto->SUPER::new({
Context=> 'Flow',
AllowHref=> 1,
AllowSrc=> 1,
});
$self->attr_encoded(0);
return $self;
}
#override the context whitelist, and stick embed in there. we'll
allow it.
sub init_context_whitelist {
my ( $self )= @_;
my $context_whitelist= $self->SUPER::init_context_whitelist() ;
$context_whitelist->{'Flow'}{'embed'}= 'Inline';
$context_whitelist->{'Context'}{'embed'}= 'Inline';
return $context_whitelist;
}
#override the attribute whitelist, and add custom cases for embed tags
sub init_attrib_whitelist {
my ( $self )= @_;
my $attrib_whitelist= $self->SUPER::init_attrib_whitelist() ;
$attrib_whitelist->{'embed'}= {
src=> 'href',
type=>'word',
width=>'number',
height=>'number',
flashvars=>'text',
allowscriptaccess=>'allowscriptaccess',
allownetworking=>'allownetworking'
};
return $attrib_whitelist
}
#override the attribute value whitelist, and add custom classes for
allowscriptaccess and allownetworking
sub init_attval_whitelist {
my ( $self )= @_;
my $attval_whitelist= $self->SUPER::init_attval_whitelist() ;
$attval_whitelist->{'allowscriptaccess'}= \&attval_allowscriptaccess;
$attval_whitelist->{'allownetworking'}= \&attval_allownetworking;
return $attval_whitelist;
}
#custom attribute value class. cleans up flash embeds
sub attval_allowscriptaccess {
my ($filter, $tagname, $attrname, $attrval) = @_;
if ( $tagname eq 'embed' ) {
return 'never';
};
return undef;
}
#custom attribute value class. cleans up flash embeds
sub attval_allownetworking {
my ($filter, $tagname, $attrname, $attrval) = @_;
if ( $tagname eq 'embed' ) {
return 'internal';
};
return undef;
}
sub filter {
my ( $self , $text )= @_;
$self->parse($text);
$self->eof;
return $self->filtered_document;
}
sub reject_start {
$_[0]->output(HTML::Entities::encode($_[1]));
}
sub reject_end {
$_[0]->output(HTML::Entities::encode($_[1]));
}
sub reject_text {
$_[0]->output(HTML::Entities::encode($_[1]));
}
sub reject_declaration {}
sub reject_comment {}
sub reject_process {}
sub __dump__ {
my ( $self )= @_;
use Data::Dumper();
print STDERR Data::Dumper->Dump( [$self] , [qw(self)] );
}
###############################################################
package main;
sub defang_text_ {
my ( $text )= @_;
my $hss= Wrapper::StripScriptsParser->new();
return $hss->filter($text);
}
my $kill= <<EOF;
<b>HI</b>
A
<i>Hello</i>
<a href="http://a.com" > hi</a>
<embed flashvars="a=f" allowscriptaccess="a"
allowNetworking="internal" type="application/x-shockwave-flash"
src="http://a.com/a.swf"></embed>
A1
<embed flashvars="b=asd" allowScriptAccess="never"
allowNetworking="internal" type="application/x-shockwave-flash"
src="http://a.com/a.swf"></embed>
B
<embed flashvars="c=kajsdlk@" allowScriptAccess="always"
allowNetworking="sameDomain" type="application/x-shockwave-flash"
src="http://b.com/b.swf" />
C
<span />
D
<div />
EOF
print defang_text_( $kill );
###############################################################
1;
Re: CSRF (Was: XSS evasion)
Posted by Chris Shiflett <sh...@php.net>.
Jonathan Vanasco wrote:
> > Unfortunately, Amit Klein published some research in July that
> > demonstrated how to do this with Flash. So, if your users use
> > clients that support Flash (which most do), this is not a good
> > safeguard.
>
> Do you have a link to that?
http://webappsec.org/lists/websecurity/archive/2006-07/msg00069.html
Chris
--
Chris Shiflett
http://shiflett.org/
Re: CSRF (Was: XSS evasion)
Posted by Jonathan Vanasco <mo...@2xlp.com>.
On Oct 6, 2006, at 4:33 PM, Chris Shiflett wrote:
> Until July of this year, checking the Referer was thought to be a
> pretty
> good safeguard against CSRF, because an attacker would have to cause a
> victim to send the right Referer, which isn't so easy.
>
> Unfortunately, Amit Klein published some research in July that
> demonstrated how to do this with Flash. So, if your users use clients
> that support Flash (which most do), this is not a good safeguard.
Do you have a link to that?
A friend was having issues with flash & referrers recently. I think
everyone but safari may have stripped it out.
Re: CSRF (Was: XSS evasion)
Posted by Jonathan Vanasco <mo...@2xlp.com>.
On Oct 6, 2006, at 4:33 PM, Chris Shiflett wrote:
> Jonathan Vanasco wrote:
>> can't a lot of this be locked down with http referrers?
>
> Until July of this year, checking the Referer was thought to be a
> pretty
> good safeguard against CSRF, because an attacker would have to cause a
> victim to send the right Referer, which isn't so easy.
>
> Unfortunately, Amit Klein published some research in July that
> demonstrated how to do this with Flash. So, if your users use clients
> that support Flash (which most do), this is not a good safeguard.
That's rather annoying.
The steps to lock down a domain are f*ing difficult.
I don't think its even entirely possible now... If a browser has
javascript + async, they can fake the entire sessions.
On all my projects , I've moved flash communications to their own
namespace to avoid *some* referrer forging, and I've locked down all
account / write pages to necessitate a http referrer from my site.
I say *some* in regards to flash, because a swf can still do a
loadMovie against a domain without crossdomain.xml constraints.
Beyond that though, anything that I can think of really just makes
things more inconvenient for 'hackers'. considering what flash and
javascript can do now-- especially in regards to async/callbacks/
regex/requests/everything happening silent behind-the-scenes-- there
are just so many new 'vulnerabilities'
i'm not even sure that these really are vulnerabilities though...
if a user gets a spam, clicks on the link, that link loads some site
in russia / china / czech republic that has a js file or flash file
that is used to fake refferrers, make requests, and basically be a
web spider using their session info -- all behind the scenes -- is
that necessarily a vulnerability in my website, or one in the browsers ?
I'm not sure on that.
What I am sure of, is that it took me all of 30 minutes to
'reasonably' lock down my websites under mod perl. thats damn fast.
CSRF (Was: XSS evasion)
Posted by Chris Shiflett <sh...@php.net>.
Jonathan Vanasco wrote:
> can't a lot of this be locked down with http referrers?
Until July of this year, checking the Referer was thought to be a pretty
good safeguard against CSRF, because an attacker would have to cause a
victim to send the right Referer, which isn't so easy.
Unfortunately, Amit Klein published some research in July that
demonstrated how to do this with Flash. So, if your users use clients
that support Flash (which most do), this is not a good safeguard.
Chris
--
Chris Shiflett
http://shiflett.org/
Re: XSS evasion
Posted by Jonathan Vanasco <mo...@2xlp.com>.
On Oct 6, 2006, at 1:04 PM, tomas@tuxteam.de wrote:
>> 1) Joe Bloggs logs into my website and has an active session.
>> 2) Clicks on a link (either from an email or from content posted
>> on my
>> site) to http://www.malicious-site.com/index.html
>> 3) That index page contains an <img src="/logo.gif" /> tag
>> 3) Instead of serving the image, the server at www.malicious-site.com
>> issues a 302 HTTP Status code which redirects Joe Bloggs to
>> http://my.website.com/change_password?new_password=abcde
can't a lot of this be locked down with http referrers ?
i know they can be spoofed - but thats a manual action. i've yet to
hear of a browser than can spoof headers via javascript. you'd have
to compromise the browser, not insert malicious JS or images into a
page.
Re: XSS evasion
Posted by to...@tuxteam.de.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, Oct 06, 2006 at 05:14:47PM +0200, Clinton Gormley wrote:
> > Users:
[...]
> > OK, now call me names :-)
> >
>
> Neither of these options will work. Consider this scenario.
>
> 1) Joe Bloggs logs into my website and has an active session.
> 2) Clicks on a link (either from an email or from content posted on my
> site) to http://www.malicious-site.com/index.html
> 3) That index page contains an <img src="/logo.gif" /> tag
> 3) Instead of serving the image, the server at www.malicious-site.com
> issues a 302 HTTP Status code which redirects Joe Bloggs to
> http://my.website.com/change_password?new_password=abcde
Woah. Right. So: encode session in URL (and not in cookies) might work
for this. The attacker would have to know the session (wait: there is
HTTP-Referrer, right? so a cautious site would have to "clean" the
session before sending the visitor to other sites. Sigh).
I'm aware that I am a bit late with all that (I myself go mostly by
those rules. There are just one or two sites I allow Javascript or
cookies. But I know I'm preaching in the desert. Still...).
Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFJoygBcgs9XrR2kYRAqRIAJ0dSh2edZmzLcwdFWu/1et/xsOzpgCfeJ8G
QPvPQGMcUja1i+fS8SUApMA=
=KqpE
-----END PGP SIGNATURE-----
Re: XSS evasion
Posted by Clinton Gormley <cl...@traveljury.com>.
> Users:
> * switch off Javascript (and any other active content)
> * avoid pages unusable without active content
>
> Developers:
> * always offer working alternatives to active content (page
> must be usable with no JS, no Java, no Flash (I won't talk
> about other client-side monsters here).
> * convince your bosses/clients that (X)HTML/CSS is enough to
> make beautiful and usable pages.
>
> OK, now call me names :-)
>
Neither of these options will work. Consider this scenario.
1) Joe Bloggs logs into my website and has an active session.
2) Clicks on a link (either from an email or from content posted on my
site) to http://www.malicious-site.com/index.html
3) That index page contains an <img src="/logo.gif" /> tag
3) Instead of serving the image, the server at www.malicious-site.com
issues a 302 HTTP Status code which redirects Joe Bloggs to
http://my.website.com/change_password?new_password=abcde
So his password gets changed, because this is coming from a live
session, the request his from his own browser and sends the session
cookie, and he doesn't see the image because it the return page isn't an
image.
Re: XSS evasion
Posted by to...@tuxteam.de.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, Oct 06, 2006 at 04:35:22PM +0200, Clinton Gormley wrote:
> I'm testing my current site for XSS vulnerabilities, and I came across
> this one on:
>
> http://ha.ckers.org/xss.html
[...]
> Now this is an interesting one... How would you avoid this? Only take
> parameters from the POST data? Any other ideas?
Users:
* switch off Javascript (and any other active content)
* avoid pages unusable without active content
Developers:
* always offer working alternatives to active content (page
must be usable with no JS, no Java, no Flash (I won't talk
about other client-side monsters here).
* convince your bosses/clients that (X)HTML/CSS is enough to
make beautiful and usable pages.
OK, now call me names :-)
For the case shown -- the best seems to disallow any links to other
sites (and provide some kind of "cleaning proxy" if users want to
publish images from elsewhere. Looks like fun).
Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFJm67Bcgs9XrR2kYRAnc9AJ996Jbg1+4r01LDBMylbRg21NvvbgCeIYfp
nNC0GM7xNlsmy/qPAC8mPmI=
=WSVV
-----END PGP SIGNATURE-----