Как я могу избежать атак SQL-инъекций?

Question

Вчера я говорил с разработчиком, и он упомянул кое-что об ограничении вставок в поле базы данных, например, таких строк, как -- (минус минус).

В то же время я знаю, что это хороший подход к экранированию символов HTML, таких как <, > и т. Д. Не --. Это правда? Должен ли я беспокоиться о --, ++? Это больше похоже на миф или старые вещи?

---

Обновление

Большое спасибо за все ответы, это легко понять, так как я новичок во всем этом. Ну, чтобы быть более конкретным в этом случае, наша дискуссия была о веб-сайте C # ASP.NET MVC, который мы разрабатываем, поэтому существует сложная форма для открытия учетной записи с важной информацией, поэтому я не уверен, что MVC использует Linq Интерфейс с базой данных уже поставляется с такой защитой или нет. Так что, если бы кто-нибудь мог дать намёк на это, было бы здорово. Еще раз спасибо

Answer 1

Правильный способ избежать атак SQL-инъекций - НЕ просто запретить некоторые проблемные символы, а использовать параметризованный SQL. Короче говоря, параметризованный SQL не позволяет базе данных выполнять необработанный пользовательский ввод как часть команды SQL, что предотвращает выполнение пользовательского ввода, такого как «отбрасывание таблицы». Простое экранирование символов не останавливает все формы атак SQL-инъекций, а исключение определенных слов, таких как «Drop», не работает во всех случаях; могут быть определенные поля, в которых «Drop» является абсолютно допустимой частью ввода данных.

Вы можете найти несколько хороших статей на тему параматеризованного SQL здесь:

https://blog.codinghorror.com/give-me-parameterized-sql-or-give-me-death/

http://www.codeproject.com/KB/database/ParameterizingAdHocSQL.aspx

Теперь, когда вы упомянули, что работаете с ASP.net, я могу дать вам несколько ссылок, которые конкретно касаются SQL-инъекций в ASP.

https://dzone.com/articles/aspnet-preventing-sql-injectio http://www.codeproject.com/KB/aspnet/SQL_Injection_.aspx?msg=3209511

Вот более общая статья о том, как сделать ваш ASP более безопасным: http://www.codeproject.com/KB/web-security/Securing_ASP_NET_Apps.aspx

И, конечно, статья MSDN о внедрении SQL: http://msdn.microsoft.com/en-us/library/ms998271.aspx

Answer 2

Внедрение SQL - это высокий риск безопасности для большинства веб-сайтов, который позволяет пользователям вводить параметры в оператор, который выполняется в базе данных.

Простой пример:

Поле ввода "Имя: _________

"SELECT * FROM tblCustomer WHERE Name = '" + nameInputField + "'"

Так что, если я наберу "Боб", у нас будет

"SELECT * FROM tblCustomer WHERE Name = 'Bob'"

Но если я введу "'; DROP TABLE tblCustomer", мы получим довольно зловещий

"SELECT * FROM tblCustomer WHERE Name = ''; DROP TABLE tblCustomer"

Есть много способов избежать этих проблем, и многие встроены в тот язык, который вы используете, - вместо того, чтобы думать обо всех хитрых возможностях ";", "-", "/ *" и т. Д., Попробуйте и используйте то, что уже существует.

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

Answer 3

Использовать параметризованные запросы. Эти запросы представляют переменные как заполнитель в SQL, например select * from person where name = ?. После создания запроса SQL вы устанавливаете значения параметров в запросе. Параметризованные запросы гарантируют, что все, что было подставлено вместо заполнителя, не будет рассматриваться как часть оператора SQL.

См. статью Джеффа Этвуда для хорошего обзора параметризованных запросов.

Answer 4

Нет ничего «опасного» во вставке строки, содержащей --, в базу данных.

Опасно вставлять что-либо в таблицу базы данных, которая поступает непосредственно от пользовательского ввода без его обработки, в противном случае вы оставляете себя открытым для Атаки с использованием SQL . Пример: кодер позволяет пользователю вводить свое имя в поле, а пользователь вводит:

Joe '); drop table users; commit transaction; --

и затем кодер помещает это в свою базу данных MySQL следующим образом:

conn.execute("insert into users (username) values ('" + userInput + "')");

Boom Пользователь удалил таблицу пользователей (при условии, что у входа в базу данных были права на это, чего не должно быть - но это другая тема), потому что кодер не гарантировал, что строка от пользователя была экранирована правильно, и поэтому она была отправлена ​​непосредственно в механизм БД, и злоумышленник посмеялся. : -)

Используйте любые инструменты, предоставляемые вашей средой, для обеспечения правильного экранирования строк. Например, JDBC использует для этого класс PreparedStatement. В большинстве сред будет нечто подобное.

Answer 5

Он говорил о SQL-инъекциях атак, что совершенно верно в его словах.

Проблема не в том, что такие данные существуют в базе данных, а в передаче входных данных непосредственно в базу данных без их очистки.

Без очистки, если кто-то передает строку, заканчивающуюся ;, он может затем следовать за ней, когда захочет (например, select * from sys.objects) или что-то более вредоносное, например, отбрасывать некоторые таблицы.

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

Храните столько -- в вашей базе данных, сколько хотите, но не передавайте это в свою базу данных, не пройдя процесс очистки (здесь важна хорошая библиотека БД - она ​​должна очищать кавычки и другие потенциально опасные вход).

Answer 6

Это не опасно, если вы правильно экранируете данные при выполнении INSERT / UPDATE /...

И экранирование символов HTML НЕ - хороший подход. Представьте, что вы написали функцию, которая экранирует такие символы, и вы сохранили некоторый экранированный текст в базе данных. Затем вы замечаете, что ваша функция не экранирована '<', поэтому вы меняете функцию ... что теперь происходит с записями, которые уже находятся в базе данных? - Их символы «<» останутся в стороне. Таким образом, <strong>НИКОГДА экранирование текста перед его сохранением в базе данных (конечно, экранирование запроса SQL). Экранирование должно происходить, когда страница HTML / XML / ... создается из текста, то есть после запроса исходного текста из базы данных!