2025. 4. 1. 16:57ㆍ카테고리 없음
방화벽
네트워크 트래픽 기반 방화벽입니다.
방화벽은 정해진 보안 규칙에 따라 네트워크 트래픽을 모니터링하고 필터링하는 네트워크 보안 장치입니다.
다음과 같은 목저이 있습니다.
- 네트워크나 컴퓨터 주변으로 보안 경계를 형성하여 트래픽 조절
- 트래픽 모니터링
- 트래픽 필터링
네트워크 기반으로 network, transport 계층에 해당합니다.
다음과 같은 공격을 막을 수 있습니다.
- 무단 액세스
- MITM(Man-in-the-middle) 공격 : 중간자 공격. 중간에서 정보를 가로채는 공격.
WAF (Web Application Firewall)
HTTP 트래픽 기반 방화벽입니다.
외부와 웹 애플리케이션 사이 모든 HTTP 트래픽을 모니터링하고 필터링하는 방화벽입니다.
XSS(교차 사이트 스크립팅) 공격, DDoS(분산 서비스 거부) 공격 및 SQL 주입 공격에 대응할 수 있습니다.
HTTP 기반으로 애플리케이션 계층에 해당합니다.
WAF를 통해 웹 애플리케이션의 취약점을 보완할 수 있으며 다음과 같은 웹 애플리케이션을 대상으로 하는 공격을 막을 수 있습니다.
- 직접 서비스 거부(DoS)
- SQL 인젝션
- 교차 사이트 스크립팅(XSS)
CSRF(교차 사이트 요청 위조)
신뢰할 수 있는 사용자를 사칭하여 웹 사이트에 악의적인 요청을 보냅니다.
특정 사이트에서 발급 받은 쿠키는 해당 사이트에 요청을 보낼 때 자동으로 보내진다는 점을 이용한 공격 방식입니다.
예를 들어 특정 리소스에 대한 삭제 권한을 가지고 있는 유저가 공격자의 사이트에 들어가고 img 태그를 통해 GET요청을 보내면 경우 의도치 않게 리소스를 삭제하게 될 수 있습니다.
아래처럼 img 태그나 link 태그를 사용해서 GET 요청을 보내는 경우가 있습니다.
<img src="https://www.example.com/index.php?action=delete&id=123" />
혹은, 이메일을 통해 위와 같이 위조된 요청을 보내는 하이퍼링크를 보내는 것입니다.
즉, 사용자의 인증된 세션을 악용하는 공격 방식입니다.
웹 애플리케이션이 사용자의 요청이 실제 사용자가 전송한 것인지 확인하지 않는 경우에 자주 발생합니다.
다음과 같은 방식으로 방지할 수 있습니다.
- CSRF 토큰을 통해 요청이 사용자가 전송한 것이 맞는지 확인
- 재인증을 요구
CSRF 토큰
사용자의 요청이 실제 자신이 생성한 요청인지 확인합니다.
서버에서 생성하여 클라이언트에 전달하고 클라이언트의 요청마다 CSRF 토큰을 포함하여 서버에서 검증을 진행합니다.
hidden input 태그에 CSRF 토큰을 저장하는 방법이 있습니다.
왜 CSRF 토큰을 사용하면 안전한가?
CSRF 공격은 인증된 사용자의 세션을 이용합니다.
만약 로그인을 성공하여 세션 쿠키를 가지고 있는 상황이면 하이퍼링크를 클릭할 때 해당 쿠키가 함께 서버로 보내지기 때문에 서버는 인증된 사용자의 요청이라고 판단합니다.
여기서 중요한 점은 인증된 사용자의 요청이 맞지만 실제 사용자가 원한 요청이 아니라는 점입니다.
그래서 서버에서 세션 쿠키와 CSRF 토큰을 함께 만들어서 클라이언트에게 보내줍니다.
하이퍼링크를 클릭할 때 세션 쿠키가 서버에 보내지더라도 CSRF 토큰이 없거나 유효하지 않으면 요청을 거부합니다.
Same Site 설정은 어떻게 CSRF 공격을 방지할 수 있는가?
해커의 사이트에 특정 사이트로 악의적인 요청을 보내는 코드가 있다면 도메인이 다를 경우에 서버에서 요청을 거부합니다.
- Strict: 반드시 같은 도메인에서만 사용 가능 (하위 도메인 포함)
- Lax: 같은 도메인에서만 사용 가능하지만, 유저가 링크를 클릭해서 접속하거나 하는 경우에는 다른 도메인에서도 사용 가능 (기본 값)
- None: 다른 도메인에서도 사용 가능. Secure 옵션과 함께 사용해야 함.
- 사용자가 서버로 요청을 보낸다.
- 서버가 SameSite와 domain을 쿠키에 담아 보낸다.
- 브라우저는 요청을 보낸 도메인과 쿠키의 도메인 값이 일치하는지 확인한다.
- 일치하고 same site 옵션을 만족하면 쿠키를 저장한다.
리퀘스트를 보내는 쪽과 받는 쪽이 도메인이 다를 때 저장하는 쿠키를 3자 쿠키(Third-Party Cookie)라고 합니다.
만약 해커의 가짜 사이트에 들어와서 로그인을 한다고 가정합니다.
실제 사이트에 로그인 요청을 받아서 세션 쿠키를 저장한다면 해커의 가짜 사이트는 이 쿠키를 탈취할 수 있습니다.
그래서 same site 설정이 필요합니다.
만약 3자 쿠키를 저장하려면 same site를 None 옵션을 주고 https에만 쿠키를 저장하도록 secure 옵션을 줘야합니다.
서버가 쿠키를 생성해서 보낼 때 Same Site 옵션을 설정하는 것이고 브라우저가 쿠키의 same site 옵션을 보고 쿠키 저장 여부를 결정하는 것입니다.
XSS (크로스 사이트 스크립팅)
악성 스크립트를 삽입하여 쿠키, 세션, 키보드 입력 값 등을 탈취합니다.
Stored XSS (저장형 크로스사이트스크립트)
취약점이 있는 웹 서버에 악성 스크립트를 저장하는 공격 방법입니다.
공격자는 악성 스크립트가 포함된 게시글을 작성하여 게시판 등 사용자가 접근할 수 있는 페이지에 업로드 합니다.
이후 사용자가 해당 게시글을 요청하면 서버에 저장된 악성 스크립트가 사용자 측에서 동작하게 됩니다.
Reflected XSS (반사형 크로스사이트스크립트)
웹 응용 프로그램의 지정된 변수를 이용할 때 발생하는 취약점을 이용하는 공격으로, 악성 스크립트가 데이터베이스와 같은 저장소에 별도로 저장되지 않고 사용자의 화면에 즉시 출력되는데 주로 이메일, 메신저 등에 포함된 URL을 통해 공격이 이루어지고 있습니다.
DOM Based XSS (DOM 기반 크로스사이트스크립트)
악성 스크립트가 서버와 상호작용 없이 브라우저 자체에서 실행되는 취약점으로, 페이지에 포함되어 있는 브라우저 악성코드가 DOM 환경에서 실행됩니다.
stored XSS 같은 경우 게시글에 <script>alert(””)<script> 이러한 내용을 작성하는 것입니다.
만약 누군가 게시글에 접속하면 html로 렌더링하는 과정에서 script 코드라고 판단하여 스크립트를 실행하게 됩니다.
이를 대비하여 ‘<’, ‘>’이러한 특수 문자를 다른 문자로 치환하여 저장하면 이러한 문제를 방지할 수 있습니다.
SQL Injection
공격자가 웹 애플리케이션 취약점을 이용해서 악의적으로 데이터베이스에 접근하는 공격입니다.
예를 들어 다음과 같은 SQL을 실행하는 API가 존재한다고 합시다.
DELETE FROM page WHERE id =
그리고 id를 쿼리 파라미터 형태로 받는다고 할 때 다음과 같은 악의적인 값을 넣을 수 있습니다.
“1 or true”
만약 웹 애플리케이션에서 유효성 검사 없이 저 값을 그대로 SQL 쿼리 문에 연결하게 될 경우 아래와 같은 SQL 문이 완성됩니다.
DELETE FROM page WHERE id = 1 or true;
or 문으로 인해 무조건 조건을 만족하게 되고 모든 행을 삭제하는 SQL 쿼리 문이 됩니다.
다음과 같은 방법으로 SQL Injection을 방지할 수 있습니다.
- Prepared Statement
단순 문자열로 사용하는 게 아니라 SQL 문을 미리 준비해두고 파라미터로 제공하는 방식입니다.
const query = 'SELECT * FROM users WHERE username = ?';
db.execute(query, [userInput]);
- 사용자 입력 이스케이프 처리
SQL의 특수 문자를 자동으로 변환하여 SQL에 영향을 줄입니다.