<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [Owasp-antisamy] onsiteURL and offsiteURL accept urls withparameters</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

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

</BODY>
<!--[object_id=#aspectsecurity.com#]--></HTML>