in reply to :OWASP ESAPI Implementation for Perl?

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).

  • Comment on Re: :OWASP ESAPI Implementation for Perl?

Replies are listed 'Best First'.
Re^2: :OWASP ESAPI Implementation for Perl?
by dannyboy1234 (Initiate) on Dec 19, 2010 at 21:34 UTC

    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.

[reply]
      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]
        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]

In Section Seekers of Perl Wisdom