<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Arshan,<br>
<br>
First of all, I think you are a defense-in-depth heretic. That might
not be a bad thing.  But I digress...<br>
<br>
&gt; <font size="2">
Can we brainstorm a combination whitelist/blacklist set of regular
expressions that accomplishes some of what you want to accomplish?</font><br>
<br>
I don't think we can beat this with a regEx - URL verification would
almost always need to be service/data driven.  (ie: google malware api)<br>
<br>
Perhaps you could scan the code after your regular expression pass
looking for URL's only - and just provide a boolean verification hook
then wash your hands of this matter altogether? <font size="2"><br>
</font><br>
I understand that this is not full-proof projection - but I have not
joined your "defense in depth is bad" cult, <b><i>yet</i></b>. <br>
<br>
I also agree that you have bigger fish to fry. I understand that this
is tough and may deserve to be put on the back burner for now.<br>
<br>
- Jim<br>
<br>
PS:  A programmer may want this feature just for functionality, too -
like say
the programmer wants to persist each url separately in order to display
outside of the rich content block, or to provide metrics on how often a
url was posted?<br>
<br>
 <br>
<blockquote
 cite="mid:B9A412898630124ABE8350F4EBD32E8493C40E@mymail.aspectsecurity.com"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 6.5.7652.24">
  <title>RE: [Owasp-antisamy] onsiteURL and offsiteURL accept urls
withparameters</title>
<!-- 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 "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).<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 moz-do-not-send="true" 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; <a class="moz-txt-link-abbreviated" href="mailto:owasp-antisamy@lists.owasp.org">owasp-antisamy@lists.owasp.org</a><br>
Subject: Re: [Owasp-antisamy] onsiteURL and offsiteURL accept urls
withparameters<br>
  <br>
 &gt;  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 moz-do-not-send="true"
 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 "importing" 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 <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 moz-do-not-send="true"
 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;
<a class="moz-txt-link-abbreviated" href="mailto:owasp-antisamy@lists.owasp.org">owasp-antisamy@lists.owasp.org</a><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
<a class="moz-txt-link-rfc2396E" href="mailto:arshan.dabirsiaghi@aspectsecurity.com">&lt;arshan.dabirsiaghi@aspectsecurity.com&gt;</a><br>
&gt; Sent: Thursday, June 12, 2008 6:57 AM<br>
&gt; To: Carlos Aguayo <a class="moz-txt-link-rfc2396E" href="mailto:carlos.aguayo@gmail.com">&lt;carlos.aguayo@gmail.com&gt;</a>;<br>
&gt; <a class="moz-txt-link-abbreviated" href="mailto:owasp-antisamy@lists.owasp.org">owasp-antisamy@lists.owasp.org</a><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: <a class="moz-txt-link-abbreviated" href="mailto:owasp-antisamy-bounces@lists.owasp.org">owasp-antisamy-bounces@lists.owasp.org</a> on behalf of Carlos
Aguayo<br>
&gt; Sent: Thu 6/12/2008 11:35 AM<br>
&gt; To: <a class="moz-txt-link-abbreviated" href="mailto:owasp-antisamy@lists.owasp.org">owasp-antisamy@lists.owasp.org</a><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="<a moz-do-not-send="true"
 href="http://mysite.com?first=12345&amp;second=34567">http://mysite.com?first=12345&amp;second=34567</a><br>
&gt; &lt;<a moz-do-not-send="true"
 href="http://mysite.com?first=12345&amp;second=34567">http://mysite.com?first=12345&amp;second=34567</a>&gt;"&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>
<a class="moz-txt-link-abbreviated" href="mailto:jim.manico@aspectsecurity.com">jim.manico@aspectsecurity.com</a> | <a class="moz-txt-link-abbreviated" href="mailto:jim@manico.net">jim@manico.net</a><br>
(301) 604-4882 (work)<br>
(808) 652-3805 (cell)<br>
  <br>
Aspect SecurityT<br>
Securing your applications at the source<br>
  <a moz-do-not-send="true" href="http://www.aspectsecurity.com">http://www.aspectsecurity.com</a><br>
  <br>
  <br>
  </font>
  </p>
<!--[object_id=#aspectsecurity.com#]--></blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">-- 
Jim Manico, Senior Application Security Engineer
<a class="moz-txt-link-abbreviated" href="mailto:jim.manico@aspectsecurity.com">jim.manico@aspectsecurity.com</a> | <a class="moz-txt-link-abbreviated" href="mailto:jim@manico.net">jim@manico.net</a>
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security™
Securing your applications at the source
<a class="moz-txt-link-freetext" href="http://www.aspectsecurity.com">http://www.aspectsecurity.com</a></pre>
</body>
</html>