웹 애플리케이션은 전 세계 수많은 인터넷 사용자에게 개방되어 있어, 보안 취약점을 악용하려는 시도가 끊임없이 발생합니다.
초창기 인터넷에서 가장 흔했던 공격 방식 중 하나는 단순 무차별 대입 공격이었습니다. 봇이나 악의적인 사용자가 대상 애플리케이션에 접근하기 위해 사용자 이름과 비밀번호 조합을 무작위로 시도했습니다.
오늘날에는 강력한 암호 정책, 로그인 시도 제한, 보안 문자(CAPTCHA) 등의 도입으로 무차별 대입 공격의 위협은 많이 감소했습니다. 하지만 사이버 범죄자들은 새로운 취약점을 찾아 공격하는 것을 멈추지 않습니다. 그들은 웹 페이지나 애플리케이션의 입력 필드에 예상치 못한 텍스트를 삽입하여, 애플리케이션이 원래 의도와 다른 동작을 수행하도록 조작할 수 있다는 것을 발견했습니다. 이것이 바로 인젝션 공격의 시작입니다.
인젝션 공격은 단순히 사용자 이름과 비밀번호 없이 애플리케이션에 로그인하는 데 사용될 수 있을 뿐만 아니라, 개인 정보나 기밀 정보를 탈취하거나, 서버 전체를 장악하는 데까지 악용될 수 있습니다. 따라서 이러한 공격은 웹 애플리케이션 자체는 물론이고, 해당 애플리케이션에 데이터를 저장한 사용자, 그리고 더 나아가 연동된 다른 애플리케이션 및 서비스에도 심각한 위협이 됩니다.
코드 인젝션
코드 인젝션은 가장 대표적인 인젝션 공격 중 하나입니다. 공격자는 웹 애플리케이션이 사용하는 프로그래밍 언어, 프레임워크, 데이터베이스, 운영 체제 등을 파악한 후, 텍스트 입력 필드를 통해 악성 코드를 삽입하여 웹 서버가 공격자가 원하는 대로 작동하도록 조작합니다.
이러한 공격은 입력 데이터 검증이 제대로 이루어지지 않는 애플리케이션에서 주로 발생합니다. 사용자가 입력 필드에 어떤 내용이든 자유롭게 입력할 수 있다면, 애플리케이션은 취약점에 노출될 수밖에 없습니다. 이러한 공격을 막기 위해서는 애플리케이션이 입력 가능한 데이터의 양이나 형태, 허용되는 문자 등을 제한해야 합니다.
예를 들어, 예상 데이터의 길이를 제한하고, 데이터 형식을 검증하며, 허용되는 문자 집합을 제한하는 등의 조치가 필요합니다.
코드 인젝션 취약점은 다양한 종류의 콘텐츠로 웹 애플리케이션의 입력 필드를 테스트해보는 것만으로도 쉽게 발견될 수 있습니다. 일단 취약점이 발견되면 악용하기는 비교적 쉬워집니다. 공격자가 이러한 취약점을 성공적으로 악용할 경우, 기밀성, 무결성, 가용성 등 애플리케이션의 핵심 기능에 심각한 손실을 초래할 수 있습니다.
SQL 인젝션
코드 인젝션과 유사하게, SQL 인젝션은 데이터베이스 쿼리에 사용되는 SQL 스크립트를 입력 필드에 삽입하는 공격 방식입니다. 삽입된 스크립트는 애플리케이션에 의해 데이터베이스에서 직접 실행됩니다. 이를 통해 공격자는 로그인 화면을 우회하거나, 데이터베이스에서 중요한 데이터를 탈취하거나, 데이터베이스의 데이터를 수정 또는 파괴하거나, 관리 작업을 수행하는 등 심각한 피해를 입힐 수 있습니다.
PHP나 ASP로 작성된 애플리케이션은 이전 버전의 인터페이스로 인해 SQL 인젝션 공격에 특히 취약할 수 있습니다. 반면, J2EE나 ASP.Net 애플리케이션은 이러한 공격으로부터 비교적 안전한 편입니다. SQL 인젝션 취약점이 발견되고 악용될 경우, 그 피해 규모는 공격자의 기술과 상상력에 따라 무궁무진해질 수 있습니다. 따라서 SQL 인젝션은 매우 심각한 위협으로 간주해야 합니다.
명령어 인젝션
이러한 유형의 공격은 주로 부실한 입력 검증으로 인해 발생합니다. 코드 인젝션과 달리, 시스템 명령어를 삽입하여 공격하는 것이 특징입니다. 따라서 공격자는 애플리케이션의 프로그래밍 언어나 데이터베이스 언어를 알 필요 없이, 호스팅 서버의 운영 체제만 파악하면 됩니다.
삽입된 시스템 명령어는 애플리케이션의 권한으로 호스트 운영 체제에서 실행되며, 서버에 존재하는 임의의 파일 내용을 노출하거나, 서버 디렉토리 구조를 표시하거나, 사용자 비밀번호를 변경하는 등 다양한 악의적인 작업을 수행할 수 있습니다.
이러한 공격은 서버에서 실행되는 웹 애플리케이션의 시스템 접근 권한을 제한하는 방식으로 예방할 수 있습니다.
크로스 사이트 스크립팅 (XSS)
애플리케이션이 사용자 입력을 검증하거나 인코딩하지 않고 출력에 사용할 때, 공격자는 다른 사용자에게 악성 코드를 삽입할 수 있는 기회를 얻게 됩니다. XSS 공격은 이러한 취약점을 이용하여 신뢰할 수 있는 웹사이트에 악성 스크립트를 삽입하고, 결국 해당 스크립트가 다른 사용자에게 전달되어 피해를 입히는 방식입니다.
피해자의 브라우저는 악성 스크립트가 신뢰할 수 없다는 사실을 인지하지 못한 채 실행합니다. 따라서 세션 토큰, 쿠키, 브라우저에 저장된 민감한 정보에 공격자가 접근할 수 있게 됩니다. 심지어, 스크립트가 제대로 프로그래밍된 경우, HTML 파일의 내용까지 변조될 수 있습니다.
XSS 공격은 일반적으로 저장형과 반사형의 두 가지 유형으로 나뉩니다.
저장형 XSS 공격에서는 악성 스크립트가 서버, 메시지 포럼, 데이터베이스, 방문자 로그 등과 같은 곳에 영구적으로 저장됩니다. 피해자는 브라우저가 저장된 정보를 요청할 때 스크립트를 실행하게 됩니다. 반면, 반사형 XSS 공격에서는 악성 스크립트가 서버로 전송된 입력 값에 포함되어 응답으로 되돌아옵니다. 예를 들어, 오류 메시지나 검색 결과에 악성 스크립트가 포함될 수 있습니다.
XPath 인젝션
이러한 유형의 공격은 웹 애플리케이션이 사용자가 제공한 정보를 기반으로 XML 데이터에 대한 XPath 쿼리를 생성할 때 발생합니다. SQL 인젝션과 마찬가지로, 공격자는 XML 데이터 구조를 파악하기 위해 의도적으로 잘못된 정보를 애플리케이션에 전송하고, 이를 통해 데이터 접근을 시도합니다.
XPath는 SQL처럼 특정 속성을 지정하여 데이터를 검색할 수 있는 표준 언어입니다. 웹 애플리케이션은 사용자의 입력을 기반으로 데이터 검색 패턴을 설정하는데, 이때 부적절한 입력을 받으면 패턴 자체가 공격자가 원하는 작업으로 바뀌어 버릴 수 있습니다.
SQL과 달리, XPath는 여러 버전이 존재하지 않습니다. 이는 XML 데이터를 사용하는 모든 웹 애플리케이션에서 XPath 인젝션 공격이 가능하다는 것을 의미하며, 자동화된 공격의 대상이 될 수 있다는 것을 시사합니다. 따라서 SQL 인젝션보다 더 광범위한 공격이 발생할 가능성이 있습니다.
메일 명령 인젝션
이 공격 방법은 부적절하게 검증된 사용자 입력을 사용하여 IMAP 또는 SMTP 명령어를 생성하는 이메일 서버 및 애플리케이션을 악용합니다. IMAP 및 SMTP 서버는 대부분의 웹 서버와 달리 강력한 보안 기능을 갖추고 있지 않은 경우가 많아 공격에 더 취약합니다. 공격자는 메일 서버를 통해 접근하여 CAPTCHA나 요청 제한 등의 보안 조치를 우회할 수 있습니다.
SMTP 서버를 악용하려면 공격자가 악성 명령어를 보낼 수 있는 유효한 이메일 계정이 필요합니다. 서버가 취약한 경우, 공격자의 요청에 응답하여 서버 제한을 무시하고 해당 서버를 스팸 발송에 이용할 수 있습니다.
IMAP 인젝션은 메시지 읽기 기능을 악용하여 주로 웹메일 애플리케이션에서 발생합니다. 이 경우, 공격자는 웹 브라우저 주소창에 명령어가 포함된 URL을 입력하는 것만으로 공격이 가능합니다.
CRLF 인젝션
웹 양식 입력 필드에 캐리지 리턴(CR)과 줄 바꿈(LF) 문자의 조합인 CRLF를 삽입하는 것은 CRLF 인젝션이라는 공격 기법을 유발할 수 있습니다. 이러한 보이지 않는 문자는 HTTP, MIME, NNTP와 같은 여러 인터넷 프로토콜에서 라인 끝이나 명령어 끝을 표시하는데 사용됩니다.
예를 들어, HTTP 요청에 CRLF를 삽입한 다음 특정 HTML 코드를 추가하면 웹사이트 방문자에게 커스터마이징된 웹 페이지를 제공할 수 있습니다.
이러한 공격은 사용자 입력에 적절한 필터링을 적용하지 않는 취약한 웹 애플리케이션에서 발생하기 쉽습니다. 이러한 취약점은 XSS나 코드 인젝션과 같은 다른 유형의 인젝션 공격의 발판이 되기도 하며, 하이재킹된 웹사이트에서 공격이 시작되기도 합니다.
호스트 헤더 인젝션
여러 웹사이트나 웹 애플리케이션을 호스팅하는 서버에서, 호스트 헤더는 어떤 웹사이트 또는 웹 애플리케이션(가상 호스트라고도 함)이 요청을 처리해야 하는지 결정하는 데 필요합니다. 헤더의 값은 서버에 요청을 보내야 하는 가상 호스트를 알려줍니다. 만약 서버가 잘못된 호스트 헤더를 수신하면, 일반적으로 목록의 첫 번째 가상 호스트로 전달합니다. 이 점을 악용하여, 공격자는 임의의 호스트 헤더를 서버의 첫 번째 가상 호스트로 전송할 수 있습니다.
호스트 헤더 조작은 주로 PHP 애플리케이션에서 발생하지만, 다른 웹 개발 기술에서도 발생할 수 있습니다. 호스트 헤더 공격은 웹 캐시 포이즈닝과 같은 다른 유형의 공격을 가능하게 하는 역할을 하며, 암호 재설정과 같은 민감한 작업 실행에까지 영향을 줄 수 있습니다.
LDAP 인젝션
LDAP는 네트워크에서 장치, 파일, 사용자 등의 리소스를 검색하기 위해 설계된 프로토콜입니다. 인트라넷 환경에서 매우 유용하며, 싱글 사인온 시스템의 일부로 사용자 이름과 비밀번호를 저장하는 데 사용될 수 있습니다. LDAP 쿼리에는 제어에 영향을 미치는 특수 제어 문자가 포함되어 있습니다. 공격자는 이러한 제어 문자를 삽입하여 LDAP 쿼리의 의도된 동작을 변경할 수 있습니다.
LDAP 인젝션 공격의 근본적인 원인 또한 사용자 입력의 부적절한 유효성 검증입니다. 사용자가 애플리케이션에 전송한 텍스트를 필터링하지 않고 LDAP 쿼리에 사용하는 경우, 쿼리 결과로 모든 사용자 목록을 검색하여 공격자에게 노출할 수 있습니다.
입력 문자열 내부의 올바른 위치에 있습니다.
인젝션 공격 방지
이 글에서 살펴본 것처럼, 모든 인젝션 공격은 인터넷에 공개된 서버와 애플리케이션을 대상으로 합니다. 이러한 공격을 방지할 책임은 애플리케이션 개발자와 서버 관리자 모두에게 있습니다.
애플리케이션 개발자는 사용자 입력에 대한 부적절한 검증이 초래하는 위험을 인지하고, 위험 예방을 위해 사용자 입력을 필터링하는 모범 사례를 따라야 합니다. 서버 관리자는 시스템을 정기적으로 감사하여 취약점을 탐지하고 가능한 한 빨리 수정해야 합니다. 온디맨드 방식이나 자동화된 방식으로 감사를 수행할 수 있는 다양한 옵션이 있습니다.