Либо использование баз данных, отличных от SQL, устраняет необходимость в защите от «SQL-инъекции»?

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

techincally, вы можете «ввести» javascript, среди прочих.