Re^2: :OWASP ESAPI Implementation for Perl?

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.

Comment on Re^2: :OWASP ESAPI Implementation for Perl?

Replies are listed 'Best First'.
Re^3: :OWASP ESAPI Implementation for Perl? by afoken (Chancellor) on Dec 19, 2010 at 22:06 UTC
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". ;-)	[reply] [d/l] [select]
Re^4: :OWASP ESAPI Implementation for Perl? by Anonymous Monk on Dec 20, 2010 at 04:08 UTC
Hi - ESAPI isn't attempting any magic. We believe developers need to have a set of strong simple security controls available, and so we created an API and a reference implementation. We can't do the impossible, so there's only limited support for verifying URLs. However, there are lots of controls that you might find useful, including validation, canonicalization, encoding, encryption, authentication, access control, logging, random numbers, etc...	[reply]
Re^5: :OWASP ESAPI Implementation for Perl? by BrowserUk (Patriarch) on Dec 20, 2010 at 04:47 UTC
We can't do the impossible, so there's only limited support for verifying URLs. Could you explain exactly what verification you do do? With examples of url's that would fail your verification? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]