XSS, CSRF, 그리고 SSRF

💡Spring security를 설정하면서, 또 웹 보안에 대해 학습하면서 계속 까먹고 구글링하게 되어 확실하게 정리해 놓고자 포스팅을 작성한다.

XSS(Cross-Site Scripting)

악의적인 사용자가 공격하려는 사이트에 스크립트를 넣는 기법, html의 <script/>태그가 사용된다.

XSS 공격은 Reflected XSS와 Stored XSS(또는 Persist XSS)로 나뉜다.

토큰 등을 저장할 때 로컬 스토리지 사용시 javascript에서 직접 엑세스 가능하기 때문에 XSS에 취약하다.

XSS 취약점은 클라이언트 측에 의해 발생한다.

Reflected XSS

일반 유저의 요청(request)에 악성코드 심음

공격 시나리오

공격자가 취약한 사이트 발견.
취약한 사이트에서 사용자 정보를 획득할 수 있는 스크립트가 담긴 URL을 만들어 일반 사용자에게 특정 방법으로 전달.
일반 사용자는 전달받은 URL 링크를 클릭. 일반 사용자 브라우저에서 취약한 사이트로 요청을 전달.
일반 사용자의 브라우저에서 서버로부터의 응답 메시지(response)를 실행하면서 악성 스크립트가 실행.
악성 스크립트를 통해 사용자 정보가 공격자에게 전달됨.

Stored XSS

서버측(게시판)에 악성코드 심음

공격 시나리오

공격자가 취약한 사이트를 발견.
취약한 사이트에서 제공하는 게시판에 사용자 정보를 획득할 수 있는 스크립트를 작성하여 게시.
일반 사용자가 공격자가 작성한 게시글을 읽으면, 서버로부터 악성 스크립트가 담긴 게시글 응답을 전달함.
일반 사용자의 브라우저에서 서버로부터의 응답 메시지(response)를 실행하면서 악성 스크립트가 실행.
악성 스크립트를 통해 사용자 정보가 공격자에게 전달됨.

XSS 대응방법

<script>의 입력을 차단하면 된다. 특수문자를 치환, 제거하거나 사용자 입력을 검증하는 것이 해결책이 될 수 있다.

CSRF(Cross-Site Request Forgery)

사이트간 요청 위조의 약자로, 사용자가 신뢰하는 웹 애플리케이션에 대해 사용자의 권한을 도용하여 원치 않는 행동을 수행하게 만드는 공격이다. 공격자는 사용자가 이미 인증된 세션을 가지고 있다는 점을 악용하여, 사용자가 의도하지 않은 요청을 수행하도록 한다. 예를 들어, 사용자가 로그인된 상태에서 악성 사이트를 방문하면, 그 사이트에서 사용자가 인증된 웹 애플리케이션에 요청을 보낼 수 있다.

CSRF 취약점은 주로 서버 측에 의해 발생한다.

CSRF 공격의 전제조건

공격자가 CSRF 공격을 하기 위해선 아래 전제조건을 만족해야한다.

사용자가 보안이 취약한 서버로부터 이미 인증을 받은 상태여야 한다.
쿠키 기반으로 서버 세션 정보를 획득할 수 있어야 한다.
공격자는 서버를 공격하기 위한 요청 방법에 대해 미리 파악하고 있어야 한다. 예상치 못한 파라미터가 있으면 불가능하다.

CSRF 공격 예시(GET 요청인 경우)

공격자의 악성 웹 사이트

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Attacker Site</title>
</head>
<body>
<div id="wrap">
    <img src="http://vulnerable-site/change?name=NameChangedByImageTag" style="width: 0px; height: 0px;"/>
</div>
</body>
</html>

공격자는 위와 같은 악성 사이트를 만들어 타겟에게 전달한다. 타겟이 해당 사이트를 방문하면, img태그(또는 a태그)의 서버로 GET요청을 보낸다. width 및 height 값이 0이므로 브라우저에 보이지 않는다.

CSRF 공격 예시(POST 요청인 경우)

공격자의 악성 웹 사이트

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Attacker Site</title>
</head>
<body>
<div id="wrap">
    <form action="http://vulnerable-site/change" method="POST">
        <input type="hidden" id="memberName" name="memberName" value="NameChangedByFormSubmit"/>
    </form>
    <script>
        setTimeout(function () {
            document.forms[0].submit();
        }, 1000);
    </script>
</div>
</body>
</html>

<form/> 태그와 hidden 타입의 <input /> 태그를 사용한다. JavaScript를 이용해 페이지 렌더링이 수행되고 1초 뒤 폼 전송을 시도한다.

CSRF 대응 방법

Referrer 검증

요청 헤더(request header) 정보에서 Referrer 정보를 확인할 수 있다. 보통 host와 Referrer 값이 일치하므로 둘을 비교한다. CSRF 공격의 대부분 Referrer 값에 대한 검증만으로 방어가 가능하다고 한다.
예시: Java servlet의 경우

String referer = request.getHeader("Referer");
String host = request.getHeader("host");

CSRF 토큰 검증

클라이언트 별로 다른 토큰을 생성하여 hidden타입 input태그가 포함된 페이지를 클라이언트에게 전달, 클라이언트가 요청을 보내면 해당 태그에 서버로부터 받은 고유한 토큰이 포함되어 있어야 함. 서버는 해당 토큰을 세션 등으로 관리하고 있어야 함. 만약 토큰이 누락되어 있다면 CSRF 로 의심할 수 있음.

Double submit cookie 웹브라우저의 Same Origin 정책으로 공격자가 쿠키값에는 접근할 수 없는것을 이용하여
1.브라우저는 get요청으로 토큰값과 _csrf(시크릿키)값을 서버로 부터 받는다
2.브라우저에서 write요청시 header에 토큰값을 주고 쿠키값에 시크릿키를 부여하여 서버의 미들웨어에서 토큰값을 decode해서 decode한 시크릿키가 쿠키값과 일치하는지 체크한다

SSRF(Server-Side Request Forgery)

서버가 위조된 요청을 보내도록 하는 취약점이다. Client-Side Request Forgery(CSRF, 클라이언트 측 요청 위조) 기법에서 요청을 보내게 되는 주체만 브라우저(Client) 에서 서버(Server) 로 바뀌었다고 이해해도 좋다.

HTTP GET 요청을 통한 SSRF 공격 예시

GET /api/fetch?url=http://internal-service.local/admin HTTP/1.1
Host: example.com

url에 외부망에서 접속 불가능한 internal-service.local/admin로의 요청을 서버가 대신 공격자에게 전달하도록 하는 예시이다.

SSRF 공격 시나리오

취약한 게시판 서버가 있다고 하자. 해당 서버는 공격자가 이미지가 포함된 게시글을 작성하면, 해당 게시글을 열람하는 유저들에게 해당 이미지의 url을 검증 없이 보여준다.

공격자는 image_url에 정상적인 url대신 악의적인 url을 삽입한다. 예를 들어, 다음과 같은 요청을 보낼 수 있다.
```
POST /upload-image HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

image_url=http://localhost/admin
```
여기서 http://부분은 스키마(scheme)로써, 자세한 내용은 하단에 후술한다.
공격자가 작성한 게시글에 접근하면, 서버는 localhost/admin으로의 요청을 보내고, 응답을 접근자에게 서빙한다.
공격자는 서버로부터 받은 이미지의 상태에 따라 서버의 내부 네트워크 구조와 정보를 대략적으로 파악할 수 있게 된다. 만약 서버가 에러 메시지나 페이지 내용을 포함하여 반환한다면, 이를 통해 내부 네트워크의 취약점을 파악할 수 있다.

💡스키마란?
URL에서 스키마(schema)는 프로토콜을 정의하며, 클라이언트가 리소스에 접근하는 방식을 결정한다. 스키마는 URL의 맨 앞 부분에 위치하며, 콜론과 두 개의 슬래시(://)로 끝난다. 스키마는 클라이언트가 서버와 어떻게 통신해야 하는지를 지정한다. 예를 들어, HTTP, HTTPS, FTP, FILE 등이 있다.
위 예시에서, http...대신, file:///etc/passwd를 넣으면, 서버 파일 시스템의 유저 정보를 취득할 수 있다.

SSRF 대응 방법

URL 검증: 업로드되는 URL이 외부 도메인에 속하는지 철저히 검증한다.
화이트리스트: 허용된 도메인의 목록을 사용하여 URL을 제한한다.
프록시 서버 사용: 직접적인 URL 접근 대신 프록시 서버를 통해 요청을 필터링한다.
응답 내용 제한: 서버가 외부로 반환하는 응답 내용을 제한하여 내부 정보가 노출되지 않도록 한다.

XSS(Cross-Site Scripting)
CSRF(Cross-Site Request Forgery)
SSRF(Server-Side Request Forgery)
- SSRF 공격 시나리오
- SSRF 대응 방법