[Web] CSRF&XSS

CS Deep Dive/Web/CSRF&XSS.md

@@ -1,53 +1,70 @@
 # CSRF & XSS
+보안 공격에는 `Click-jaking`, `XSS`, `CSRF`, `MitM`, `Session hijacking`등의 다양한 유형이 존재하는데, 그 중 `CSRF`와 `XSS`공격에 대하여 다룬다. 모든 공격에 대한 내용은 [MDN | Types of attacks
+](https://developer.mozilla.org/ko/docs/Web/Security/Types_of_attacks)에 자세히 나와있다.
 
 ## CSRF(Cross Site Request Forgery)
-웹 어플리케이션 취약점 중 하나로, 인터넷 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위 (modify, delete, register 등)를 특정한 웹사이트에 request하도록 만드는 공격을 말한다.
+`CSRF`는 웹사이트 취약점 공격 유형 중 하나로 `XSRF`라고도 한다. 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(`modify`, `delete`, `register` 등)를 특정한 웹사이트에 `request`하도록 만드는 공격이다. 해커가 사용자의 SNS 계정으로 광고성 글을 올리는 것은 대표적인 CSRF 공격에 해당한다.
 
-해커들이 많이 이용하는 것으로, 유저의 권한을 도용해 중요한 기능을 실행하도록 한다.
+### CSRF 공격 흐름
+1. 사용자는 웹사이트에 로그인하여 정상적인 [쿠키](https://github.com/da-in/tech-interview-study/blob/main/CS%20Deep%20Dive/Web/Cookie%26Session.md)를 발급받는다.
+2. 공격자는 공격용 HTML 페이지 링크를 이메일이나 게시판 등을 통해 사용자에게 전달한다.
+3. 공격용 HTML 페이지는 다음과 같은 이미지 태그를 가진다.  
+   ```html
+   <img src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" />
+   ```
+4. 사용자가 공격용 페이지를 로드하면, 브라우저는 이미지 파일을 받아오기 위해 `src` 속성으로 등록되어있는 URL에 요청을 보낸다.
+5. 로그인 상태로 쿠키가 유효하고 다른 확인이 없는 경우, 사용자의 승인이나 인지 없이 송금되어 공격이 완료된다.
 
-우리가 실생활에서 CSRF 공격을 볼 수 있는 건, 해커가 사용자의 SNS 계정으로 광고성 글을 올리는 것이다.
+> `POST`메서드의 엔드포인트도 보이지 않는 `<form>` 제출을 트리거하는 방법으로 공격할 수 있다.
 
-CSRF는 해커가 사용자 컴퓨터를 감염시거나 서버를 해킹해서 공격하는 것이 아니다.  
-CSRF 공격은 아래와 같은 조건이 만족할 때 실행된다.
+### CSRF 대응 방법
 
-- 사용자가 해커가 만든 피싱 사이트에 접속한 경우  
-- 위조 요청을 전송하는 서비스에 사용자가 로그인을 한 상황  
+**리퍼러(Referer) 검증**  
+백엔드에서 Referer\* 검증을 통해 승인된 도메인으로 요청시에만 처리하도록 한다.
 
-보통 자동 로그인을 해둔 경우에 이런 피싱 사이트에 접속하게 되면서 피해를 입는 경우가 많다.  
-또한, 해커가 XSS 공격을 성공시킨 사이트라면, 피싱 사이트가 아니더라도 CSRF 공격이 이루어질 수 있다.
+\* referer : `HTTP request header`에 포함된 요청을 보낸 웹 페이지의 주소
 
-### 대응 방법  
-- 리퍼러(Refferer) 검증: 백엔드에서 Refferer 검증을 통해 승인된 도메인으로 요청시에만 처리하도록 한다.
-- Security Token 사용: 사용자의 세션에 임의의 난수 값을 저장하고, 사용자의 요청시 해당 값을 포함하여 전송시킨다. 백엔드에서는 요청을 받을 때 세션에 저장된 토큰값과 요청 파라미터로 전달받는 토큰 값이 일치하는 지 검증 과정을 거치는 방법이다.
+**CSRF Token 사용**  
+사용자의 세션에 임의의 난수 값을 저장하고, 사용자의 요청시 해당 값을 포함하여 전송시킨다. 백엔드에서는 요청을 받을 때 세션에 저장된 토큰값과 요청 파라미터로 전달받는 토큰 값이 일치하는 지 검증 과정을 거치는 방법이다.
 
----
-## XSS(Cross Site Scription)
+<br/>
 
-CSRF와 같이 웹 어플리케이션 취약점 중 하나로, 관리자가 아닌 권한이 없는 사용자가 웹 사이트에 스크립트를 삽입하는 공격 기법을 말한다.
+## XSS(Cross Site Scripting)
 
-악의적으로 스크립트를 삽입하여 이를 열람한 사용자의 쿠키가 해커에게 전송시키며, 이 탈취한 쿠키를 통해 세션 하이재킹 공격을 한다. 해커는 세션ID를 가진 쿠키로 사용자의 계정에 로그인이 가능해지는 것이다.
+`XSS`는 `CSRF`와 같이 웹사이트 취약점 공격 유형 중 하나로, 관리자가 아닌 권한이 없는 사용자가 웹 사이트에 스크립트를 삽입하는 공격 기법이다.
+- 이를 통해 사용자의 정보(쿠키, 세션 등)을 탈취하거나, 자동으로 비정상적인 기능을 수행할 수 있다.
+- 주로 다른 웹사이트와 정보를 교환하는 식으로 작동하므로 사이트 간 스크립팅이라고 한다.
+- `CSS`라는 이름은 웹 기술인 `CSS`와 중복되어 `XSS`라고 부른다.
 
-공격 종류로는 지속성, 반사형, DOM 기반 XSS 등이 있다.
+### XSS 공격 유형
 
-- 지속성 : 말 그대로 지속적으로 피해를 입히는 유형으로, XSS 취약점이 존재하는 웹 어플리케이션에 악성 스크립트를 삽입하여 열람한 사용자의 쿠키를 탈취하거나 리다이렉션 시키는 공격을 한다. 이때 삽입된 스크립트를 데이터베이스에 저장시켜 지속적으로 공격을 하기 때문에 Persistent XSS라고 불린다.
-- 반사형 : 사용자에게 입력 받은 값을 서버에서 되돌려 주는 곳에서 발생한다. 공격자는 악의 스크립트와 함께 URL을 사용자에게 누르도록 유도하고, 누른 사용자는 이 스크립트가 실행되어 공격을 당하게 되는 유형이다.
-- DOM 기반 : 악성 스크립트가 포함된 URL을 사용자가 요청하게 되면서 브라우저를 해석하는 단계에서 발생하는 공격이다. 이 스크립트로 인해 클라이언트 측 코드가 원래 의도와 다르게 실행된다. 이는 다른 XSS 공격과는 달리 서버 측에서 탐지가 어렵다.
+`XSS`공격의 세부 유형은 표준으로 정해져 있지 않지만, 일반적으로 `반사형(Non-persistent)`, `저장형(persistent)`, `DOM 기반 XSS` 등으로 구분한다.
 
-### 대응 방법 
-- 입출력 값 검증  
-XSS Cheat Sheet에 대한 필터 목록을 만들어 모든 Cheat Sheet에 대한 대응을 가능하도록 사전에 대비한다. XSS 필터링을 적용 후 스크립트가 실행되는지 직접 테스트 과정을 거쳐볼 수도 있다,
-- XSS 방어 라이브러리, 확장앱  
-Anti XSS 라이브러리를 제공해주는 회사들이 많다. 이 라이브러리는 서버단에서 추가하며, 사용자들은 각자 브라우저에서 악성 스크립트가 실행되지 않도록 확장앱을 설치하여 방어할 수 있다.
-- 웹 방화벽  
-웹 방화벽은 웹 공격에 특화된 것으로, 다양한 Injection을 한꺼번에 방어할 수 있는 장점이 있다.
-- CORS, SOP 설정  
-CORS(Cross-Origin Resource Sharing), SOP(Same-Origin-Policy)를 통해 리소스의 Source를 제한 하는것이 효과적인 방어 방법이 될 수 있다. 웹 서비스상 취약한 벡터에 공격 스크립트를 삽입 할 경우, 치명적인 공격을 하기 위해 스크립트를 작성하면 입력값 제한이나 기타 요인 때문에 공격 성공이 어렵다. 그러나 공격자의 서버에 위치한 스크립트를 불러 올 수 있다면 이는 상대적으로 쉬워진다. 그렇기 떄문에 CORS, SOP를 활용 하여 사전에 지정된 도메인이나 범위가 아니라면 리소스를 가져올 수 없게 제한해야 한다.
+**반사형(Reflected, Non-persistent)**  
+반사형 XSS 공격은 요청 메세지에 입력된 스크립트 코드가 즉시 응답 메세지를 통해 출력되는 취약점을 이용한다. 공격자가 주입한 스크립트가 브라우저에 반사되는 것처럼 동작하여 붙은 이름이다.
 
+**저장형(Stored, Persistent)**  
+악성 스크립트를 대상 서버에 삽입하여 이를 열람한 사용자를 공격 한다. 삽입된 스크립트를 서버에 저장시켜 지속적으로 공격을 하기 때문에 `Persistent XSS`라고 불린다.
 
----
-# 출처
-https://itstory.tk/entry/CSRF-%EA%B3%B5%EA%B2%A9%EC%9D%B4%EB%9E%80-%EA%B7%B8%EB%A6%AC%EA%B3%A0-CSRF-%EB%B0%A9%EC%96%B4-%EB%B0%A9%EB%B2%95  
-https://noirstar.tistory.com/266  
+**DOM 기반**  
+악성 스크립트가 포함된 URL을 사용자가 요청하게 되면서 브라우저를 해석하는 단계에서 발생하는 공격이다. 이 스크립트로 인해 클라이언트 측 코드가 원래 의도와 다르게 실행된다. 이는 다른 XSS 공격과는 달리 서버 측에서 탐지가 어렵다.
+
+### XSS 대응 방법
 
+**입력 값 검증**  
+데이터가 입력되기 전이나, 서버에 전달하기 전 검증하는 방식으로, 입력 데이터 길이 제한, 특정 값 무효화 등을 수행할 수 있다.
 
+**출력 값 검증**
+출력하려는 데이터에 스크립트로 해석될 여지가 있는 문자열을 인코딩하는 것이다. `<`를 `&lt;`, `>`를 `&gt;`로 변환하는 등의 과정을 거쳐 출력하면 스크립트로 해석되지 않는다.
 
+**보안 라이브러리 사용**    
+Anti XSS 라이브러리를 제공해주는 회사들이 많다. 서버 단에서는 이러한 라이브러리들을 추가하여, 클라이언트는 브라우저에 확장앱을 설치하여 방어할 수 있다.
+
+<br/>
+
+---
+## Reference
+📄https://developer.mozilla.org/ko/docs/Web/Security/Types_of_attacks  
+📄https://ko.wikipedia.org/wiki/사이트_간_요청_위조  
+📄https://itstory.tk/entry/CSRF-공격이란-그리고-CSRF-방어-방법  
+📄https://noirstar.tistory.com/266

CS Deep Dive/Web/로그레벨.md

@@ -1,6 +1,6 @@
 # 로그레벨(Logging Level)
 
-로그는 비즈니스 로직에는 직접적인 연관이 없는 개발자 자율적인 영역이다. 하지만 더 좋은 시스템을 위해 고민하면 좋다.
+로그와 관련된 부분은 비즈니스 로직에는 직접적인 연관이 없는 개발자의 자율적인 영역이지만 더 좋은 시스템을 위해 고민하면 좋다. 로그와 로그레벨에 대하여 알아본다.
 
 <br/>
 
@@ -13,7 +13,7 @@
 
 로그를 남기는 방법은 크게 두 가지로 생각할 수 있다.
 
-1. 직접 출력하기
+1. 직접 출력하기  
    `stdout`, `stderror` (c 기준) 방식으로 출력하는 것이다.
 
    ```python
@@ -34,7 +34,7 @@
 
 ## 로그레벨
 
-로그레벨은 다음과 같은 우선순위를 갖는다. (log4j 기준의 로그레벨이다.)
+로그레벨은 로그(Log) 메세지의 중요도를 나타내는 단계이다. 로깅 시스템에서 사용되며, 로그레벨에 따라 로그 메세지 기록 여부를 결정한다. 로그레벨은 다음과 같은 우선순위를 갖는다.(log4j 기준)
 
 | Log Level | Description                                                                                                             |
 | --------- | ----------------------------------------------------------------------------------------------------------------------- |
@@ -48,13 +48,17 @@
 | TRACE_INT | TRACE level integer value                                                                                               |
 | **WARN**  | The WARN level designates potentially harmful situations                                                                |
 
+<br/>
+
 다음과 같은 중요도 순위를 갖는다.
 
-ALL < TRACE < DEBUG < INFO < WARN < ERROR < FATAL < OFF
+`ALL` < `TRACE` < `DEBUG` < `INFO` < `WARN` < `ERROR` < `FATAL` < `OFF`
 
 <br/>
 
-**Example**
+### Logging Level Example
+
+아래는 지정한 로그레벨에 대하여 기록된 로그의 예시이다. 지정한 로그레벨 이상의 로그 메세지만 기록된다.
 
 ```java
 import org.apache.log4j.*;
@@ -75,10 +79,8 @@ public class LogClass {
 }
 ```
 
-**Result**
-
-```
-// WARN 보다 높은 레벨이 로그에 찍힌다.
+```shell
+# WARN 보다 높은 레벨의 로그가 기록된다.
 Warn Message!
 Error Message!
 Fatal Message!