XSS(Cross-Site Scripting)는 웹 애플리케이션에서 발견되는 보안 취약점 중 하나다. XSS는 공격자가 웹 페이지에 악의적인 스크립트를 주입하고, 이 스크립트가 다른 사용자의 브라우저에서 실행되도록 함으로써 사용자의 정보를 탈취하거나 사기 행위를 저지를 수 있게 만드는 공격이다.
Stored XSS는 악의적인 스크립트가 웹 애플리케이션의 서버에 저장된다. 예를 들어, 게시판이나 댓글 섹션에 악의적인 스크립트가 포함된 내용을 작성할 수 있다. 사용자가 해당 페이지를 방문할 때마다 악의적인 스크립트가 실행된다. 이 유형은 다수의 사용자에게 영향을 미칠 수 있어 매우 위험하다.
Reflected XSS 사용자로부터 받은 입력이 즉시 실행된다. 예를 들어, 검색 결과 페이지에서 검색어를 그대로 브라우저에 출력할 때 악의적인 스크립트가 포함된 검색어를 사용자가 입력하면 스크립트가 실행된다. 이 스크립트는 주로 피싱 공격에 사용되며, 사용자가 링크를 클릭해야만 공격이 발동된다.
DOM-based XSS DOM(Document Object Model)의 취약점을 이용하여 공격이 수행된다. 웹 페이지의 클라이언트 사이드 스크립트가 DOM을 잘못 처리하여 발생한다. URL의 일부로 전달된 데이터가 안전하지 않게 처리되어 스크립트가 실행될 수 있다.
돔 기반 XSS 예시:
<!DOCTYPE html>
<html>
<head>
<title>DOM-based XSS Example</title>
</head>
<body>
<h1>Welcome</h1>
<div id="message"></div>
<script>
var message = document.getElementById('message');
var query = window.location.search.substring(1);
message.innerHTML = decodeURIComponent(query);
</script>
</body>
</html>
XSS는 사용자의 세션 토큰이나 쿠키를 탈취하여 사용자의 계정을 도용할 수 있다. 악의적인 스크립트를 통해 사용자의 브라우저에서 웹 사이트의 내용이나 기능을 변경할 수 있다. 가짜 로그인 폼을 생성하여 사용자의 로그인 정보를 탈취할 수 있다. 한 사용자의 브라우저에서 실행된 스크립트가 다른 사용자들에게 퍼질 수 있다.
입력 검증 및 새니타이징으로 사용자 입력을 검증하고, 스크립트 태그나 이벤트 핸들러 등을 포함할 수 있는 문자를 적절히 필터링하거나 이스케이프 처리를 해야한다.
콘텐츠 보안 정책(CSP)은 콘텐츠 보안 정책을 설정하여 외부 스크립트의 실행을 제한한다.
HTTPOnly 쿠키는 HTTPOnly 플래그를 쿠키에 설정하여 자바스크립트를 통한 쿠키 접근을 차단한다.
CORS(Cross-Origin Resource Sharing)는 웹 페이지가 다른 도메인의 리소스를 안전하게 요청할 수 있도록 하는 보안 메커니즘이다. 기본적으로 브라우저는 같은 출처 정책(Same-Origin Policy)을 적용하여, 스크립트가 실행 중인 원본(도메인, 프로토콜, 포트)과 다른 원본의 리소스에 대한 접근을 제한한다. CORS는 이 정책을 확장하여, 특정 조건 하에 다른 출처의 리소스 접근을 허용한다.
CORS는 HTTP 헤더를 사용하여 브라우저와 서버 간에 정보를 교환한다. 서버는 'Access-Control-Allow-Origin'과 같은 CORS 관련 헤더를 설정하여, 특정 출처의 브라우저가 해당 서버의 리소스에 접근할 수 있도록 허용한다.
메소드가 GET, HEAD, POST 중 하나이고, HTTP 헤더가 일반적으로 허용되는 헤더(CORS 사양에서 정의된 'Accept', 'Accept-Language', 'Content-Language', 'Content-Type' 등)로만 구성되어 있을 때 단순 요청으로 간주된다.
이 경우 브라우저는 특별한 CORS 헤더 없이 요청을 보낸다. 서버는 응답에 'Access-Control-Allow-Origin' 헤더를 포함하여 요청을 허용할 출처를 지정한다.
PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH 또는 Content-Type이 application/json인 POST 등, 단순 요청에 해당하지 않는 메소드를 사용하는 요청은 사전 요청이 필요하다.
브라우저는 실제 요청을 보내기 전에 'OPTIONS' 메소드를 사용하여 사전 요청을 보낸다. 이 요청은 서버에게 실제 요청을 안전하게 처리할 수 있는지 확인하기 위한 것이다.
서버는 'Access-Control-Allow-Methods', 'Access-Control-Allow-Headers' 등의 헤더로 응답하여, 어떤 HTTP 메소드와 헤더, 출처가 허용되는지 명시한다.
쿠키나 HTTP 인증 정보와 같은 사용자 자격 증명을 포함하는 요청도 CORS 정책의 일부다. 이러한 요청을 허용하려면 서버는 'Access-Control-Allow-Origin' 헤더에 구체적인 출처를 명시하고, 'Access-Control-Allow-Credentials' 헤더를 'true'로 설정해야 한다.
CORS는 안전하지 않은 교차 출처 요청을 방지하면서도, 필요한 경우에는 이를 허용하여 웹 애플리케이션의 유연성을 증가시킨다.
API 제공자는 CORS를 통해 자신의 리소스에 대한 접근을 세밀하게 제어할 수 있다. 개발자는 서로 다른 도메인에서 호스팅되는 리소스를 안전하게 요청하고 활용할 수 있어, 서비스 구성의 유연성이 향상된다.
Code Injection은 공격자가 애플리케이션에 악의적인 코드를 주입하고 실행하게 만드는 보안 취약점을 이용한 공격이다. 이러한 공격은 일반적으로 애플리케이션의 입력 검증 또는 적절한 새니타이징이 부족할 때 발생한다. 공격자는 이 취약점을 통해 시스템을 제어하거나 데이터를 탈취하고, 추가적인 악의적 행위를 수행할 수 있다.
SQL Injection은 애플리케이션의 데이터베이스 쿼리에 악의적인 SQL 코드를 삽입하는 방식이다. 공격자는 데이터베이스에서 데이터를 읽어오거나 수정, 삭제하는 등의 작업을 수행할 수 있다.
서비스 거부(DoS)는 애플리케이션의 리소스를 고갈시켜 정상적인 서비스 제공을 방해할 수 있다.
'웹 개발 > 기타' 카테고리의 다른 글
| jest와 github actions를 이용한 간단한 코드 테스트(React) (0) | 2024.07.12 |
|---|---|
| host domain, origin, cookie, local, session (0) | 2024.05.05 |
| HTTP, HTTPS, Mixed Content (0) | 2024.05.05 |
| Web Workers와 Concurrency (0) | 2024.04.13 |
| Synchronous I/O, Asynchronous I/O (1) | 2024.04.06 |