SEB_BE 60일차 - [인증/보안] 기초

💡 오늘의 학습목표

• HTTPS
• Hashing
• Cookie
• Session
• 웹 보안 공격

📔 HTTPS

• HTTP + Secure : HTTP 프로토콜 내용을 암호화하여 보안성 추가
• 요청의 내용을 암호화시켜 보안
• 인증서 / CA / 비대칭 키 암호화 방식 이용

📖 인증서 (Certificate)

• 데이터 제공자 신원 보장
• 도메인 종속
• 요청을 받으면 서버는 인증서와 함께 응답을 전송 -> 응답을 받은 클라이언트는 인증서에 작성된 도메인과 응답 객체에 작성된 도메인 비교

📖 CA (Certificate Authority)

• 공인된 인증서 발급 기관

📖 HTTPS : 비대칭 키 암호화

• 전혀 다른 키 한쌍으로 암호화, 복호화 진행
  

📖 HTTPS ?

• HTTP over SSL(TLS), HTTP over Secure
• HTTP 요청을 SSL 또는 TLS 라는 알고리즘을 이용해 통신 과정에서 데이터를 암호화하여 전송하는 방법

• 목적
  • 암호화
    • 비대칭키와 대칭키 방식을 혼용하여 사용
  • 인증서
    • 서버의 신원 보증 (이를 보증할 수 있는 제 3자를 CA라고 함)
      인증서가 CA의 비밀키로 암호화되어 CA의 공개키로 복호화 가능하다.

📜 인증서 발급 및 HTTPS 서버 구현

• 사설 인증서 발급 및 서버 구현
• 자바가 지원하는 인증서 형식
  • PKCS12(Public Key Cryptographic Standards #12) : 여러 인증서와 키 포함 가능, 암호로 보호된 형식. 가장 널리 사용
  • JKS (Java KeyStore) : 유사함, 독점 형식이며 Java환경으로 제한

• mkcert 라는 프로그램을 이용하여 로컬환경에서 신뢰할 수 있는 인증서 만들 수 있다.(PKCS12형식만 지원)
• 윈도우 사용자 설치 (Ubuntu)

$ 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/

• 인증서 생성
  • 로컬을 인증된 발급기관으로 추가

$ mkcert -install

• CA가 생성되고 설치되면 PKCS12 형식 인증서를 생성 가능

  $ mkcert -pkcs12 localhost

• 생성된 인증서 (우분투 파일) 를 애플리케이션 resource 폴더로 이동
• 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

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

• 암호화만 해놓는다면 해시된 결과가 늘 동일함.
  해시된 값과 원래 값을 테이블(레인보우테이블)로 만들어서 decoding 하는 경우도 생김

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

• 기존 : 암호화 하려는 값 -> 해시값
  salt사용 : 암호화 하려는 값 + salt용 값 -> 해시값

• Salt 사용시 주의사항

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

• shiftBy 메서드 : 인자로 문자열과 숫자 전달 -> 입력받은 숫자의 값만큼 알파벳 순서를 건너뛴 문자열로 변환하여 새로운 문자열 반환

📔 Cookie

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

• 서버가 클라이언트에 데이터를 저장할 수 있다.

• 데이터를 저장한 이후 특정 조건들이 만족하는 경우에만 다시 가져올 수 있다. (쿠키 옵션)

  • Domain
    쿠키 옵션에서 도메인은 포트 및 서브 도메인 정보, 세부 경로 포함 x
    localhost.com 같이 쿠키 옵션에서 도메인 정보가 존재하면 클라이언트에서는 쿠키의 도메인 옵션과 서버의 도메인이 일치해야만 쿠키 전송 가능
  • Path
    세부 경로는 서버가 라우팅할 때 사용하는 경로 /users/login 같이
    설정된 path를 전부 만족하는 경우 요청하는 path가 추가로 더 존재해도 쿠키를 서버에 전송 가능하다.
  • MaxAge or Expires
    쿠키가 유효한 기간을 정하는 옵션 ( 옵션에 따라 세션, 영속성 쿠키로 나누어짐)
    MaxAge : 몇 초
    Expires : Date를 지정
    • 세션쿠키 : 옵션이 없는 쿠키로, 브라우저 종료시 쿠키 삭제
    • 영속성 쿠키 : 브라우저의 종료 여부와 상관없이 옵션에 지정된 유효시간만큼 사용 가능
  • Secure
    쿠키를 전송해야 할 때 사용하는 프로토콜에 따른 쿠키전송 여부 결정
    true로 설정 시 HTTPS 프로토콜 이용하는 경우에만 쿠키 전송 가능
  • HttpOnly
    자바스크립트에서 브라우저의 쿠키에 접근 여부 결정
    true 설정 시, 자바스크립트에서는 쿠키에 접근 불가
    기본값 false ( XSS 공격에 취약해짐 )
  • SameSite
    Cross-Origin 요청을 받은 경우 요청에서 사용한 메소드와 해당 옵션(GET,POST,...)의 조합으로 서버의 쿠키 전송 여부 결정
    • Lax : Cross-Origin 요청이면 GET 메소드에 대해서만 쿠키 전송 가능
    • Strict : Cross-Origin이 아닌 same-site인 경우에만 쿠키 전송 가능
    • None : 항상 쿠키 전송 가능, 다만 옵션중 Secure 옵션 필요
  • same-site는 요청을 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 같은 경우

📔 Session

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

• 로그인 시 성공했다면 서버는 인증에 성공했다고 판단, 다음번에 인증을 필요로 하는 작업을 요청 시 매번 로그인할 필요가 없다.

• 인증에 따라 리로스의 접근 권한이 달라진다.

  • 서버는 사용자가 인증에 성공했음을 알고 있어야 한다.
  • 클라이언트는 인증 성공을 증명할 수단을 갖고 있어야 한다.

• 사용자가 인증에 성공한 상태는 세션이라고 한다.

  • 서버는 일종의 저장소에 세견을 저장, 주로 in-memory, 또는 세션 스토어에 저장
  • 세션이 만들어지면 각 세션을 구분하는 세션 아이디도 만들어진다. 클라이언트에서 세션 성공을 증명할 수단
    ->웹사이트에서 로그인을 유지하기 위한 수단으로 쿠키 사용(쿠키에는 발급한 세션 아이디 저장)

• 로그아웃
  쿠키는 세션아이디, 인증 성공에 대한 증명을 갖고 있으므로 탈취될 경우 서버는 해당 요청이 인증된 사용자의 요청이라고 판단.
  • 서버 : 세션 정보를 삭제
  • 클라이언트 : 쿠키를 갱신해야함.

서버가 클라이언트의 쿠키 임의 삭제는 불가 ,대신 set-cookie로 클라이언트에게 쿠키 전송 시 세션 아이디 키 값을 무효한 값으로 갱신 가능

---

📔 웹 보안 공격

📖 SQL Injection (SQL 삽입)

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

• 대응 방안
  • 입력(요청) 값 검증
    화이트리스트 방식으로 해당 키워드가 들어오면 다른 값으로 치환아여 대응
    • 화이트리스트 : 기본 정책이 모두 차단인 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식 또는 지정된 대상
  • prepared Statement 구문 사용
    구문 사용시 사용자의 입력이 SQL문으로 분리되어 방어 가능, 사용자의 입력 값을 단순 텍스트로 인식
  • Error Message 노출 금지
    에러가 발생한 SQL문과 에러 내용이 클라이언트에 노출되지 않도록 별도의 에러 핸들링 필요

📖 CSRF(Cross-Site Request Forgery)

• 다른 사이트(cross-site)에서 유저가 보내는 요청을 조작하는 것
  ex) 이메일에 첨부된 링크를 누르면 내 은행계좌의 돈이 빠져나간다.
• 해커가 직접 데이터를 접근할 수 없음.
  다른 사이트기 때문에 response에 직접 접근할수 x

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

• CSRF 방지
  • CSRF 토큰 사용하기
    서버측에서 CSRF 공격에 보호하기 위한 문자열을 유저의 브라우저와 웹 앱에만 제공.
  • Same-site cookie 사용
    같은 도메인에서만 세션/쿠키를 사용할 수 있음.