Является ли экранирование только последнего параметра в запросе и завершение запроса "-" безопасным?

Question

Я думаю о практических решениях для этого избегания методов.mysql_query не выполняет два запроса одновременно, поэтому злоумышленник не может использовать такие вещи, как 'OR 1;удалить от пользователя;выберите * из // он будет угадывать остальную часть запроса здесь.(это сбивает с толку)

(мне явно не нравится pdo, в oop это непрактично, когда вам нужно определить соединение в каждой функции каждого класса, в противном случае я должен использовать $ this или global $ДБК каждый раз.)

Answer 1

Практическое решение побега заключается в следующем:

$blah = mysql_real_escape_string($blah, $connection);
$num = (int)$num;
$sql = "select * from `test` where foo = '$blah' and num_col = $num";

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

Если у вас есть только одно соединение, вы можете определить свою собственную функцию:

function qescape($var)
{
  global $connection;
  return mysql_real_escape_string($var, $connection);
}

У меня большая проблема с этим заявлением, которое вы сделали:

mysql_query не выполняет два запроса одновременно, поэтому злоумышленник не может использовать такие вещи, как

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

Answer 2

Нет, вам все еще нужно экранировать каждый нечисловой тип, а не только последний параметр.

Пример проверки, должно ли совпадение имени пользователя и пароля войти в систему пользователя:

// Check username / password
SELECT user_id FROM users WHERE username = 'nickb' AND password = 'password'

Если экранируется только последний параметр (пароль), то я могу передать это:

• username="nickb' --"

В результате:

SELECT user_id FROM users WHERE username = 'nickb'

Здесь пользователь входит в систему без пароля.

Answer 3

Не совсем, нет. Есть несколько способов, которыми запрос может быть «небезопасным», кроме того, чтобы спрятать отдельный DML или DDL или инструкцию. Например:

• Большой, очень плохо работающий подзапрос может быть использован для сканирования вашей базы данных.
• Ветвь предложения WHERE может вызывать произвольную хранимую процедуру с любыми возможными эффектами.

и каждый конкретный запрос должен быть проверен на возможность случайного кода, вставляемого посередине. Например, если результаты запроса будут каким-либо образом представлены пользователю, то подзапрос, указывающий на таблицу с информацией аутентификации, потенциально может позволить пользователю многое сделать вывод. (Представьте себе серию тестов where exists (select 1 from app_users where username = 'JoeAdmin' and password like 'a%'), затем password like 'ba%' после идентификации b и т. Д. Даже если хакер изначально не знает, что у вас есть таблица с именем app_users, они могут быстро понять, что используя такой подход к системным таблицам.)

Answer 4

Я не понимаю всей идеи.

Почему вы пришли к такому методу?
Существуют обычные методы экранирования / привязки / белого списка.
Почему ни один из них вам не подходит?Зачем придумывать что-то необычное и непригодное?

Я уже говорил вам много раз - экранирование не является чем-то «защищающим от инъекции».
Это всего лишь часть правил синтаксиса SQL.И только в качестве побочного эффекта он защищает ваши струны от инъекций.
Итак, вы все равно должны избегать (если не хотите связывать) свои струны.
Таким образом, бесполезны такие странные изобретениякак "экранирование только последнего параметра в запросе" на всех .

Есть идея?