📌 HTTPS

• 인증서(Certificate)
  • 데이터 제공자 신원 보장
  • 도메인 종속
• CA (Certificate Authority)
  • 공인 인증서 발급 기관
• 비대칭 키 암호화
  • A키로 암호화 → B키로만 복호화 가능

HTTPS 목적

• 암호화
  • 대칭키와 비대칭키 방식을 이용해 데이터를 암호화한다.
• 인증서
  • 서버가 CA의 비밀키로 암호화한 인증서를 전달하면 클라이언트는 해당 CA 기관의 공개키로 서버 인증서를 복호화한다.
  • 서버와 클라이언트 간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우른 프로토콜을 TLS 또는 SSL이라고 말한다.

인증서 발급 및 HTTPS 서버 구현

자바는 다음과 같은 두 가지의 인증서 형식을 지원

1. PKCS12 (Public Key Cryptographic Standards #12) : 여러 인증서와 키를 포함할 수 있으며, 암호로 보호된 형식.
2. JKS (Java KeyStore) : PKCS12와 유사. 독점 형식이며 Java 환경으로 제한된다.

인증서 생성

$ brew install mkcert
$ brew install nss  # firefox를 사용할 경우 필요에 따라 설치

$ mkcert -install

$ mkcert -pkcs12 localhost

HTTPS 서버 작성

1. 생성된 인증서를 resources 폴더로 이동
2. application.properties 에서 관련 설정을 추가

server.ssl.key-store=classpath:localhost.p12  #  -> 인증서 경로
server.ssl.key-store-type=PKCS12              #  -> 인증서 형식
server.ssl.key-store-password=changeit        #  -> 인증서 비밀번호

# 여기서 비밀번호인 changeit은 비밀번호를 설정하지 않았을 때의 기본값

📌 Hashing

해싱

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

1. 모든 값에 대해 해시 값을 계산하는데 오래걸리지 않아야 한다.
2. 최대한 다른 해시 값을 피해야 하며, 모든 값은 고유한 해시값을 가진다.
3. 아주 작은 단위의 변경이 있더라도 반환되는 해시값은 완전히 다른 값을 가져야 한다.

• 대표적인 해시 알고리즘 : SHA1, SHA256

Salt

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

1. 암호화만 해놓는다면 해시된 결과가 늘 동일

   해시된 값과 원래 값을 테이블(레인보우 테이블)로 만들어서 decoding 해버리는 경우도 생긴다.

2. 원본값에 임의로 약속된 ‘별도의 문자열’을 추가하여 해시를 진행한다면 기존 해시값과 전혀 다른 해시값이 반환되어 알고리즘이 노출 되더라도 원본값을 보호할 수 있도록 하는 안전장치

3. 기존 : (암호화 하려는 값) ⇒ (hash 값)

   Salt 사용 : (암호화 하려는 값) + (Salt용 값) ⇒ (hash 값)

• Salt 사용시 주의점
  • Salt는 유저와 패스워드 별로 유일한 값을 가져야 한다.
  • 사용자 계정을 생성할 때와 비밀번호를 변경할 때마다 새로운 임의의 Salt를 사용해서 해싱해야 한다.
  • Salt는 절대 재사용하지 말아야 한다.
  • Salt는 DB의 유저 테이블에 같이 저장되어야 한다.

📌 Cookie

쿠키는 서버에서 클라이언트에 데이터를 저장하는 방법의 하나

Cookie Options

서버는 데이터를 저장한 이후 특정 조건들이 만족하는 경우에만 다시 가져올 수 있다.

1. Domain

2. Path

3. MaxAge or Expires

MaxAge는 앞으로 몇 초 동안 쿠키가 유효한지, Expires 언제까지 유효한지 Date를 지정한다.

• 쿠키는 위 옵션의 여부에 따라 세션 쿠키(Session Cookie)와 영속성 쿠키(Persistent Cookie)로 나눠진다.
  • 세션 쿠키: MaxAge 또는 Expires 옵션이 없는 쿠키로, 브라우저가 실행 중일 때 사용할 수 있는 임시 쿠키. 브라우저를 종료하면 해당 쿠키는 삭제된다.
  • 영속성 쿠키: 브라우저의 종료 여부와 상관없이 MaxAge 또는 Expires에 지정된 유효시간만큼 사용가능한 쿠키.

4. Secure

5. HttpOnly

• true로 설정된 경우, 자바스크립트에서는 쿠키에 접근이 불가
• 명시되지 않는 경우 기본으로 false로 지정되어 있다. → ‘XSS’ 공격에 취약하다.
  

6. SameSite

Cross-Origin 요청을 받은 경우 요청에서 사용한 메소드와 해당 옵션(e.g. GET, POST, PUT, PATCH
…)의 조합으로 서버의 쿠키 전송 여부를 결정

• 사용 가능한 옵션
  • Lax :Cross-Origin 요청이면 'GET' 메소드에 대해서만 쿠키를 전송할 수 있다.
  • Strict : Cross-Origin이 아닌 same-site 인 경우에만 쿠키를 전송 할 수 있다.
    • same-site는 요청을 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 같은 경우를 말한다. 이 중 하나라도 다르다면 Cross-Origin으로 구분된다.
  • None: 항상 쿠키를 보내줄 수 있다. 다만 쿠키 옵션 중 Secure 옵션이 필요.

💡 쿠키의 특성을 이용하여 Stateless 한 인터넷 연결을 Stateful 하게 유지할 수 있다.

📌 Session

세션기반 인증 (Session-based Authentication)

• 사용자가 인증에 성공한 상태는 세션이라고 부른다.
• 세션 아이디가 담긴 쿠키는 클라이언트에 저장되어 있으며, 서버는 세션을 저장한다. 서버는 그저 세션 아이디로만 인증 여부를 판단한다.
  

📌 웹 보안 공격

SQL injection(SQL 삽입)

대응 방안

• 입력(요청) 값 검증 화이트리스트 방식으로 해당 키워드가 들어오면 다른 값으로 치환

  화이트리스트?
  기본 정책이 모두 차단인 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식 또는 그 지정된 대상들

• Prepared Statement 구문 사용
  • 사용자의 입력 값이 전달 되기 전에 데이터베이스가 미리 컴파일하여 SQL을 바로 실행하지 않고 대기하며, 사용자의 입력값을 단순 텍스트로 인식
• Error Message 노출 금지
  • Error Message를 통해 테이블이나 컬럼 등 데이터베이스의 정보를 얻을 수 있기 때문

Cross-Site Request Forgery(CSRF)

• 다른 사이트(cross-site)에서 유저가 보내는 요청(request)을 조작(forgery)하는 것
• CSRF 공격을 하기 위한 조건
  • 쿠키를 사용한 로그인
  • 예측할 수 있는 요청/parameter를 가지고 있어야 함
• CSRF를 막는 방법
  • CSRF 토큰 사용하기
    • 서버측에서 CSRF 공격에 보호하기 위한 문자열을 유저의 브라우저와 웹 앱에만 제공
  • Same-site cookie 사용하기
    • 같은 도메인에서만 세션/쿠키를 사용할 수 있다.