X-Requested-With 헤더 서버 검사가 Ajax 기반 애플리케이션의 CSRF로부터 보호하기에 충분합니까?

X-Requested-With 헤더 서버 검사가 Ajax 기반 애플리케이션의 CSRF로부터 보호하기에 충분합니까?

저는 모든 요청이 기본적으로 기본적으로 다음과 같이 보이는 메인 컨트롤러를 통과하는 완전히 Ajax 기반의 애플리케이션을 개발하고 있습니다.

if(strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') {
    fetch($page);
}

이 정도면 일반적으로 사이트 간 요청 위조로부터 보호하기에 충분합니까?

요청할 때마다 전체 페이지가 새로 고쳐지지 않을 때는 회전 토큰이 있는 것이 불편합니다.

저는 모든 요청에 따라 고유 토큰을 글로벌 자바스크립트 변수로 전달하고 업데이트할 수 있다고 생각합니다. 하지만 왠지 어색하고 본질적으로 안전하지 않은 것처럼 보입니다.

편집 - 사용자의 UUID와 같은 정적 토큰이 없는 것보다 나을 수 있습니까?

편집 #2 - 룩이 지적했듯이, 이것은 머리를 쪼개는 질문일 수 있습니다.저는 양쪽 모두의 추측을 읽었고 오래된 버전의 플래시가 이런 종류의 속임수에 이용될 수 있다는 먼 소문을 들었습니다.저는 그것에 대해 아무것도 모르기 때문에, 저는 이것이 어떻게 CSRF 위험인지 설명할 수 있는 사람에게 현상금을 걸고 있습니다.그렇지 않으면, 아르테파토에게 줄 겁니다.감사해요.

충분하다고 생각합니다.도메인 간 요청이 허용된 경우 공격자가 Javascript를 사용하여 CSRF 토큰을 가져와 위조된 요청에 사용할 수 있기 때문에 어쨌든 실패할 수 있습니다.

정적 토큰은 좋은 생각이 아닙니다.토큰은 세션당 한 번 이상 생성되어야 합니다.

EDIT2 마이크는 결국 옳지 않습니다, 죄송합니다.제가 링크한 페이지를 제대로 읽지 못했습니다.다음과 같이 표시됩니다.

단순한 교차 사이트 요청은 다음과 같습니다. [...] HTTP 요청으로 사용자 정의 헤더를 설정하지 않습니다(예: X-수정됨 등).

따서라를 하면, 할경우설이 됩니다.X-Requested-With제출해야 , 한, 사전 비행에 응답해야 합니다.OPTIONS교차 사이트 요청을 승인하는 요청입니다. 연결되지 않습니다.

EDIT Mike가 맞습니다. Firefox 3.5부터는 교차 사이트 XMLHttpRequest가 허용됩니다.결과적으로, 당신은 또한 확인해야 합니다.Origin헤더가 존재할 경우 사이트와 일치합니다.

if (array_key_exists('HTTP_ORIGIN', $_SERVER)) {
    if (preg_match('#^https?://myserver.com$#', $_SERVER['HTTP_ORIGIN'])
        doStuff();
}
elseif (array_key_exists('HTTP_X_REQUESTED_WITH', $_SERVER) &&
        (strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest'))
    doStuff(); 

나는 이것이 안전하다고 믿지 않습니다.동일한 오리진 정책은 다른 도메인의 문서가 다른 도메인에서 반환된 내용에 액세스하지 못하도록 설계되었습니다.이것이 XSRF 문제가 애초에 존재하는 이유입니다.일반적으로 XSRF는 반응에 관심이 없습니다.삭제 작업과 같은 특정 유형의 요청을 실행하는 데 사용됩니다.가장 간단한 형태로, 이 작업은 적절한 형식의 img 태그를 사용하여 수행할 수 있습니다.제안된 솔루션은 이러한 단순한 형식을 방지할 수는 있지만, XMLHttp 개체를 사용하여 요청하는 것을 방지할 수는 없습니다.XSRF에 대한 표준 예방 기법을 사용해야 합니다.자바스크립트로 난수를 생성하여 쿠키와 폼 변수에 추가하는 것을 좋아합니다.이렇게 하면 코드가 해당 도메인에 대한 쿠키도 작성할 수 있습니다.자세한 내용은 이 항목을 참조하십시오.

또한 XMLHTTP가 스크립트에서 작동하지 않는다는 설명을 미리 입력합니다.저는 다음 코드를 파이어폭스 3.5와 함께 사용하여 localhost 도메인에서 실행 중인 html에서 구글에 요청했습니다.내용은 반환되지 않지만, Firebug를 사용하면 요청이 이루어진 것을 확인할 수 있습니다.

<script>
var xmlhttp = false; 

if (!xmlhttp && typeof XMLHttpRequest != 'undefined') {
    try {
        xmlhttp = new XMLHttpRequest();
    } catch (e) {
        xmlhttp = false;
    }
}
if (!xmlhttp && window.createRequest) {
    try {
        xmlhttp = window.createRequest();
    } catch (e) {
        xmlhttp = false;
    }
}

xmlhttp.open("GET", "http://www.google.com", true);
xmlhttp.onreadystatechange = function() {
    if (xmlhttp.readyState == 4) {
        alert("Got Response");
        alert(xmlhttp.responseText)
    }
}

xmlhttp.send(null)
alert("test Complete");

저는 이것이 어떤 종류의 보호를 제공한다고 생각하지 않습니다.공격 사이트는 여전히 사용할 수 있습니다.xmlhttprequest교차 사이트 요청의 경우 체크를 무시합니다.

단답: 아니오.모든 공격자는 Ajax를 사용하여 웹 사이트를 공격합니다.각 Ajax 요청 시 업데이트할 수명이 짧지만 너무 길지 않은 임의 토큰을 생성해야 합니다.

동시에 여러 Ajax 요청을 실행할 수 있기 때문에 Javascript에서 토큰 배열을 사용해야 합니다.

xmlhttprequest는 일반적으로 사이트 간 요청 위조에 취약하지 않기 때문에 안전합니다.

이것은 클라이언트 측의 문제이기 때문에, 가장 안전한 방법은 각 브라우저의 보안 아키텍처를 확인하는 것입니다 :-

^{(요약입니다. 이 질문이 매우 혼란스러워서 이 답변을 추가합니다. 투표 결과를 보겠습니다.)}

아니요, 쉽게 무시할 수 없습니다. 이 헤더와 이 헤더의 자격 증명이 포함된 요청을 서버에 교차 도메인-플래시 요청을 수행하면 다음을 참조하십시오. https://www.geekboy.https/suffort/json-csrf-using-flash/?unapproved=66858cf808808690596905da

CSRF로부터 보호하는 가장 좋은 방법은 헤더 또는 파라미터에 각 요청에 대한 비밀 키가 포함되도록 하는 것입니다.

언급URL : https://stackoverflow.com/questions/3315914/is-an-x-requested-with-header-server-check-sufficient-to-protect-against-a-csrf