Устраняет ли использование баз данных, отличных от SQL, необходимость защиты от «внедрения SQL»?

Question

Это может показаться очевидным (или не очень очевидным) вопросом, но позвольте мне объяснить. Я кодирую сайт Google App Engine, используя технологию баз данных Google BigTable. Любой кодировщик App Engine будет знать, что у Google есть свой собственный ограниченный язык запросов, называемый GQL. В результате у меня возникает соблазн не выполнять никакой проверки на внедрение SQL (или GQL) в моем приложении, поскольку я предполагаю, что Google не использует необработанный строковый запрос в своих внутренних методах для извлечения данных.

Кроме того, библиотеки для технологий БД, таких как CouchDB, MongoDB и других баз данных объектов или документов (также известных как NoSQL), по-видимому, устраняют необходимость проверять, вводит ли злонамеренный пользователь команды манипулирования базой данных. У них часто есть библиотеки, которые напрямую сопоставляют объекты в базе данных с объектами на выбранном вами языке. Я знаю, что есть много библиотек SQL, которые также делают это, но я предполагаю, что на каком-то уровне они объединяют параметры для выполнения запроса над строкой, и поэтому я все еще должен использовать защиту SQL-инъекций даже с этими платформами.

Я близорукий? Или это только вопрос времени, когда появится следующая великая система БД, и тогда я увижу внедрение в эти системы?

Answer 1

«Инъекционные» дыры связаны с несоответствием контекста текста. Каждый раз, когда вы помещаете текстовую строку в другой контекст строки, вы должны выполнять кодирование, чтобы соответствовать измененному контексту. Соблазнительно просто соединять строки вслепую, но сложность обработки строк обманчива.

Базы данных с чисто объектным интерфейсом защищены от инъекционных уязвимостей, так же как и параметризованные запросы в SQL. Злоумышленник ничего не может вставить в свою строку, чтобы вырваться из контекста строкового литерала, в который вы его поместили.

Но GQL, в частности, не является одним из них. Это язык строковых запросов, и если вы объедините ненадежный неэкранированный материал в запрос, например " WHERE title = '% s' " % title , вы так же уязвимы, как и в полноценном SQL. Возможно, ограниченные возможности GQL затрудняют использование этого для полной компрометации приложения, но, конечно, не являются невозможными в целом, и в лучшем случае ваше приложение все еще не так и будет падать, когда люди попытаются законно использовать апострофы.

GQL имеет интерфейс привязки параметров. Используй это. Сопротивляйтесь привлекательности взлома строк.

Answer 2

SQL-подмножества, такие как GQL, очевидно, все еще занимаются этим, но чистые базы данных, отличные от SQL, такие как CouchDB, Voldemort и т. д., должны поставить & amp; получать данные без опасений для атак в стиле SQL-инъекций.

Это, однако, не освобождает вас от проверки контента, поскольку, хотя это может не повредить базу данных, оно может сломать ваше приложение и разрешить такие вещи, как XSS (если это веб-приложение).

Answer 3

Каждый раз, когда данные, которые поступают от пользователя или обрабатываются с его помощью, используются для управления выполнением кода, необходимо проводить санитарную обработку. Я видел случаи, когда код использовал пользовательский ввод для выполнения команды без очистки ввода. Он не использовался, но если бы это было так, это был бы ужасный вектор атаки.

Answer 4

SQl Injection - это только подмножество типа уязвимости безопасности, в которой оценивается любой неконтролируемый ввод.

технически, вы могли бы "ввести" " JavaScript, среди прочих.