20230707

아홍·2023년 7월 7일

2023.07

목록 보기
4/12

HTTP

HTTP : HTTP + Secure
SSL이나 TLS라는 알고리즘을 통해 HTTP 프로토콜 내용을 암호화

인증서, CA, 비대칭 키 암호화를 사용한다.

-인증서Certificate : 데이터 제공자의 신원을 보장
서버는 요청을 받는다면 인증서와 응답을 전송한다.
클라이언트는 인증서의 도메인과 응답의 도메인을 비교하고, 두 도메인의 비교를 통해 제공자의 신원을 확인한다.

-CA(공인 인증서 발급 기관Certificate Authority) : 인증서를 보증, 발급해주는 기관.

-비대칭 키 암호화
한 쌍의 서로 다른 키, 공개 키와 개인 키를 사용한 방식.
개인키로 암호화한 데이터는 공개키로 복호하할 수 있고,
공개키로 암호화한 데이터를 개인키로만 복호화할 수 있다.
비대칭키 방식은 알고리즘이 복잡해서 매번 수행하기엔 부담되므로, 연결 초기에 비대칭키 방식으로 대칭키를 교환하고 이후에는 대칭키를 사용하여 통신을 한다.


인증서 발급 실습

mkcert를 이용해서 PKCS12 형식의 인증서를 만들 수 있다.
이는 로컬에서만 인증 가능한 사설 인증서이기 때문에 배포 환경에서는 사용할 수 없다.

  1. Spring Web을 포함해서 프로젝트 하나 생성하기
  2. 프로젝트 저장 위치로 이동 후
$ 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 //백업 파일에 실행할 수 있는 권한을 준다. (x : executable)
$ sudo cp mkcert /usr/local/bin/

$ mkcert -install
$ mkcert -pkcs12 localhost //해당 위치에 localhost.p12 가 생성된다
  1. 인증서(localhost.p12)를 resources 폴더로 이동
  2. application.properties를 수정한다
server.ssl.key-store=classpath:localhost.p12
server.ssl.key-store-type=PKCS12
server.ssl.key-store-password=changeit   #changeit은 기본 비밀번호

https 서버가 작동된다.

2023-07-07 11:21:47.843  INFO 2332 --- [  restartedMain] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (https)

Hashing

암호화만 가능한 방식. 해시 함수를 사용해 암호화를 한다.
주로, 동일한 값의 데이터를 사용하고 있는지 여부를 확인하기 위해 사용한다.

항상 같은 길이의 문자열을 리턴하고, 서로 다른 문자열에 동일한 해시 함수를 사용하면 반드시 다른 결과값이 나오고, 같은 문자열에 같은 해시 함수를 사용하면 항상 같은 결과값이 나온다.

이러한 특성을 이용해, 암호화 이전의 값을 알아낼 수 있도록 기록해놓은 레인보우 테이블이 존재한다. 암호화된 데이터라도, 그 해싱 값이 레인보우 테이블에 있다면 데이터를 알 수 있다.
이를 피하기 위해 사용하는 것이 솔트Salt. 해싱 이전에 임의의 값을 더해서 해싱 값만으로 원본을 찾기 어렵게 만드는 방법이다.


서버에서 클라이언트에 데이터를 저장하는 방법.
HTTP는 Stateless하지만
서버는 클라이언트에 인증정보를 담은 쿠키를 전송,
클라이언트는 쿠키를 요청과 함께 전송하여 연결을 Stateful하게 유지할 수 있다.
-> 사용자 선호, 테마 등 장기간 보존해야하는 정보 저장에 적합

쿠키 옵션 : 데이터를 저장한 후 조건이 만족하는 경우에만 데이터를 가져올 수 있음

-Domain : 쿠키에 도메인 정보가 존재한다면 쿠키의 도메인 옵션과 서버의 도메인이 일치해야만 쿠키를 전송할 수 있다
e.g. http://www.test.com/path 에서 도메인은 test.com

-Path : e.g. http://www.test.com/path 에서 세부 경로는 /path

-MaxAge or Expires : 유효기간. MaxAge는 몇 초 동안, Expires는 유효 기간 Date를 지정.
이런 옵션이 없다면 세션 쿠키로, 브라우저가 종료되면 삭제되는 쿠키이고
이런 옵션이 존재한다면 이는 영속성 쿠키로, 브라우저 종료 여부와 관계없이 유효시간만큼만 사용이 가능하다

-Secure : true라면 HTTPS 프르토콜로만 전송이 가능하다.

-HttpOnly : 자바스크립트 접근 여부. true라면 자바스크립트에서 쿠키 접근이 불가능하다.
false라면 XSS공격에 취약하다.

-SameSite : CORS 요청의 경우 옵션 및 HTTP 메서드에 따라 쿠키 전송 여부 결정
--Lax : GET 요청에만 쿠키 전송
--Strict : 쿠키 전송 불가
--None : 모든 메서드 요청에 쿠키 전송 가능. 이 경우는 Secure 쿠키 옵션을 반드시 사용해야 함
-> CSRF 공격에 매우 효과적

*Cross-Origin : 도메인, 프로토콜, 포트 하나라도 다른 경우

*Cross-Site : eTLD+1이 다른 경우

TLD(Top Level Domain 최상위 도메인) : 도메인의 가장 마지막 부분. e.g. .com .org
다만, .io의 경우는 바로 왼쪽 주소를 하나 더 합한 것을 TLD로 본다.

eTLD+1 : 최상위 도메인의 하위 레벨 도메인을 합한 것.
e.g. http://abc.test.com 의 eTLD+1 : test.com
http://123.test.com 의 eTLD+1 : test.com
둘의 eTLD+1이 같으므로 Same-Site

e.g. http://abc.test.io 의 eTLD : test.io, eTLD+1 : abc.test.io
http://123.test.io 의 eTLD : test.io, eTLD+1 : 123.test.io
둘의 eTLD+1이 다르므로 Cross-Site


Session

세션 : 사용자가 인증에 성공한 상태. 서버는 주로 인메모리나 세션 스토어(트랜잭션이 빠른 DB)에 세션을 저장한다. 세션이 만들어지만 세션을 구분할 수 있는 세션 아이디를 만들고, 세션 성공을 증명할 수단으로 세션 아이디를 전달한다. 서버에서 발급한 세션 아이디는 쿠키에 저장된다. 쿠키에 세션 아이디 정보가 없는 경우, 인증되지 않았음을 보여준다.
+쿠키는 자바스크립트에 취약하므로 세션 아이디는 암호화가 필요하다.

로그아웃을 한다면?
1. 서버는 세션 정보를 삭제한다.
2. 클라이언트의 쿠키를 갱신한다 > 서버에서 클라이언트로 set-cookie로 세션 아이디의 키값을 무효한 값으로 갱신한다.

CookieSession
설명쿠키는 그저 http의 stateless한 것을 보완해주는 도구접속 상태를 서버가 가짐(stateful) 접속 상태와 권한 부여를 위해 세션아이디를 쿠키로 전송
접속상태저장경로클라이언트서버
장점서버에 부담을 덜어줌신뢰할 수 있는 유저인지 서버에서 추가로 확인 가능
단점쿠키 크 가체는 인증이 아님하나의 서버에서만 접속 상태를 가지므로 분산에 불리

SQL Injection

DB에서 SQL문을 실행하도록 명령어를 삽입하는 공격 유형

대응 방안
1. 입력 값 검증 : SQL의 키워드를 막기엔 한계가 있으므로, 블랙리스트가 아닌 화이트리스트 방식으로 대응
2. Prepared Statement 구문 사용 : 사용자의 input이 DB에 전달되기 전에 컴파일하여 단순 텍스트로 적용된다.
3. Error Message 노출 금지 : 에러 메세지를 통해 DB의 정보를 얻을 수 있다. 클라이언트에 에러 메세지가 노출되지 않도록 해야한다.


CSRF (Cross-Site Request Forgery)

다른 사이트에서 유저가 보내는 요청을 조작하는 것
요청을 조작하는 것이기 때문에 해커가 response에 접근할 수 없다. > 데이터에 접근할 수 없다.

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

CSRF 공격을 막는 방법
-CSRF 토큰 사용하기 : 서버 측에서 CSRF 공격에 보호하기 위한 문자열을 유저의 브라우저와 웹 앱에만 제공
-Same-site 쿠키 사용하기 : 같은 도메인에서만 세션이나 쿠키를 사용할 수 있게 한다.

0개의 댓글