2013-05-10 2 views
1

Эта хранимая процедура проверяет имя пользователя и пароль и возвращает 1, если учетные данные соответствуют другим 0.Является ли эта хранимая процедура уязвимой для SQL-инъекций?

CREATE PROCEDURE usp_CheckPermisssions 
    @UserName NVARCHAR(50), 
    @Password NVARCHAR(50) 
AS 
BEGIN 
    SET NOCOUNT ON; 

    IF EXISTS(SELECT 1 FROM dbo.Users WHERE [email protected] and [email protected]) 
    RETURN 1 
    ELSE 
    RETURN 0 
END 
GO 

Это всего лишь образец хранимой процедуры. Я просто хочу узнать о методах SQL-инъекций, чтобы мой код не был введен.

Предположим, что входы не дезинфицированы в переднем конце.

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

Нет: входные данные передаются через передний конец.

Мой вопрос в другом слова

Может кто-нибудь сделать инъекцию на этот запрос? Если да, то как?

ответ

0

Первого правила для предотвращения SQL Injection является:

НЕ CONCATENATE вашего запроса струн USER INPUT.

Используйте параметры, как в вашем примере!

КПП. ваш пример не работает, потому что вы просто объявляете @ -variables без присвоения какого-либо значения. должны быть параметры для вашей хранимой процедуры f.e.

+0

Почему пользовательский ввод только? –

+0

Потому что это первое эмпирическое правило. Есть еще: P –

+0

Зачем разделять одно правило на два? Не могут ли данные сервера также содержать служебный символ? –

5

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

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

Пример опасного кода:

string userName = Request.Form("username"); 
string password = Request.Form("password"); 

int ok; 
using (SqlConnection conn = new SqlConnection(connStr)){ 

    // parameters are not encoded correctly, so totally open to SQL INJECTION! 
    string query = "usp_CheckPermissions '" + userName + "', '" + password + "'"; 

    using (SqlCommand cmd = new SqlCommand(query, conn)) { 
    cmd.CommandType = CommandType.Procedure; 
    ok = cmd.ExecuteScalar(); 
    } 
} 

Если войти в систему с паролем ';drop table Users;--, это было бы плохо ...

0

Microsoft имеет некоторые полезные documentation на инъекции SQL. Как это объясняет, есть два сценария:

  • вход немедленно объединяется с другим кодом и выполненные
  • вход сохраняется непосредственно в таблице и извлекать позже, сцепляются с другим кодом и выполняется

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

Проблема в том, что в большинстве систем ';drop table Users;-- - это абсолютно правильный пароль, потому что в общем случае пароли не должны проверяться системой.Поэтому кто-то может ввести это как пароль, надеясь, что позже он будет конкатенирован и выполнен.

Это означает, что вам нужно постоянно использовать параметры во всем, во всем вашем коде. И если некоторые данные полностью находятся под контролем пользователя - например, пароли - тогда вам нужно убедиться, что вы справляетесь с ними должным образом даже после того, как они были введены.

Смежные вопросы