X-Requested-With 헤더의 요점은 무엇입니까?

X-Requested-With 헤더의 요점은 무엇입니까?

JQuery 및 기타 프레임워크는 다음 헤더를 추가합니다.

X-Requested-With: XMLHttpRequest

이게 왜 필요하죠?서버가 AJAX 요청을 일반 요청과 다르게 처리하는 이유는 무엇입니까?

업데이트: https://core.spreedly.com/manual/payment-methods/adding-with-js라는 헤더를 사용한 실제 예를 발견했습니다.AJAX를 사용하지 않고 결제 프로세서를 요청하면 처리가 완료되면 원래 웹 사이트로 리다이렉트됩니다.AJAX에서 요구되었을 때 리다이렉션은 실행되지 않습니다.

적절한 이유는 보안을 위해서입니다.이 헤더는 CORS 경유 서버의 동의 없이 AJAX 요구 크로스 도메인에 추가할 수 없기 때문에 CSRF 공격을 방지할 수 있습니다.

오리진 간에는 다음 헤더만 허용됩니다.

• 승낙하다
• 수용 언어
• 콘텐츠 언어
• 마지막 이벤트 ID
• 콘텐츠 타입

그 외의 경우는, CORS가 서포트하는 브라우저로 「사전 비행」요구가 발행됩니다.

CORS를 할 수 .X-Requested-WithXHR을 사용하다

서버가 이 헤더가 존재하는지 확인하고 있는 경우 JavaScript를 사용하여 사용자를 대신하여 요청을 시도하는 공격자의 도메인에서 요청이 시작되지 않았음을 인식합니다.또한 토큰을 사용하지 않으면 크로스 도메인이 아님을 확인하기 어려운 일반 HTML 형식에서 요청이 POST되지 않았는지 확인합니다.(단, 지원되는 브라우저에서는 헤더를 체크하는 것이 옵션일 수 있습니다.단, 오래된 브라우저는 취약합니다.

새로운 플래시 바이패스가 검출되었습니다.

리다이렉트 단계가 있는 경우 Safari에서 실행되는 플래시가 이 헤더를 설정할 수 있기 때문에 토큰과 결합할 수 있습니다.Chrome에서도 동작하고 있는 것 같습니다만, 현재는 복구되고 있습니다.영향을 받는 다른 버전을 포함한 자세한 내용은 여기를 참조하십시오.

OWASP는 이것을 오리진 및 레퍼러 체크와 조합할 것을 권장합니다.

이 방어 기술은 사이트 간 요청 위조를 위한 견고한 방어 섹션 4.3에서 구체적으로 설명합니다.그러나 Vimeo의 CSRF 결함을 이용하기 위해 플래시를 사용한 이러한 방어 방법을 2008년 초에, 그리고 2015년에 Mathias Karlsson에 의해 다시 문서화되었습니다.단, 플래시 공격은 오리진 또는 레퍼러 헤더를 스푸핑할 수 없기 때문에 두 헤더를 모두 체크함으로써 플래시 바이패스 CSRF 공격을 방지할 수 있을 것으로 생각됩니다.(주: 이 의견에 대해 확인 또는 반박할 수 있는 사람이 있으면 이 기사를 갱신할 수 있도록 알려 주십시오.)

그러나 이미 논의된 이유로 인해 오리진 확인이 까다로울 수 있습니다.

갱신하다

CORS, CSRF 및 X-Requested-With에 대한 보다 상세한 블로그 투고를 작성.

Silverlight Fox의 답을 꼭 읽어보세요.그것은 더 중요한 이유를 강조한다.

그 이유는 대부분 요청의 출처를 알고 있다면 요청의 출처를 약간 맞춤화할 수 있기 때문입니다.

예를 들어, 많은 레시피가 있는 웹 사이트가 있다고 가정해 봅시다.또한 커스텀 jQuery 프레임워크를 사용하여 클릭하는 링크를 기반으로 레시피를 컨테이너에 밀어 넣습니다.링크는 다음과 같습니다.www.example.com/recipe/apple_pie

일반적으로 페이지 전체, 머리글, 바닥글, 레시피 콘텐츠 및 광고가 반환됩니다.그러나 누군가가 웹 사이트를 탐색하는 경우 이러한 부품 중 일부는 이미 로드되어 있습니다.따라서 사용자가 선택한 레시피를 얻기 위해 AJAX를 사용할 수 있지만 시간과 대역폭을 절약하기 위해 헤더/풋어/애드를 로드하지 않습니다.

이제 데이터에 대한 보조 끝점을 다음과 같이 쓸 수 있습니다.www.example.com/recipe_only/apple_pie유지하기가 더 힘들고 다른 사람들과 공유하기가 더 힘들죠.

그러나 요청을 수행한 후 데이터의 일부만 반환하는 Ajax 요청임을 감지하는 것이 더 쉽습니다.이렇게 하면 사용자가 대역폭 낭비를 줄이고 사이트의 응답성을 높일 수 있습니다.

어떤 요구는 Ajax이고 어떤 요구는 Ajax가 아닌지를 추적하는 것이 유용할 수 있기 때문에 프레임워크는 헤더만 추가합니다.그러나 이러한 기술을 사용하는 것은 전적으로 개발자에게 달려 있습니다.

이건 사실 좀 비슷해Accept-Languageheader를 클릭합니다.브라우저는 웹사이트를 요청할 수 있습니다.URL에 /ru/ 또는 유사한 내용을 삽입하지 않고 이 웹사이트의 러시아 버전을 보여 주십시오.

일부 프레임워크에서는 이 헤더를 사용하여 xhr 요청을 검출하고 있습니다.예를 들어 스프링 보안에서 이 헤더를 사용하여 xhr 요청을 식별하고 json 응답 또는 html 응답을 응답으로 제공합니다.

대부분의 Ajax 라이브러리(v2.1의 경우 Protype, JQuery 및 Dojo)에는 일반 하이퍼링크 또는 폼 제출 버튼을 클릭하여 트리거되는 대신 XMLHttpRequest에 의해 요청이 이루어졌음을 나타내는 X-Requested-With 헤더가 포함되어 있습니다.

출처 : http://grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html

언급URL : https://stackoverflow.com/questions/17478731/whats-the-point-of-the-x-requested-with-header