2019년 3월 5일에 처음 게시됨
응용 프로그램 개발자, 데이터베이스 관리자(DBA) 또는 기술 전문가라면 코드 주입을 주의해야 합니다.
안전한 클라우드 환경이 있습니다. 데이터베이스 액세스가 잠겨 있습니다. 하지만 애플리케이션 코드는 어떻습니까? 더 안전한 것으로 간주되지만 아니요 NoSQLi에서 주사할 수 없다는 의미는 아닙니다! NoSQL은 다른 데이터베이스 코드만큼 코드 주입에 취약할 수 있습니다. 코드 삽입을 방지하지 않는 것은 문에 보안 시스템을 설치하고 뒷창문을 열어 두는 것과 같습니다.
코드 주입이란 무엇입니까?
코드 삽입은 단순히 주입되는 검증되지 않은 데이터입니다. (또는 추가) 취약한 프로그램에 응용 프로그램 코드 형태로 실행되어 종종 치명적인 결과를 초래합니다.
SQLi는 가장 일반적인 주입 유형 중 하나이며 10년이 넘었지만 여전히 강력합니다. 주입 문제는 데이터베이스 언어에만 국한되지 않습니다. SQL 및 NoSQL 외에도 XPath®, XML 파서, SMTP 헤더 및 기타 컨텍스트에서 삽입이 발생할 수 있습니다. 심각도에 따라 코드 삽입은 원격 코드 실행(RCE)과 유사합니다. 게임 오버 침투 테스트 화면입니다.
애플리케이션에서 NoSQLi를 감지하고 방지하는 것이 중요합니다. 완화되지 않은 주입 벡터를 허용하면 사용자 기반의 안전을 위협할 수 있으며 이는 비즈니스 종료에 따른 신뢰 상실을 의미합니다. 다행히도 테마 역학을 이해한 후에는 서비스에서 NoSQLi 취약점을 감지하고 방지하기 위한 구체적인 조치를 취할 수 있습니다.
간단한 NoSQLi 예제
일반적으로 MongoDB®는 보안 BSON 쿼리 구성 도구를 사용하여 구성된 이진 JSON(BSON) 데이터를 수집합니다. 그러나 특정 경우에 MongoDB는 $where와 같은 직렬화되지 않은 JSON 및 Javascript(JS) 표현식도 허용할 수 있습니다. operator.SQL과 마찬가지로 $where 연산자는 NoSQL에서 잠재적인 주입이 발생하기 쉽습니다. 그러나 SQL과 달리 NoSQL $where 조건문을 JS로 표현합니다. 이것은 SQL이 제공하는 것에 제한되지 않고 가능한 인젝션 쿼리를 만들기 위해 JS의 완전한 표현력을 사용할 수 있음을 의미합니다.
이와 같은 공개 리포지토리의 MongoDB 주입 문자열 목록을 살펴보면 SQL 및 기타 언어의 유사한 취약점과 유사한 일반적인 주입 전략 중 일부를 보여줍니다. 예를 들어 일부는 고전적인 1 == 1을 사용합니다. 숨겨진(또는 관리자 수준) 리소스 및 권한을 다시 시도할 때 쿼리가 true 값을 반환하도록 하는 표현식:
$Where: '1 == 1'
다른 스니펫은 sleep()를 사용하여 블라인드 인젝션 전략을 에뮬레이트합니다. DB 속도를 늦추고 교묘하게 설계된 필터와 함께 민감한 정보를 열거하는 부작용을 만드는 기능:
';sleep(5000); ';it=new%20Date();do{pt=new%20Date();}while(pt-it<5000);
그리고 물론 삽입된 쿼리가 중요한 정보를 직접 일치시키고 검색하려고 하는 평범한 오래된 데이터 유출이 있습니다.
' && this.password.match(/.*/)//+%00
첫 번째 예제 이후에 나머지 두 개는 $where를 사용하지 않습니다. 운영자. NoSQL DB를 공격하기 위한 발판으로 편리한 JS-flavoredexpression이 필요하지 않습니다.
NoSQLi 방지
NoSQLi 내성 애플리케이션 아키텍처를 구축하려고 할 때 추구해야 할 몇 가지 일반적인 전략이 있습니다. 일반적인 주사 금지 지침을 따른다는 것은 놀라운 일이 아닙니다.
MongoDB / NoSQLi도 예외는 아닙니다
어떤 사람들은 코드 인젝션을 SQL에 한정된 것으로 보고 다른 컨텍스트에 적용된 인젝션 원칙의 유효성을 과소평가합니다. 이 게시물이 NoSQLi가 있다 진짜. 이것은 MongoDB가 Node.js 앱에서 NoSQL 주입을 방지하지 않습니다
와 유사한 게시물에 잘 설명되어 있습니다.검증되지 않은 사용자 데이터를 신뢰하지 않음
보안상의 이유로 사용자를 신뢰해서는 안 됩니다!
이것은 보안의 진부한 표현으로 보일 수 있지만 모든 입력은 악의적인 의도로 조사될 것으로 예상됩니다. $where 앞의 예는 $where: unvalidated_input 행을 따라 무언가를 할 수 없는 이유를 명확하게 보여줍니다. —이 시점에서 필터를 사용자에게 노출하고 있다고 생각할 수도 있습니다(충분히 나쁩니다!). 사용자가 검증되지 않은 데이터를 더 큰 쿼리에 도입한다는 사실은 모범 사례가 아닙니다.
언어 또는 통합 세부 사항에 주의
NoSQLi가 주입에 면역이 된다는 점에서 특별하지는 않지만(그리고 많은 동일한 유형의 공격을 겪고 있음), 이것이 NoSQLi 또는 심지어 언어나 구성 요소에도 고유한 전략이 없다는 것을 의미하지는 않습니다. NoSQL DB를 기반으로 구축되었습니다. 대표적인 예는 $where 이후로 PHP 변수로 전달되는 방식으로 형식이 지정되면 PHP 애플리케이션 위에 구축된 NoSQL DB는 이를 설명해야 하며 $where에 저장된 악성 문자열 삽입의 가능한 시나리오를 고려해야 합니다. .
결론
다시 말하지만 아니요 NoSQLi에서 주사 불가를 의미하지는 않습니다! SQL, SMTP 헤더, XML 및 기타 컨텍스트와 유사한 NoSQL은 코드 삽입 및 기타 많은 기술을 괴롭히는 애플리케이션 코드가 아닌 애플리케이션 코드로 처리하는 일반적인 함정에 취약합니다.
이 게시물을 통해 NoSQLi와 이것이 비즈니스에 미치는 영향에 대해 더 잘 이해할 수 있기를 바랍니다. 이제 코드를 덜 널리 퍼뜨리고 덜 널리 퍼뜨리고 덜 영향을 미치는 프로세스로 조정할 수 있습니다. 앱과 호스팅 환경이 안전한지 확인하기 위해 MongoDB 관리 조언이 필요한 경우 Rackspace ObjectRocket이 도움을 줄 수 있는 경험 많은 DBA를 보유하고 있습니다.
Rackspace DBA 서비스에 대해 자세히 알아보십시오.
피드백 탭을 사용하여 의견을 작성하거나 질문하십시오. 영업 채팅을 클릭할 수도 있습니다. 지금 채팅하고 대화를 시작하세요.