2023/01/12 TIL | 인증/보안 기초

💭 오늘의 학습 전략

# HTTPS

◼️HTTP와 HTTPS

◼️인증서

◼️CA

◼️비대칭키 암호화

◻️ TSL & SSL

◻️ 실습: 인증서 발급 및 HTTPS 서버 구현

# Hashing

　◾hashing

　◾암호화 알고리즘

　◽salting

# Cookie

　◾Set-Cookie

　◾쿠키 옵션

# Session

　◾Cookie와 Session

# 웹 보안 공격

　◾SQL Injection

　◾CSRF

🌼 학습한 것들

◾인증과 인가

　▪️ 인증 (Authentication)

　　- 사용자 신원 확인

　▪️ 인가 (Authorization)

　　- 인증을 끝낸 사용자의 권한 확인

　　- 인증되었다고 해서 모두 인가되는 것은 아님

◾ HTTPS 특징

　▪️ 인증서 (Certificate)

　　- 데이터 제공자 신원 보장

　　- 인증서 내 도메인 관련 정보 -> 인증 용이

　　- 1. 서버 -> 클라이언트 CA 발급 인증서 전달

　　- 2. 클라이언트: OS 또는 브라우저에 내장된 CA 리스트를 통해 인증된 CA의 인증서인지 확인

　　- 3-1. 인증된 CA의 인증서가 아니라면 경고창

　　- 3-2. 확인 되었다면 서버 인증서 복호화(CA 공개키)

　▪️ CA (Certificate Authority)

　　- 인증서 보증해주는 제 3자 (인증서 발급 공인된 기관)

　　- 각 브라우저는 신뢰하는 CA 정보를 가지고 있다

　▪️ 비대칭 키 암호화

◾ HTTPS 연결 과정

　▪️ HTTPS는 대칭키, 비대칭키 방식을 모두 이용해 데이터를 암호화 한다

◾ TLS 또는 SSL (표준화 -> 이름 변경)

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

◾ 자바가 지원하는 인증서 형식

　▪️ PKCS12(Public Key Cryptographic Standards)

　　- mrcert(: 인증서 발급 프로그램) 지원 형식

　▪️ JKS(Java KeyStore)

◾ Hashing

◾ Cookie 특징

　▪️ 서버가 웹 브라우저에 정보를 저장하고 불러올 수 있도록 클라이언트에 일방적으로 전달하는 데이터

　▪️ 해당 도메인에 쿠키가 존재하면 http 요청 시 자동으로 쿠키 전달

　▪️ 삭제하지 않으면 사라지지 않는 성질 -> 로그인 상태 유지, 장바구니 등

　▪️ 인증 정보는 암호화(해싱)된 내용으로 저장

◾ Cookie 전달 방법

◾ Cookie 옵션

　▪️ 아무 때나 쿠키 정보를 가져올 수 없고, 특정 조건을 만족할 때.

　▪️ Domain: 서버 도메인과 요청 도메인 일치해야

　　- ex) naver.com

　▪️ Path: 요청 세부 경로가 일치해야

　　- ex) Path: /users, 요청: /users/info

　▪️ MaxAge or Expires: 쿠키 유효기간. 앞으로 몇 초 or 언제까지(Date)

　　- 세션 쿠키: 옵션x 브라우저 실행 중에 사용하는 임시 쿠키, 종료하면 삭제

　　- 영속성 쿠키: 지정된 유효시간만큼 사용

　▪️ Secure: true면 HTTPS 프로토콜에서만 전송 가능

　▪️ SameSite:

　　- Lax: Cross-Origin 요청이면 GET만

　　- Strict: same-site만

　　- None: 항상(Secure 옵션 필요)

stateless -> stateful

◾ Session

　▪️ 서버가 클라이언트에 유일하고 암호화된 ID를 부여, 중요 데이터는 서버에서 관리

　▪️ 전달 방법

　▪️ 로그아웃: 서버가 쿠키 임의 삭제 불가능. Set-Cookie로 무효한 값 갱신할 수 있다

　　- 서버: 세션 정보 삭제

　　- 클라이언트: 쿠키 갱신

　▪️ 단점

　　- 서버 이용자가 많으면 가용 메모리가 줄어 성능 줄어듦

　　- XSS -> 탈취 위험 존재

◾ 웹 보안 공격

　▪️ SQL Injection: 명령문 삽입으로 임의의 SQL문 실행

　　- ex) 'OR '1'='1을 넣으면 해당 쿼리가 무조건 실행될 수 있다

　　  　  '; DROP TABLES users; --' 해버리면 테이블 삭제 당할 수 있다

　　- 대응 방안

　　  1. 요청값 검증 (화이트 리스트)

　　  2. Prepared Statement 구문 사용 (입력값을 단순 텍스트로 인식)

　　  3. Error Message 노출 금지 (별도의 에러 핸들링 필요)

　▪️ CSRF (Cross-Site Request Forgery: 다른 사이트/요청/조작)

　　- ex) 링크 누르면 계좌 출금

　　- 공격 조건

　　  1. 쿠키를 사용한 로그인 (쿠키로 어떤 유저인 지 알 수 있을 때)

　　  2. 예측 가능한 요청 파라미터 가져야 함. 비밀번호 입력 재요청 -> 몰라... 실패

　　- 대응 방안

　　  1. CSRF 토큰 사용

　　  2. Same-Site Cookie 사용하기

🔥 보충이 필요한 것들

◾ Same-Site와 Same-Origin

 

 

💨 하루를 마치며

1. 실습 신기했다. 근데 설치하는데 좀 헤매서 시간을 많이 썼다.ㅠ

2. 나만 내용이 많다고 생각한 걸까..../...???!!

3. 시큐리티 열심히 해보자...🥹