[TIL] Day58 #웹공격 #Token #JWT #OAuth

2022.07.15(Fri)

[TIL] Day58
[SEB FE] Day57

☑️ 웹 공격

➰ Web application Security

: 개발자들이 웹사이트, 모바일 어플, 웹 API 등을 만들 때 해커들의 공격을 막기 위한 보안(security) → 필수 사항!

📎 SQL Injection (SQL 삽입)

: 데이터베이스에서 임의의 SQL문을 실행할 수 있도록 명령어를 삽입하는 공격 유형
👉 데이터베이스를 비정상적으로 조작하므로 기록 삭제 / 데이터 유출 가능성 ⭕️

➰ 대응 방안

1. 입력(요청) 값 검증
   • 화이트리스트 방식으로 해당 키워드가 들어오면 다른 값으로 치환하여 대응 가능
     • 화이트리스트: 모든 기본 정책 차단 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식 / 그 지정된 대상들
2. Prepared Statement 구문 사용
   • 사용시 사용자 입력이 SQL문으로부터 분리되어 방어 가능
   • 사용자 입력값을 Text로 인식 → 입력값이 SQL문이 아닌 Text로 적용되어 공격 실패
3. Error Message 노출 금지
   • Error Message를 통해 데이터베이스 정보를 얻을 수 있음 → 노출 방지를 위해 별도 에러핸들링 필요!

📎 Cross-Site Scripting (XSS)

: 웹 사이트 관리자가 아닌 공격자가 웹 사이트에 악의적인 스크립트를 심어놓는 행위

• 공격 대상 - Client
• 사용자가 의도하지 않은 행동을 하게 하거나 민감 정보 탈취
• 탈취한 민감 정보를 이용해 권한 획득 후, 다양한 공격에 활용

➰ XSS 공격 유형

1. Stored XSS = 지속적(persistent) 기법: 스크립트가 서버에 저장되어 여러 사용자에게 피해를 줄 수 있는 유형
   • 주로 게시판 형태의 웹 사이트에서 공격자가 악의적인 스크립트가 담긴 글 작성 후, 서버에 저장된 글을 조회할 때마다 스크립트 실행되는 형식
2. Reflected XSS = 비지속적(Non-persistent) 기법: URL 파라미터를 사용하여 스크립트를 만드는 유형
   • 서버에 저장되지 않으며, 지정된 파라미터 사용시 나타나는 취약점 이용
   • 주로 검색엔진에서 발생
   • 클라이언트에서 악성 스크립트가 실행!

➰ XSS 대응 방안

1. Script Tag 입력 막기
   • 스크립트 실행을 막기 위해 태그(<>)가 글자 그대로 저장되지 않게 방지 가능
     a. 입력값 확인 / 필터링: 클라이언트와 서버에서 모두 가능한 방법으로, Client측에선 input에 textContent 속성을 사용하여 필터링 가능
     b. 입력값 치환: 글에 있는 태그를 HTML 문자 참조로 치환 후 저장 (< → <, > → >)
2. 쿠키 설정 확인 (httpOnly)
   • 사이트에 스크립트가 저장 혹은 실행되는 일 자체를 방지하진 않음
     But, 스크립트가 쿠키를 탈취하는 경우를 방지해 쿠키에 저장된 민감한 개인 정보 유출 방지 가능
3. 쿠키에 민감 정보 담지 않기
   a. 민감 정보를 서버에서 관리
   b. 암호화 사용

📎 Cross-Site Request Forgery (CSRF)

: 다른 사이트에서 유저가 보내는 요청(request) 조작

• 해커가 직접 데이터 접근 불가 ❌ (response에 직접 접근 X)

➰ CSRF 공격 하기 위한 조건

• 쿠키를 사용한 로그인
• 예측할 수 있는 요청 / parameter를 가지고 있어야 함

➰ CSRF 대응 방안

• CSRF Token 사용: 서버측에서 CSRF 공격에 보호하기 위한 문자열을 유저 브라우저와 웹 앱에만 제공
• Same-site cookie 사용: 같은 도메인에서만 세션/쿠키 사용 가능

📎 Clickjacking

: 사용자가 의도한 클릭 대상이 아닌 다른 대상을 클릭하도록 속이는 공격 기법

• = 사용자 인터페이스 덧씌우기 (User Interface Redress)
• 공격자는 눈에 보이는 화면 위에 눈에 보이지 않는 다른 행동 실행 화면 배치

➰ Clickjacking 대응 방안

• X-Frame-Options: 헤더에 설정한 옵션에 따라 브라우저가 웹 페이지 화면 <iframe> 렌더링 여부 제한 가능
• 콘텐츠 보안 정책(Content Security Policy, CSP): 컴퓨터 보안 표준으로, 웹 페이지에서 악의적인 콘텐츠를 실행하게 하는 보안 공격 예방을 위해 도입

---

☑️ Token

📎 토큰기반 인증(Token-based Authentication)

: 클라이언트에서 인증 정보를 보관하는 방법

✋ 토큰은 유저 정보를 암호화하므로 클라이언트에 담을 수 있음

➰ JWT(JSON Web Token)
: JSON 포맷으로 사용자에 대한 속성을 저장하는 웹 토큰

1. Access Token: 보호된 정보들에 접근할 수 있는 권한부여에 사용

   • 짧은 유효기간을 주어 토큰을 탈취하더라도 오랫동알 사용할 수 없도록 하는 것이 좋음 👍

2. Refresh Token: 액세스 토큰 유효기간 만료시, 리프레시 토큰을 사용하여 새로운 액세스 토큰 발급

   • 유저는 다시 로그인할 필요 ❌
   • 유효기간이 긴 편

➰ JWT 구조

1. Header: 어떤 종류의 토큰인지, 어떤 알고리즘으로 Signature를 암호화(sign)할지 적혀 있음

   // JSON 형태
   {
   	"alg": "HS256", // 어떤 알고리즘으로 Signuture를 암호화헀는지
   	"typ": "JWT" // 어떤 종류 토큰인지
   }
   
   // 이 JSON 객체를 base64방식으로 encoding

2. Payload: 서버에서 활용할 수 있는 유저 정보가 담김 (Base64로만 인코딩된 값)

3. Signature: Header, Payload를 base64인코딩한 값 & salt값의 조합으로 암호환된 값

   • 서버 비밀키 & 헤더에서 지정한 알고리즘 사용하여 암호화

➰ 토큰기반 인증 절차

1. [Client → Server] ID/PW를 담아 로그인 요청
2. ID/PW가 일치하는지 확인, Client에게 보낼 암호화된 토큰 생성
   • Access/Refresh Token 모두 생성
3. Server가 Token을 Client에게 보내주면, 토큰 저장
   • 저장 위치: Local Storage, Session Storage, Cookie …
4. Client가 HTTP Header / Cookie에 토큰을 담아 보냄
   • Authorization Header 사용시 Bearer Authentication 이용
5. 서버는 토큰 해독 → 맞을 경우 클라이언트 요청 처리 → 응답 보내줌

➰ 토큰기반 인증 장점

1. 무상태성(Statelessness) & 확장성(Scalability)
   • [Server] 클라이언트에 대한 정보 저장 필요 ❌
   • [Client] 새로운 요청을 보낼 때마다 토큰을 헤더에 포함시킴
   • 같은 토큰으로 여러 서버에서 인증 가능!
2. 안전함
   • 암호화한 토큰 사용, 암호화 키 노출할 필요 없으므로 안전
3. 어디서나 생성 가능
   • 토큰을 확인하는 서버가 토큰을 생성하지 않아도 됨
4. 권한 부여 용이
   • 토큰 Payload 안에 어떤 정보에 접근 가능한지 정할 수 있음

---

☑️ OAuth 2.0

: 인증 중개 매커니즘으로, 보안된 리소스에 액세스하기 위해 클라이언트에게 권한(Authorization)을 제공하는 프로세스를 단순화하는 프로토콜

✋ 인증(Authentication)을 다른 서비스에 맡길 뿐, 접근 권한 관리(Authorization)는 서버 몫!

• Resource Owner: 액세스 중인 리소스의 User
• Client: 리소스 Owner를 대신하여 보호된 리소스에 액세스하는 애플리케이션
• Resource Server: 클라이언트 요청을 수락하고 응답할 수 있는 서버
• Authorization Server: Resource Server가 액세스 토큰을 발급받는 인증 서버
• Authorization Grant: 클라이언트가 액세스 토큰을 얻는 방법 의미 (즉, 자격 증명!)
• Authorization Code: 액세스 토큰 발급을 위한 코드
• Access Token: 보호 리소스에 액세스하는데 사용되는 인증 토큰 (credentials)
• Scope: 토큰 권한 정의 / 주어진 액세스 토큰 사용 → 액세스할 수 있는 리소스 범위

✎ Grant type: Client가 액세스 토큰을 얻는 방법

➰ Authorization Code Grant type: 먼저 Authorization code를 받아 액세스 토큰과 교환하는 방법

1. Resource owner가 client로 접근
2. Client가 Resource owner를 Authorization server로 리다이렉트
3. Resource owner의 액세스 권한 부여 요청
4. Authorization code 제공
5. Authorization code → Access token으로 교환
6. Client는 Access token을 통해 Resource에 액세스 가능
7. 액세스 토큰과 함께 API 요청을 보냄
8. Client가 요청한 리소스 전달

✋ Authorization code 절차를 거치는 이유는 보안성 강화에 목적이 있음!

👉 [Client] authorization code만 받아오고, [Server] Access Token 요청 진행

➰ Refresh Token Grant Type: 일정 기간 유효 시간이 지나서 만료된 액세스 토큰을 편리하게 다시 받아오기 위해 사용하는 방법

1. Refresh token을 통해서 새로운 액세스 토큰 요청
2. 새로운 액세스 토큰 반환
3. Client는 액세스 토큰을 통해 User의 Resource에 액세스 가능

---

☑️ [Pair] Auth Token

: 로그인 상태 유지 기능을 제공하는 간단 웹 앱을 JWT를 이용하여 구현해보기 🙌

👾 한번 다시 공부하고 다시 업로드하기!~!

---

토큰 넘 어렵다,, 아직도 제대로 이해 엑스 🥲