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-With교차 도메인 XHR 요청 에 추가 할 수 없습니다 .

서버가이 헤더가 있는지 확인하는 경우, 사용자는 JavaScript를 사용하여 사용자 대신 요청을 시도하는 공격자의 도메인에서 요청이 시작되지 않았 음을 알 수 있습니다. 또한 요청이 일반 HTML 양식에서 POST되지 않았는지 확인합니다. 토큰을 사용하지 않으면 도메인 간이 아닌지 확인하기가 더 어렵습니다. 그러나 오래된 브라우저는 취약하게 유지되지만 지원되는 브라우저에서는 헤더를 확인하는Origin 것이 옵션이 될 수 있습니다 .

새로운 플래시 바이 패스 발견

당신은 할 수 있습니다 토큰과 함께이 결합 플래시 OSX에서 Safari에서 실행되는 때문에, 리디렉션 단계가 있다면이 헤더를 설정할 수 있습니다 . Chrome에서도 작동하는 것으로 보이지만 이제는 수정되었습니다. 영향을받는 다른 버전을 포함한 자세한 내용은 여기 를 참조하십시오 .

OWASP이를 Origin 및 Referer check와 결합하는 것이 좋습니다 .

이 방어 기술은 사이트 간 요청 위조에 대한 강력한 방어 섹션 4.3에서 구체적으로 설명됩니다. 그러나 Flash를 사용한 이러한 방어 우회는 2008 년 초와 2015 년에 다시 한 번 Mathme Karlsson에 의해 Vimeo의 CSRF 결함을 악용 한 것으로 기록되었습니다. 그러나 Flash 공격은 Origin 또는 Referer 헤더를 스푸핑 할 수 없으므로 두 가지를 모두 확인함으로써 이러한 우회 조합으로 인해 Flash 바이 패스 CSRF 공격을 막을 수 있다고 생각합니다. (참고 : 누구나이 믿음을 확인하거나 반박 할 수 있으면이 기사를 업데이트 할 수 있도록 알려주십시오.)

그러나 이미 논의한 이유로 Origin을 확인하는 것은 까다로울 수 있습니다.

최신 정보

CORS, CSRF 및 X-Requested-With here 에 대한보다 심도 깊은 블로그 게시물을 작성했습니다 .

---

SilverlightFox의 답변을 읽으십시오. 더 중요한 이유를 강조합니다.

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

예를 들어 레시피가 많은 웹 사이트가 있다고 가정 해 보겠습니다. 또한 사용자 지정 jQuery 프레임 워크를 사용하여 클릭하는 링크를 기준으로 레시피를 컨테이너에 밀어 넣습니다. 링크는www.example.com/recipe/apple_pie

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

이제 데이터에 대한 보조 엔드 포인트를 작성할 수 www.example.com/recipe_only/apple_pie있지만 다른 사람과 유지 관리 및 공유하기가 더 어렵습니다.

그러나 요청을 한 다음 데이터의 일부만 반환하는 아약스 요청임을 감지하는 것이 더 쉽습니다. 이렇게하면 사용자가 적은 대역폭을 낭비하고 사이트의 응답 성이 향상됩니다.

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

실제로는 Accept-Language헤더 와 비슷합니다 . 브라우저가 웹 사이트를 요청할 수 있습니다 URL에 / ru / 등을 삽입하지 않고도이 웹 사이트의 러시아어 버전을 보여주세요.

---

일부 프레임 워크는 xhr 요청을 감지하기 위해이 헤더를 사용합니다. 예를 들어 grails spring security는이 헤더를 사용하여 xhr 요청을 식별하고 json 응답 또는 html 응답을 응답으로 제공합니다.

대부분의 Ajax 라이브러리 (v2.1부터 프로토 타입, 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