[TIL] 인증/보안

🙏🏻 인증 / 보안

💡 HTTP 무상태성
 - 서버는 클라이언트를 식별할 수 없음을 의미
 - 즉, 매번 새로운 인증을 해야하는 번거로움 발생
 
* 상태를 기억하는 방법
 ① 쿠키   ② 세션   ③ OAuth와 JWT

---

📍 HTTPS

 * HTTP
 - 인터넷에서 데이터를 주고받을 수 있는 통신 프로토콜

 * HTTPS
 - HTTP + Secure

  - HTTPS : Hyper Text Transfer Protocol Secure Socket layerd의 약자

  - HTTPS = HTTP over SSL(TLS) = HTTP over Secure

  - HTTP 요청을 SSL 혹은 TLS 알고리즘을 이용하여 HTTP 통신을 하는 과정에서 데이터를 암호화하여 전송

  - HTTP 프로토콜 내용을 암호화를 통해 보안성이 추가됨

  - 정확한 키가 없다면 노출이 되더라도 알 수 없음

---

 

 ① 인증서 : Certificate

 - 데이터 제공자 신원 보장 및 도메인 종속

 - 브라우저가 서버의 응답과 인증서를 확인할 수 있음

 - 데이터를 제공한 서버가 정말로 데이터를 보낸 서버인지 인증 및 확인하는 용도

 - 인증서 내용에 서버의 도메인 관련 내용이 있어서 데이터 제공자의 인증을 용이하게 함

 - 서버가 요청을 받는다면 인증서와 함께 응답을 전송함

 - 응답을 받은 클라이언트는 인증서에 작성된 도메인과 응답 객체에 작성된 도메인을 비교

 - 즉 우리가 Naver에 접속했을 때 해커가 정교하게 따라한 가짜 Naver가 아님을 보장

---

 ② CA 

 - 공인 인증서 발급 해주는 공인된 기간

 - 각 브라우저는 신뢰하는 CA의 정보를 가지고 있음 ( 브라우저 마다 인증서 차이 있음 )

 - 서버의 신원을 보장해주는 제 3자를 CA라고 함

 - 서버의 공개키와 정보를 CA의 비밀키로 암호화하여 인증서 발급함

 - 인증서는 CA의 비밀키로 암호화되어 있으므로 CA의 개인키로 복호화 가능함

---

 ③ 비대칭 키 암호화

 - 전혀 다른 키 한 쌍으로 암호화 및 복호화 진행 가능

 - 즉, A 키로 암호화 했다면 복호화 할 때는 A가 아닌 다른 키 필요

---

 ④ 암호화

 - 제 3자가 서버와 클라이언트가 주고받는 정보를 탈취할 수 없도록 하는 것

 - 서버와 클라이언트가 서로 합의한 방법으로 데이터를 암호화하여 주고받음

    → 제 3자에게 데이터가 탈취되어도 서로가 합의한 방법으로 데이터를 암호화하여 주고 받음

 - 클라이언트와 서버가 데이터를 암호화하여 주고받기 위해 비대칭키와 대칭키 방식 혼용해서 사용

💡 대칭키 방식

  : 양쪽이 공통의 비밀 키를 공유하여 데이터를 암호화 및 복호화 하는 것

   - 컴퓨터에 부담을 덜 주기 때문에 주로 사용

   - But 대칭키를 서로 주고 받는 과정에서 부터 정보가 탈취될 수 있음

      → 암호화의 유무와 관꼐없이 모든 데이터 복호화 가능

💡 비대칭키 방식

  : 각각 공개키와 비밀키를가지고 상대가 나의 공개키로 암호화한 데이터를 개인이 가진 비밀키로 복호화 하는 것

  - HTTPS가 주로 사용하는 방식

  - 중간에 대칭키가 탈취되어도 개인키 없이는 복호화할 수 없음

	대칭키	비대칭키
키관계	암호화 키 = 복호화 키	암호화 키 != 복호화 키
암호화 키	비밀 키	공개 키
복호화 키	비밀 키	개인 키

  ▸ 공개 키 ? 사람들에게 공개된 키이며 정보를 암호화 할 수 있음

  ▸ 비밀 키 ? 사용자만 알고 있는 암호를 풀 수 있는 키 

💡 TLS or SSL

  : 서버와 클라이언트 간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우른 프로토콜

---

🔹 클라이언트와 서버와의 통신 과정

 ▸ Hand Shake

 - 클라이언트와 서버가 서로를 확인

 - 서버는 클라이언트의 공개키 중의 하나를 전달함

 ▸ 비밀 키 생성

 - 클라이언트는 전달받은 공개키를 이용해서 서버와 키를 만들어 낼 임의의 정보를 암호화해서 전송

 - 서버는 클라이언트와 마찬가지로 임의의 정보를 암호화해서 전송

 - 서로 만들고 교환한 임의의 정보를 바탕으로 비밀키를 생성

 ▸ 상호 키 검증

 - 각자 생성한 키를 바탕으로 클라이언트가 테스트용 데이터를 만들어 낸 비밀 키로 암호화해서 전달

---

🔹 Java의 인증서 형식

 ▸ PKCS12 : Public Key Cryptographic Standards #12

  - 여러 인증서와 키를 포함할 수 있으며 암호로 보호된 형식

 ▸ JKS

  - PKCS12와 유사하며 독점 형식으로 Java환경으로만 제한됨

---

📍 Encryption : 암호화

  - 일련의 정보를 임의의 방식을 사용하여 다른 형태로 변환

      → 해당 방식에 대한 정보를 소유한 사람을 제외하고 이해할 수 없도록 알고리즘을 이용하여 정보 관리

shiftBy(content : "banana", offset : 2)   // dcpcpc
shiftBy(content : "dcpcpc", offset : -2)  // banana

  ▪️ shiftBy( )

  - 입력받은 문자열을 입력받은 숫자의 값 만큼 알파벳 순서를 건너뛴 문자로 변환하여 새로운 문자열 반환

  - 즉 ( a, 2 ) 라면 a 에서 두번의 알파벳을 건너 뛴 c가 반환됨

---

📍 Hashing

  - 어떠한 문자열에 임의의 연산을 적용하여 다른 문자열로 변환하는 것

  ① 모든 값에 대해 해시 값을 계산하는데 오래 걸리지 않아야 함

    - 해시 값을 해독하는데는 많은 시간을 걸리지만 해시 값을 만드는데는 오래 걸리지 않아야 함

    - 해시 값을 만드는데 30초가 걸리면 로그인하는데에도 최소 30초가 걸림

  ② 최대한 해시 값을 피해야 하며 모든 값은 고유한 해시 값을 가짐

  ③ 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 함 

🔸 Salt

 - 암호화 해야 하는 값에 어떤 별도의 값을 추가하여 결과를 변형하는 것

 ① 암호화만 해놓는다면 해시결과가 항상 동일

   - 해시된 값과 원래 값의 테이블을 레인보우 테이블로 만들어 decoding 해버리는 경우도 생김

 ② 원본 값에 임의로 약속된 별도의 문자열을 추가하여 해시 진행한다면 기존 해시값과 전혀 다른 해시 값 반환

   - 알고리즘이 노출 되더라도 원본 값을 보호할 수 있도록 하는 안전 장치가 됨

---

📍 Cookie

: 서버에서 클라이언트에 데이터를 저장하는 방법 중 하나 

 → 서버가 원하면 클라이언트에서 쿠키를 이용하여 데이터를 가져올 수 있음

  - 어떤 웹 사이트에 들어갔을 때, 서버가 일방적으로 클라이언트에 전달하는 작은 데이터

  - 서버가 웹 브라우저에 정보를 저장하고 불러올 수 있는 수단

  - 해당 도메인에 대해 쿠키가 존재하면 웹 브라우저는 도메인에게 http 요청시 쿠키를 함께 전달

 💡 서버는 쿠키를 통해 어떤 데이터를 저장하려고 할까 ?

    : 쿠키는 삭제하지 않는다면 사라지지 않는다 !

    → 장기간 저장해야 하는 옵션(ex. 로그인 상태 유지 등)을 저장하기에 적합

 💡 쿠키를 이용한 상태 유지

   - 서버는 클라이언트에 인증 정보를 담은 쿠키 전송  +  클라이언트는 전달받은 쿠키를 요청과 같이 전송

      = Stateless한 인터넷 연결을 Stateful 하게 유지 가능

---

🔹 Cookie의 옵션

  ▸ Domain

   : 서버와 요청의 도메인이 일치하는 경우 쿠키 전송

   - 도메인은 www.google.com과 같이 서버에 접속할 수 있는 이름 

      → 도메인은 포트번호(3000), 서브도메인 정보(www), 세부 경로(users/login)를 포함하지 않음

   - http://www.localhost.com:3000/users/login 이라고 하면 도메인은 localhost.com

---

  ▸ Path

   : 서버와 요청의 세부경로가 일치하는 경우 쿠키 전송

  - 세부 경로는 서버가 라우팅할 때 사용하는 경로

---

  ▸ MaxAge or Expires

   : 쿠키의 유효기간 설정

   - 쿠키가 영원히 남아있다면 그만큼 탈취되기도 쉬워지기 때문에 유효기간 설정하는 것은 보안 측면에서 중요

   - PC방에서 로그아웃을 안했을 때 서버에서 쿠키에 MaxAge or Expires 옵션을 통해 유효 기간 지정 → 일정 시간 후 자동 소멸

   - MaxAge : 앞으로 몇 초 동안 쿠키가 유효한지 설정

   - Expires : MaxAge와 비슷하지만 언제까지 유효한지 Date 지정 ( 클라이언트 시간 기준 )

       ▪️  세션 쿠키

      - MaxAge 또는 Expires 옵션이 없는 쿠키

      - 브라우저가 실행중일 때 사용할 수 있는 임시 쿠키

      - 브라우저가 종료되면 해당 쿠키는 삭제 됨

      ▪️  영속성 쿠키

      - 브라우저의 종료 여부와 상관없이 MaxAge / Expires에 지정된 유효시간만큼 사용 가능

---

  ▸ HttpOnly

   : 스크립트의 쿠키 접근 가능 여부 결정

   - 해당 옵션이 true이면 자바스크립트에서는 쿠키에 접근 불가 (기본값 false)

   - 스크립트 쿠키 접근을 막고 브라우저만 접근 가능하게 할 수 있음

   - 스크립트 태그로 접근 할 수 있는데 이 경우 XSS 공격에 취약함

---

  ▸ Secure

   :  HTTPS 프로토콜에서만 쿠키 전송 여부 결정

   - 쿠키를 전송할 때 사용해야 하는 프로토콜에 따른 쿠키전송 여부 결정

   - 해당 옵션이 true 라면 HTTPS만 가능

  - Secure 옵션이 없다면 HTTP, HTTPS 둘 다 가능

---

▸ SameSite

   : CORS (Cross-Origin) 요청을 받은 경우 사용한 메소드와 해당 옵션 (GET, POST, PUT, PATCH, .. )의 조합으로

     서버의 쿠키 전송 여부 결정

   - 같은 사이트에서만 쿠키를 사용할  수 있게 하는 설정

   - SameSite는 요청을 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 같은 경우를 말함

      → 이 중 하나라도 다르다면 Cross-Origin으로 구분함

    ① Lax : GET 메서드 요청에만 쿠키 전송 가능

    ② Strict : 쿠키 전송 불가

    ③ None : 모든 메서드 요청에 대해 쿠키 전송 가능

     → None 옵션은 Secure 쿠키 옵션과 HTTPS 프로토콜 사용해야 안전

---

📍Session

  - 서버가 클라이언트에 유일하고 암호화된 ID를 부여

  - 중요 데이터는 서버에서 관리

 💡 쿠키와 세션의 차이는 ?

   ▸ 쿠키

    - Http의 Stateless한 것을 보완해주는 도구

    - 저장 경로 : 클라이언트

    - 장점 : 서버에 부담을 덜어줌 (클라이언트에 저장하니깐)

    - 단점 : 쿠키 그 자체는 인증이 아님

  ▸ 세션

    - 접속 상태와 권한 부여를 위해 세션 아이디를 쿠키로 전송

    - 저장 경로 : 서버

    - 장점 : 신뢰할 수 잇는 유저인지 서버에서 추가로 확인 가능

    - 단점 : 하나의 서버에서만 접속 상태를 가지므로 분산 불리

---

🔸 세션 기반 인증 - 로그인

 : 인증에 따라 접근 권한이 달라짐

 - 서버 : 사용자가 인증에 성공했음을 알고 있어야 함

 - 클라이언트 : 인증 성공을 증명할 수단을 갖고 있어야 함

 

① 세션 : 사용자가 인증을 성공한 상태

 - 서버는 일종의 저장소에 세션을 저장함

② 세션 ID : 각 세션을 구분

 - 세션이 만들어지면 각 세션을 구분할 세션 아이디 생성됨

 - 보통 클라이언트에 세션 성공을 증명할 수단으로 세션 아이디 전달

③ 쿠키 사용 : 로그인을 유지하기 위한 수단으로 사용

 - 쿠키에는 서버에서 발급한 세션 아이디를 저장함

 

🔸 세션 기반 인증 - 로그아웃

 - 세션 아이디가 담긴 쿠키는 클라이언트에, 세션은 서버에 저장

 - 서버는 세션 아이디로만 인증 여부 판단

 - 서버 : 세션 정보를 삭제해야 함

 - 클라이언트 : 쿠키를 갱신해야 함

---

 💡 Web Application Security

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

---

📍 웹 보안 공격

👉🏻 SQL Injection

 : 데이터베이스에서 임의의 SQL문을 실행할 수 있도록 명령어를 삽입하는 공격

 - 응용 프로그램의 보안상의 허점을 이용하여 데이터베이스르 비정상적으로 조작

   → 이로 인해 기록이 삭제되거나 데이터 유출 가능

(1) 공격자가 악의적인 SQL문을 넣어 서버에 전송
(2) 서버에 해당 SQL문을 기존 SQL에 삽입해 데이터베이스에 쿼리를 보냄
    id = '{사용자 ID}'  → id = '{사용자 ID}' OR '1'='1'
(3) ID 검증 여부와 상관없이 '1' = '1'은 참이므로 모든 사용자 정보 반환
(4) 모든 사용자의 정보가 공격자에게 전송

---

 ▪️ SQL Injection 대응 방안

① 입력 (요청) 값 검증

 - 화이트 리스트 방식으로 해당 키워드가 들어오면 다른 값으로 치환

 ▸ 화이트 리스트 ? 기본 정책이 모두 차단인 상황에서 예외적으로 접근이 가능한 대상 지정

② Prepared Statement 구문 사용

 - Prepared Statement 구문을 사용하면 사용자의 입력이 SQL문으로부터 분리

 - 사용자의 입력 값이 전달되기 전에 DB가 미리 컴파일하여 SQL을 바로 실행하지 않고 대기

    → 사용자의 입력값을 단순 텍스트로 인식

③ Error Message 노출 금지

 - 공격자는 DB의 에러 메세지를 통해 테이블이나 컬럼 등의 정보를 얻을 수 있음

---

👉🏻 CSRF : Cross Site Request Forgery

 - 주소가 다른 사이트에서 요청을 조작하는 것

  → 이메일에 첨부된 링크를 누르면 은행 쪽으로 요청을 보내서 내 은행 계좌에 돈이 빠져나감

 - 해커가 직접 데이터를 접근할 수 없음

  → 다른 오리진이기 때문에 response에 직접 접근할 수 없음

오리진 : https://localhost.com:80
도메인 : localhost.com

---

▪️ CSRF가 작동하기 위한 조건 

① 쿠키를 사용한 로그인

 - 유저가 로그인 했을 때 쿠키로 어떤 유저인지 알 수 있어야 함

② 예측할 수 있는 요청, 파라미터를 가지고 있어야함

 - Request에 해커가 모를 수 있는 정보가 담겨있으면 X

---

▪️ CSRF를 막기 위해서는

① CSRF 토큰 사용

 - 서버측에서 CSRF 공격에 보호하기 위한 토큰 문자열을 유저의 브라우저와 웹 앱에만 제공

 - 이 조합으로만 생성된 요청에만 성공적으로 요청 처리해줌

② Same - Site Cookie 사용

 - 같은 도메인에서만 세션 / 쿠키 사용 가능

 - 같은 도메인에서 온 요청이 아니라면 받아주지 않음

---

👉🏻 XSS

 - 크로스 사이트 스크립팅 : XSS ( Cross Site Scripting )

 - 공격자가 상대방의 브라우저에 스크립트가 실행되도록 하여

    사용자의 세션을 가로채거나 웹사이트 변조, 악의적인 콘텐츠 삽입, 피싱 공격을 진행하는 것