[Esapi-dev] [Esapi-user] URL Validation and Encoding

[Chris Schmidt]

  It seems like we may be redoing a lot of work here that is already 
done for us -

 From the JavaDocs on java.net.URL

Note, the |URI| 
<http://download.oracle.com/javase/6/docs/api/java/net/URI.html> class 
does perform escaping of its component fields in certain circumstances. 
The recommended way to manage the encoding and decoding of URLs is to 
use |URI| 
<http://download.oracle.com/javase/6/docs/api/java/net/URI.html>, and to 
convert between these two classes using |toURI()| 
<http://download.oracle.com/javase/6/docs/api/java/net/URL.html#toURI%28%29> 
and |URI.toURL()| 
<http://download.oracle.com/javase/6/docs/api/java/net/URI.html#toURL%28%29>. 


Unless I am missing something, why not just use the built-in API to 
perform the encoding of the URL.

Validation is another story altogether, but URL validation seems like a 
big dark hole that could lead to some interesting assumptions and 
expectations - I have written a couple of URL validators that even go so 
far as to do a DNS lookup of the domain, submit a request to the url 
specified (and thought has been given to scanning the response for 
*dangerous* content), verify the response code is a 200 and only then 
would the URL be valid.

Point here being that while this sounds like something that may be 
somewhat useful to a handful of people, and perhaps at least a basic - 
this is a valid url - functionality would be helpful, I think that there 
are bigger fish to fry that re-inventing RFC2396 Encoding for URLs. To 
the best of my knowledge, the URI encoding is fully compliant. If we 
really want to add to the encoding interface, perhaps just a delegation 
method to that is the right way to go?

Thoughts?

On 9/22/2010 11:58 PM, Jim Manico wrote:
> We can add a second encoder for relative URL's, but the programmer would
> need to specify the domain, using one of the other URL constructors, like:
>    new URL("http", "www.gamelan.com", "/pages/Gamelan.net.html");
>
> And ESAPI would provide:
>
> ESAPI.encoder().encodeCompleteURL(String URL);
> ESAPI.encoder().encodeURLParameter(String data); //Javascript calls this a
> "URIComponent"
> ESAPI.encoder().encodeRelativeURL(String root, String relativeURL);
>
> As well as
>
> ESAPI.validator().assertValidCompleteURL(String url) throws
> ValidationException;
> ESAPI.validator().assertValidRelativeURL(String root, String relativeURL)
> throws ValidationException;
> boolean ESAPI.validator().isValidCompleteURL(String url);
> boolean ESAPI.validator().isValidRelativeURL(String root, String
> relativeURL);
>
> - Jim
>
>
> -----Original Message-----
> From: Ed Schaller [mailto:schallee at darkmist.net]
> Sent: Wednesday, September 22, 2010 4:44 PM
> To: augustd
> Cc: Jim Manico; ESAPI-Developers; esapi-user at lists.owasp.org
> Subject: Re: [Esapi-user] [Esapi-dev] URL Validation and Encoding
>
> * PGP Signed by an unknown key
>
>> This should be easy enough to do with built-in methods of java.net.URL
> like
>> getProtocol(), getHost(), getPath(), etc.
> Just to be the devil's advocate here, what happens if the URL the
> developer wants to support doesn't have a protocol handler? Is this
> something we care about? If it is, java.net.URL wont work well and
> adding new protocol handlers has implications on ClassLoaders and java
> 2 security.
>
>>>> ------>
> * Unknown Key
> * 0xA1297841
>
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-dev/attachments/20100923/e627f2ff/attachment.html