HTTPS
HTTP + Secure
HTTPS 는 Hyper Text Transfer Protocol Secure Socket layer 의 약자다. HTTP over SSL(TLS), HTTP over Secure라고 부르기도 한다. HTTPS는 HTTP 요청을 SSL 혹은 TLS라는 알고리즘을 이용해, HTTP 통신을 하는 과정에서 데이터를 암호화하여 전송하는 방법이다
암호화
-
대칭키 암호화
키 한개로 암복호
-
비대칭키 암호화
암호/복호 키가 다름
개인키로 암호, 공개키로 복호 = 전자서명 (인증용)
공개키로 암호, 개인키로 복호 = 암호화 (정보 보호) -
해시
시드 + 본문의 해시 값이 같은지 확인
HTTPS의 암호화 방식
-
대칭, 비대칭키 암호화 방식 사용
- 인증서 - 전자 서명
- 클라이언트에서 만든 대칭키
- 대칭키를 암호화하여 전달 - 비대칭키(공개키) 암호화
인증서
HTTPS의 또 다른 특징 중 하나는 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있다는 점이다. 이러한 인증서는 서버의 신원을 보증하여, 우리가 접속한 사이트가 정식 사이트인지 보장해주는 역할을 한다.
Hashing
어떠한 문자열에 '임의의 연산'을 적용하여 다른 문자열로 변환하는 것
-
모든 값에 대해 해시 값을 계산하는데 오래걸리지 않아야 한다.
-
최대한 다른 해시 값을 피해야 하며, 모든 값은 고유한 해시값을 가진다.
-
문자열에 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 한다.
Salt
암호화해야 하는 값에 어떤 별도의 값을 추가하여 결과를 변형하는 것
-
암호화만 해놓는다면 해시된 결과가 늘 동일.
해시된 값과 원래 값을 테이블(레인보우 테이블)로 만들어서 decoding 해버리는 경우도 생긴다. -
원본값에 임의로 약속된 별도의 문자열을 추가하여 해시를 진행한다면 기존 해시값과 전혀 다른 해시값이 반환되어 알고리즘이 노출 되더라도 원본값을 보호할 수 있도록 하는 안전장치
-
기존 : 암호화 하려는 값 => hash 값
Salt 사용 : 암호화 하려는 값 + Salt용 값 => hash 값
Salt 사용 시 주의점
-
Salt는 유저와 패스워드 별로 유일한 값을 가져야 한다.
-
사용자 계정을 생성할 때와 비밀번호를 변경할 때 마다 새로운 임의의 Salt를 사용해서 해싱해야 한다.
-
Salt는 절대 재사용하지 말아야 한다.
-
Salt는 DB의 유저 테이블에 같이 저장되어야 한다.
특정 알고리즘을 통한 해시는 결과가 항상 같기 때문에 해시된 값과 원본 값을 대조한 테이블이 있다면 쉽게 원본 비밀번호를 알아내는 경우도 있다. 그렇기 때문에 기존 문자열에 Salt 값을 추가한 후 Hashing을 한다면 예상하기 힘든 hash 값이 만들어진다. 그래서 Salt를 이용하면, 사용한 알고리즘이 노출 되더라도 원본 비밀번호 데이터를 보호할 수 있는 안전장치 역할을 할 수 있다.
Cookie
어떤 웹사이트에 들어갔을 때, 서버가 일방적으로 클라이언트에 전달하는 작은 데이터
- 서버가 웹 브라우저에 정보를 저장하고 불러올 수 있는 수단
- 해당 도메인에 대해 쿠키가 존재하면, 웹 브라우저는 도메인에게 http 요청 시 쿠키를 함께 전달
이용법
- 사용자 선호, 테마 등 장시간 보존해야하는 정보 저장에 적합 (쇼핑몰 장바구니 정보, 로그인 상태 유지 등)
Options
-
Domain : 서버와 요청의 도메인이 일치하는 경우 쿠키 전송
-
Path : 서버와 요청의 세부경로가 일치하는 경우 쿠키 전송
-
MaxAge or Expires : 쿠키의 유효기간 설정 → 일정 시간 후 자동 소멸
CASE - PC방에 가서 로그아웃을 하지 않은 경우
-
HttpOnly : 스크립트의 쿠키 접근 가능 여부 결정
쿠키는
<script>태그로 접근이 가능 → XSS 공격에 취약하다. 이것이 불가능하도록 HttpOnly 를 사용한다. -
Secure : HTTPS 프로토콜에서만 쿠키 전송 여부 결정
-
SameSite : CORS 요청의 경우 옵션 및 메서드에 따라 쿠키 전송 여부 결정
CASE : 은행 사이트에 로그인이 되어 있는 상태에서 CSRF 공격을 받은 경우
-
옵션에 따른 서버의 쿠키 전송 여부
Lax : GET 메서드 요청만 쿠키 전송 가능
Strict : 쿠키 전송 불가
None : 모든 메서드 요청에 대해 쿠키 전송 가능sameSite=none 옵션은 Secure 쿠키 옵션이 필요하다.
Session
- 서버가 Client에 유일하고 암호화된 ID를 부여
- 중요 데이터는 서버에서 관리
| 설명 | 접속 상태 저장 경로 | 장점 | 단점 | |
|---|---|---|---|---|
| Cookie | 쿠키는 그저 http의 stateless한 것을 보완해주는 도구 | 클라이언트 | 서버에 부담을 덜어줌 | 쿠키 그 자체는 인증이 아님 |
| Session | 접속 상태를 서버가 가짐(stateful), 접속 상태와 권한 부여를 위해 세션아이디를 쿠키로 전송 | 서버 | 신뢰할 수 있는 유저인지 서버에서 추가로 확인 가능 | 하나의 서버에서만 접속 상태를 가지므로 분산에 불리 |
SQL Injection
SQL Injection(SQL 삽입)은 웹 해킹을 접한다면 가장 먼저 배우는 공격 기법인 만큼 간단하지만 아주 강력한 공격입니다. 이름처럼 데이터베이스에서 임의의 SQL문을 실행할 수 있도록 명령어를 삽입하는 공격 유형입니다. 응용 프로그램의 보안상의 허점을 이용해 데이터베이스를 비정상적으로 조작하며, 이로 인해 기록이 삭제되거나 데이터가 유출될 수 있습니다.
대응 방안
- 입력(요청) 값 검증
SQL문은 사람이 사용하는 자연어와 비슷하기 때문에 키워드를 막기엔 한계가 있습니다. 따라서 블랙리스트가 아닌 화이트리스트 방식으로 해당 키워드가 들어오면 다른 값으로 치환하여 SQL Injection에 대응할 수 있습니다.
보안에서 화이트리스트란 기본 정책이 모두 차단인 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식 또는 그 지정된 대상들을 말합니다.
- Prepared Statement 구문 사용
Prepared Statement 구문을 사용하면 사용자의 입력이 SQL문으로부터 분리되어 SQL Injection을 방어할 수 있습니다. 사용자의 입력 값이 전달 되기 전에 데이터베이스가 미리 컴파일하여 SQL을 바로 실행하지 않고 대기하며, 사용자의 입력값을 단순 텍스트로 인식합니다. 따라서 입력 값이 SQL문이 아닌 단순 텍스트로 적용되며 공격에 실패하게 됩니다.
- Error Message 노출 금지
공격자는 데이터베이스의 Error Message를 통해 테이블이나 컬럼 등 데이터베이스의 정보를 얻을 수 있습니다. 에러가 발생한 SQL문과 에러 내용이 클라이언트에 노출되지 않도록 별도의 에러핸들링이 필요합니다.
CSRF
- 다른 사이트에서 유저가 보내는 요청을 조작(forgery) 하는 것
이메일에 첨부된 링크를 누르면 내 은행계좌의 돈이 빠져나감
- 해커가 직접 데이터를 접근할 수 없다
다른 오리진이기 때문에 response에 직접 접근할 수 없음
CSRF 공격을 하기 위한 조건
-
쿠키를 사용한 로그인
유저가 로그인 했을 때, 쿠키로 어떤 유저인지 알 수 있어야 함
-
예측할 수 있는 요청/parameter를 가지고 있어야 함
request에 해커가 모를 수 있는 정보가 담겨있으면 안됨
CSRF 방어
-
CSRF 토큰 사용하기
서버 측에서 CSRF 공격에 보호하기 위한 문자열을 유저의 브라우저와 웹 앱에만 제공
-
Same-site cookie 사용하기
같은 도메인에서만 세션/쿠키를 사용할 수 있다.
