I couldn't figure it out. I took at the link you provided, but it doesn't work without javascript, and then it doesn't explain what it does ... http://www.owasp.org/index.php/Perl appears to list some modules, so thats a starting point I guess. owasp.org fails at accessibility :)

I took at the link you provided, but it doesn't work without javascript

It seems to be intentionally damaged. Disable CSS too to see the page content without Javascript.

owasp.org fails at accessibility

Absolutely, and it seems to be intentional. The content is present, you just can't see it with CSS enabled, but Javascript disabled. It seems Javascript changes the CSS or the HTML to make the page readable again. That doesn't increase my trust in their product(s).

From the site:

ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development.

I read that as "sprinkle some magic fairy dust on your existing code and all security problems are magically gone". Smells like snake oil. Or maybe I'm just tired.

From the data sheet and the design patterns PDFs, it looks like a big fat form validator and a strange attempt to detect SQL injections. Several form validators are available on CPAN, not too hard to re-invent if needed, and SQL injection is impossible when you always use DBI placeholders.

So, what's left? Some buzzwords: Enterprise Security API, Web Application Firewall, design pattern.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

I'm hoping to find a security library to run the urls through prior to redirect.

I'm not a OWASP/ESAPI expert (so I could be wrong), but I don't think there is any black-box control that would magically solve any potential issues with redirects. You'll somehow have to maintain a list of what is valid. As the Open redirect page on OWASP says under "Related Controls": The server must have a relation of the authorized redirections (i.e. in a database).

thanks for the replies.

Basically I want a library I can run a url through before I redirect to it, to ensure it's not some type of security risk that I am unaware of.

I've talked to the client more it looks like I will be able to maintain a list of safe domains, but the url itself could be anything. So basically if the domain is found I'd like to run the url through some function prior to redirect. I don't care if the function makes it safe or just tells me it's unsafe, I could handle either case.

I guess if it could remove anything from say xss cheat
http://ha.ckers.org/xss.html
sheet that would be a starting point, but I'm not confident that's all that would need to be addressed in this context, thus I'm hoping for some type of vetted library.

Looks like HTML::Defang is one candidate but it only handles a url in an html (attribute only?) context from what I can see.

Basically I want a library I can run a url through before I redirect to it, to ensure it's not some type of security risk that I am unaware of.

Questions:

• What are the risks of a redirect to a malicious URL?
• What can you do to prevent the risks?
• Is it your responsibility to prevent those risks?

A URL is just that. You could check some basics:

• Does the URL have a scheme and is it allowed? Typically, you would only allow http, https, and ftp, and not telnet or file.
• Does the URL have a host name or IP address, does it resolve, and is it a non-private IP address?
• Are the path, query and fragment parts of the URL properly encoded?

After that, the browser leaves what you can control. You can't protect the browser user from being redirected to malicious pages. Simply because any sufficiently evil page can detect that you attempt to check it and present itself as a completely harmless page.

You can prevent information leakage. Many browsers sent a Referer header, so if the URL of the redirecting page contains sensitive information like a session ID, you may want to redirect via a "trampolin" page that is passed the redirection URL, and only that, as URL parameter. Perhaps you also want to create a new browser tab/window for the trampolin page.

If the redirection goes back to your own page / application, well, it should not be able to do any harm, because you validate all your input, properly encode / escape all your output, and use only DBI placeholders for database access. Also, your application runs with taint mode enabled, and it refuses to work on any input that can't be properly validated.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)