Re: CSRF (Was: XSS evasion)
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;
bHI/b
A
iHello/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)
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)
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/
CSRF (Was: XSS evasion)
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/
CSRF (Was: XSS evasion)
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: CSRF (Was: XSS evasion)
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.
