如何使用ESAPI修复HTTP响应分裂漏洞

Question

在最近的一个findbugs(FB)运行后,它抱怨:安全性 - HTTP响应分裂漏洞以下代码触发它:

String referrer = req.getParameter("referrer");
 if (referrer != null) {
  launchURL += "&referrer="+(referrer);
 }
resp.sendRedirect(launchURL);

基本上'referrer'http参数包含一个url,当点击我们的应用程序中的后退按钮时,浏览器返回到该url.它作为参数附加到url.经过一番研究后,我知道我需要清理引荐来源网址.经过一番研究后,我发现esapi项目似乎提供了这种功能:

//1st canonicalize
import org.owasp.esapi.Encoder;
import org.owasp.esapi.Validator;
import org.owasp.esapi.reference.DefaultEncoder;
import org.owasp.esapi.reference.DefaultValidator;
[...]
Encoder encoder = new DefaultEncoder(new ArrayList<String>());
String cReferrer = encoder.canonicalize(referrer);

但是我没有弄清楚如何检测例如jscript代码或其他不属于引用URL的东西.那么如何用esapi实现这一目标呢？

我试过了:

Validator validator = new DefaultValidator(encoder);
validator.isValidInput("Redirect URL",referrer,"HTTPParameterValue",512,false);

但这不起作用.我需要的是一个导致以下结果的函数:

http://www.google.com (ok)

http://www.google.com/login?dest=http://google.com/%0D%0ALocation:javascript:%0D%0A%0D%0Aalert(document.cookie)(不行)

或者是否足以称之为以下声明？

encoder.encodeForHTMLAttribute(referrer);

任何帮助赞赏.

Answer 1

如果有人有兴趣,这是我的最终解决方案.首先我规范化然后对字符串进行URL解码.如果存在CR或LF(\n\r),我只剪切了以\n或\ r开头的潜在"攻击"字符串的其余部分.

String sanitize(String url) throws EncodingException{

    Encoder encoder = new DefaultEncoder(new ArrayList<String>());
    //first canonicalize
    String clean = encoder.canonicalize(url).trim();
    //then url decode 
    clean = encoder.decodeFromURL(clean);

    //detect and remove any existent \r\n == %0D%0A == CRLF to prevent HTTP Response Splitting
    int idxR = clean.indexOf('\r');
    int idxN = clean.indexOf('\n');

    if(idxN >= 0 || idxR>=0){
        if(idxN>idxR){
            //just cut off the part after the LF
            clean = clean.substring(0,idxN-1);
        }
        else{
            //just cut off the part after the CR
            clean = clean.substring(0,idxR-1);
        }
    }

    //re-encode again
    return encoder.encodeForURL(clean);
}

从理论上讲,我可以稍后验证ESAPI.properties中定义的'HTTPParameterValue'正则表达式的值,但它不喜欢http://中的冒号,我没有进一步调查.

还有一个评论经过测试:现在大多数现代浏览器(Firefox> 3.6,Chrome,IE10等)检测到这种漏洞并且不执行代码......