[Owasp-antisamy] onsiteURL and offsiteURL accept urls withparameters
arshan.dabirsiaghi at aspectsecurity.com
Mon Jun 23 09:10:15 EDT 2008
I'm not trying to sound lazy, but if it's a beatable protection, I don't think we can have it. Also, it is hard to provide a "hook" capability as the engine is driven by a regular expression policy file, not an abstract class. It is easy for someone to alter the URL regular expression to be "192\.168\..*" to limit the URLs to an intranet, and do something similar to prevent certain filetypes (though it's much harder as URLs are fairly difficult to handle with regular expressions).
As you said, the protections are not strong. The file extension check is not that strong as an attacker could point to a valid URL that serves a 302 redirect to a malicious file.
Can we brainstorm a combination whitelist/blacklist set of regular expressions that accomplishes some of what you want to accomplish?
PS Don't get me started on the myth of defense in depth. =]
From: Jim Manico [mailto:jim at manico.net]
Sent: Mon 6/23/2008 12:36 AM
To: Arshan Dabirsiaghi
Cc: Carlos Aguayo; owasp-antisamy at lists.owasp.org
Subject: Re: [Owasp-antisamy] onsiteURL and offsiteURL accept urls withparameters
> it's impossible to verify the URLs in a useful way
With all due respect, I do not agree with this conjecture. Remember, we
are talking defense in depth. Some use cases where URL verification
1) Intranet applications where use driven URL's should be intranet url's
only (whitelist verification style)
2) Running url's through known malware blacklists using the Google
malware url api http://code.google.com/apis/safebrowsing/ (blacklist style)
3) Allowing URL's to only be a certain content type (no links to .exe
And of course there are ways around these projections - this is just one
useful defense-in-depth layer of protection.
I'm also not saying that AntiSamy needs to do any of this, but I think
AntiSamy should *at least provide the hook* so developers can choose to
do so if they like.
> I had a brain fart during this discussion - it's impossible to verify
> the URLs in a useful way. We already decided this this out when opting
> to only allow the "importing" of remote stylesheets. The attacker can
> obviously control the remote data, so it's simple for them to host
> innocent data during initial validation, then replace it with
> malware/goatse afterwards.
> -----Original Message-----
> From: Jim Manico [mailto:jim at manico.net]
> Sent: Fri 6/13/2008 2:22 AM
> To: Arshan Dabirsiaghi; Carlos Aguayo; owasp-antisamy at lists.owasp.org
> Subject: RE: [Owasp-antisamy] onsiteURL and offsiteURL accept urls
> IMO, AntiSamy should not allow all arbitrary urls. There should at
> least be hooks to verify urls through malware blacklists like Google's
> malware blacklist API provides. I would suspect that Slashdot is doing
> something like this already.
> - Jim
> -----Original Message-----
> From: Arshan Dabirsiaghi <arshan.dabirsiaghi at aspectsecurity.com>
> Sent: Thursday, June 12, 2008 6:57 AM
> To: Carlos Aguayo <carlos.aguayo at gmail.com>;
> owasp-antisamy at lists.owasp.org
> Subject: Re: [Owasp-antisamy] onsiteURL and offsiteURL accept urls
> There are two reasons why we allow arbitrary HTTP URLs:
> It's the Slashdot policy file, so we do exactly what Slashdot does.
> That is the point of AntiSamy in general: to allow rich input.
> You can lock down a policy file as much as you want, but the more you
> lock it down, the less useful it is to your users. If you prevent URL
> parameters from being in a URL, users can't put up a link to a CNN
> article, or their profile page on a social network, etc.
> Hope that helps.
> From: owasp-antisamy-bounces at lists.owasp.org on behalf of Carlos Aguayo
> Sent: Thu 6/12/2008 11:35 AM
> To: owasp-antisamy at lists.owasp.org
> Subject: [Owasp-antisamy] onsiteURL and offsiteURL accept urls
> By default both onsiteURL and offsiteURL accept url with parameters,
> for example, the following link:
> <a href="http://mysite.com?first=12345&second=34567
> <http://mysite.com?first=12345&second=34567>">click here</a>
> would pass using AntiSamy slashdot policy. Ultimately using AntiSamy
> an attacked shouldn't be able to dynamically craft th
> [The entire original message is not included]
Jim Manico, Senior Application Security Engineer
jim.manico at aspectsecurity.com | jim at manico.net
(301) 604-4882 (work)
(808) 652-3805 (cell)
Securing your applications at the source
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-antisamy