Coders Conquer Security: 공유 및 학습 시리즈 - NoSQL 인젝션

NoSQL 데이터베이스의 인기가 날로 높아지고 있습니다. 특히 애자일 방법론을 도입하는 개발 팀이 늘어남에 따라, 비정형 데이터를 다루는 속도와 편의성은 부정할 수 없는 장점입니다.

신기술에서 발생하는 취약점과 문제점을 개발자가 파악하기까지는 시간이 걸립니다. 실제 운영 환경에서 일정 기간 사용된 후에야 비로소 문제들이 수면 위로 드러나기 시작하기 때문입니다.

NoSQL 데이터베이스도 마찬가지입니다. 개발자가 애플리케이션을 안전하게 보호하기 위해 반드시 알아야 할 핵심 위험 요소가 있으며, 그중 하나가 바로 NoSQL 인젝션입니다.

NoSQL 인젝션이 무엇인지, 어떤 피해를 줄 수 있는지, 그리고 어떻게 해결할 수 있는지 살펴보겠습니다.

NoSQL 인젝션 이해하기

NoSQL 인젝션은 XML이나 SQL 인젝션과 같은 기존의 인젝션 취약점들과 많은 부분에서 원인이 같습니다.

NoSQL 인젝션을 이용하면 공격자가 NoSQL 쿼리에 임의의 명령을 삽입할 수 있습니다. 이를 통해 데이터를 탈취하거나, 권한이 충분할 경우 데이터베이스를 변경할 수도 있습니다.

애플리케이션이 사용자 제어 데이터를 NoSQL 쿼리 표현식에 직접 삽입할 때, 이러한 표현식은 종종 데이터 탈취나 변조에 악용될 수 있는 함수나 내장 연산자를 포함하게 됩니다. 악의적인 의도로 이러한 코드가 실행될 경우 그 결과는 치명적일 수 있습니다.

MongoDB 데이터베이스는 이러한 취약점을 악용하기 가장 좋은 환경 중 하나입니다. "$ne: ""'은 SQL 세계의 1=1과 같은 연산자입니다. 예를 들어, 공격자가 사용자 이름과 비밀번호 입력란에 "$ne: “”’ 문자를 입력한다고 가정해 봅시다. 만약 해당 코드가 NoSQL 인젝션에 취약하다면, 데이터베이스는 사용자 이름과 비밀번호가 빈 문자열이 아닌 모든 레코드를 검색하게 됩니다. 즉, 모든 데이터를 찾아내는 것이죠. 정말 위험합니다.

만약 이 데이터베이스가 암호화되어 있지 않다면, 공격자는 데이터베이스 내의 모든 사용자 이름과 비밀번호를 탈취할 수 있습니다. 여기에는 관리자 계정도 포함되므로, 데이터베이스 전체에 대한 모든 권한을 얻게 되는 셈입니다.

공격자들은 종종 항상 참(true)이 되는 값을 입력하려고 시도합니다. 또 다른 흔한 공격 방식은 함수로 설정된 속성에 악성 코드를 주입하는 것입니다.

예를 들어, MongoDB는 $where라는 속성을 가진 객체를 인자로 받는 find 함수를 사용합니다. $where 속성은 참 또는 거짓을 반환해야 하는 함수로 설정됩니다. 만약 이 함수가 사용자 입력에 의해 조금이라도 변경된다면, 그곳에 NoSQL 인젝션 취약점이 숨어 있을 가능성이 큽니다.

NoSQL 인젝션의 복잡한 메커니즘에 대해 자세히 알고 싶다면 이 InfoQ 아티클을 확인해 보세요.

NoSQL 인젝션이 위험한 이유

NoSQL 인젝션이 위험한 주된 이유는 아직 보안 커뮤니티로부터 마땅히 받아야 할 만큼의 철저한 검증을 거치지 않았기 때문입니다.

NoSQL 인젝션의 영향은 기존의 SQL 인젝션과 거의 동일합니다. 데이터가 탈취되거나 변조될 수 있고, 탈취된 데이터로 계정이 도용될 수 있습니다. 가장 치명적인 경우, 삭제 명령이 성공적으로 실행되면 데이터가 완전히 삭제될 수도 있습니다.

결론적으로 MongoDB를 비롯한 NoSQL 데이터베이스 엔진도 공격에 취약합니다. "No SQL"이라고 해서 인젝션 공격이 없다는 뜻은 아닙니다.
다행히 커뮤니티 내 일부 전문가들이 이 문제를 인지하고 경각심을 일깨우고 있습니다. 더 많은 개발자가 스스로 학습하여, 방치할 경우 큰 골칫거리가 될 수 있는 이러한 잘 알려지지 않은 위협으로부터 자신의 앱을 보호해야 합니다.

NoSQL 인젝션 방어하기

NoSQL 인젝션은 방어하기가 까다로울 수 있습니다. 안타깝게도 SQL 인젝션처럼 매개변수화된 쿼리(parameterized queries)를 사용할 수 있는 옵션이 없기 때문입니다. 하지만 불가능한 것은 아닙니다. 다음은 도움이 될 몇 가지 방법입니다.

• 퍼저(Fuzzer)를 사용하여 취약점을 탐지할 수 있습니다. 하지만 세상의 많은 일이 그렇듯, 가장 단순한 접근 방식이 가장 효과적일 때가 많습니다. 이 경우, 꼼꼼한 코드 리뷰가 가장 강력한 무기가 됩니다.
• 코드를 검토할 때는 사용자 입력값이 표현식의 값을 설정하거나 함수를 변경할 수 있는 부분을 찾아보세요. 사용자 입력이 쿼리를 변경하지 못하도록 해야 합니다.
• 사용자 입력값은 반드시 올바른 클래스로 형변환(cast)하세요. 숫자라면 숫자로, 문자열이라면 문자열로 변환하는 식입니다.
• $where 또는 이와 유사한 eval 함수에 사용자 입력값을 절대 사용하지 마세요. 대부분의 경우 데이터 모델이나 스키마를 변경하여 해결할 수 있습니다.
• MongoDB 드라이버로 Mongoose를 사용해 보세요. Mongoose를 사용하면 NoSQL 데이터베이스의 스키마를 정의할 수 있습니다. 입력값이 문자열이라고 Mongoose에 명시하면, 해당 값은 문자열로 형변환됩니다. 따라서 공격자가 객체를 전달하더라도 객체가 아닌 문자열로 처리됩니다.
• 데이터베이스를 강화하세요! 권한이 낮은 사용자 계정을 생성하고, 쿼리 실행 시간을 제한하며, 조직의 보안 모범 사례를 항상 준수하세요.

NoSQL 데이터베이스의 편리함은 개발자가 보안을 고려하지 않은 채 데이터베이스를 구축하고 바로 사용하게 만드는 단점이 있습니다.

NoSQL 데이터베이스를 안전하게 구축하는 방법을 익히고 NoSQL 인젝션으로부터 스스로를 보호하는 시간을 갖는 것이 필수적입니다.

예를 들어, MongoDB Enterprise Edition은 문서에 대한 고급 액세스 제어 기능을 제공합니다. '최소 권한' 원칙을 적용하는 것은 애플리케이션에서 취약점이 발견될 경우를 대비한 훌륭한 심층 방어(DiD) 전략이 될 수 있습니다.

요약하자면 다음과 같습니다.

• NoSQL 쿼리 표현식에 사용하기 전에 입력값을 검증(Sanitize)하세요.
• Mongoose와 같이 도움이 되는 드라이버를 사용하세요.
• 쿼리 내에서 입력 데이터가 어떻게 사용되는지 중점적으로 코드 리뷰를 수행하세요.
• 퍼저와 스캐너를 사용하여 코드 내 취약점을 찾아보세요.

NoSQL이라고 인젝션이 없는 것은 아닙니다.

NoSQL 데이터베이스는 확장성과 빠른 구축 속도 덕분에 빠르게 인기를 얻고 있습니다. 하지만 새로운 기술인 만큼 개발자들이 보안을 고려하지 않고 사용하는 경우가 많습니다.

NoSQL 데이터베이스도 SQL 데이터베이스만큼이나 인젝션 공격에 취약할 수 있으므로, 항상 주의를 기울이고 쿼리를 세심하게 관리해야 합니다. 더 자세한 내용을 알고 싶다면 학습 리소스를 확인하거나 무료 데모를 통해 실력을 테스트해 보세요.

미리 대비하면 애플리케이션의 NoSQL 인젝션 걱정을 덜 수 있습니다. 아주 간단하죠!

NoSQL 인젝션을 지금 바로 찾아내고 수정할 준비가 되셨나요? 보안 코드 아레나에 입장하세요, 전사여!

2018년은 여기까지입니다! 올해의 마지막 게시물이지만, 2019년 1월 10일에 다음 'Coders Conquer Security' 가이드로 돌아오겠습니다. 곧 만나요!