Устраняет ли использование баз данных, отличных от SQL, необходимость защиты от «внедрения SQL»? - PullRequest
4 голосов
/ 01 декабря 2009

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

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

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

Ответы [ 4 ]

7 голосов
/ 01 декабря 2009

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

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

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

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

2 голосов
/ 01 декабря 2009

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

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

1 голос
/ 01 декабря 2009

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

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

1 голос
/ 01 декабря 2009

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

...