CSRF (Cross-Site Request Forgery)와 XSS (Cross-Site Scripting)는 웹 애플리케이션 보안에서 자주 언급되는 두 가지 취약점입니다. 이 둘에 대해 자세히 설명하겠습니다.
개념
CSRF (Cross-Site Request Forgery)
정의: CSRF는 공격자가 인증된 사용자의 권한을 이용하여 원치 않는 동작을 수행하게 만드는 공격입니다. 예를 들어, 사용자가 로그인을 유지한 상태에서 악성 웹사이트를 방문하면 그 사이트에서 사용자의 권한으로 임의의 요청을 보낼 수 있습니다.
작동 원리:
- 사용자가 신뢰할 수 있는 웹사이트에 로그인하여 인증된 상태를 유지합니다.
- 사용자는 별도의 브라우저 탭에서 공격자가 만든 악성 사이트를 방문합니다.
- 악성 사이트는 사용자가 인증된 상태라는 것을 악용하여 신뢰할 수 있는 웹사이트로 특정 요청을 보냅니다.
- 웹사이트는 이 요청을 사용자가 의도한 것으로 잘못 인식하고 처리합니다.
방어 방법:
- CSRF 토큰: 서버는 각 요청에 대해 고유한 토큰을 생성하고, 클라이언트는 이 토큰을 요청에 포함시켜야 합니다. 서버는 토큰의 유효성을 검증하여 공격을 방지합니다.
- Referer 검증: 요청의 출처(Referer)를 검증하여 신뢰할 수 없는 출처에서 온 요청을 차단합니다.
- SameSite 쿠키 속성: SameSite 쿠키 속성을 설정하여 동일한 사이트에서만 쿠키가 전송되도록 합니다.
XSS (Cross-Site Scripting)
정의: XSS는 공격자가 신뢰할 수 있는 웹사이트에 악성 스크립트를 삽입하여 다른 사용자가 해당 스크립트를 실행하게 만드는 공격입니다. 이를 통해 공격자는 사용자의 세션 정보, 쿠키, 기타 민감한 데이터를 탈취하거나, 웹 페이지의 콘텐츠를 변경할 수 있습니다.
종류:
- 저장형 XSS (Stored XSS): 악성 스크립트가 서버에 저장되어 다수의 사용자가 이를 실행하게 되는 형태입니다. 예: 게시판 글에 스크립트를 포함시키는 경우.
- 반사형 XSS (Reflected XSS): 악성 스크립트가 서버에 저장되지 않고, 요청과 함께 반사되어 사용자의 브라우저에서 실행됩니다. 예: URL 파라미터를 통해 스크립트를 전달하는 경우.
- DOM 기반 XSS: 악성 스크립트가 클라이언트 측에서 DOM 조작을 통해 실행되는 형태입니다. 서버와의 상호작용 없이 클라이언트 측 코드의 취약점을 악용합니다.
방어 방법:
- 입력 값 검증 및 인코딩: 사용자가 입력하는 모든 데이터를 검증하고, HTML 엔티티 인코딩을 통해 스크립트 실행을 방지합니다.
- Content Security Policy (CSP): 웹 서버의 응답 헤더에 CSP를 설정하여 브라우저가 스크립트 실행을 제한하도록 합니다.
- 출력 시 이스케이프 처리: 사용자 입력 데이터를 HTML로 출력할 때 적절히 이스케이프 처리하여 악성 스크립트가 실행되지 않도록 합니다.
CSRF와 XSS는 각각 다른 방식으로 웹 애플리케이션에 악영향을 미치지만, 공통적으로 보안의 중요성을 강조합니다. 적절한 보안 조치와 검증을 통해 이러한 공격을 방지하는 것이 중요합니다.
암기
비유를 통한 이해
비유를 통해 복잡한 개념을 더 쉽게 기억할 수 있습니다.
- CSRF: 마치 누군가 당신의 집 열쇠를 훔쳐서 당신 몰래 집에 들어가서 일을 처리하는 것과 같습니다. 당신은 문을 열어둔 채 잠시 밖에 나갔고, 그 동안 침입자가 들어온 것입니다.
- XSS: 친구가 준 초콜릿 상자에 사실 초콜릿이 아니라 폭죽이 들어있었던 것과 같습니다. 당신은 친구를 신뢰하고 초콜릿을 먹으려고 했는데, 대신 폭죽이 터진 것입니다.
이야기 만들기
CSRF와 XSS 개념을 이야기로 만들어보세요. 이야기는 기억에 오래 남습니다. 예를 들어:
CSRF 이야기: "앨리스와 몰래 온 손님"
한 때, 인기 있는 소셜 미디어 플랫폼을 운영하는 앨리스가 있었습니다. 그녀의 플랫폼은 사용자들이 서로 메시지를 주고받고 사진을 공유할 수 있는 공간이었습니다.
1. 상황 설정
어느 날, 앨리스는 새로운 기능을 추가했습니다. 바로 '친구에게 선물 보내기' 기능이었죠. 이 기능은 사용자가 로그인한 상태에서 친구에게 가상의 선물을 보낼 수 있는 멋진 기능이었습니다.
2. 악의적인 계획
그러나, 같은 도시에 사는 악의적인 해커인 밥은 앨리스의 플랫폼을 연구하다가 이 '친구에게 선물 보내기' 기능에 취약점이 있다는 것을 발견했습니다. 밥은 이 기능이 CSRF 공격에 취약하다는 것을 알아냈습니다.
3. 밥의 공격 준비
밥은 앨리스의 플랫폼을 이용하는 사람들에게 자신의 악성 웹사이트를 방문하도록 유도했습니다. 밥의 웹사이트에는 '무료 영화 스트리밍'이라는 유혹적인 광고가 있었죠. 많은 사용자가 이 광고에 속아 사이트를 방문했습니다.
4. CSRF 공격 발동
앨리스의 플랫폼에 이미 로그인한 사용자들이 밥의 웹사이트를 방문하면, 밥의 웹사이트는 자동으로 앨리스의 플랫폼에 요청을 보내도록 설정되어 있었습니다. 이 요청은 '친구에게 선물 보내기' 기능을 이용해 임의의 친구에게 선물을 보내는 것이었죠. 플랫폼은 사용자가 이미 인증된 상태이기 때문에 이 요청을 정상적인 것으로 받아들였습니다.
5. 문제 발생
곧 많은 사용자가 자신도 모르는 사이에 친구들에게 선물을 보내게 되었습니다. 사용자들은 이유도 모른 채 선물이 전달되었고, 이로 인해 혼란이 발생했습니다. 선물을 받은 사람들은 왜 선물을 받았는지 물어보고, 보낸 사람들은 자신이 보낸 적이 없다고 부인했습니다.
6. 해결책 마련
앨리스는 곧 이 문제를 인지하고 해결책을 마련하기로 했습니다. 그녀는 CSRF 토큰을 도입하여 모든 중요한 요청에 고유한 토큰을 포함하도록 플랫폼을 수정했습니다. 이제 각 사용자가 선물을 보낼 때마다 고유한 토큰을 포함해야 했고, 이 토큰이 유효하지 않으면 요청이 처리되지 않도록 했습니다.
7. 해피 엔딩
이후, 앨리스의 플랫폼은 다시 안전하게 운영되었고, 사용자들은 안심하고 친구들에게 선물을 보낼 수 있었습니다. 밥의 공격은 실패로 돌아갔고, 앨리스는 보안의 중요성을 다시 한 번 깨닫게 되었습니다.
XSS 이야기: "조의 블로그와 악의적인 댓글"
1. 블로그 개설
조는 기술 블로그를 운영하는 블로거였습니다. 그는 자신의 블로그에서 다양한 프로그래밍 언어와 기술에 대한 정보를 공유하고, 독자들이 댓글을 남길 수 있도록 했습니다. 조의 블로그는 점점 인기를 얻으며 많은 사람들이 방문하게 되었습니다.
2. 새로운 독자
어느 날, 조의 블로그에 새로운 독자가 나타났습니다. 그 사람의 이름은 몰리였습니다. 몰리는 조의 블로그에서 유익한 정보를 얻고자 자주 방문하였고, 어느 날 한 포스트에 댓글을 남기기로 했습니다.
3. 몰리의 악의적인 계획
사실, 몰리는 악의적인 해커였습니다. 그녀는 XSS 공격을 통해 조의 블로그를 공격하려는 계획을 세웠습니다. 몰리는 블로그의 댓글 기능이 사용자의 입력을 제대로 검증하지 않는다는 취약점을 발견했습니다.
4. 악성 댓글 작성
몰리는 조의 블로그에 다음과 같은 댓글을 남겼습니다:
<script>alert('Your session is hijacked!');</script>이 댓글은 겉으로는 평범해 보였지만, 실제로는 스크립트 태그를 통해 악성 코드를 포함하고 있었습니다.
5. 공격 발동
조의 블로그를 방문한 다른 독자들이 이 포스트를 보았을 때, 몰리가 남긴 댓글이 브라우저에서 그대로 실행되었습니다. 그러자 그들의 화면에는 경고창이 뜨며 "Your session is hijacked!"라는 메시지가 표시되었습니다. 이 메시지는 단순한 경고창일 수도 있었지만, 실제로는 세션 정보를 탈취하는 더 복잡한 스크립트로 변경될 수 있었습니다.
6. 문제 인식
조는 독자들로부터 이상한 경고창이 뜬다는 보고를 받았습니다. 그는 문제를 조사한 끝에 몰리의 댓글이 XSS 공격의 일환임을 알게 되었습니다.
7. 해결책 마련
조는 즉시 블로그의 댓글 기능을 수정하기로 결심했습니다. 그는 모든 사용자 입력을 HTML 엔티티로 인코딩하여 스크립트가 실행되지 않도록 했습니다. 예를 들어, <script> 태그는 <script>로 인코딩되어 브라우저에서 실행되지 않도록 했습니다. 또한, 조는 Content Security Policy (CSP)를 설정하여 외부에서 스크립트가 실행되는 것을 방지하고, 신뢰할 수 있는 소스에서만 스크립트가 로드되도록 했습니다.
8. 해피 엔딩
이후, 조의 블로그는 다시 안전하게 운영되었고, 독자들은 마음 놓고 댓글을 남길 수 있었습니다. 몰리의 공격은 더 이상 효과가 없었고, 조는 보안의 중요성을 다시 한 번 깨닫게 되었습니다.
