Hi k,

To answer your question:

• > Is it true that a domain should be able to safely redirect to a URL that is local to that domain? (By this I mean the request is relative to the domain's context root, having no explicit protocol/domain/port in the URL)

Typically yes, though it's impossible to make any absolute statements about this as it depends entirely on the available functionality within the application.

Say for example the application supports a URL "/admin/drop-database" which drops the database immediately if visited by the administrator. It would be very unfortunate if an attacker was able to trick the admin into going there.

• And if so, I'm curious why there seems to be little public (esp. Java) support for a cleanser for this functionality, and none recognized by Veracode.

Because of the aforementioned problem with knowing what URLs are and are not safe to redirect to it's generally advisable to create your own cleansing function (which you can get our engine to recognise by annotating it https://help.veracode.com/reader/DGHxSJy3Gn3gtuSIN2jkRQ/xrEjru~XmUHpO6~0FSae2Q ).

> I note that several posts on this suggest checking to see if the redirect is to a local url. And https://help.veracode.com/reader/4EKhlLSMHm5jC8P8j3XccQ/QSde6PQlbxAPLvVx1K933A shows recognized support for IsUrlLocalToHost (although the definition of "local to host" is a bit vague for this particular method). Is there similar support for Java that's also recognized by the Veracode static scan? 

Unfortunately, we are not currently aware of any Java method that performs the same validation. If you are please let us know.

>We could obviously implement this ourselves a la, 

>

> if (new java.net.URI("asdf").getHost() == null) { 

> // ...it's ok 

> }

> 

> But then we'd have to manually mitigate things.

This may be okay in the context of your application, but be aware that this may allow "evil.com" which you may not wish to redirect to. For a short (incomplete) testcase including a port of the IsLocalUrl method (found here https://github.com/ASP-NET-MVC/aspnetwebstack/blob/master/src/System.Web.WebPages/RequestExtensions.cs ) see the attached.java file.

> It seems like ESAPI/OWASP or someone could easily provide this and Veracode readily adopt it as a supported cleanser. Maybe there's something I still don't fully understand about this type of flaw?

Unfortunately, the ESAPI library is not actively developed so I'm afraid that's not a viable avenue for new security functionality.

Please do let us know if you have found a port of this algorithm in a trustworthy library we can support.

Thank you,

Boy Baukema

Hi Boy,

Thank you for the thorough response along with the sample java port and reference to the original code for IsLocalUrl. Along with wanting to say thanks, I wanted to add just a little bit of follow up.

1. You make the point that redirecting to the request's domain isn't always safe and site the example of "/admin/drop-database". But
   1. Is the above example really in the realm of CWE 601? It seems that anyone with enough access to the secure session to hack in a redirect like that could just issue the request directly without relying on a redirect at all?
   2. And if it's truly not safe, then why does Veracode recognize the .NET IsLocalUrl implementation as valid remediation in their scan engine?
2. We'll likely use the logic you site/port for IsLocalUrl - thanks again - and mitigate. We do know about the custom cleanser Java annotations, but our Security team hasn't yet enabled them for our company, and probably won't in the near future (if at all).
3. Even with the annotations enabled, my understanding is that they're really just a way to fast-track mitigations and not a way to actually remediate flaws. But as I say, that's academic for us currently
4. We also don't know of any public Java library that includes the logic in IsLocalUrl. I may post to stackoverflow to see. If you know of any existing libraries that might accept contributions, we'd be willing to submit a pull request for this
5. I'm just curious why Veracode doesn't consider publishing their own jar files for things like this. Vercode already publishes a jar for the annotations so there's some precedent there. Admittedly annotations represent code decorations more than logic. But I thought I'd ask

Thanks again for your time. Your input is very much appreciated.

Regards,

Ken

Hi Ken,

1. You make the point that redirecting to the request's domain isn't always safe and site the example of "/admin/drop-database". But
   1. Is the above example really in the realm of CWE 601? It seems that anyone with enough access to the secure session to hack in a redirect like that could just issue the request directly without relying on a redirect at all?

CWE 601 concerns it's self not with what *I* can do with the redirect, but with what I can make *you* do with that link. Providing such a link (obfuscated off course) to an administrator (signed into the application) could prove to have devastating consequences.

1. And if it's truly not safe, then why does Veracode recognize the .NET IsLocalUrl implementation as valid remediation in their scan engine?

It's better to have a custom method that you can guarantee follows your rules of redirection. Still we have to make a trade-off, for the majority of applications constraining the URL to local paths is 'good enough' and it's supported by the default .NET library. If a similar method was available for Java we could support it as well.

1. We'll likely use the logic you site/port for IsLocalUrl - thanks again - and mitigate. We do know about the custom cleanser Java annotations, but our Security team hasn't yet enabled them for our company, and probably won't in the near future (if at all).
2. Even with the annotations enabled, my understanding is that they're really just a way to fast-track mitigations and not a way to actually remediate flaws. But as I say, that's academic for us currently

I understand your frustration, unfortunately this is a discussion I would recommend you have with your security team. We allow you to set the setting to None / Proposed / Accept. The last option would have the same effect as remediation (but with the added audit trail).

1. We also don't know of any public Java library that includes the logic in IsLocalUrl. I may post to stackoverflow to see. If you know of any existing libraries that might accept contributions, we'd be willing to submit a pull request for this
2. I'm just curious why Veracode doesn't consider publishing their own jar files for things like this. Vercode already publishes a jar for the annotations so there's some precedent there. Admittedly annotations represent code decorations more than logic. But I thought I'd ask

It's unfortunate ESAPI is no longer actively developed as that would have been a good candidate. I'm afraid I'm not aware of any other good candidates, perhaps the Spring Framework? The OWASP Java Encoder? Though it's not really an encoder.

As I mentioned the best defense against CWE 601 is a custom method that follows the rules for your application. Furthermore Veracode prefers to rely on industry standard controls by language and library authors within the given technology rather than develop and maintain it's own controls.

Thank you,

Boy Baukema