仅仅检查Referer头就足以防止CSRF吗？

Question

比较Referer http头足以防止CSRF，我有下面的html代码。在

<div id="Message"></div><br>
Username:<br>
<input type="text" name="Username" id="Username"><br>
Password:<br>
<input type="password" name="Password" id="Password"><br>
Keep me logged in:<br>
<input type="checkbox" id="KeepSessionAlive"><br>
<input type="submit" onClick="ProcessLogin();">
<script>
function ProcessLogin(){
    Username=document.getElementById("Username").value;
    Password=document.getElementById("Password").value;
    KeepSessionAlive=document.getElementById("KeepSessionAlive").value;
    var xmlhttp;
    if (window.XMLHttpRequest){// code for IE7+, Firefox, Chrome, Opera, Safari
            xmlhttp=new XMLHttpRequest();
    }else{// code for IE6, IE5
            xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
    }
    xmlhttp.onreadystatechange=function(){
            if (xmlhttp.readyState==4 && xmlhttp.status==200){
                    document.getElementById("Message").innerHTML=xmlhttp.responseText;
            }
    }
    xmlhttp.open("POST","/Login/Process",true);
    xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
    xmlhttp.send("<A>Username</A><B>"+Username+"</B><A>Password</A><B>"+Password+"</B><A>KeepSessionAlive</A><B>"+KeepSessionAlive+"</B>");
}
</script>

这只是一个标准的html表单，但我想知道如果我使用下面的代码，我可以完全保护我免受CSRF攻击。在

^{pr2}$

Answer 1

是的，这已经足够了，但它被认为是一种较弱的保护形式：

Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF prevention when memory is scarce. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token.

However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check and some organizations or browser tools remove referrer headers as a form of data protection. There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change. Also note that the attacker has limited influence over the referer. For example, if the victim's domain is "site.com" then an attacker have the CSRF exploit originate from "site.com.attacker.com" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.

In short, referer checking is a reasonable form of CSRF intrusion detection and prevention even though it is not a complete protection. Referer checking can detect some attacks but not stop all attacks. For example, if you HTTP referrer is from a different domain and you are expecting requests from your domain only, you can safely block that request.

如果您想要一个防止来自XHR的CSRF的“快速方法”，您可以设置并检查一个自定义头，如^{}。目前这是安全的，但是推荐的方法是Synchronizer Token Pattern。这对于浏览器插件中的缺陷更为强大，比如允许设置通常不可能设置的头的old vulnerability in Flash。在