Spring Security 기본

0. 시작하게 된 계기 및 다짐 😮

• 이번 코드스테이츠의 백엔드 엔지니어링 개발자 부트캠프에 참여하게 되면서 현직개발자 분들의 빠른 성장을 위한 조언 중 자신만의 블로그를 이용하여 배운 것 들을 정리하는게 많은 도움이 된다 하여 시작하게 되었다.

  • 그 날 배웠던 것을 길지 않아도 좋으니 정리하며 복습하는 습관 기르기
  • 주말에 다음주에 배울 내용들을 예습
  • 코딩 문제와 java코드들은 꾸준히 학습
  • 자료구조를 이용한 알고리즘 문제 해결 학습

1. 학습 목표 😮

목표	결과
API 문서화 이해	O
Spring Rest Docs와 Swagger의 차이점 및 사용법 이해	O
Spring Rest Docs를 위한 기본 설정 및 사용 방법을 이해	O
Spring Rest Docs를 사용해서 API 문서를 생성 및 배포	O

2. 정리 😮

Extra 알아두기

1. Restful API

• 자원을 이름(표현)으로 구분하여 자원의 상태(정보)를 주고받는 것을 의미하며 웹의 기존기술과 HTTP프로토콜을 그대로 이용하여 웹의 장점을 최대한 활용한 아키텍처.
• www와 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처
  URI를 통해 자원을 명시하고 HTTP 메소드를 통해 자원에 대한 CRUD Operation을 적용

2. 무상태성

• 시스템이 현재의 상태를 나타내는 데이터를 보유하지 않고, 단지 입력 내용에 따라 내용이 결정되는 방식.
• 즉, 같은 입력에 대하여는 언제나 같은 출력을 지님

---

HTTPS

---

Ⅰ. HTTPS

• HTTP + Sercure(SSL, TLS)
• SSL,TLS : 클라이언트 서버간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우른 프로토콜
• HTTP 프로토콜 내용을 암호화
• 브라우저(chrome, explore, firefox등)에 CA들의 목록이 내장되어 있음

1. HTTPS 특징

0. 접속과정
   1). browser와 Server handShake을 통해 클라이언트는 서버에게 랜덤 스트림을 생성해서 보내고 서버에서도 마찬가지로 무작위 데이터를 보내며 함께 인증서를 보낸다.

   2). 브라우저에 내장된 CA목록에 저장된 해당 브라우저의 공개키로 이 인증서 내부에 CA의 비밀키로 내장된 공개키를 암호화 하여 성공하면 인증완료

   3). 이후 클라이언트쪽에서 주고 보냈던 스트림을 혼합하여 임시 키를 만들고 이 임시키를 서버의 공개키로 암호화하여 서버로 보냄

   4). 이후 서버에서 이 임시키를 개인키로 복호화하면 양쪽에 임시키가 생기는데, 이 임시키를 일련의 과정을 거쳐 공개키로써 사용한다.
   

1. 인증서
   • 데이터 제공자 신원보장, 도메인 종속
   • 서버와 함께 전달된 인증서를 확인가능
   • 이를 보증하는 제 3자를 CA라고 부름

2. CA
   • 공인 인증서 발급 기관
   • Certificate Authority
   • 서버의 공개키와 정보를 CA의 비밀키로 암호화하여 인증서를 발급
   • 비대칭 키 암호화
   (1) A키로 암호화 -> B키로만 복호화 가능 (A,B의 한쌍으로 한키는 비밀키, 한키는 클라이언트에게 공개키로 제공

3. 비대칭/대칭 키 암호화

   1). 대칭 키

   • 양쪽이 공통의 비밀 키를 공유하여 데이터를 암호화 및 복호화 하는 것
   • 비 대킹키에 비해 알고리즘이 간단하여 자주 사용하지만 보안이 좀 더 취약
   • 대칭키를 주고 받을 때만 비대칭키 방식으로 주고 받음

   2). 비대칭(공개 키) 키

   • 각각 공개키와 비밀키를 가지고 상대가 나의 공개키로 암호화한 데이터를 개인이 가진 비밀키로 복호화
   • 좀더 알고리즘이 복잡하지만 보안이 강하다

2. 두가지 인증서 형식

0. mkcert라는 프로그램을 이용하여 로컬환경 내에서 신뢰 인증서 생성가능

   • PKCS12형식만 지원

1. PKCS12 : 여러 인증서와 키를 포함, 암호로 보호된 형식

2. JKS : PKCS12와 유사하며, java환경으로 제한됨

---

Hashing, Cookie, Sessoin

---

Hashing

1. Hashing

• 알고리즘을 이용한 암호화 방식
• SHA-256알고리즘의 출력값의 길이는 언제나 동일
• 1). 모든 값에 대해 해시 값을 계산하는데 오래걸리지 않아야한다.
• 2). 최대한 해시 값을 피해야 하며, 모든 값은 고유한 해시값을 가진다.
• 3). 아주 작은 단위의 변경이라도 완전히 다른 해시값을 가져야한다.

2. Salt

• 암호화해야 하는 값에 어떤 '별도의 값'을 추가하여 결과를 변형한 것
• 원본값 + '별도의 문자열'(Salt) 하여 Hasing
• 해싱 알고리즘이 노출되더라도 원본 값을 보호할 수 있는 안전장치
  1). Salt는 유저와 패스워드 별로 유일한 값을 가져야 한다.
  2). 계정을 생성하고 비밀번호를 변경할 떄마다 새로운 임이의 Salt를 사용해서 해싱필요
  3). Salt는 절대 재사용하지 않아야한다.
  4). Salt는 DB의 유저테이블에 같이 저장되어야 한다.

---

Cookie

1. Cookie

• 서버에서 클라이언트에 데이터를 저장하는 방법 중 하나
• 쿠키는 클라이언트 로컬에 저장되는 Key-Value쌍의 작은 데이터 파일입니다.
• 웹사이트에 들어갔을 때, 서버가 일방적으로 클라에 전달하는 작은 데이터
• 서버가 웹 브라우저에 정보를 저장하고 불러올 수 있는 수단
• 저장된 쿠키는 서버에 요청시마다 클라이언트에서 서버로 자동으로 전송됨
• 삭제하지 않으면 사라지지않음 -> 장기간 보존해야한느 정보 저장에 적합(로그인 상태유지, 테마, 선호등)

2. Cookie 옵션

• Domain : 서버와 요청의 도메인이 일치하는 경우 쿠키 전송
• Path : 서버와 요청의 세부경로가 일치하는 경우 쿠키 전송
• MaxAge or Expires : 쿠키의 유효기간 설정(몇 초동안 or 몇일까지)
  (1) 세션 쿠키 : MaxAge, Expires가 없는 옵션 쿠키로, 브라우저가 실행중일 때만 사용하는 쿠키, 브라우저 종료시 사라짐
  (2) 영속성 쿠키 : 브라우저의 종료 여부와 상관없이 MaxAge or Expires에 지정된 유효시간만큼 사용가능한 쿠키
• HttpOnly : 스크립트의 쿠키 접근 가능 여부 설정
• Secure : HTTPS 프로토콜에서만 쿠키 전송 여부결정
• SameSite : CORS 요청의 경우 옵션 및 메서드에 따라 쿠키 전송 설정
  Lax : GET메서드 요청만 쿠키 전송 가능
  Strict : 쿠키 전송 불가, sameSite만 가능
  None : 모든 메서드 요청에 대해 쿠키 전송 가능, Secure 옵션이 필요)

---

Sessoin

1. Session

• 서버가 Client에 유일하고 암호화된 ID를 부여
• 쿠키에는 해당 데이터에 대한 ID만 암호화하여 부여
• 중요 데이터는 서버에서 관리
• 해당 DB를 대표하는 코드 같은 개념
• 쿠키와 달리 접속 상태 저장경로가 서버에 있음
• 단점으로는, XSS 공격으로 마찬가지로 쿠키정보를 탈취당하면 해당 세션ID를 도둑맞음
• 따라서, 서버의 세션정보를 삭제하고 클라이언트의 구키를 갱신하여 정보를 지워야함
  (서버가 클라이언트쪽에 무의한 키값을 전달하여 갱신)

---

Extra

1. same-site 와 same-origin 차이

• https://en.wikipedia.org/wiki/Same-origin_policy

---

SQL Injection

---

1. SQL Injection

1. SQL Injection

• DB에서 임이의 SQL문을 실행할 수 있도록 명령어를 삽입하는 공격 유형
  [ Ex. 비밀번호에 OR '1' = '1'] 과같은 것을 넣으면
  SELECT * FROM users WHERE auth='admin' AND id='' OR '1'='1'; 로 무조건 참이 되기 때문에

2. 대응방안

• 입력(요청)값 검증 : 화이트 리스트 방식으로 해당 키워드가 들어오면 다른 값으로 치환하여 SQL Injection에 대응
  (Ex. 화이트리스트 : 기본 정책이 모두 차단인 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식)
• Prepared Statement구문 : 사용자의 입력이 SQL문으로부터 분리되어 SQL Injection을 방어
• Error Message 노출금지 : 에러가 발생한 SQL문과 에러 내용이 클라에 노출되지 않도록 별도의 에러핸들링
  에러 메시지를 통해 DB정보를 얻을 수 있기 떄문에

3. Cross-Site Request Forgery(CSRF)

• 다른 사이트에서 유저가 보내는 요청을 조작(forgery)하는 것
  [ 이메일에 첨부된 링크를 누르면 내 은행계좌의 돈이 빠져나감 ]
• 해커가 직접 데이터를 접근할 수 없다.
  [response에 직접 접근불가]

1). Web application Security

• 개발자들이 해커들의 공격(SQL Injection, XSS, CSRF)을 막기위한 보안

2). 공격을 하기 위한 조건

• 쿠키를 사용한 로그인 (쿠키로 어떤 유저인지 확인)
• 예측할 수 있는 요청/parameter를 가지고 있음

3). 방지 방법

• CSRF 토큰 사용하기 (서버측에서 CSRF 공격에 보호하기위한 문자열을 유저의 브라우저와 웹 앱에만 제공)
• Same-site Cookie 사용 (같은 도메인에서만 세션/쿠키 사용)

---

3. 피드백 😮

• 기본적으로 Stateless(무상태성)을 유지하는 HTTPS란 HTTP에서 Security를 추가하여, 클라이언트-서버간에 CA를 통해 인증서를 발급받아 인증하는 과정과 데이터를 암호화하는 프로토콜을 말한다.
  
  
  
• Hashing이란, 알고리즘을 통한 암호화 방식을 말하며, Salt(Secret)값을 추가하여 제 3자가 해독을 하지못하게 만드는 방식
  
  
  
• Cookie란, HTTPS 가 무상태성이기에 서버에서 클라이언트의 PC에 데이터를 저장하는 방법 중 하나이다. 일반적으로, 사용자의 인증이나 기타 정보를 유지하기 위해 사용하고 "쿠키는 서버의 자원을 사용하지 않음"
  
  
  
• Session이란, 서버가 클라이언트에 유일하고 암호화된 ID를 부여하고 중요한 데이터는 서버에서 관리하며, 클라이언트는 이 ID를 통해 서버에 접속하여 요청을 하는 개념이다. "Session은 서버의 자원을 사용하며, 데이터량이 많아지면 서버 속도가 느려짐"

4. 앞으로 해야 될 것 😮

• 매일 꾸준히 할 것
  • 꾸준히 velog 작성
  • Java 언어 및 Algorithm 공부(Coding-Test)
  • 틈틈히 운동 하기

---

• 내일 해야 할 것
  • Spring Security 기본