본문 바로가기
Webhacking/버그바운티

CSRF(Cross-Site Request Forgery) 공격

by Mina-Han 2022. 4. 13.

CSRF(Cross-Site Request Forgery) 공격

CSRF(Cross-Site Request Forgery - 사이트 간 요청 위조 공격)은 공격자가 공격 대상 브라우저에서 다른 웹 사이트로 HTTP 요청을 보낼 때 발생한다.

요청을 수신한 웹 사이트는 유효한 요청으로 받아들이며 공격 대상이 직접 전송한 것으로 여기고 작업을 수행한다.

이러한 공격은 일반적으로 취약한 웹 사이트에서 이미 인증을 완료한 대상을 공격 대상으로 삼으며, 공격 대상이 전혀 인지하지 못한 상황에서 요청을 보낸다.

CSRF 공격이 성공하면 공격자는 서버 측 정보를 수정하고 사용자 계정을 장악할 수도 있다.

 

예제)

  1. Bob은 뱅킹 웹 사이트에 로그인해 잔액을 확인한다.
  2. 작업을 마치고 Bob은 다른 도메인에서 이메일 계정을 확인한다.
  3. Bob은 낯선 웹 사이트로의 링크가 포함된 이메일을 수신했으며, 연결된 곳을 확인하려고 링크를 클릭한다.
  4. 낯선 사이트에 방문했을 때 Bob의 브라우저가 Bob이 사용하던 뱅킹 웹 사이트로 Bob의 계좌에서 공격자의 계좌로 이체하는 HTTP 요청을 보낸다.
  5. Bob이 사용하던 뱅킹 웹 사이트는 낯선(악성) 웹 사이트에서 시작된 HTTP 요청을 전달받는다. 뱅킹 웹 사이트에서는 CSRF 보호 기능이 없어 이체를 처리한다.

 

인증

CSRF 공격은 웹 사이트에서 요청을 인증하는 절차상의 약점을 악용한다.

일반적으로 사용자 이름과 비밀번호로 로그인해야 하는 웹 사이트를 방문하면 이러한 사이트에서는 사용자를 대상으로 인증을 수행할 것이다. 그런 다음 사이트는 해당 인증 결과를 브라우저에 저장하기 때문에 이 사이트의 새로운 페이지를 방문할 때마다 로그인할 필요가 없다. 인증은 기본 인증 프로토콜이나 쿠키라는 두 가지 방식을 사용해 저장할 수 있다.

 

HTTP 요청에 Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l 헤더가 포함된 경우 기본 인증을 사용하는 사이트인 것을 알 수 있다. 무작위로 보이는 문자열은 base64 인코딩을 적용한 사용자 이름과 비밀번호며 콜론으로 구분된다. 이 경우에는 QWxhZGRpbjpPcGVuU2VzYW1l은 Aladdin:OpenSesame으로 디코딩된다.

 

쿠키(Cookie)는 웹 사이트가 사용자의 브라우저에서 만들고 저장하는 작은 파일이다.

웹 사이트는 사용자 기본 설정이나 웹 사이트 방문 기록과 같은 정보를 저장하는 등 다양한 목적으로 쿠키를 사용한다.

쿠키는 표준화를 준수하는 일련의 정보로 특정 속성을 보유하고 있다. 이러한 세부 정보는 브라우저에게 쿠키와 쿠키의 처리 방법을 알려준다.

일부 쿠키 속성으로 domain(도메인), expires(만료), max-age(최대 기간), secure(보안), httponly(http 전용)가 있다.

쿠키는 속성 이외에도 이름/값 쌍을 포함시킬 수 있으며, 이름/값 쌍은 식별자와 웹 사이트로 전달하는 연관 값으로 구성된다(쿠키의 domain 속성은 이러한 정보를 전달하는 사이트를 정의한다.).

 

브라우저는 사이트가 설정할 수 있는 쿠키의 개수를 정의한다. 하나의 사이트를 대상으로 일반 브라우저는 50-150개 사이의 쿠키를 설정할 수 있으며, 일부 브라우저는 600개 이상의 쿠키를 지원한다. 브라우저는 일반적으로 사이트당 쿠키를 최대 4KB까지 허용한다. 쿠키 이름이나 값에 대한 표준은 없으며 사이트에서 이름/값 쌍과 사용 목적을 자유롭게 선택할 수 있다.

예를 들어 사이트에서 sessionId 쿠키를 사용해 사용자가 방문하는 모든 페이지나 수행하는 작업을 대상으로 사용자 이름과 비밀번호의 입력을 받지 않고 사용자를 기억할 수 있다.

예를 들면 쿠키의 이름/값 쌍은 sessionId=9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08이고, 쿠키의 도메인은 .site.com일 수 있다. 따라서 sessionId 쿠키는 사용자가 방문하는 모든 .<site>.com 사이트(예를 들면 foo.<site>.com, bar.<site>.com, www.<site>.com)으로 전송할 수 있다.

 

secure와 httponly 속성은 브라우저에게 쿠키를 보내고 읽는 시점과 방식을 알려준다.

이 속성은 값을 할당하지 않는 대신 쿠키에서 플래그의 역할을 한다.

쿠키에 secure 속성이 포함되면 브라우저는 HTTPS 사이트를 방문할 때만 해당 쿠키를 전송한다.

예를 들어 secure 쿠키가 있는 http://www.<site>.com/(HTTP 사이트)을 방문하면 브라우저가 해당 사이트로 쿠키를 보내지 않는다. HTTPS 연결은 암호화되고 HTTP 연결은 암호화를 적용하지 않기 때문에 개인정보를 보호하기 위해서다.

httponly 속성은 브라우저에게 HTTP 및 HTTPS 요청을 통해서만 쿠키를 읽게 지시한다.

따라서 브라우저는 자바스크립트와 같은 스크립팅 언어가 쿠키 값을 읽는 것을 허용하지 않는다. 쿠키에 secure와 httponly 속성을 설정하지 않으면 쿠키를 정상적으로 전송할 수 있지만 쿠키 값이 노출될 수 있다. secure 속성이 없는 쿠키는 HTTPS가 아닌 사이트로 전송할 수 있으며 마찬가지로 httponly를 설정하지 않은 쿠키는 자바스크립트를 통해 쿠키 값을 확인할 수 있다.

 

expires와 max-age 속성은 쿠키가 만료되고 브라우저가 쿠키를 폐기해야 하는 시점을 나타낸다.

expires 속성은 브라우저가 특정 날짜에 쿠키를 삭제하도록 지시한다.

예를 들어 쿠키에 속성을 expires=Wed, 18 Dec 2019 12:00:00 UTC로 설정할 수 있다. 반대로 max-age는 쿠키가 만료될 때까지의 시간(초)을 정수 형식으로 나타낸다(예를 들어 max-age=300).

 

요약하면 Bob이 방문한 뱅킹 사이트에서 쿠키를 사용하는 경우 이 사이트는 다음 절차를 통해 밥의 인증 정보를 저장한다.

Bob이 사이트를 방문하고 로그인하면 이 은행은 HTTP 응답(Bob을 식별하는 쿠키를 포함한)을 통해 HTTP 요청에 응답한다. 다시 Bob의 브라우저는 이후 모든 뱅킹 웹 사이트로 HTTP 요청을 보낼 때 이 쿠키를 자동으로 전송한다.

은행 업무를 마친 Bob은 뱅킹 웹 사이트를 떠날 때 로그아웃을 하지 않는다. 이 사이트에서 로그아웃하면 사이트는 일반적으로 쿠키를 만료시키는 HTTP 응답을 보내기 때문에 이런 중요한 세부 사항에 유의해야 한다. 그 결과, 사이트를 다시 방문하면 다시 로그인을 해야 한다.

Bob은 자신의 이메일을 확인하고 링크를 클릭해 낯선 사이트를 방문하면 의도하지 않게 악성 웹 사이트를 방문하게 된다. 이 웹 사이트는 Bob의 브라우저에게 뱅킹 웹 사이트에 요청하도록 지시해 CSRF 공격을 수행하게 설계돼 있다. 브라우저는 이 요청에 쿠키도 함께 전송할 것이다.

 

GET 요청 기반 CSRF

악성 사이트가 Bob의 뱅킹 사이트를 공격하는 방법은 은행이 GET 또는 POST 요청을 통해 이체를 처리하는지에 따라 달라진다. Bob의 뱅킹 사이트가 GET 요청을 통한 전송을 허용하면 악성 사이트는 hidden form이나 <img> 태그와 함께 HTTP 요청을 전송한다. GET이나 POST 메서드 모두 HTML을 사용해 브라우저가 필요한 HTTP 요청을 보내도록 설계해야 하며, 두 메서드를 대상으로 hidden form 기법을 사용할 수 있지만 GET 메서드만 <img> 태그 기법을 사용할 수 있다.

 

공격자는 Bob이 사용하는 뱅킹 웹 사이트로 전송하는 HTTP 요청에 Bob의 쿠키를 포함시켜야 한다. 그러나 공격자는 Bob의 쿠키를 읽을 방법이 없기 때문에 뱅킹 사이트로 HTTP 요청을 작성해 전송할 수 없다. 대신 공격자는 HTML <img> 태그를 사용해 Bob의 쿠키가 포함된 GET 요청을 생성할 수 있다. <img> 태그는 웹 페이지에 이미지를 렌더링하고 src 속성을 포함시켜 브라우저에게 이미지 파일의 위치를 알려준다. 브라우저는 <img> 태그를 렌더링 할 때 태그의 src 속성 값에 HTTP GET 요청을 보내고 이 요청에 기존 쿠키도 포함시킨다. 따라서 악성 사이트에서 Bob이 Joe에게 500달러를 이체하기 위해 다음과 같은 URL을 사용한다고 가정해보자.

https://www.bank.com/transfer?from=bob&joe&amount=500

그런 다음 악성 <img> 태그에서 다음과 같이 위의 URL을 소스(scr) 값으로 사용할 것이다.

<img src="https://www.bank.com/transfer?from=bob&to=joe&amount=500">

그 결과 Bob이 공격자의 사이트를 방문하면 HTTP 응답에 <img> 태그가 추가되고, 브라우저는 뱅킹 사이트에 HTTP GET 요청을 보내게 된다. 브라우저는 이미지라고 판단하고 이미지를 얻으려고 Bob의 인증 쿠키를 전송한다. 그러나 실제로 은행은 요청을 수신하고 태그의 src 속성으로 URL을 처리하며 이체 요청을 만들어낸다.

 

이 취약점을 만들지 않으려면 개발자는 절대로 이체 금액과 같은 백엔드 데이터의 수정 요청을 처리하고자 HTTP GET 요청을 사용해서는 안 된다. 그러나 읽기 전용인 요청도 안전해야 한다. Ruby on Rails, Django 등과 같은 웹 사이트를 구축하는 데 사용되는 다수의 일반적인 웹 프레임워크는 개발자가 이러한 원칙을 따를 것이라고 생각하기 때문에 POST 요청에는 자동으로 CSRF 보호 기능을 추가하지만 GET 요청에는 추가하지 않고 있다.

 

POST 요청 기반 CSRF

은행에서 POST 요청으로 이체를 처리하는 경우 다른 접근 방식을 사용해 CSRF 공격을 해야 한다.

<img> 태그는 POST 요청을 호출할 수 없기 때문에 공격자가 <img> 태그를 사용할 수 없다. 대신 공격자의 전략은 POSR 요청에 내용에 따라 달라진다.

가장 간단한 상황은 콘텐츠 유형으로 application/x-www-form-urlencoded나 text/plain을 사용한 POST 요청을 사용하는 경우다. 콘텐츠 유형은 HTTP 요청을 보낼 때 브라우저에 추가할 수 있는 헤더다. 헤더는 수신자에게 HTTP 요청 본문의 인코딩 방법을 알려준다. 

다음은 text/plain 콘텐츠 유형 요청의 예다.

POST / HTTP/1.1
Host: www.google.ca
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9*/*;q=0.8
Content-Length: 5
① Content-Type: text/plain;charset=UTF-8
DNT: 1
Connection: close
hello

①에 콘텐츠 유형 레이블이 지정돼 있고 요청의 문자 인코딩이 함께 나열돼 있다. 브라우저는 유형에 따라 다르게 처리하기 때문에 콘텐츠 유형이 중요하다.

이 경우 악성 사이트에서 hidden HTML form을 생성해 대상에 대한 배경 지식을 갖추지 않은 상황에서도 취약한 사이트에 은밀하게 전달될 수도 있다. 이러한 폼은 POST나 GET 요청으로 URL을 제출할 수 있고 심지어 파라미터 값으로 전달할 수도 있다.

 

다음은 Bob에게 지시를 내리는 악성 웹 사이트 코드의 악성 링크 예제다.

① <iframe style="display:none" name="csrf-frame"></iframe>
② <form method='POST' action="http://bank.com/trnasfer' target="csrf-frmae" id="csrf-form">
      ③ <input type='hidden' name='from' value='Bob'>
    	<input type='hidden' name='to' value='Joe'>
        <input type='hidden' name='amount' value='500'>
        <input type='submit' value='submit'>
  </form>
③ <script>document.getElementById("csrf-form").submit()</script>

여기서는 <form> 태그의 action 속성에서 보이는 것처럼 Bob의 은행으로 HTTP POST 요청을 보낸다②. 공격자는 Bob이 form을 발견하지 않기 바라며 각 <input> 요소③에 'hidden' 유형을 지정했기 때문에 Bob이 보는 웹 페이지에서는 form을 볼 수 없다. 마지막 단계로 공격자는 페이지를 불러올 때 자동으로 form을 제출하려고 <script> 태그 내에 일부 자바스크립트를 추가했다④.

자바스크립트는 두 번째 행②에서 설정한 폼의 ID("csrf-form")를 인수(argument)로 하고, HTML 문서에서 getElementByID() 메서드를 호출해 이를 수행한다. GET 요청과 마찬가지로 폼이 제출되면 브라우저는 이체를 시작하려고 Bob의 쿠키를 은행 사이트로 전송하는 HTTP POST 요청을 제작한다. POST 요청은 HTTP 응답을 브라우저로 다시 보내기 때문에 공격자는 display:none 속성①을 사용ㅇ해 iFrame에서 응답을 숨긴다. 결과적으로 Bob은 이러한 상황을 인지하지 못했으며 무슨 일이 있었는지 알아채지 못한다.

 

다른 시나리오에서 사이트는 콘텐츠 유형 application/json과 함께 POST 요청을 제출하는 것을 예상할 수 있다. 경우에 따라 application/json 유형의 요청에서도 CSRF 토큰을 사용할 수 있다. 이 토큰은 HTTP 요청과 함께 제출되는 값이므로 정상적인 사이트는 이 요청이 악성 사이트가 아닌 자체 사이트에서 시작했는지 확인할 수 있다. POST 요청의 HTTP 본문에 토큰이 포함되는 경우도 있지만 POST 요청에서는 X-CSRF-TOKEN과 같은 사용자 지정 헤더를 사용할 수도 있다. 브라우저가 application/json POST 요청을 사이트로 보내면 POST 요청 전에 OPTIONS HTTP 요청을 보낸다. 그런 다음 사이트는 OPTIONS 호출에 대해 허용하는 HTTP 요청의 유형과 신뢰할 수 있는 출처를 응답으로 반환한다. 이것을 프리플라이트(preflight) OPTIONS 호출이라고 한다. 브라우저는 이 응답을 읽은 다음 적절한 HTTP 요청을 만드는데, 이는 은행 예제에서 이체를 하기 위한 POST 요청에 해당한다.

 

악성 사이트는 서버에서 신뢰할 수 있는 사이트로 나타나지 않으며, 브라우저는 특정 웹 사이트(화이트리스트에 등록된 웹 사이트)만 HTTP OPTIONS 응답을 읽도록 허용하기 때문에 프리플라이트 OPTIONS 호출은 올바르게 구현됐을 경우 일부 CSRF 취약점을 예방해준다. 결과적으로 악성 사이트가 OPTIONS 응답을 읽을 수 없기 때문에 브라우저는 악의적인 POST 요청을 보내지 않게 된다.

 

웹 사이트가 서로 간에 응답을 읽을 수 있는 시점과 방법을 정의하는 규칙 세트를 CORS(Cross-Origin Resource Sharing: 교차 출처 리소스 공유)라고 한다. CORS는 테스트 중인 사이트에서 허용하는 도메인이나 파일을 제공하는 도메인 이외의 도메인으로부터 JSON 응답의 접근을 포함한 리소스의 접근을 제한한다. 즉, 개발자가 사이트를 보호하려고 CORS를 사용하는 경우 테스트 중인 application/json을 호출하기 위한 요청을 제출할 수 없고 응답을 읽을 수 없으며 테스트 중인 사이트에서 허용하지 않는 한 다른 호출을 만들 수 없다. 상황에 따라 콘텐츠 유형 헤더를 application/x-www-form-urlencoded, multipart/form-data 또는 text/plain으로 변경해 이러한 보호 기능을 우회할 수 있다. POST 요청을 보낼 때 브라우저에서 이러한 세 가지 콘텐츠 유형은 프리플라이트 OPTIONS 호출을 전송하지 않기 때문에 CSRF 요청이 작동할 수도 있다. 그렇지 않은 경우 서버의 HTTP 응답에서 Access-Control-Allow-Origin 헤더를 확인해 서버가 임의의 출처를 신뢰하지 않는지 다시 한번 확인해야 한다. 임의의 출처에서 요청을 보낼 때 해당 응답 헤더가 변경되면 모든 출처에서 서버의 응답을 읽을 수 있으므로 사이트에서 더욱 큰 문제가 발생할 수 있다. 이로 인해 CSRF 취약점이 발생할 수도 있지만 악의적인 공격자가 서버의 HTTP 응답에 반환된 중요 데이터를 읽을 수도 있다.

 

CSRF 공격에 대한 방어

CSRF 공격에 대한 가장 보편적인 보호 방법 중 한 가지로 CSRF 토큰이 있다. 보호를 받는 사이트에서는 데이터를 변경할 수 있는 요청(즉, POST 요청)을 제출할 때 CSRF 토큰이 필요하다. 이러한 상황에서 웹 애플리케이션(Bob이 이용하는 은행과 같은)은 Bob이 전달받는 토큰과 애플리케이션이 유지하는 토큰을 생성할 것이다. Bob은 이체 요청을 할 때 자신의 토큰을 제출해야 하며 제출한 토큰을 은행 측에서 확인한다. 토큰의 설계를 통해 토큰을 추측할 수 없게 만들고 토큰을 부여한 특정 사용자(Bob과 같은)만 액세스할 수 있다. 또한 특정 이름을 지정하지 않아 예를 들어 X-CSRF-TOKEN, lia-token, rt, form-id 등 다양한 이름을 사용한다.

다음 예제와 같이 HTTP 요청 헤더, HTTP POST 본문, 히든 필드에 토큰을 포함시킬 수 있다.

<form method='POST' action='http://bank.com/transfer'>
	<input type='text' name='from' value='Bob'>
    <input type='text' name='to' value='Joe'>
    <input type='text' name='amount' value='500'>
    <input type='hidden' name='csrf'
    	value='1Ht7DDDyUNKoHCC66BsPB8aN4hxNu6ZuJA+81+YA='>
    <input type='submit' value='submit'>
    </form>

이 예에서 사이트는 쿠키, 웹 사이트의 내장 스크립트나 사이트에서 제공한 콘텐츠의 일부에서 CSRF 토큰을 얻을 수 있다. 메서드에 관계없이 대상 웹 브라우저만 값을 알고 읽을 수 있다. 공격자는 토큰을 제출할 수 없기 때문에 POST 요청을 성공적으로 제출할 수 없고 CSRF 공격을 수행할 수 없다. 그러나 사이트가 CSRF 토큰을 사용한다고 해서 취약점을 더 이상 발견할 수 없는 것을 의미하지 않는다. 토큰을 제거하거나 값을 조작하는 등의 작업을 통해 토큰이 올바르게 구현돼 있는지 확인해야한다.

 

사이트가 자체적으로 방어하는 다른 방법으로 CORS를 사용하는 방법도 있지만 이는 브라우저 보안에 의존해야 하며 제삼자 사이트가 응답에 접근할 수 있는 시점을 결정하는 적절한 CORS 구성이 보장돼야 제기능을 하기 때문에 완벽하지 않을 수도 있다. 공격자는 때로는 콘텐츠 유형을 application/json에서 application/x-www-form-urlencoded로 변경하거나 서버 측의 구성이 잘못돼 있어 POST 요청 대신 GET 요청을 사용하는 방식으로 CORS를 우회할 수 있다. 이러한 우회 방법을 적용할 수 있는 이유는 콘텐츠 유형이 application/json일 때 브라우저가 OPTIONS HTTP 요청을 자동으로 전송하지만 GET 요청이거나 콘텐츠 유형이 application/x-www-form-urlencoded인 경우 OPTIONS HTTP 요청을 자동으로 전송하지 않기 때문이다.

 

마지막으로 일반적으로 사용되지 않는 두 가지 CSRF 취약점 완화 방안이 있다.

첫 번째로 사이트는 HTTP 요청과 함께 제출된 Origin이나 Referer 헤더의 값을 확인하고 예측값이 포함돼 있는지 확인할 수 있다. 예를 들어 경우에 따라 트위터는 Origin 헤더를 확인하고 헤더가 없을 경우 Referer 헤더를 확인한다. 이는 브라우저가 이러한 헤더를 제어할 수 있으며 공격자는 원격으로 헤더를 설정하거나 변경할 수 없기 때문에 효과적인 방법이다.

두 번째로 브라우저에서 최근 새로운 쿠키 속성인 samesite의 지원을 구현하기 시작했다. 이 속성 값으로 strict나 lax를 설정할 수 있다. strict로 설정하면 브라우저는 사이트에서 시작되지 않은 HTTP 요청에 쿠키를 함께 전송하지 않는다. 여기에는 단순한 HTTP GET 요청도 전송하지 않는다. 예를 들어 아마존에 로그인했고 아마존에서 strict samesite 사이트 쿠키를 사용하는 경우 다른 사이트의 링크를 따라가도 브라우저가 쿠키를 전달하지 않을 것이다. 또한 아마존 웹 페이지를 방문해 쿠키가 전달될 때까지 아마존에서는 본인이 로그인한 것으로 인정하지 않을 것이다. 이와 반대로, samesite 속성을 lax로 설정하면 최초의 GET 요청과 함께 쿠키를 보내도록 브라우저에 지시한다. 이는 GET 요청이 서버 측의 데이터를 변경해서는 안 된다는 설계 원칙을 뒷받침하는 것이다. 이러한 경우 아마존에 로그인한 상태에서 lax samesite 쿠키를 사용한 경우 브라우저는 쿠키를 제출하고 다른 사이트에서 리디렉션도나 경우 아마존은 사용자가 로그인한 것으로 인정할 것이다.

 

쇼피파이 트위터 연결 끊기

난이도: 낮음
URL: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect/
출처: https://www.hackerone.com/reports/111216/
보고 날짜: 2016년 1월 17일
포상금: 500달러

CSRF 취약점을 찾을 때는 서버 측 데이터를 수정하는 GET 요청을 살펴보자. 예를 들어 해커는 쇼피파이 기능 중 트위터를 사이트에 추가해 상점 주인이 판매 중인 제품을 트윗하는 기능에서 취약점을 발견했다. 이 기능을 통해 사용자는 연계된 상점으로부터 트위터 계정의 연결을 해지할 수 있었다.

트위터 계정의 연결을 해지하는 URL은 다음과 같다.

https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect/

결과적으로 이 URL을 방문하면 다음과 같이 계정 연결을 해지하는 GET 요청이 전송된다.

GET /auth/twitter/disconnect HTTP/1.1
Host: twitter-commerce.shopifyapps.com
User-Agent: Mozilla/5.0 (Macintosh; Intel MAC OS X 10.11; rv:43.0)
Gecko/20100101 Firefox/43.0
Accept: text/html, application/xhtml+xml, application/xml
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://twitter-commerce.shopifyapps.com/account
Cookie: _twitter-commerce_session=REDACTED
Connection: keep-alive

또한 링크를 처음 구현했을 때 쇼피파이는 전송된 GET 요청의 정합성을 검증하지 않아 CSRF에 취약하게 만들었다.

보고서를 제출한 해커 WeSecureApp은 다음과 같은 개념 증명(Proof of Concept) HTML 문서를 작성했다.

<html>
	<body>
		① <img src="https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect">
	</body>
</html>

이 HTML 문서를 열면 브라우저는 <img> 태그의 src 속성①으로 인해 https://twitter-commerce.shopifyapps.com으로 로 HTTP GET 요청을 보낸다. 쇼피파이와 연결된 트위터 계정을 가진 사람이 이 <img> 태그가 있는 웹 페이지를 방문하면 트위터 계정과 쇼피파이의 연결이 해지된다.

 

앞서 살펴본 GET 요청을 통한 트위터 계정 연결 해지와 같이 서버에서 일부 조치를 수행하는 HTTP 요청을 유심히 살펴보자. 앞에서 언급했듯이 GET 요청이 서버의 데이터를 수정해서는 안 된다. 이 상황에서는 Burp나 OWASP의 ZAP과 같은 프록시 서버를 사용해 쇼피파이로 전송되는 HTTP 요청을 모니터링함으로써 취약점을 발견할 수 있을 것이다.

 

 

 

 

**피터 야로스키, Real-World Bug Hunting(실전 버그 바운티)를 참고하여 작성

저작자표시

'Webhacking > 버그바운티' 카테고리의 다른 글

HTTP 파라미터 오염  (0) 2022.04.08
오픈 리디렉션(Open Redirect) 취약점  (0) 2022.04.07
버그 바운티 기본 사항  (0) 2022.04.04

관련글

댓글

티스토리툴바