인증/보안 기초

HTTPS(Hyper Text Transfer Protocol Secure Socket layer)

= HTTP + Secure

HTTP 프로토콜 내용을 암호화를 통해서 보안성을 추가

HTTP 요청을 SSL 혹은 TLS라는 알고리즘을 이용해, 데이터를 암호화하여 전송하는 방법

 

HTTPS 특징

암호화

제 3자가 서버와 클라이언트가 주고받는 정보를 탈취할 수 없도록 서로가 합의한 방법으로 데이터를 암호화하여 주고받는다. 비대칭키 방식과 대칭키 방식을 혼용하여 사용한다.

대칭키 방식은 양쪽이 공통의 비밀키를 공유해서 데이터를 암호화, 복호화하는 것이다.

비대칭키 방식은 각각 공개키와 비밀키를 가지고 상대가 나의 공개키로 암호화한 데이터를 개인이 가진 비밀키로 복호화하는 것이다.

인증서

브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있다.

인증서의 역할 중에서는 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장해주는 역할을 하는데 이런 역할을 하는 인증서를 발급해주는 공인 기관들을 CA(Certificatie Authority)라고 한다.

 

인증서가 CA의 비밀키로 암호화되어 있기 때문에, CA의 공개키로 복호화가 가능하다.

따라서, 해당 CA에서 발급한 인증서라는 것을 보증할 수 있다.

 

서버와 클라이언트 간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우른 프로토콜을 TLS 또는 SSL이라고 한다. (SSL이 표준화되며 바뀐 이름이 TLS이다)

 

Hashing

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

1. 모든 값에 대해 해시 값을 계산하는데 오래 걸리면 안된다.
2. 최대한 해시 값을 피해야하고, 모든 값은 고유한 해시 값을 가진다.
3. 아주 작은 단위의 변경이라도, 완전히 다른 해시 값을 가져야 한다.
4. 대표적인 해시 알고리즘으로는 SHA1이 있고, 요즘에는 SHA256을 많이 사용한다.

 

Salt

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

암호화만 해놓으면 해시된 결과가 항상 동일할 수 있고, 해시된 값과 원래 값을 레인보우 테이블로 만들어서 decoding 해버리는 경우가 생길 수 있다. 이를 방지하기 위해, 기존 암호화 하려는 값에 Salt용 값을 추가해서 해시를 진행한다.

 

해시 알고리즘이 노출되더라도, 보안적으로 더 안전할 수 있다.

Salt 사용 시 주의 사항

1. 유저와 패스워드별로 유일한 값을 가져야 한다.
2. 사용자 계정을 생성할 때와 비밀번호를 변경할 때마다 새로운 임의의 Salt를 사용해서 해싱해야 한다.
3. 절대 재사용해선 안된다.
4. DB의 유저 테이블에 같이 저장되어야 한다.

 

Cookie

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

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

ex) 장바구니, 로그인 유지 기능

 

Cookie 옵션

Domain

클라이언트에서는 Cookie의 도메인 옵션과 서버의 도메인이 일치해야만 쿠키를 전송할 수 있다.

 

Path

세부 경로를 설정하는 옵션으로 기본으로 / 으로 설정되어 있고, 세부 경로가 일치해야만 쿠키를 전송할 수 있다.

 

MaxAge or Expires

• MaxAge
  앞으로 몇 초 동안 쿠키가 유효한지 설정하는 옵션
• Expires
  언제까지 쿠키가 유효한지 Date를 지정하는 옵션 (클라이언트의 시간을 기준으로)

세션 쿠키 : MaxAge or Expires 옵션이 없는 쿠키로, 브라우저가 실행 중일 때 사용할 수 있는 임시 쿠키 (종료 시 삭제)
영속성 쿠키 : MaxAge or Expires 옵션이 있는 쿠키로, 지정한 시간 동안만 쿠키 사용 가능

 

Secure

사용하는 프로토콜에 따른 쿠키 전송 여부를 결정한다.

true인 경우, 'HTTPS' 프로토콜을 이용하여 통신하는 경우에만 쿠키를 전송할 수 있다.

 

HttpOnly

자바 스크립트에서 브라우저의 쿠키에 접근 여부를 결정한다.

true인 경우, 자바 스크립트에서 쿠키에 접근이 불가하다. (false인 경우, 'XSS' 공격에 취약)

XSS 공격에 대해 https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9D%B4%ED%8A%B8_%EA%B0%84_%EC%9A%94%EC%B2%AD_%EC%9C%84%EC%A1%B0

 

SameSite

같은 사이트에서만 쿠키를 사용할 수 있게 하는 옵션이다.

• Lax
  Cross-Origin 요청이면 'GET' 메서드에 대해서만 쿠키를 전송 가능
• Strict
  Cross-Origin이 아닌, same-site인 경우에만 쿠키를 전송 가능
• None
  항상 쿠키 전송 가능, Secure 옵션 필요

same-site : 요청을 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 같은 경우
하나라도 다르면, Cross-Origin으로 구분

same-site와 same-origin과의 차이에 대해
https://en.wikipedia.org/wiki/Same-origin_policy

 

 

기본적으로 쿠키는 오랜 시간 동안 유지될 수 있고, 자바 스크립트를 이용해서 쿠키에 접근할 수 있기 때문에, 쿠키에 민감한 정보를 담는 것은 위험하다.

 

Session

장바구니에 옷을 담는 과정에서 매번 로그인할 필요는 없다. 바로 Session을 전달했기 때문이다.

쿠키가 클라이언트가 저장하고 있는 거라면, 세션은 서버가 저장하고 있다.

사용자가 인증에 성공한 상태를 세션이라 부르고, 이 세션을 서버의 저장소(in-memory, redis 등등)에 저장한다.

세션이 만들어지면, 각 세션을 구분하기 위한 세션 아이디도 만들어지고 이는 쿠키에 저장되어 이동한다.

 

로그아웃 시, 서버에서는 세션 정보를 삭제해야 하고, 클라이언트는 쿠키를 갱신해야 한다.

 

 

---

 

웹 보안 공격

SQL Injection

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

 

# <SQL Injection 예시>

SELECT * 
FROM users
WHERE auth='admin'
AND id='' OR '1'='1';

WHERE 절에서 OR는 AND 보다 연산 순위가 낮기 때문에, OR 절인 '1' = '1' (항상 참)이 가장 나중에 실행되서 로그인에 성공한다.

 

대응 방안

1. 요청 값 검증
   블랙리스트가 아닌 화이트리스트 방식으로 해당 키워드가 들어오면 다른 값으로 치환하여 대응 가능
   (화이트리스트란 기본 정책이 모두 차단된 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식)
2. Prepared Statement 구문 사용
   이 구문을 사용하면, 사용자의 요청 값이 전달되기 전에 데이터베이스가 미리 컴파일하여 SQL을 실행하지 않고 대기하고, 사용자의 요청 값을 단순 텍스트로 인식한다. 사용자의 요청이 SQL문으로부터 분리되기 때문에 대응 가능
3. Error Message 노출 금지
   에러가 발생한 SQL문과 에러 메세지가 노출되지 않도록 에러핸들링을 통해 대응 가능

 

CSRF (Cross Site Request Forgery)

주소가 다른 사이트에서 유저가 보내는 요청을 조작하는 것

요청만 조작하기 때문에, 응답 데이터에는 접근 할 수 없다.

쿠키를 사용한 로그인이고, 예측할 수 있는 요청 정보를 가지고 있어야 한다는 조건이 있다.

 

대응 방안

1. CSRF 토큰 사용
   서버 측에서 CSRF 공격에 보호하기 위한 문자열을 유저의 브라우저와 웹 앱에만 제공해서 대응 가능
2. Same-site cookie 사용
   같은 도메인에서만 세션 / 쿠키를 사용하도록 해서 대응 가능

CSRF에 대해
https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9D%B4%ED%8A%B8_%EA%B0%84_%EC%9A%94%EC%B2%AD_%EC%9C%84%EC%A1%B0