From 768bd9806a61dc18400eeb3b52f72d12cfef3a86 Mon Sep 17 00:00:00 2001 From: da-in Date: Mon, 25 Sep 2023 21:33:03 +0900 Subject: [PATCH 1/2] =?UTF-8?q?Update=20=EB=A1=9C=EA=B7=B8=EB=A0=88?= =?UTF-8?q?=EB=B2=A8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...34\352\267\270\353\240\210\353\262\250.md" | 20 ++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git "a/CS Deep Dive/Web/\353\241\234\352\267\270\353\240\210\353\262\250.md" "b/CS Deep Dive/Web/\353\241\234\352\267\270\353\240\210\353\262\250.md" index 02dcabca..f1af767c 100644 --- "a/CS Deep Dive/Web/\353\241\234\352\267\270\353\240\210\353\262\250.md" +++ "b/CS Deep Dive/Web/\353\241\234\352\267\270\353\240\210\353\262\250.md" @@ -1,6 +1,6 @@ # 로그레벨(Logging Level) -로그는 비즈니스 로직에는 직접적인 연관이 없는 개발자 자율적인 영역이다. 하지만 더 좋은 시스템을 위해 고민하면 좋다. +로그와 관련된 부분은 비즈니스 로직에는 직접적인 연관이 없는 개발자의 자율적인 영역이지만 더 좋은 시스템을 위해 고민하면 좋다. 로그와 로그레벨에 대하여 알아본다.
@@ -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 | +
+ 다음과 같은 중요도 순위를 갖는다. -ALL < TRACE < DEBUG < INFO < WARN < ERROR < FATAL < OFF +`ALL` < `TRACE` < `DEBUG` < `INFO` < `WARN` < `ERROR` < `FATAL` < `OFF`
-**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! From 782b820ba5af93fc5920693fe1d73ebeca67b029 Mon Sep 17 00:00:00 2001 From: da-in Date: Tue, 3 Oct 2023 14:31:15 +0900 Subject: [PATCH 2/2] update: CSRF&XSS --- CS Deep Dive/Web/CSRF&XSS.md | 83 ++++++++++++++++++++++-------------- 1 file changed, 50 insertions(+), 33 deletions(-) diff --git a/CS Deep Dive/Web/CSRF&XSS.md b/CS Deep Dive/Web/CSRF&XSS.md index 85c971fa..450f4b6f 100644 --- a/CS Deep Dive/Web/CSRF&XSS.md +++ b/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 + + ``` +4. 사용자가 공격용 페이지를 로드하면, 브라우저는 이미지 파일을 받아오기 위해 `src` 속성으로 등록되어있는 URL에 요청을 보낸다. +5. 로그인 상태로 쿠키가 유효하고 다른 확인이 없는 경우, 사용자의 승인이나 인지 없이 송금되어 공격이 완료된다. -우리가 실생활에서 CSRF 공격을 볼 수 있는 건, 해커가 사용자의 SNS 계정으로 광고성 글을 올리는 것이다. +> `POST`메서드의 엔드포인트도 보이지 않는 `
` 제출을 트리거하는 방법으로 공격할 수 있다. -CSRF는 해커가 사용자 컴퓨터를 감염시거나 서버를 해킹해서 공격하는 것이 아니다. -CSRF 공격은 아래와 같은 조건이 만족할 때 실행된다. +### CSRF 대응 방법 -- 사용자가 해커가 만든 피싱 사이트에 접속한 경우 -- 위조 요청을 전송하는 서비스에 사용자가 로그인을 한 상황 +**리퍼러(Referer) 검증** +백엔드에서 Referer\* 검증을 통해 승인된 도메인으로 요청시에만 처리하도록 한다. -보통 자동 로그인을 해둔 경우에 이런 피싱 사이트에 접속하게 되면서 피해를 입는 경우가 많다. -또한, 해커가 XSS 공격을 성공시킨 사이트라면, 피싱 사이트가 아니더라도 CSRF 공격이 이루어질 수 있다. +\* referer : `HTTP request header`에 포함된 요청을 보낸 웹 페이지의 주소 -### 대응 방법 -- 리퍼러(Refferer) 검증: 백엔드에서 Refferer 검증을 통해 승인된 도메인으로 요청시에만 처리하도록 한다. -- Security Token 사용: 사용자의 세션에 임의의 난수 값을 저장하고, 사용자의 요청시 해당 값을 포함하여 전송시킨다. 백엔드에서는 요청을 받을 때 세션에 저장된 토큰값과 요청 파라미터로 전달받는 토큰 값이 일치하는 지 검증 과정을 거치는 방법이다. +**CSRF Token 사용** +사용자의 세션에 임의의 난수 값을 저장하고, 사용자의 요청시 해당 값을 포함하여 전송시킨다. 백엔드에서는 요청을 받을 때 세션에 저장된 토큰값과 요청 파라미터로 전달받는 토큰 값이 일치하는 지 검증 과정을 거치는 방법이다. ---- -## XSS(Cross Site Scription) +
-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 대응 방법 +**입력 값 검증** +데이터가 입력되기 전이나, 서버에 전달하기 전 검증하는 방식으로, 입력 데이터 길이 제한, 특정 값 무효화 등을 수행할 수 있다. +**출력 값 검증** +출력하려는 데이터에 스크립트로 해석될 여지가 있는 문자열을 인코딩하는 것이다. `<`를 `<`, `>`를 `>`로 변환하는 등의 과정을 거쳐 출력하면 스크립트로 해석되지 않는다. +**보안 라이브러리 사용** +Anti XSS 라이브러리를 제공해주는 회사들이 많다. 서버 단에서는 이러한 라이브러리들을 추가하여, 클라이언트는 브라우저에 확장앱을 설치하여 방어할 수 있다. + +
+ +--- +## 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