재우니의 블로그

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery

 

CSRF (교차 사이트 요청 위조 )는 최종 사용자가 현재 인증된 웹 애플리케이션에서 의도하지 않은 작업을 실행하도록 하는 공격입니다. 약간의 사회 공학적 도움(예: 이메일 또는 채팅을 통한 링크 전송)으로 공격자는 웹 응용 프로그램 사용자가 공격자가 선택한 작업을 실행하도록 강제할 수 있습니다. 

 

성공적인 CSRF 악의공격은 일반 사용자를 대상으로 할 때 최종 사용자 데이터와 작업을 손상시킬 수 있습니다. 대상 최종 사용자가 관리자 계정인 경우 CSRF 공격은 전체 웹 응용 프로그램을 손상시킬 수 있습니다.

CSRF는 다음에 의존합니다.

 

 

  1. 쿠키 및 HTTP 인증 정보와 같은 세션 관련 정보 처리와 관련된 웹 브라우저 동작.
  2. 유효한 웹 애플리케이션 URL, 요청 또는 기능에 대한 공격자의 지식.
  3. 브라우저가 알고 있는 정보에만 의존하는 애플리케이션 세션 관리.
  4. HTTP[S] 리소스에 대한 즉각적인 액세스를 유발하는 HTML 태그의 존재; (예를 들어 이미지 태그 img.)

 

포인트 1, 2, 3은 취약점이 존재하는 데 필수적이며 포인트 4는 실제 악용을 용이하게 하지만 반드시 필요한 것은 아닙니다.

 

 

 

Cross-Site Request Forgery (CSRF) 공격 방식은 어떻게 하나요?

 

최종 사용자가 웹 애플리케이션에서 정보를 로드하거나 웹 애플리케이션에 정보를 제출하도록 속일 수 있는 방법은 여러 가지가 있습니다. 공격을 실행하려면 먼저 피해자가 실행할 유효한 악성 요청을 생성하는 방법을 이해해야 합니다.

다음 예를 살펴보겠습니다.

 

사용자가 $50를 친구에게 송금하려고 합니다. 은행 애플리케이션은 CSRF에 취약합니다. 공격자는 사용자를 속여 친구의 계정이 아닌 자신의 계정으로 돈을 이체하려고 합니다. 그렇게 하려면 공격자가 다음을 수행해야 합니다.

  • URL 또는 스크립트 작성을 통해 악의적으로 사용한다.
  • 사용자를 속여 social engineering 으로 작업을 실행하도록 합니다.

 

GET 시나리오

 

 

은행 애플리케이션이 매개변수를 전송하고 작업을 실행하기 위해 GET 요청을 사용하도록 설계된 경우 송금 작업은 다음과 같은 요청으로 축소될 수 있습니다.

 

GET http://vulnerable-bank.com/transfer.do?acct=Nedim&amount=50 HTTP/1.1

 

공격자는 먼저 피해자로부터 공격자의 계정으로 $50,000를 전송하는 다음 익스플로잇 URL을 구성합니다. 공격자는 원본 명령 URL을 조작하여 수취인 이름과 송금 금액을 대체합니다.

 

 

http://vulnerable-bank.com/transfer.do?acct=ATTACKERNAME&amount=50000 HTTP/1.1

 

사회 공학을 통해 피해자에게 HTML 콘텐츠가 포함된 이메일을 보내거나 다른 페이지에 익스플로잇 URL을 포함함으로써 공격자는 피해자가 URL을 로드하도록 할 수 있습니다.

 

GET를 사용하는 애플리케이션에 대한 CSRF 공격의 실제 사례는 맬웨어를 다운로드하기 위해 대규모로 사용된 2008년의 uTorrent 익스플로잇이었습니다.

 

 

POST 시나리오

 

우리 은행이 매개변수를 전송하고 작업을 실행하기 위해 POST를 사용한다고 가정해 보겠습니다. 취약한 요청은 다음과 같습니다.

 

 

POST http://vulnerable-bank.com/transfer.do HTTP/1.1
acct=Nedim&amount=50

 

이러한 요청은 양식 태그를 사용하여 전달할 수 있습니다.

 

<form action="http://vulnerable-bank.com/transfer.do" method="POST">
<input type="hidden" name="acct" value="Filip"/>
<input type="hidden" name="amount" value="50000"/>
<input type="submit" value="View my pictures"/>
</form>

 

이 양식은 제출 버튼을 클릭하는 사용자에 의존하지만 JavaScript를 사용하여 자동으로 실행할 수도 있습니다.

 

<body onload="document.forms[0].submit()">
<form...

 

 

기타 HTTP 메소드

최신 웹 애플리케이션의 API는 PUT 또는 DELETE와 같은 다른 HTTP 메서드를 자주 사용합니다.

이제 취약한 은행 애플리케이션이 JSON 블록을 인수로 사용하는 PUT을 사용한다고 가정해 보겠습니다.

 

PUT http://vulnerable-bank.com/transfer.do HTTP/1.1
{ "acct":"Nedim", "amount":50 }

 

페이지에 포함된 JavaScript를 사용하여 악의적으로 이 요청을 실행할 수 있습니다.

 

<script>
function put() {
    var x = new XMLHttpRequest();
    x.open("PUT","http://vulnerable-bank.com/transfer.do",true);
    x.setRequestHeader("Content-Type", "application/json");
    x.send(JSON.stringify({"acct":"Nedim", "amount":50})); 
}
</script>
<body onload="put()">

 

same-origin policy restrictions (동일 출처 정책 제한)으로 인해 이 요청은 최신 브라우저에서 실행되지 않습니다. 이 제한은 대상 웹 사이트가 다음 헤더와 함께 CORS를 사용하여 공격자의 cross-origin requests 을 명시적으로 열지 않는 한 기본적으로 활성화됩니다.

 

Access-Control-Allow-Origin: *

 

 

Cross-Site Request Forgery 취약점에 대한 수동 테스트

 

세션이 안전하지 않은지 확인하려면 애플리케이션의 세션을 검사해야 합니다. 세션 관리가 사용자 측에서 수행되는 경우 브라우저에서 정보를 사용할 수 있음을 나타내는 경우 애플리케이션이 취약합니다. "클라이언트 측 값"은 HTTP 인증 자격 증명 및 쿠키를 나타냅니다. 

HTTP GET 요청을 통해 액세스 가능한 리소스는 의심할 여지 없이 취약하지만 POST 요청은 JavaScript를 통해 자동화되는 경향이 있고 노출되고 취약하므로 POST만 사용하는 것만으로는 CSRF 취약성의 발생을 수정하기에 충분하지 않습니다.

 

CSRF 테스트용 자동화 도구

 

1. NeuraLegion’s Nexploit

 

NeuraLegion의 Nexploit은 DAST(Dynamic Application Security Testing) 스캐너입니다. 개발 파이프라인 전체에 통합되어 웹 애플리케이션 및 API를 테스트하고 CSRF 및 기타 여러 취약점의 탐지 및 수정을 자동화 및 단순화할 수 있습니다.

DAST 스캔을 왼쪽으로 이동하고 CI/CD 전체에 통합함으로써 개발자와 애플리케이션 보안 전문가는 가능한 한 빨리 취약점을 감지하고 프로덕션에 들어가기 전에 수정할 수 있습니다. 이를 통해 개발자는 솔루션을 채택하고 소프트웨어 개발 수명 주기(SDLC) 전체에서 사용할 수 있습니다.

 

NeuraLegion의 CSRF 테스트는 먼저 대상에 "Access-Control-Allow-Origin" 헤더 구성이 잘못되었거나 "Origin" 헤더가 누락되었는지 확인하여 구현된 CSRF 보호가 있는지 확인합니다. 두 번째 단계에서는 요청 쿼리 내에서 CSRF 토큰 자체가 누락되었는지 확인합니다. 이 모든 단계가 확인되면 마지막 단계에서 요청을 실행하여 취약점이 성공적으로 악용되었는지 확인하고 유효성을 검사하여 오탐지가 없는지 확인합니다.

 

 

2. OWASP ZAP

 

OWASP ZAP은 전문 침투 테스터가 주로 사용하는 오픈 소스 웹 애플리케이션 보안 스캐너입니다. 훌륭한 도구이지만 개발자 친화적이지 않습니다.

ZAP는 속성 이름으로만 안티 CSRF 토큰을 감지합니다. 이는 안티 CSRF 토큰으로 간주되고 옵션에서 안티 CSRF를 사용하여 구성됩니다. ZAP가 이러한 토큰을 감지하면 토큰 값과 토큰을 생성한 URL을 기록합니다.

https://www.neuralegion.com/

 

3. CSRF Tester

 

CSRF 테스터는 웹 애플리케이션에서 HTTP 요청의 무결성을 확인하기 위해 개발자 그룹이 개발자를 위해 만든 OWASP의 프로젝트입니다. CSRF 테스터는 신중한 완화를 위해 PHP 라이브러리와 Apache 모듈을 제공합니다.

 

 

4. Pinata-csrf-tool

고급 응용 프로그램 보안 전문가가 사용하기 위한 것입니다. HTTP 요청이 주어지면 개념 증명 CSRF HTML을 생성하여 표준 POST 및 Multipart/form POST에 대한 추가 유효성 검사를 통해 이것이 GET 또는 POST 요청인지 여부를 자동으로 검색합니다. 이 도구는 요청 유형에 해당하는 HTML을 생성합니다.

 

 

 

출처 : https://www.neuralegion.com/blog/cross-site-request-forgery-testing/

 

How to test for Cross-Site Request Forgery?

Learn what cross-site request forgery testing is and how to test for CSRF vulnerabilities in your applications.

www.neuralegion.com

 

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery

 

WSTG - Latest | OWASP Foundation

WSTG - Latest on the main website for The OWASP Foundation. OWASP is a nonprofit foundation that works to improve the security of software.

owasp.org