안전한 코딩만으로는 막을 수 없는 세 가지 공격

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

앱과 데이터 노출이 관련된 침해 사고가 발생하면 거의 항상 개발자에게 책임이 돌아갑니다. 실제로 많은 경우 개발자에게 원인이 있습니다. 인젝션 공격과 스택 기반 익스플로잇은 거의 언제나 안전하지 않은 코드에서 비롯됩니다. 대개 보안 규칙 제0조를 위반했기 때문입니다.

하지만 모든 침해 사고의 책임을 개발자에게 돌릴 수는 없습니다.모든 사실 개발자가 완벽하게 안전한 코드를 작성할 수 있다고 해도, 그 밖의 수많은 공격을 방어하려면 여전히 애플리케이션 서비스가 필요합니다.

그 이유는 애플리케이션 보안이 여러 계층으로 구성되기 때문입니다. 프로토콜과 네트워킹 원리를 악용하는 공격은 단순히 "안전하게 코딩"하는 것만으로는 막을 수 없습니다. 보안을 더욱 어렵게 만드는 점은 애플리케이션이 악성 요청과 정상적인 요청을 구분할 수 있는 가시성을 갖추지 못해 이러한 공격을 탐지하지 못하는 경우가 많다는 것입니다.

특히 개발자가 직접 처리할 책임을 져서는 안 되는 공격이 세 가지 있습니다. 이러한 공격은 가시성과 맥락 정보를 활용해 차단할 수 있는 업스트림에 배포된 애플리케이션 서비스에서 탐지하고 완화하는 것이 가장 효과적입니다.

대규모 DDoS

당사는 기존의 분산 서비스 거부 공격을 설명할 때 '볼류메트릭'이라는 용어를 사용하여, 네트워크 과부하를 기반으로 하는 공격과 스택의 상위 계층으로 이동해 애플리케이션 계층을 노리는 공격을 구분합니다. 이들은 서로 다른 유형의 공격이므로 두 공격 모두에 대응할 수 있어야 하지만, 각각을 방어하는 데 필요한 솔루션은 매우 다릅니다.

볼류메트릭 공격은 말 그대로 물량 공세입니다. 요청을 처리하는 장치, 인프라 또는 소프트웨어를 과부하 상태로 만들기 위해 특정 서비스에 대량의 트래픽을 집중시킵니다. 여기에는 하드웨어든 소프트웨어든, 온프레미스에 있든 클라우드에 있든 모든 장치의 리소스는 한정되어 있다는 원리가 적용됩니다. 따라서 충분히 많은 요청을 보내면 해당 장치를 마비시켜 그 뒤에 있는 모든 대상에 대한 접근을 차단할 수 있습니다.

개발자가 이 공격을 효과적으로 방지할 수 없는 이유는 애플리케이션이 네트워크 관리를 플랫폼과 호스트 운영 체제에 의존하기 때문입니다. 볼류메트릭 DDoS 공격은 해당 네트워크 스택을 표적으로 삼아 공유 리소스를 대량으로 소모하므로, 애플리케이션은 공격받고 있는지 판단하기 위한 요청조차 거의 처리할 수 없게 됩니다.

보안 코딩으로는 이를 방지할 수 없습니다. 취약점을 악용한 공격이 아니기 때문입니다. 또한 시스템의 어느 부분에 있는 코드에도 잘못이 있는 것은 아닙니다. 아무리 하드웨어가 없는 것처럼 생각하려 해도, 결국 리소스는 하드웨어에서 나오며 그 양은 한정되어 있다는 단순한 사실 때문입니다.

대규모 DDoS 공격은 애플리케이션의 상위 네트워크에 위치한 대용량·고성능 애플리케이션 서비스를 통해 탐지하고 완화하는 것이 가장 효과적입니다. 공격의 근원지에 가까울수록 더 좋습니다.

익스플로잇이 없다면, 보안 코딩으로 해결할 수도 없습니다.

계층 7 DDoS

스택을 따라 애플리케이션 계층으로 올라가면 레이어 7(또는 HTTP) DDoS라고 하는 교묘한 서비스 거부 공격을 접하게 됩니다. 이러한 공격은 익스플로잇이면서도 취약점이나 안전하지 않은 코딩 때문에 발생하는 것이 아니라는 점에서 매우 골치 아픕니다. 이러한 공격은 HTTP와 이를 구현하는 시스템의 특성을 악용합니다.

일반적으로 계층 7 DDoS 공격에는 느린 공격과 빠른 공격이라는 두 가지 유형이 있습니다. 느린 계층 7 DDoS 공격은 네트워크 연결 상태가 매우 나쁜 것처럼 가장하여 정상적인 요청에 대한 응답을 아 주 천 천 히 받아 가면서 리소스를 소모시킵니다. 웹 애플리케이션은 연결 기반으로 작동하고 이러한 연결을 유지하는 데 사용할 수 있는 리소스 역시 제한되어 있기 때문에 리소스가 소모됩니다. 공격자는 충분히 많은 클라이언트를 연결한 뒤 정상적인 요청을 보내되 응답을 천천히 수신하는 방식으로 애플리케이션 리소스를 점유할 수 있습니다. 그 결과 정상적인 클라이언트가 연결하기가 거의 불가능해져 사실상 서비스 거부 공격이 이루어집니다.

이 공격은 특히 악의적이며 탐지하기도 어렵습니다. 네트워크 속도와 수신 속도를 비교하지 않는 한 말입니다. 즉, 상위 애플리케이션 서비스는 클라이언트의 네트워크 특성을 파악할 수 있으므로, 해당 클라이언트가 의도적으로 느리게 수신하는 것인지 아니면 실제로 네트워크 문제가 있는 것인지 더 정확하게 판단할 수 있습니다. 이러한 유형의 공격을 차단하려면 정상적인 요청인지 판단하는 것이 매우 중요합니다.

기본적으로 이러한 공격은 프로토콜 계층(HTTP)의 취약점을 악용하므로, 보안 코딩만으로는 이를 해결할 수 없습니다.

취약점이 없으므로, 보안 코딩으로 해결할 수도 없습니다.

크리덴셜 스터핑

마지막으로 빼놓을 수 없는 공격은 크리덴셜 스터핑입니다. 지난 몇 년간 침해 사고로 노출된 자격 증명의 수가 믿기 어려울 정도로 많아지면서, 이 공격은 반드시 철저히 방어해야 할 주요 위협이 되었습니다.

크리덴셜 스터핑 공격은 일반적으로 봇이나 도구에 의존합니다. 기존에 유출된 방대한 사용자 이름/비밀번호 데이터를 활용하는 무차별 대입 원리를 기반으로 하기 때문입니다. 크리덴셜 스터핑 공격이 수동으로 수행되는 경우는 거의 없습니다. 크리덴셜 스터핑 공격이 성공하는 것은 안전하지 않은 코딩* 때문이 아닙니다. 공격자는 잘못된 비밀번호 사용 관행과 진행 중인 공격을 인지하지 못하는 허점만을 노립니다.

이러한 공격을 탐지하려면 클라이언트가 실제 사람이 아님을 판별할 수 있어야 합니다. 따라서 일종의 역(逆) 튜링 테스트처럼 자동화 시스템이 통과할 수 없는 과제를 제시하고 CAPTCHA를 사용해야 합니다.

아무리 안전하게 코딩하더라도 이 공격이 성공하는 것을 막을 수는 없습니다. 비밀번호 사용 관행을 개선하고 공격 시도를 탐지하는 것이 인터넷에서 점점 확산되는 이 위협에 당하지 않는 최선의 방법입니다.

악용 가능한 코드가 없다면, 보안 코딩으로 해결할 수도 없습니다.

*안전하지 않은 코딩으로 인해 크리덴셜 스터핑 공격이 가능해질 수 있습니다. 실제로 상당수의 침해 사고는 코드 기반 취약점 때문에 발생하며, 그 결과 이러한 공격에 악용될 수 있는 대규모 인증 정보 목록이 유출됩니다.

차이를 구분하여 탐지하고 방어하기

보안 코딩으로 공격을 예방할 수 있는 경우와 그렇지 않은 경우를 구분하는 것이 중요합니다. 모든 공격이 성공할 때마다 개발자에게만 계속 책임을 돌릴 수는 없기 때문입니다. 보안에는 시스템 차원의 사고가 필요하며, 방어해야 할 공격 유형이 다양하므로 여러 가지 해결책이 필요합니다.

대부분의 조직이 가까운 미래에 직면하게 될 다양한 공격을 효과적이고 성공적으로 방어하려면 공격의 성격을 구분하는 것이 중요합니다. 공격이 (1) 안전하지 않은 코딩으로 인한 취약점 악용이 아니거나 (2) 가시성 부족으로 인해 방어가 불가능한 경우, 개발자에게 억지로 방어를 요구하느라 시간을 낭비하지 마세요.

소스나 공격 표면이 무엇이든 관계없이 적재적소에 적절한 보안을 제공하는 서비스 체계의 관점에서 보안에 전략적으로 접근해야 합니다.

안전을 지키세요.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물