[인증/보안] 기초

1. HTTPS

개념

HTTPS

• 기존 HTTP + secure(보안 기능)
• HTTP 프로토콜 내용을 암호화
• 인증서 + CA + 비대칭 암호화
  • 인증서(certificate) : 데이터 제공자 신원 보장, 도메인 종속
    • 클라이언트에서 인증서에 작성된 도메인과 응답 객체에 작성된 도메인 비교
    • 일치할 경우 접속 허용(제 3자가 접속을 할 경우 도메인이 다르기 때문에 접근 차단)
  • CA(Certificate Authority)
    • 공인 인증서 발급 기관
    • 각 브라우저는 신뢰하는 CA 정보 소유
  • 비대칭 암호화
    • 서로 다른 키로 암호화, 복호화 가능
    • 한 개는 public으로 한 개는 private으로 사용
    • 공개키는 연산이 복잡하기 때문에 통신 초창기에 비밀키를 만들기 위해 사용
      • handshake - 클라이언트는 Hello를 보내고 서버는 hello, 공개키, 인증서 정보 전달
      • 비밀 키 생성 - 키 제작용 랜덤 스트링 전송(비밀 키 생성)
      • 상호 키 검증 - 서로 세션 키로 암호화된 메시지 전달(상호 키 검증)
      • HTTPS 연결 성립

보안 사이트 확인

• 웹 브라우저 주소창 왼쪽 자물쇠 아이콘을 클릭하여 확인
  • “이 사이트는 보안 연결(HTTPS)이 사용되었습니다.
• HTTP에 접속하면 NOT Secure라는 메시지를 표시한다.
• HTTPS(Hyper Text Transfer Protocol Secure Socket layer)는 HTTP over SSL(TLS), HTTP over Secure라고 부른다.
• SSL 혹은 TLS 알고리즘으로 HTTP 통신 과정에서 데이터를 암호화하여 전송

암호화

• 제 3자가 서버와 클라이언트 사이의 정보를 탈취 못하게 하는 것
• 서버와 클라이언트가 합의된 방법으로 데이터를 암호화하고 통신한다.
• HTTPS에서는 대칭키, 비대칭키 방식 혼용
  • 대칭키는 공통의 비밀 키를 공유해서 데이터 암호화, 복화화 진행
  • 비대칭키는 공개키, 비밀키를 각각 가지고 상대가 나의 공개키로 암호화한 데이터를 개인이 가진 비밀키로 복호화하는 것
• HTTPS에서는 대칭키를 주고받을 때 비대칭키 방식으로 주고받는다.

인증서

• HTTPS는 브라우저가 서버의 응답과 함께 전달된 인증서를 확인 가능
• 인증서는 서버의 신원을 보증
• 제 3자가 이것을 보증할 때 그 제 3자를 CA(certificate Authority)라고 부름
• CA는 서버의 공개키와 정보를 CA 비밀키로 암호화하여 인증서 발급
• 인증서는 CA의 비밀키로 암호화되어 있기 때문에 CA의 공개키로 복호화 가능
• 과정(SSL, TLS)
  • 서버가 클라이언트에게 CA에서 발급받은 인증서를 전달
  • 브라우저에 미리 내장된 CA 리스트를 통해 인증된 CA에서 발급받은 인증서인지 확인
  • 브라우저에서 제공된 해당 CA 기관의 공개키로 서버 인증서를 복호화
  • 만약 위조되었다면 CA의 공개키로 서버의 인증서 복호화 불가
• CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우르는 프로토콜을 TLS 혹은 SSL이라고 부른다.(SSL이 표준화되어 바뀐 이름이 TLS)

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

• 자바 지원 인증서 형식
  • PKCS12(Public Key Cryptogaphic Standards #12) : 여러 인증서와 키를 포함, 암호로 보호된 형식
  • JKS(Java KeyStore) : 독점 형식의 java 환경으로 제한
• mkcert라는 프로그램을 이용해서 로컬 환경에 신뢰할 수 있는 인증서 생성 가능
  • wsl 터미널에서 mkcert 설치
    • 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/
  • macOS
    • brew install mkcert
    • brew install nss
• 인증서 생성
  • mkcert -install : CA 생성
  • mkcert -pkcs12 [localhost](<http://localhost>) : PKCS12 형식 인증서 생성
  • localhost.p12라는 파일 생성 확인

HTTPS server 작성

• Spring Boot를 이용하여 HTTPS 서버 작성
• src/main/resources에 생성된 localhost.p12 파일을 복사해 넣는다.
• applicaiton.yml에 코드 추가
  • 초기 비밀번호는 changeit으로 설정
• server: ssl: key-store: classpath:localhost.p12 key-store-type: PKCS12 key-store-password: changeit

2. Hashing

No Authentication

• 이메일 관련 정보를 얻을 때 인증과정을 거치지 않으면 보안상 문제

Authentication(Plaintext)

• 비밀번호를 이용한 인증
  • 서버에서 이메일과 비밀번호 정보를 받고 DB에서 비교
  • 유저 정보가 일치하면 클라이언트가 요청하는 데이터를 전달
  • 비밀번호는 공개되면 안 되기 때문에 DB에 저장할 때 암호화해서 저장

Encryption

• 일련의 정보를 특정 방식을 사용하여 다른 형태로 변환하여 타인은 해석할 수 없도록 알고리즘을 사용하여 정보 처리하는 과정
• 예시
  • 문자열에서 알파벳 순서를 특정 숫자만큼 이동하여 새로운 문자열 형성

Hashing 과정

• DB에 유저 정보를 비교하기 전에 비밀번호를 암호화한 후 DB 정보를 대조
• 알고리즘을 거친 결과를 DB에 저장
• 서버에 알고리즘을 가지고 있고 인증 요청이 들어올 때마다 암호화를 시키고 DB에 저장된 값과 비교해서 같은지 확인하는 과정을 거친다.

Hasing

• 어떠한 문자열을 연산을 적용하여 다른 문자열로 변환하는 과정
• 세 가지 원칙
  • 해시값을 decoding 할 때는 많은 시간이 걸려야 하지만 해시값을 만드는 데에는 오래 걸리지 않아야 한다.
  • 해시 값들은 다른 해시 값들을 피해야 하고 고유한 해시 값을 가져야 한다.
  • 문자열의 작은 변화가 있어도 해시값은 완전히 다른 값이 되어야 한다.
  • SHA1, SHA256 알고리즘 사용

Authentication with hashing

• 회원 가입할 때 비밀번호를 해시 알고리즘을 이용해 해시 값으로 변환하여 DB에 저장
• 로그인이나 인증 요청이 들어오면 입력받은 비밀번호를 해시값으로 바꾸고 DB에 있는 해시값과 일치하는지 비교

Salt

• 암호화를 해야 하는 값에 별도의 값을 추가하여 결과 변형
• 특정 알고리즘을 사용하면 원본 값과 해시 값을 대조한 테이블로 쉽게 비밀번호 유추 가능
• 이러한 이유로 기존 문자열에 salt값을 추가한 후 hashing 하면 예측하기 힘든 해시값이 만들어진다.
• 주의 사항
  • salt는 유저와 패스워드 별로 유일한 값을 가진다.
  • 계정을 생성할 때, 비밀번호를 변경할 때마다 새로운 salt 사용
  • 재사용 불가
  • DB의 유저 테이블에 salt 같이 저장

Authentication with Salt & hashing

• 회원가입 시 입력받은 비밀번호에 salt를 더하고 해싱 알고리즘을 통한 반환 값을 DB에 저장
• 로그인이나 인증이 필요할 때, 입력받은 비밀번호에 해당 유저의 salt 값을 더하고 결과 값을 DB에 저장된 유저의 비밀번호화 비교

3. Cookie

배경

• HTTP는 stateless(무상태성)으로 요청에 대한 응답만 처리하는 방식으로 상태 기록하지 않는다.
• 그러나 웹사이트에서 장바구니에 옷을 담으면 기록이 된다. 그것이 cookie의 효과이다.

cookie

• 웹사이트에 들어갔을 때 서버가 일방적으로 클라이언트에게 전달하는 작은 데이터
• 서버가 웹 브라우저에 정보를 저장하고 불러올 수 있는 수단
• 해당 도메인에 쿠키가 존재한다면, 웹 브라우저는 도메인에게 http 요청 시 쿠키 함께 전달

cookie 사용법

• 장기간 보존해야 하는 정보를 저장
• 로그인 상태 유지, 테마 적용, 회사에서 필요한 마케팅 정보 등 적용
• 인증 정보와 같은 민감 정보는 암호화된 내용으로 구성(hashing)

cookie 전달 방법

• 서버의 응답 헤더에 set-cookie에 쿠키 이름, 값, 경로를 저장
• 클라이언트는 set-cookie를 확인하고 매 요청 시마다 쿠키를 담아 요청

Cookie Options

• domain
  • 서버에 접속할 수 있는 이름(ex, www.naver.com)
  • naver.com에 해당
  • 쿠키의 도메인 옵션과 서버의 도메인이 일치하는 경우 쿠키 전송
• path
  • 서버가 라우팅 할 때 사용하는 경로
  • http://www.localhost.com:3000/users/login에서 /users/login에 해당
  • path를 전부 만족하는 경우 요청하는 path가 추가로 존재하더라도 쿠키 서버 전송 가능
  • 즉, 쿠키의 path 옵션과 서버의 path가 일치하거나 path 옵션을 만족하고 추가되는 경우 쿠키 전송
• MaxAge or Expires
  • 쿠키의 유효기간 설정
  • 외부 컴퓨터에 로그인을 하고 로그아웃을 하지 않은 경우 문제 발생
  • 쿠키가 일정 시간 지나면 소멸하도록 설정
  • MaxAge는 앞으로 몇 초 동안 유효한지 설정
  • Expires는 언제까지 유효한지 Data를 지정(클라이언트 시간 기준)
  • session cookie : MaxAge, Expires 옵션이 없는 쿠키, 임시 쿠키로 브라우저 종료하면 쿠키 삭제
  • persistenet cookie : 지정된 MaxAge, Expires에 의해 유효시간만큼 사용
• HttpOnly
  • 스크립트에서 접근을 막고 브라우저에서만 접근하도록 설정
  • 쿠키는 <script> 태그로 접근이 가능하여 XSS 공격에 취약
  • 이것을 위해 스크립트 접근을 막을 수 있다.
• Secure - HTTPS 프로토콜에서만 쿠키 전송 여부 결정
• SameSite
  • CORS 요청의 경우 옵션 및 메서드에 따라 쿠키 전송 여부 결정
  • CSRF(Cross Site Request Forgery) - 다른 사이트를 통해서 잘못된 요청을 전송하는 공격
  • SameSite로 CSRF 공격 예방
  • Lax 옵션 - GET 메서드 요청만 쿠키 전송 가능
  • Strict 옵션 - sameStie인 경우에만 쿠키 전송
  • None 옵션 - 모든 메서드 요청에 대해 쿠키 전송 가능
    • none 옵션은 Secure 쿠키 옵션 필요
    • HTTPS 프로토콜 사용 필수

쿠키 이용 상태 유지

• 서버가 클라이언트에게 인증정보를 쿠키에 담아 전송하고 클라이언트가 쿠키를 요청과 함께 전송하여 stateless 한 http 인터넷 연결을 stateful 하게 유지 가능
• 민감 정보를 쿠키에 담는 것은 위험

4. Session

개념

• 중요 데이터를 ‘서버’에 저장(cookie는 클라이언트에 저장)
• 서버가 클라이언트에 유일하고 암호화된 id 부여

Session 전달 방법

• 클라이언트가 user, p/w, 요청 사항을 서버에 전송
• 서버가 DB에 정보를 저장하고 session_id를 반환하는데 이것을 암호화된 세션 아이디로 저장하고 반환한다.
• set-cookie에 담아서 클라이언트에게 전송
• 클라이언트가 이후 session_id를 통해 접근하고 작업을 수행

Authentication with Session

• 로그인
  • 서버는 해당 유저가 로그인을 했다는 사실을 안다면 매번 로그인할 필요가 없다.
  • 서버는 사용자가 인증에 성공했다는 것을 알아야 한다. - 저장소(in-memeory, 세션 스토어)에 session 저장
  • 클라이언트는 인증 성공 수단을 가지고 있어야 한다. - session_id를 전달
  • 서버는 쿠키로 session_id를 전달하고 클라이언트는 서버에 요청할 때마다 쿠키를 포함하여 요청
• 로그아웃
  • 서버에서는 세션 정보를 삭제
  • 클라이언트는 session_id가 담긴 쿠키를 갱신
    • set-cookie로 클라이언트에게 쿠키를 전송할 때 세션 아이디의 키 값을 무효하게 갱신

coockie & session 차이

• cookie
  • http의 stateless를 보완
  • 저장 경로가 클라이언트
  • 서버에 부담을 덜어줌
  • 쿠키 자체는 인증이 아니다.
• session
  • 접속 상태를 서버가 가진다.
  • 접속 상태와 권한 부여를 위해 세션 아이디를 쿠키로 전송
  • 저장 경로가 서버
  • 신뢰할 수 있는 유저인지 서버에서 추가 확인 가능
  • 하나의 서버에서만 접속 상태를 가지기 때문에 분산에 불리
    • 토큰으로 보완 가능

Session 단점

• 서버 저장 공간 부족
• 여전히 쿠키를 사용하고 있기 때문에 세션 쿠키 탈취에 대한 보안 우려

5. 웹 보안 공격

SQL Injection

개념

• 데이터베이스에 임의의 SQL문을 실행할 수 있도록 명령어 삽입하는 공격
• 기록 삭제 혹은 데이터 유출

공격 과정

• 사용자가 input form에 작성하는 상황에 발생
• 예를 들어 로그인할 때 아이디 값과 패스워드 값을 이용해서 DB에 접근
• 공격자는 input form에 일반 텍스트가 아닌 sql문을 작성
  • OR ‘1’=’1’을 패스워드에 넣어 보내면
  • sql에서 조건문으로 아이디를 and로 연결하였는데 비밀번호를 항상 참인 것으로 실행하면 로그인에 성공한다.
  • 혹은 ‘;DROP TABLES users;—’을 삽입하면 sql문을 실행할 수 있다.

SQL injection 대응

• 입력 값 검증
  • SQL문은 사람이 사용하는 자연어와 비슷하여 막기 어렵지만 화이트리스트 방식으로 키워드가 들어오면 다른 값으로 치환하여 대응 가능
  • 화이트리스트는 기본 정책이 모두 차단인 상황에서 예외적으로 접근 가능한 대상을 지정하는 방식 혹은 대상들
• prepared statement 사용
  • 사용자의 입력이 SQL문으로부터 분리되어 대응 가능
  • 입력 값이 전달되기 전에 DB가 미리 컴파일해서 SQL 실행하지 않고 기다리고 입력값을 단순 텍스트로 인식
• Error Message 노출 금지
  • 공격자는 error message를 통해 DB 정보를 얻을 수 있다. 에러가 발생한 SQL 문의 에러 내용을 클라이언트에게 노출하지 않도록 핸들링이 필요

CSRF - Cross Site Request Forgery

web application security

• 웹사이트, 앱, 웹 만들 때 보안 필수
• SQL Injection, CSS, CSRF

CSRF

• 다른 사이트(cross site)에서 유저가 보는 요청을 조작(forgery)하는 것
• 해커가 직접 데이터 접근 불가

CSRF 조건

• 쿠키를 사용한 로그인
  • 유저가 로그인했을 때, 쿠키로 어떤 유저인지 알 수 있어야 한다.
• 예측할 수 있는 요청/ parameter를 가지고 있어야 한다.
  • request에 해커가 모르는 정보가 있으면 안 된다.

CSRF 공격 예시

• 계좌이체에 사용되는 get 요청
  • 사용자가 은행에 로그인하여 세션이 살아있고 로그인 정보가 쿠키에 담겨 있다.
  • 일정 금액을 이체하는데 그 대상을 해커 쪽으로 바꾸는 API 준비
  • 악성 링크를 사용자가 클릭하도록 누르고 준비한 API 가 실행되도록 한다.
  • 서버에서 API 수행
• Post 요청으로 공격
  • post는 body에 내용을 담아 요청하는 작업
  • 해커가 웹사이트를 만들어서 document form을 작성
  • 비밀번호를 바꾸는 post 요청을 전송
• 예방 방법
  • CSRF 토큰 사용
    • 서버 측에서 CSRF 공격에 보호하기 위한 문자열을 유저의 브라우저와 웹 앱에만 제공
  • Same-site cookie 사용
    • 같은 도메인에서만 세션/쿠키를 사용할 수 있도록 한다.