Как я могу избежать атак с использованием кода на SQL в своем приложении ASP.NET?
С помощью Postgres 9.4 это можно сделать немного короче:
select c.*
from comments c
join (
select *
from unnest(array[43,47,42]) with ordinality
) as x (id, ordering) on c.id = x.id
order by x.ordering
Удаление необходимости вручную назначать / поддерживать позицию для каждого значения.
С помощью Postgres 9.6 это можно сделать, используя array_position():
with x (id_list) as (
values (array[42,48,43])
)
select c.*
from comments c, x
where id = any (x.id_list)
order by array_position(x.id_list, c.id);
CTE используется, так что список значений должен быть только указанный один раз. Если это не важно, это также можно записать в виде:
select c.*
from comments c
where id in (42,48,43)
order by array_position(array[42,48,43], c.id);
14 ответов
Даже при том, что Ваш вопрос очень универсален, несколько правил всегда применяются:
- параметризированные запросы Использования (
SqlCommandсSqlParameter) и помещенный ввод данных пользователем в параметры. - не создают строки SQL из ввода данных пользователем непроверенного.
- не предполагают, что можно создать стандартную программу очистки, которая может проверить ввод данных пользователем на каждый вид уродливости. О пограничных случаях легко забывают. Проверка числового входа может быть достаточно проста добраться, Вы на безопасной стороне, но для строкового входа просто используете параметры.
- Проверка на уязвимости второго уровня - не создает строки SQL-запроса из значений таблицы SQL, если эти значения состоят из ввода данных пользователем.
- хранимые процедуры Использования для инкапсуляции операций базы данных.
Попытайтесь использовать Хранимые процедуры и проверить вход на Ваших данных. Не используйте прямой SQL как INSERT INTO...
Хотелось бы надеяться, это поможет:
http://www.codersbarn.com/post/2008/11/01/ASPNET-Data-Input-Validation.aspx
короткий ответ должен использовать параметризированные запросы.
Anthony :-) www.codersbarn.com
Внедрение SQL происходит, потому что запрос к базе данных создается в режиме реального времени, например:
SELECT * From Table1 WHERE " + UserInput
UserInput может быть злонамеренным и содержать другие операторы, которые Вы не предназначаете.
Для предотвращения его необходимо постараться не связывать запрос вместе.
можно выполнить, это при помощи параметрических запросов - проверяет эти DBCommand объект для конкретной разновидности DB.
Используйте параметры! Это действительно настолько просто :-)
Создают Ваши запросы как это (для SQL-сервера MS с C#):
SqlCommand getPersons = new SqlCommand("SELECT * FROM Table WHERE Name = @Name", conn);
Здесь @Name является параметром, где Вы хотите избежать, чтобы внедрение SQL и вести было объектом SqlConnection. Затем для добавления значения параметра Вы делаете следующее:
getPersons.Parameters.AddWithValue("@Name", theName);
Здесь theName является переменной, которая содержит имя, которое Вы ищете.
Теперь должно быть невозможно сделать любые внедрения SQL на том запросе.
, Так как это - это простое, нет никакой причины не использовать параметры.
Используйте Подготовленные Операторы (свяжитесь с учебным руководством ASP.NET, которое использует подготовленные операторы в разделе 'To add nodes for products'). вот и все.
ну, это или использование ORM, как Linq к SQL или NHibernate, они внутренне используют подготовленные операторы.
Поймите, что такое SQL Injection, и никогда не пишите ничего, что уязвимо для него.
В книге «Создание безопасных приложений ASP.NET» есть раздел по этой теме.
Всегда использовать только параметризованные запросы.
Как говорили другие, не объединяйте вводимые пользователем данные для создания динамических операторов sql; всегда используйте параметризованный SQL при использовании динамического SQL. Однако я отмечу, что это правило также применяется при создании динамического sql внутри хранимой процедуры . Этот факт люди часто упускают из виду. Они думают, что они безопасны, потому что «используют хранимые процедуры».
Скотт Гатри недавно опубликовал небольшую приличную статью об этом. В нем он предлагает 5 советов по защите себя:
Не создавайте динамические операторы SQL без использования типобезопасного механизма кодирования параметров. [...]
Всегда проводите проверку безопасности вашего приложения, прежде чем запускать его в производство, и установите формальный процесс безопасности, чтобы проверять весь код каждый раз, когда вы делаете обновления. [...]
Никогда не храните конфиденциальные данные в открытом виде в базе данных. [...]
Убедитесь, что вы пишете модульные тесты автоматизации, которые специально проверяют ваш уровень доступа к данным и приложение на предмет атак путем внедрения кода SQL. [... ]
Заблокируйте свою базу данных, чтобы предоставить веб-приложению, обращающемуся к ней, только минимальный набор разрешений, необходимых для работы. [...]
Он достойно объясняет , почему они важны, а также ссылки на несколько других ресурсов ...
Используйте параметризованные запросы и / или хранимые процедуры и анализируйте свои параметры с помощью параметров SQL. Никогда не генерировать код SQL путем объединения строк. Также почитайте о SQL-инъекциях и о написании безопасного кода, потому что предотвращение SQL-инъекций - лишь небольшая часть безопасности. Есть еще много других (например, XSS - межсайтовый скриптинг). Если хакер захочет взломать ваш сайт / приложение, он будет искать не только SQL-инъекцию.
Никогда не доверяйте вводу пользователя - Проверяйте все записи текстового поля с помощью элементов управления проверкой, регулярных выражений, код и т. д.
Никогда не используйте динамический SQL - Используйте параметризованный SQL или хранимые процедуры
Никогда не подключайтесь к базе данных с помощью учетной записи уровня администратора - Используйте учетную запись с ограниченным доступом для подключения к базе данных
Не храните секреты в виде обычного текста - Шифруйте или хэшируйте пароли и другие конфиденциальные данные; вам также следует зашифровать строки подключения
Исключения должны раскрывать минимум информации - Не раскрывайте слишком много информации в сообщениях об ошибках; используйте customErrors для отображения минимальной информации в случае необработанной ошибки; установите для отладки значение false
Полезная ссылка в MSDN Остановить внедрение SQL
НИКОГДА не доверяйте вводу пользователя, всегда проверяйте его и используйте параметры sql. Должно быть достаточно оснований для предотвращения внедрения SQL-кода.