사이트 간 요청 위조 작동 방식

CSRF(Cross-Site Request Forgery) 공격은 인증된 사용자를 속여 자금 이체, 자격 증명 변경, 일부 보호된 리소스에 대한 액세스 권한 부여 등과 같은 애플리케이션에서 위험한 활동을 수행하도록 합니다. 사용자는 애플리케이션에서 인증되기 때문에 이 활동을 수행하는 것을 방해하지 않습니다.



Open Web Application Security Project(OWASP)는 이 취약점을 다음과 같이 설명합니다.

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing.

If the victim is a normal user, a successful CSRF attack can force the user to perform state-changing requests like transferring funds, changing their email address, etc. CSRF can compromise the entire web application if the victim is an administrative account.

예시

다음은 CSRF 공격이 작동하는 방식을 보여주는 시나리오입니다.

1단계: 공격자가 일부 위험한 활동을 수행하는 사기 요청을 생성합니다.

2단계: 공격자는 이 요청을 하이퍼링크나 양식에 삽입하고 의심하지 않는 사용자가 포럼 댓글, 이미지, 이메일 링크 등과 같이 클릭할 가능성이 있는 인터넷의 여러 위치에 이러한 링크를 게시합니다.

3단계: 피해자는 한 탭에서 애플리케이션(예: 은행 웹사이트)에 로그인하고 다른 탭에서 이메일을 엽니다. 그런 다음 이메일에서 사기 링크를 클릭합니다.

4단계: 대부분의 웹 애플리케이션은 브라우저 쿠키를 사용하여 인증을 구현합니다. 쿠키는 탭이나 창과 관련이 없으며 도메인에 대한 요청과 관련이 있습니다. 브라우저가 웹 서버에 도메인을 요청할 때마다 브라우저가 해당 도메인에 대해 가지고 있는 모든 쿠키가 요청 헤더로 전송됩니다. 사용자가 첫 번째 탭에서 애플리케이션에 로그인했기 때문에 브라우저는 두 번째 탭에서 요청한 쿠키를 보냅니다.

5단계: 요청을 받으면 웹 애플리케이션이 쿠키를 확인하고 사용자를 인증합니다. 이제 이 요청을 수행하고 있다고 생각합니다. 그러나 이것은 공격자가 만든 위조된 요청입니다. 이 요청은 이제 은행 계좌에서 돈을 이체하는 것과 같이 애플리케이션이 로그인한 사용자에게 허용하는 모든 작업을 수행할 수 있습니다.

이제 링크를 클릭하거나 이미지를 열면 무해한 GET 요청이 발생한다고 생각할 수 있습니다. 글쎄, 공격자는 링크를 클릭하거나 웹 페이지를 방문할 때 즉시 양식을 생성하고 제출하는 JavaScript 코드를 쉽게 작성할 수 있습니다.

다음은 은행 이메일을 업데이트하기 위해 POST 요청을 하는 양식을 만들고 페이지가 로드될 때마다 양식을 제출하는 예입니다.

<form action="https://your-bank.com/user/email" method="POST">
    <input type="email" value="[email protected]">
</form>

<script>
    document.forms[0].submit();
</script>

이제 해커가 해야 할 일은 귀하가 은행 웹사이트에 로그인한 상태에서 페이지를 방문하도록 속이는 것입니다. 페이지가 로드되면 쿠키를 전달하여 은행 웹사이트에 양식을 제출합니다. 은행 웹사이트는 귀하가 실제 사용자라고 생각하고 이메일 주소를 업데이트합니다.

CSRF를 방지하는 방법?

따라서 CSRF 공격의 주된 문제는 서버 응용 프로그램이 실제 요청(실제 응용 프로그램의 요청)과 공격자의 코드에서 온 위조 요청을 구분하지 않는다는 것입니다.

Only if there was a way for the server to identify the requests that came from the application, then it could reject all other requests that came from anywhere else.

우리는 각 양식 안에 고유한 무작위 토큰을 삽입하도록 서버 응용 프로그램에 지시하여 이 문제를 해결할 수 있습니다. 이제 애플리케이션에서 양식을 제출하면 이 토큰이 함께 전송됩니다. 요청을 받으면 서버는 이 토큰이 있는지 확인하고 가지고 있는 토큰과 일치합니다. 존재하고 일치하는 경우 요청이 실제 사용자로부터 왔으며 유효하다는 것을 알고 있습니다. 토큰이 없거나 일치하지 않으면 요청을 거부합니다.



토큰은 무작위이기 때문에 공격자는 이를 추측하여 위조된 요청에 삽입할 수 없습니다. 따라서 서버는 모든 위조된 요청을 거부하여 사용자를 안전하게 보호합니다.

이것은 대부분의 웹 애플리케이션 프레임워크가 진위를 확인하는 토큰을 사용하여 CSRF 공격을 방지하는 방법입니다. Ruby on Rails가 이 작업을 수행하는 방법에 대해 더 자세히 알고 싶다면 내 블로그에서 이 자세한 기사를 읽을 수 있습니다: Preventing CSRF Attacks using Authenticity Tokens in Rails

도움이 되었기를 바랍니다. 질문이나 의견이 있으면 알려주세요. 귀하의 의견을 기다리겠습니다.