[인증/보안] HTTP + 보안(Secure)

HTTPS

인증서(Certificate)

• 데이터 제공자 신원 보장
• 도메인 종속
• 기밀성 : 메세지 가로챌 수 없음
• 무결성 : 메세지를 수정할 수 없음

CA (Certificate Authority) 공인인증서 발급기관

• CA가 발급된 인증서를 이용하면 안전한 서버라는 것을 사용자에게 알려줄 수 있음
• 서버와 클라이언트 간의 CA를 통해 서버를 인증 과정 + 데이터 암호화 과정을 거치는데 이 프로토콜을 TLS라고 부름

대칭키 암호화

• 한개의 암호화, 복호화

비대칭 키 암호화

• 한 쌍의 키를 가지고 있다. ( 암호화, 복호화 )

통신 과정

• Hand Shake (탐색 과정)
  • -> To 서버에게 임의 문자 Hello
  • <- To 클라이언트에게 Hello, 공개키, 해당 서버의 인증서 정보 전달 (서버 인증서 검증)
  • 클라이언트는 서버 인증서를 CA 개인키를 사용해서 인증서 확인 (실패시 Not secure 경고)
  • 이로써 해당 서버가 CA 인증된 서버라는 것을 검증할 수 있음
  • 서버에서 보낸 공개키를 가지게 됨
• 비밀 키 생성 (세션 키 생성)
  • -> 키 제작용 랜덤 스트링 전송
  • <-키 제작용 랜덤 스트링 전송
  • 동일한 대칭키 생성
• 상호 키 검증 (HTTPS 연결 성립)
  • -> 세션 키로 암호화 된 메세지 전달
  • <- 세션 키로 암호화 된 메세지 전달

HTTPS 사설 인증서 발급 및 서버 구현

인증서 종류

• PKCS12 
  • public key cryptographic standards #12
  • 여러 인증서와 키를 포함할 수 있고, 암호로 보호된 형식
  • 업계에도 표준으로 사용
• JKS
  • Java환경에 제한됨

Ubuntu 사용

설치가 안될 경우 $ sudo apt update 명령어 실행 후 재시도

//mkcert 프로그램을 통한 내 local 환경 인증작업

$ sudo apt install libnss3-tools
$ wget -O mkcert https://github.com/FiloSottile/mkcert/releases/download/v1.4.3/mkcert-v1.4.3-linux-amd64
$ chmod +x mkcert
$ sudo cp mkcert /usr/local/bin/

// 해당 로컬을 인증된 발급기관으로 추가 
// CA 생성,설치
$ mkcert -install


// PKCS12 인증서 생성
$ mkcert -pkcs12 localhost

--> localhost.p12 파일 생성 완료


// localhost.p12 파일을 IDEA resources 폴더로 이동
// application.properties 설정
=================================================================================
server.ssl.key-store=classpath:localhost.p12    -> 인증서 경로
server.ssl.key-store-type=PKCS12                -> 인증서 형식
server.ssl.key-store-password=changeit          -> 인증서 비밀번호
=================================================================================

---

 

Hashing

Encrytion (암호화)

• 일련의 정보를 임의의 방식으로 다른 형태로 변환하여 소유한 사람을 제외한 사람이 알 수 없도록 하는 것
• public key & private key 는 한 쌍이다. 
• public key
  • 데이터 제공자의 신원을 보장함
  • 누구나 소유 가능
• private key
  • public key 소유자는 private key로 암호화된 서버에서 받은 데이터를 복호화가 가능 

Hashing 조건 

• Hash값 생성은 빠르고, 해독은 어렵고 오래 걸려야 함
• 모든 값은 고유한 hash 값을 가져야 함
• 혹여라도 같은 hash값이 생기지 않도록 하는 알고리즘 배포중
• 작은 단위의 변경이 있더라도 반환 되는 해시값은 완전히 다른 값을 가지도록 함 

대표적인 Hash 알고리즘

• SHA1
• SHA256 (대표) : 동일한 길이를 가짐

Salt

• hash 하기 전 Salt값을 추가해서 보안을 2차로 강화한 것
• 알고리즘 노출 방지 안전장치

Salt 조건

• 유저와 패스워드 별로 유일한 값을 가져야 함
• 사용자 계정을 생성하거나 비밀번호 변경시 새로운 Salt 값 부여
• Salt 재사용 금지
• Salt는 유저테이블에 같이 저장되어야 함

비대칭키 (= 공개키)

• 2개의 키 사용 ( A, B Key ) <-- 공개키 
• 개인키로 암호화 하면 공개키로만 풀 수 있다. = 전자 서명 
• 공개키로 암호화 하면 개인키로만 풀 수 있다 = 암호화
• 네이버 소유 (개인키)  / 대중에게 공개 (공개키)

 

---

쿠키 (CooKie)

서버는 클라이언트에게 인증 정보를 담은 쿠키를 전송, 클라이언트는 전달받은 쿠키를 요청과 함께 전송하여
Stateless 한 인터넷 연결을 Stateful하게 유지할 수 있다.

Cookie Options

• Domain : 서버와 요청 도메인이 일치할 경우 쿠키 전송
• Path : 서버와 요청 세부경로가 일치할 경우 쿠키 전송
• MaxAge or Expires : 유효 기간
  • Session cookie : 유효기간이 없고 브라우저가 실행 중일 때 사용할 수 있는 임시 쿠키로 브라우저 종료시 삭제됨
  • Persistent Cookie : 브라우저의 종료 여부와 관계없이 유효기간만큼 사용하는 쿠키
• HttpOnly : 스크립트의 쿠키 접근 가능 여부
  
  • true가 입력된 경우 -> 자바 스크립트에서 쿠키 접근 불가능 (default)
  • false가 입력된 경우 -> XSS 공격에 취약
• Secure : HTTPS 프로토콜에서만 쿠키 전송 여부
  
  • true가 입력된 경우 ->  HTTPS 프로토콜을 이용하는 경우에만 쿠키 사용 가능
  • false가 입력된 경우 -> 프로토콜 상관없이 쿠키 사용 가능
• SameSite : CORS 요청의 경우 메서드에 따라 쿠키 전송 여부
  • 같은 사이트에서만 쿠키를 사용할 수 있게하는 설정!?
  • CSRF 공격 방지
  • sameStie = '옵션'
    • Lax : 사이트가 달라도 Get 요청은 쿠키 전송 가능
    • Strict : 사이트가 다르면 쿠키 전송 불가
    • None : 모든 메서드 요청에 대해 쿠키 전송 가능 (Secure옵션 필수)

---

Session

클라이언트가 로그인을 통해 인증을 성공 (성공한 상태 = session)

• 서버에서 저장소에 세션을 저장하고 쿠키에 세션아이디(암호화)를 만든것을 포함해서 클라이언트에게 전달
• 암호화된 세션아이디로 작업을 수행하면 서버에서 세션아이디를 DB와 일치하는지 확인 후 일치하면 업데이트

로그아웃 

• 서버 : 세션 정보 삭제
• 클라이언트 : 쿠키 갱신

---

SQL Injection

웹 해킹의 강력한 공격

• 데이터 베이스에서 임의의 SQL문을 실행할 수 있도록 명령어 삽입하는 공격 유형
• 데이터 베이스를 비정상적으로 조작하여 기록을 삭제하거나 유출

대응 방안

• 입력값 검증 : 화이트 리스트 방식 사용
  
  • * 블랙리스트 * : 자동 거부 항목
  • * 화이트 리스트* : 기본 정책이 차단인 상황에서 예외로 접근 가능한 대상을 지정한 항목
• Prepared Statement
  • 사용자의 입력을 SQL문과 분리
• Error Message 노출 금지
  • Error Message를 통해 데이터 베이스의 정보를 얻을 수 있으므로 노출을 금지

 

CSRF (Cross Site Request Forgery)

• 다른 오리진에서 유저가 보내는 요청을 조작하는 것
  • ex) 이메일 첨부된 링크를 누르면 내 은행계좌 돈 인출... ㅠㅠ
• 해커가 직접 데이터에 접근할 수 없다 (다른 오리진이기 때문에)

공격 조건

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

방어 조건

• CSRF 토큰
  • 보호용 토큰 문자열 유저의 브라우저와 웹 앱에만 제공
• Same-site cookie
  • 같은 도메인에서만 세션/쿠키를 사용 가능