2012-02-11 1 views
0

Учитывая это MySQL хранимые процедуры:Возможная инъекция SQL, удаляющая таблицу с хранимой процедурой?

CREATE PROCEDURE customer.`getCustomers5`(
sdf varchar(1000) 
) 
BEGIN 

set @se = concat('select * from customer.customertbl where id=', sdf); 


PREPARE stm1 from @se; 

EXECUTE stm1; 

END; 

Можно ли делать инъекции SQL в эту процедуру магазина, даже если передний конец, который называется эта хранимая процедура использует PDO параметр/привязки данных?

Прежде чем вызывать его, мне нужно создать запрос динамически (предложение dynamic where).

Если это возможно сделать SQL-инъекцию, есть ли способ противостоять этой проблеме?

+0

http://stackoverflow.com/questions/60174/best-way-to-stop-sql-injection-in-php. Короче говоря, PDOs вы должны быть в безопасности. aaand http://php.net/manual/en/pdo.prepared-statements.php –

+0

@SergeyBenner, похоже, у вас нет вопроса. –

+0

-1 для запроса неопределенного вопроса, который получается «нет, я не имел в виду, что код совершенно другой». –

ответ

-1

Если ваш параметр является varchar, и вы отправляете строку, то да, это возможно, потому что, даже если вы используете PDO, это все равно будет ЛЮБАЯ строка.

Вы должны определить sdf как свой тип id (это целое число, если нет, сделать его целочисленным!), А затем параметр PDO будет экранирован и избежать SQL Injection.

Хорошей практикой является предотвращение создания динамических запросов в хранимой процедуре и построение запроса в приложении.

+0

Да, Id целое, я просто тестировал предел. другой вопрос, если есть много заявлений sql, было бы лучше консолидироваться в хранимой процедуре или на уровне приложения? – Melvin

+0

хранимая процедура в порядке. но вам придется следить за всеми вашими ожиданиями блокировки/блокировки и так далее. –

+0

Если вы выполняете много операторов SQL для вычисления одного результата, лучше всего консолидировать его в хранимой процедуре. Таким образом, приложение не должно запрашивать несколько запросов и сохранять данные локально для дальнейшей обработки. Итак, постарайтесь создать максимально сложные запросы, чтобы сделать все вычисления на сервере базы данных, и вы можете поместить их в хранимые процедуры для упрощения доступа/обслуживания. Вам все равно следует избегать создания динамических запросов в хранимых процедурах, возможно, добавьте больше параметров или создайте больше процедур для соответствия каждому сценарию. –

2

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

DELIMITER // 
CREATE PROCEDURE customer.`getCustomers5`(sdf varchar(1000)) 
BEGIN 
    PREPARE stm1 from 'select * from customer.customertbl where id=?'; 
    SET @a = sdf; 
    EXECUTE stm1 using @a; 
END// 
DELIMITER ; 
+0

SQL-оператор, который я хочу сделать, является динамическим, количество параметров не определено. в этом случае метод set @a не будет работать. Думаю, мне все равно нужно построить уровень SQL @ Application. – Melvin

+0

Извините, приятель, но ваш комментарий выглядит глупо. set @a использует переменную stm, которая, по-видимому, не является динамической инструкцией вообще. Если вам нужно создать SQL динамически - никаких проблем. Создайте подготовленный SQL с заполнителями, а не значениями. Это неважно. Только вам нужно научиться и слушать. –

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