[API 보안] #1. API 기술이 관심을 받게 된 배경

2007년 미국의 스티브잡스는 전세계에 IT 환경의 큰 변화를 일으킬 대단한 시도를 했다. 

바로 아이폰 출시~

[ 이미지 출처 : https://hub.zum.com/enjoiyourlife/10535 ]

전세계의 인류의 휴대폰 사용 환경이 정말 거짓말처럼 빠른 시간 안에 변하게 된다.

아이폰 출시 이전까지는 휴대폰은 단순히 사람과 사람을 연결 시켜 주는 통신 수단의 역할만 했다. 전화, 텍스트 메시지.. 

하지만 아이폰은 휴대폰의 역할을 삶의 중요한 디바이스 이상으로 바꿨으며, 모든 생활이 휴대폰을 중심으로 만들어 진다 해도 과언이 아닐 정도로 변화 시켰다. 

가장 큰 변화는 인터넷 사용 환경을 변화 시켰다는데 있다. 

아이폰 이전을 우리가 생각해 보자. 

인터넷을 하기 위해서는 우리는 집에 있는 PC 앞으로 가야 하거나, 사무실 내 자리 컴퓨터 앞 또는 PC 방으로 옮겨야 했다. 

즉, 장소의 제약이 생겼고, 이는 시간의 제약으로 이어졌다. 

하지만 아이폰 덕분에 이제는 언제 어디서든 내가 원하면 인터넷을 이용한다. 

외부에서 이동 중에도, 해외 여행 중에 유명한 관광지에서 정보를 검색하거나 인터넷뱅킹으로 이체를 할 수 있다. 

장소와 시간의 벽이 과감히 허물어졌다. 

당연히 인터넷 사용량이 늘어나게 되었다. 

하지만 내가 생각하는 가장 큰 변화는 인터넷 사용량의 증가가 아닌 인터넷 사용자의 층을 허문 것이라 생각한다. 

잘 생각해보면 과거 인터넷은 젊은이들의 소유물이라 불릴 정도로 어린아이들이나 노년층은 인터넷 사용을 어려워 했다. 정보를 검색하기 힘들었고 인터넷 뱅킹의 편리함을 즐길 수도 없었다. 

인터넷 사용자 층의 확대는 애플리케이션 개발/운영 환경에 크게 작용하게 된다. 

사용층이 늘어나다 보니 모 서비스에 대한 요구 사항이 증가하고, 빠르게 변화한다. 

애플리케이션으로 이윤을 추구하는 기업은 사용자 요구를 빠르게 반영하여 보다 편리하게 서비스를 만들어야만 경쟁력을 갖게 된다. 

" 인터넷 사용층의 확대가 많은 요구사항을 만들었으며 이에 따라 애플리케이션의 개발 및 운영 환경에 큰 변화가 만들어지게 되었다. 이것이 API 가 주목 받기 시작한 이유이다. "

개발 환경의 변화

개발 환경은 Monolithic 방식에서 MSA (Micro Service Architecture) 형태로 변화 할 수 밖에 없다. Monolithic 는 여러 기능을 하나의 덩어리로 개발해서 운영하는 환경을 말한다. 

관리 포인트가 많지 않아 운영 측면의 이점이 있다지만 어떤 변화에 발빠르게 따라가기엔 구조적으로 불리할 수 밖에 없다. 

어떤 기능을 변경해야 한다고 하면 여러 기능들이 복잡하게 얽혀 있기에 수정이 단순하지 않다. 수정되었다고 해도 검증을 해야 하는데 이 또한 쉽지 않다. 

바로 이런 단점들을 보완한 것이 MSA 방식이라 할 수 있다. 

Monolithic 안에 있는 여러 기능들을 서비스 단위로 각각 분리한 후 서비스 간 API 로 연동 시킨다. 이렇게 되면 각 서비스 별로 독립적이다 보니 기능의 수정도 검증도 배포도 Monolithic방식에 비해 상대적으로 아주 빠르다. 

요즘 애플리케이션 개발 운영 환경은 거의 MSA 형태로 진행된다. 

MSA 형태의 증가는 곧 API 사용량의 증가가 되는 것이다.

운영 환경의 변화 

운영 환경은 어떤가? 

예전은 On-premise 방식으로 데이터센터 내에 하나의 서비스 망을 구축하고 애플리케이션이 운영되는 서버도 갖추어 놓는다. 

사용량의 증가로 서버의 증설이 요구되면 서버를 추가로 구매해야 하고 네트워크에 연결하여 서비스가 잘되는지 살펴야 한다. 구매부터 서비스 투입까지 지켜야 할 절차 들이 있기에 시간적 소요가 많을 수 밖에 없다. 

그래서 변화하는 환경에 유연하게 대처할 수 있는 클라우드 환경이 인기가 높아진 것이다. 트래픽이 늘어나면 자동으로 서버를 추가하고 사용량이 줄면 다시 운영 서버의 수를 줄인다. 필요한 만큼 사용하고, 사용한 만큼만 비용을 지불하면 된다. 

서버의 증설과 감소를 자동으로 할 수 있게 해주는 것.. 바로 여기에도 API 가 이용된다. 

이처럼 시대적 요구에 따른 개발과 운영 환경의 변화가 API 의 사용량을 크게 증가 시켰다. 

현재 API 는 공공데이터포털, 웹사이트의 간편로그인등 다양한 곳에서 많이 사용되고 있으며, 현재 애플리케이션 운영의 핵심이라 볼 수 있다. 

서비스간 정보를 교환하는 중요한 기술인 API 는 2022년 1월 시행된 마이데이터 서비스에도 핵심적으로 이용되고 있다. 

요즘 애플리케이션 운영에 없어서는 안될 중요한 기술인 API.

우리가 API 보안을 신경 써야 하는 이유이다. 

[HTTP DDoS] Slowloris 공격

이번 포스팅에서 Slowloris 라는 DDoS 공격 방법에 대해 정리한다. 

# HTTP 요청헤더의 시작과 끝

웹서버는 클라이언트의 요청을 받으면 요청 내용을 처리한 후 되돌려 준다. 

그렇다면 웹서버는 클라이언트의 요청의 전체를 어떻게 구분할까? 

다시말하면 요청 내용의 시작과 끝을 어떻게 구분할까? 

HTTP 요청/응답을 자세히 들여다 보면 다음과 같이 구성되어 있다.

위 붉은색 표시가 요청이고, 아래 파란색 부분이 응답에 해당한다. 

Slowloris 는 위와 같이 HTTP 요청 방식 중 "GET" 을 이용한 공격이다. 

GET 방식은 요청 내용 (Method, URL, Version) 과 다수의 요청 헤더로 이루어진다. 

요청 헤더는 "헤더 명 : 헤더 값(value)" 형태로 이루어 지는데.. 위 Host, Connection 등이 이에 해당된다. 

요청 헤더의 각각의 구분은 줄바꿈 (CRLF) 로 하고 있다. 

즉, 예를 들면 Host, Connection 은 각각의 헤더 정보이며 이를 구분하기 위해 새로운 줄에 위치하고 있음을 알수 있다. 

(Host와 Connection 은 한줄에 같이 존재할 수 없음)

그럼 각 요청마다 헤더의 내용들이 모두 상이할텐데..  서버는 요청 헤더가 모두 전달되었는지 어떻게 알 수 있을까? 

다시 말해서 위 내용을 예로 들면.. 클라이언트가 전달한 요청 헤더가 Host 부터 Accept-Language 까지가 전부인데.. 과연 Accept-Language가 마지막 요청 헤더인지 어떻게 알수 있을까?

답은 "줄바꿈(CRLF) 2번" 이다. 

줄바꿈 2번이 전달되면 웹서버는 요청 헤더가 모두 전달되었다고 인식한다. 

Wireshark 에서 해당 내용을 살펴보자. 

헤더간 구분은 위와 같이 줄바꿈으로 하는걸 볼수 있다. 

Host 헤더(왼쪽)의 끝부분과 Cache-Control 헤더(오른쪽) 의 끝부분을 보면 줄바꿈(CRLF)을 의미하는 Hex 값인 "0d0a" 가 있다. 

헤더의 마지막 부분을 보자. 

요청 헤더의 마지막 부분에 줄바꿈(CRLF)을 의미하는 "0d0a" 가 2번 반복되는 것을 확인할 수 있다. 

이와 같이 클라이언트는 웹서버에게 줄바꿈(CRLF) 2번을 전송하여 서버에게 헤더 전송의 끝을 알린다. 

# Slowloris 공격

Slowloris 는 바로 GET Method의 요청 헤더 전송 형태를 악의적으로 이용하여 웹서버의 TCP 세션 수를 가득 채워 서비스 불가상태(Deny of Service)를 만드는 공격 방법이다. 

Slowloris 는 헤더 종결자인 줄바꿈(CRLF) 2회를 의도적으로 1회만 보내서 웹서버에게 더 전달될 헤더 정보가 있는것처럼 인식하게 하여 세션을 유지하게 한다. 

아래 그림을 참고하자. 

일반적으로는 클라이언트와 웹서버간 TCP 세션 수립 이후 요청을 보내면, 웹서버는 그에 맞는 응답을 회신한다. 

이때, 요청을 자세히 들여다 보면 HTTP 요청 헤더의 종결자로 줄바꿈(CRLF) 2번이 사용됨을 알수 있다. 

Slowloris 공격은 다음과 같이 요청 헤더의 종결자를 보내지 않는 형태를 띈다. 

헤더의 마지막에 종결자를 의미하는 줄바꿈(CRLF) 2회를 보내지 않는다. 

1회만 전달해서 웹서버에게 마치 더 전송될 요청 헤더가 있는것처럼 속여서 세션을 오래 유지하게 하는 것이 Slowloris 이다. 

이런 요청을 많은 클라이언트를 이용하여 특정 웹서버로 공격하면 웹서버는 처리할 수 있는 최대 TCP 세션 풀(Pool) 을 가득 채워 더이상 세션을 맺지 못하게 되어 DoS 상태에 빠지게 된다. 

--- 끝 ---

XSS와 CSRF의 차이

XSS와 CSRF는 다소 비슷하면서도 다르다.

그건 공격스크립트는 비슷하나 공격이 이루어지는 형태가 좀 다르다.

XSS는 직접적인 공격자가 해커 자신이지만. CSRF는 해커가 등록해 놓은 컨텐츠를 클릭한 정상적인 사용자가 직접적인 공격자가 된다.

즉, 직접적인 공격자가 해커 자신이냐? 아니냐? 의 차이로 이해가 된다.

세부적인 설명은 아래 링크를 통해 확인할 수 있다.

보러가기

Cross Site Script(XSS)

SQL 인젝션과 같이 웹해킹에 주로 사용되는 공격 방법인 XSS를 알아보자.

먼저 XSS는 원천적으로 방어하기엔 쉽지 않은것 같다.
XSS를 불가능하게 하기 위해서는 HTML 태그를 게시글등에 사용하지 못하도록 봉쇄하여야 한다. 하지만 이렇게 되면 게시글을 이쁘게 꾸미기가 어려워진다.
때문에 HTML 태그의 사용은 열어두되 공격에 종종 사용될수 있는 iframe 이나 script 태그등을 웹소스단에서 차단하는 형태를 취한다.

좀 더 자세한 사항은 아래 링크글을 통해 확인해보자.

보러가기

False Positive 와 False Negative 의 차이

맨날 헷갈리는 것 중에 하나.

어느 여자가 임신을 했다고 가정하고...
임신 검사를 했는데 임신이 아니라고 나오면.. "False Negative"

어느 여자가 임신을 하지 않았는데...
임신 검사를 했더니 임신이라고 나오면 "False Positive"

즉.. 둘다 검사 결과는 다르게 나온경우인데..
결과가 "긍정(+)" 이면 Positive 를..
결과가 "부정(-)" 이면 Negative 를..
사용한다.

IT에서 위 용어는 흔히 보안장비에서 사용하는데..

IDS/IPS/웹방화벽/UTM등에서...
오탐이면 False Positive..
미탐이면 False Negative..

라 할 수 있겠다...