Просто проверяет заголовок Referer, чтобы предотвратить CSRF?

Question

Сравнивая HTTP-заголовок Referer, чтобы предотвратить 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> 

Это просто Standerd HTML форма, но мне было интересно, если я использую ниже код я могу быть полностью защищенным от атак CSRF.

class LoginProcess(webapp2.RequestHandler): 
    def post(self): 
     self.response.headers['Content-Type'] = 'text/plain' 
     HTTTP_REFERER=self.request.referer 
     if HTTP_REFER=="http://example.com": 
      self.response.write('Referer: '+cgi.escape(HTTTP_REFERER)) 

Answer 1

Да, это достаточно, но считается более слабой формой защиты:

Хотя это тривиальное подделывать заголовок Referer на собственном браузере, это невозможно сделать в атака CSRF. Проверка рефератора является широко используемым методом предотвращения CSRF на встроенных сетевых устройствах , поскольку для него не требуется состояние для каждого пользователя. Этот делает рефератора полезным методом предотвращения CSRF, когда память скудна. Этот метод смягчения CSRF также широко используется с неаутентифицированными запросами, такими как запросы, сделанные до установления состояния сеанса, которое требуется для отслеживания токена синхронизации .

Однако проверка реферирования считается слабее от Защита CSRF. Например, открытые уязвимости переадресации могут быть , используемые для использования запросов на основе GET, которые защищены реферированием , а некоторые организации или инструменты браузера удаляют заголовки рефереров в качестве одной из форм защиты данных. Существуют также общая реализация ошибок с реферированными проверками. Например, если атака CSRF происходит из домена HTTPS, то референт будет опущен. В в этом случае отсутствие референта следует рассматривать как атаку , когда запрос выполняет изменение состояния. Также обратите внимание, что злоумышленник имеет ограниченное влияние на референта. Например, если домен жертвы является «site.com», тогда злоумышленник использует эксплойт CSRF , исходя из «site.com.attacker.com», который может обмануть сломанного реферирования . XSS можно использовать для обхода проверки реферирования.

Короче говоря, проверка референта является разумной формой обнаружения вторжения CSRF , хотя это не полная защита. Проверка референта может обнаруживать некоторые атаки, но не останавливать все атаки. Например, для , если вы используете HTTP-реферер из другого домена, и вы ожидаете запросы только от вашего домена, вы можете безопасно заблокировать этот запрос .

Если вы хотите «быстрый способ» предотвращения CSRF от XHR вы можете установить и проверить пользовательский заголовок, такие как X-Requested-With. В настоящее время это безопасно, однако рекомендуемый подход - Synchronizer Token Pattern. Это более устойчиво против ошибок в плагинах браузера, таких как old vulnerability in Flash, которые позволяют устанавливать заголовки, которые обычно не могут быть возможными.