Я могу получить атаку с использованием кода на SQL от оператора SELECT?
Хотя Библиотека базовых классов включает Ping, BCL не включает tracert функциональности.
Однако быстрый поиск показывает две попытки с открытым исходным кодом, первое в C# второе в C++:
8 ответов
Чтобы ответить на ваши вопросы.
A: Да, вы можете получить атаку SQL-инъекции из любого запроса , который принимает параметры (даже вызывая хранимые процедуры, если вы не используете методы, предоставленные вашей платформой, а делаете это через вызовы SQL).
Меня попросили предоставить пример того, как можно сделать инъекцию даже с помощью хранимой процедуры. Я видел разработанные приложения, которые действительно используют хранимые процедуры, но таким образом:
// C# - DON'T DO THIS!
String regionName = assignedSomewhereElse();
SQLCommand sqlCmd = DatabaseConnection.CreateCommand();
SQLCommand sqlCmd.CommandText =
String.Format("EXECUTE sp_InsertNewRegion '{0}'", regionName);
sqlCmd.ExecuteNonQuery();
Очевидно, это не способ вызова хранимой процедуры. Вы должны использовать абстракции вашей платформы или параметризованные запросы.
B: SQLDataSource - это уровень абстракции для вашей базы данных. Он создаст для вас запросы SQL и автоматически очистит их, чтобы предотвратить внедрение.
Чтобы избежать внедрения, либо:
- Очистите входные данные
- Используйте уровень абстракции, предоставляемый вашей платформой.
- Используйте параметризованные запросы.
Предлагаю насладиться этим xkcd комиксом, хорошим уроком о внедрении sql
Вы можете получить атаку с помощью SQL-инъекции в любое время, когда по большей части не используете параметризованные запросы.
Если в вашем примере,
SELECT * from MyTable
нет данных, вводимых пользователем , так что все должно быть хорошо. Однако если что-то вроде:
SELECT * from MyTable WHERE name='x'
( x является параметром), тогда есть вероятность, что кто-то вставит некоторый SQL в свое имя.
B: ASP.NET использует параметризованные запросы, потому что он строит запрос на основе на параметры, которые вы предоставляете программно.
Взломы внедрения происходят, когда вы даете пользователю возможность манипулировать запросом, Поле поиска: [] [GO]
select * from myTable where keywords like '%$searchTerm%'
Затем хакер вставляет '; чтобы завершить запрос и написать любой другой запрос, который захотят.
если вы не используете параметризованные запросы, но объединяете, вы можете получить sql-инъекцию для любого типа оператора SELECT, UPDATE, DELETE или INSERT
В ответ на ваш комментарий - «что я должен делать?»
Для начала вы можете проверить текстовые поля или любой другой элемент управления, который будет использоваться для разрешения ввода. Если вы ищете число, убедитесь, что они вводят только цифры, если они вводят слово, убедитесь, что знаки препинания недоступны. Удалите символы вроде - и ', если в этом нет крайней необходимости. Все это можно сделать с помощью ajax и / или javascript. Также, Вот интересная статья о защите от инъекций. Также параметризованные запросы - отличный вариант
SQL-инъекция требует, чтобы строка SQL была объединена с некоторыми параметрами, управляемыми пользователем, поэтому, если оператор Select является постоянным, он невосприимчив к инъекциям. С другой стороны, если вы добавляете «WHERE user_id =» + userIdString, тогда инъекция возможна.
Чтобы избежать инъекций, не требуются хранимые процедуры, и вы не должны рассчитывать на дезинфекцию входных данных. Вместо этого просто привяжите к параметрам вместо того, чтобы манипулировать строками.
Взгляните на: http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlparameter.aspx
]Каждый раз, когда вы разрешаете пользователю вводить данные в динамический запрос sql, вы подвергаетесь риску внедрения. И sqldatasource не защищает вас от инъекции. Вставки, удаления, отбрасывания и т. Д. Все равно будут происходить.