Случайное внедрение SQL-кода, запускаемое из SQL Management Studio - PullRequest
0 голосов
/ 25 апреля 2018

Странный способ выразить это, но не мог придумать лучшего способа назвать это.

Я знаю, что использование LINQ / Entity / SqlParam / etc в некоторой степени помогает в защите от SQL-инъекций. Мой клиент спрашивает, существует ли какая-либо ответственность от разрешения администратора БД среднего уровня, который выполняет SQL-запросы из Management Studio , случайно запускать вредоносный код, который уже сохранен как значение в БД.

Не думаю, что это будет проблемой, но потом я подумал о некоторых более сложных запросах, где у вас есть циклы и т. Д., Где он может прочитать значение поля электронной почты, которое может иметь значение, например:

--Let's say this value already is stored in the database
--since Linq/Entities/SqlParams prevented it from running in code
--but it obviously still stored it inside of the field.
x'; DROP TABLE members; --

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

1 Ответ

0 голосов
/ 25 апреля 2018

При написании хранимых процедур вы должны думать о внедрении SQL, аналогично тому, как вы пишете запросы в коде приложения.Вы никогда не должны объединять строковые параметры для встроенного SQL и просто выполнять его, вы должны сначала их санировать.

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

...