4. 보안측면

진명재·2024년 1월 8일

TLS https ssl 보안측면

Here we go!(User Management Theory)

목록 보기

4/4

4. 보안측면

4-1 HTTPS 와 SSL / TLS : 데이터 전송의 보안

HTTPS

HTTP Secure 혹은 HTTP over SSL/TLS
HTTP와 달리 HTTPS는 전송 데이터를 암호화한다.

HTTPS의 장점

통신하고자 하는 서버가 신뢰할 수 있는 서버인지 판별할 수 있다.
통신 과정에서 데이터가 노출될 가능성이 적다.

SSL/TLS를 알아보기 전에 이들이 사용하는 암호화 방법에 대해 간략하게 알아보고 넘어가도록 하겠습니다.
대칭키 암호화 / 공개키 암호화

대칭키 암호화 - 하나의 키로 암호화 및 복호화를 진행하는 과정
이는 빠르다는 장점이 있지만 누군가가 중간에 키를 가로채게 되면 해킹의 위험이 있다.
공개키 암호화 - 서로 다른 두키(공개키,개인키)로 암호화 복호화 하는 과정을 거치게 된다.
공개키: 누구나 가질 수 있는키 , 개인키: 소유자 한명만 가질 수 있다.
이를 통해 안전하게 암호화가 가능하지만, 속도 측면에서 느리다.

SSL

SSL(Secure Scokets Layer)은 암호화 기반 인터넷 보안 프로토콜이다. 전달되는 모든 데이터를 암호화하고 특정한 유형의 사이버 공격도 차단한다. SSL은 TLS(Transport Layer Security) 암호화의 전신이기도 한다.

TLS

TLS 는 SSL의 업데이트 버전으로 SSL의 최종버전인 3.0과 TLS의 최초버전의 차이는 크지않으며, 이름이 바뀐것은 SSL을 개발한 Netscape가 업데이트에 참여하지 않게 되어 소유권 변경을 위해서였다고 한다.
결과적으로 TLS는 SSL의 업데이트 버전이며 명칭만 다르다고 볼 수 있다.

SSL 인증서와 SSL Handshake에 탑재된 기술

하나의 키로 암호화/복호화를 수행하는 대칭키 암호화 방식
한 쌍의 키 페어로 암호화/복호화를 수행하는 비대칭키 암호화 방식
통신 대상을 서로가 확인하는 신분 확인
믿을 수 있는 SSL 인증서를 위한 디지털 서명
디지털 서명을 해주는 인증 기관 (CA)
공개키를 안전하게 전달하고 공유하기 위한 프로토콜
암호화된 메세지의 변조 여부를 확인하는 메세지 무결성 알고리즘

실제 데이터는 대칭키 방식으로 암호화를 하고
대칭키의 키를 공개키 방식으로 암호화한다.

컴퓨터와 컴퓨터가 네트워크를 이용하여 통신을 할 때는 내부적으로 악수, 세션, 세션 종료 이렇게 3가지 단계가 있다.

1) 악수 (handshake)

사람과 사람이 소통을 할 때 먼저 악수를 하듯,
SSL 방식을 이용하여 통신을 하는 브라우저와 서버 역시 악수(handshake)를 한다.

① 클라이언트가 서버에 접속한다. (Client Hello)
이 단계에서 다음과 같은 정보들을 서버로 전송한다.

클라이언트 측에서 생성한 랜덤 데이터
클라이언트가 지원하는 암호화 방식
세션 아이디

② 서버는 Client Hello에 대한 응답으로 Server Hello를 한다.
다음과 같은 정보들을 클라이언트로 전송한다.

서버 측에서 생성한 랜덤 데이터
서버가 선택한 암호화 방식
인증서

③ 클라이언트는 서버의 인증서를 발급한 CA가 자신이 내장한 CA의 리스트에 있는지 확인한다.
확인 결과 서버를 통해서 다운받은 인증서가 내장된 CA 리스트에 포함되어 있다면
해당 CA의 공개키를 이용해서 암호화되어있는 인증서를 복호화한다.

위에서 언급했듯 비공개키로 암호화된 인증서를 공개키로 복호화한다는 것은
인증서는 CA의 개인키로 암호화된 문서임이 암시적으로 보증된 것이다.

즉, 클라이언트는 인증서를 전송한 서버를 믿을 수 있게 된 것이다.
복호화를 통해 클라이언트는 인증서에 들어있는 서버 공개키를 획득한다.

④ 클라이언트는 주고받은 랜덤 데이터를 조합해 pre master secret이라는 키를 생성한다.
아까 인증서에서 복호화해낸 서버의 공개키로 pre master secret 키를 암호화해서 서버로 전송하면
서버는 자신의 비공개키로 pre master secret키를 복호화한다.
이제 클라이언트, 서버 둘 다 pre master secret키를 가지고 있게 된다.

⑤ 서버와 클라이언트 모두 pre master secret을 일련의 과정을 거쳐서 master secret으로 만든다.
이렇게 만든 master secret으로 session key를 생성한다.

⑥ 핸드쉐이크 단계의 종료를 서로에게 알린다.

2) 세션
서버와 클라이언트가 실제로 데이터를 주고받는 단계이다.
정보를 세션키값을 이용해 대칭키 방식으로 암호화해서 전송한다.

3) 세션 종료
데이터 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려주고 세션키는 폐기한다.

링크텍스트

4-2 CSRF(Cross-Site-Request-Forgery)와 XSS(Cross-Site Scripting) 공격방지

1.CSRF

CSRF(cross-site-request-forgery) 의 줄임말로 웹 취약점 중 하나이다.
공격자가 희생자의 권한을 도용하여 특정 웹 사이트의 기능을 실행하게 할 수 있으며 이는 희생자의 의도와는 무관하게 이루어진다.

우선 몇가지 조건이 갖춰져야 한다.
- 희생자가 공격자가 만든 피싱 사이트에 접속할 것
- 희생자가 위조 요청을 보낼 사이트에 로그인 되어 있을 것

이러한 전제 조건이 필요한 이유는 CSRF는 직접적으로 공격을 하는것이 아니라 하나의 희생양을 통해 대신 공격하게끔 설정 하기 때문이다.

희생양이 로그인이 되어 있는채로 피싱사이트에 접근
해당 페이지에서 희생양이 악성행위를 하도록 하는 행위가 전달 됨
서버에서는 이 행위를 전달 받을때, 희생양의 쿠키에 들어있는 sessionId를 확인하게 되는데, 이것이 유효하다고 판단하고, 행동을 실행 한다.

핵심 개념
쿠키에 sessionid를 이용하는 것이다. 서버는 클라이언트의 쿠키 헤더에 들어있는 sessionid가 유효한지를 판단하는 허점을 파고 든것이다.

링크텍스트

2.XSS

다른 공격방법과 다르게 클라이언트를 공격하는 기법이다. CSS가 맞는 표기법이지만 이미 약어로 사용되어 있기에 XSS로 표기한다.

여기에는 3가지 방식이 존재한다.

Reflected XSS

공격자가 악성 스크립트를 클라이언트에게 직접 전달하여 공격하는 방식이다.

공격자는 악성스크립트가 포함된 URL을 이메일, 메신저 등을 통해 사용자가 클릭할 수 있도록 유도한다. 사용자가 악성스크립트가 삽입된 URL을 클릭하거나 공격자에 의해 악의적으로 조작된 게시물을 클릭했을 때 사용자의 브라우저에서 악성스크립트가 실행된다.

Stored XSS

공격자의 악성스크립트가 데이터베이스에 저장되고 이 값을 출력하는 페이지에서 피해가 발생한다.

공격자는 악성스크립트가 포함된 게시물을 작성하여 게시판 등 사용자가 접근할 수 있는 페이지에 업로드한다. 이때 사용자가 악성스크립트가 포함된 게시물을 요청하면, 공격자가 삽입한 악성스크립트가 사용자 측에서 동작하게 된다.

공격자의 악성스크립트가 서버에 저장되어 불특정 다수를 대상으로 공격에 이용될 수 있어 Reflected XSS보다 공격 대상의 범위가 훨씬 크다.

Dom Based XSS

공격자의 악성스크립트가 DOM 영역에서 실행됨으로써 서버와의 상호작용 없이 브라우저 자체에서 악성스크립트가 실행되는 취약점이다.

DOM 영역에 변화가 생기면 브라우저는 서버로 패킷을 보내지 않고 DOM 영역에서 페이지를 변환시킨다. 따라서 DOM의 일부로 실행되기 때문에 브라우저 자체에서 악성스크립트가 실행된다.

여기서 DOM이란?

Document Object Model의 약자로, HTML요소를 JavaScript Object처럼 조작할 수 있는 Model이다.
HTML의 작은 부분까지 접근할 수 있는 구조로, DOM을 이용하여 HTML로 구성된 웹페이지를 동적으로 움직이게 만들 수 있다.

DOM의 구조는 트리구조로, body가 가장 상위에 있고, 아래에 여러 구성요소가 부모-자식 관계를 가지고 있다.