보안 코딩으로 막을 수 없는 세 가지 공격

앱과 데이터 노출과 관련된 침해가 발생하면 대개 개발자에게 책임이 있습니다. 많은 경우, 이것이 올바른 방향입니다. 주입 공격과 스택 기반 악용은 거의 항상 안전하지 않은 코드로 인해 발생합니다. 일반적으로 보안 규칙 0이 위반되었기 때문입니다.

하지만 모든 침해 사고의 책임을 개발자에게 돌릴 수는 없습니다. 사실 개발자가 완벽하게 안전한 코드를 만들어낸다 하더라도 여전히 다른 많은 공격으로부터 보호하기 위해 애플리케이션 서비스가 필요합니다.

그 이유는 애플리케이션 보안이 스택이기 때문입니다. 단순히 "보안 코드"로 해결할 수 없는 프로토콜과 네트워킹 원칙을 악용하는 공격도 있습니다. 보안을 더욱 복잡하게 만드는 것은 이러한 공격이 악의적인 요청과 합법적인 요청을 구별할 수 있는 가시성이 부족하기 때문에 애플리케이션에서 감지하기 어렵다는 것입니다.

특히, 개발자가 책임을 져서는 안 될 세 가지 공격이 있습니다. 대신, 이러한 공격은 상류에 배치된 애플리케이션 서비스를 통해 가장 잘 감지되고 완화될 수 있으며, 이를 통해 가시성과 상황을 파악하여 공격을 중단할 수 있습니다.

볼륨식 DDoS

네트워크 과부하 기반 공격과 애플리케이션 계층을 공격하기 위해 '스택 상위'로 이동한 공격을 구별하기 위해 기존의 분산형 서비스 거부 공격을 설명하는 데 '체적'이라는 용어를 사용합니다. 이들은 서로 다른 종류의 공격이므로 우리는 두 가지 모두로부터 방어할 수 있어야 합니다. 그러나 이를 방어하는 방법에는 매우 다른 솔루션이 필요합니다.

볼륨 공격은 단지 전격전일 뿐이다. 어떤 장치/인프라/소프트웨어의 요청을 처리하든, 그 장치에 과부하를 일으키려는 의도로 특정 서비스에 대량의 트래픽이 집중됩니다. 이 원칙은 모든 장치(하드웨어든 소프트웨어든, 사내든 클라우드든)가 제한된 리소스를 가지고 있다는 것입니다. 따라서 충분한 요청을 보내면 장치가 과부하 상태가 되어 그 뒤에 있는 모든 것에 대한 액세스를 차단할 수 있습니다.

개발자가 이러한 공격을 효과적으로 방지할 수 없는 이유는 애플리케이션이 네트워킹을 관리하기 위해 플랫폼과 호스트 운영 체제에 의존하기 때문입니다. 볼륨형 DDoS 공격은 네트워크 스택을 표적으로 삼고 공유 리소스를 너무 많이 소모하여 애플리케이션이 요청을 처리하기 어려울 정도로 심각한 피해를 입어 공격을 받고 있다는 것을 판단할 수 없습니다.

보안 코딩으로는 이를 막을 수 없습니다. 취약점으로 인한 악용이 아니기 때문입니다. 그리고 그것은 실제로 시스템의 어떤 부분에 있는 코드의 잘못이 아닙니다. 아무리 하드웨어가 없다고 가장하더라도 결국 리소스는 하드웨어에서 나오며 그 리소스는 제한되어 있다는 것입니다.

볼륨형 DDoS 공격은 애플리케이션의 상류에 있는 대용량, 고성능 애플리케이션 서비스를 통해 가장 잘 감지하고 완화할 수 있습니다. 공격의 근원지에 가까울수록 좋습니다.

익스플로잇이 없으면 안전한 코딩 솔루션도 없습니다.

7계층 DDoS

스택을 애플리케이션 계층으로 옮기면 계층 7(또는 HTTP) DDoS라고 하는 교활한 서비스 거부 유형을 발견할 수 있습니다. 이런 공격은 취약점이나 안전하지 않은 코딩으로 인한 것이 아니라 악용이기 때문에 분노를 유발합니다. 이러한 공격은 HTTP와 이를 구현하는 시스템의 특성으로 인해 효과적입니다.

일반적으로 7계층 DDoS 공격에는 느린 공격과 빠른 공격의 두 가지 유형이 있습니다. 느린 7계층 DDoS는 끔찍한 네트워크 연결이 있는 것처럼 가장하고 합법적인 요청에 대한 응답을 천천히 빼돌려 리소스를 소모합니다. 웹 앱은 연결 기반이기 때문에 리소스가 소모되고, 연결을 유지하는 데 필요한 리소스도 제한적입니다. 공격자는 충분한 수의 클라이언트에 접속하고 합법적인 요청만 보내서 응답을 느리게 받도록 함으로써 애플리케이션 리소스를 묶어 둘 수 있습니다. 이로 인해 합법적인 클라이언트가 연결하는 것이 사실상 불가능해져 사실상 서비스 거부 공격이 실행됩니다.

이 공격은 특히 사악하고 감지하기 어렵습니다. 물론 네트워크 속도를 수신 속도와 비교하지 않는 이상 말입니다. 즉, 업스트림의 애플리케이션 서비스는 클라이언트의 네트워크 특성을 파악할 수 있으며, 해당 클라이언트가 의도적으로 수신 속도를 느리게 하는 것인지 아니면 실제로 네트워크 문제가 있는 것인지를 보다 정확하게 판단할 수 있습니다.  이런 종류의 공격을 차단하려면 적법성을 판단하는 것이 중요합니다.

기본적으로 이러한 공격은 프로토콜 계층(HTTP)을 악용하며, 보안 코딩으로는 이를 해결할 수 있는 방법이 없습니다.

취약점이 없으면 안전한 코딩 솔루션도 없습니다.

자격 증명 채우기

마지막으로 중요한 것은 신임장 정보 채우기 입니다. 지난 몇 년 동안 보안 침해로 인해 노출된 자격 증명의 수는 믿을 수 없을 정도로 많았기 때문에 이러한 공격은 방어하기 매우 어려운 공격입니다.

신임장 정보 입력 공격은 일반적으로 봇이나 도구에 의존합니다. 이는 기존 사용자 이름/비밀번호 덤프의 방대한 풀을 활용하는 무차별 대입 공격 원칙에 기반하기 때문입니다. 자격 증명 채우기 공격이 수동으로 수행되는 경우는 거의 없습니다. 성공적인 자격 증명 채우기 공격은 안전하지 않은 코딩의 결과가 아닙니다*.  공격자는 비밀번호 관리가 취약한 점과 진행 중인 공격을 인식하지 못하는 것 외에는 아무것도 악용하려고 하지 않습니다.

이러한 공격을 탐지하려면 클라이언트가 유효한 인간이 아니라는 것을 확인해야 합니다. 그래서 일종의 역튜링 테스트에서 자동화 시스템이 답할 수 없는 방식으로 과제를 제시하고 CAPTCHA를 사용해야 합니다.

아무리 안전한 코딩을 하더라도 이 공격의 성공을 막을 수는 없습니다. 비밀번호 사용 관행을 개선하고 공격 시도를 탐지하는 것이 인터넷에서 점점 더 늘어나는 재앙에 굴복하지 않기 위한 가장 좋은 방법입니다.

악용 가능한 코드가 없으면 안전한 코딩 솔루션도 없습니다.

*안전하지 않은 코딩으로 인해 자격 증명 채우기 공격이 가능해질 수 있습니다. 결국, 상당수의 침해는 이러한 공격에 사용할 수 있는 자격 증명 목록이 대량으로 생성되는 코드 기반 취약성으로 인해 발생합니다.

탐지 및 방어를 위한 차별화

보안 코딩을 사용해 공격을 막을 수 있는 경우와 그렇지 않은 경우를 인식하는 것이 중요합니다. 이는 성공적인 공격이 있을 때마다 개발자만을 비난할 수는 없기 때문에 중요합니다. 보안에는 시스템 수준의 사고가 필요합니다. 방어해야 할 공격 유형이 다양하기 때문에 여러 가지 솔루션이 필요합니다.

가까운 미래에 대부분의 조직이 겪게 될 다양한 공격을 효과적이고 성공적으로 방어하기 위해서는 차별화하는 것이 중요합니다. (1) 안전하지 않은 코딩으로 인해 악용이 불가능하거나 (2) 가시성이 부족하여 불가능한 경우 개발자가 공격에 대항하여 방어하도록 강제하는 데 시간을 낭비하지 마십시오.

출처나 공격 표면이 무엇이든 상관없이 적절한 장소에서 적절한 보안을 제공하는 서비스 시스템을 통해 전략적으로 보안에 접근해야 합니다.

안전히 계세요.