mysqli real escape string Предотвращает SQL-Инъекции?
Согласно документации, функция: Экранирует специальные символы в строке для использования в операторе SQL, принимая во внимание текущий набор символов соединения.
, То:
- Существует вероятность, SQL-Инъекция даже при использовании функции
mysqli_real_escape_string()
? - , Если используется в сочетании с
filter_input
для получения данных, можно повысить уровень безопасности приложений? - Какие функции могут быть объединены, чтобы приложение, чтобы стать более безопасным в этом случае Профилактики SQL-Инъекция?
Ссылки:
2 answers
Существует возможность SQL-Инъекции, даже при использовании функции mysqli_real_escape_string()?
Обычно нет, за исключением, если использовать charset странные. Предполагая, что используйте UTF8MB4 и всегда используйте "
(или '
) query, этого будет достаточно. В идеале charset используется также, с помощью mysqli_set_charset
.
Включительно, Cure53, компании по безопасности, утверждает, что использовать addslashes
- это страхование, при условии, что всегда используйте charset безопасный (и, по умолчанию будет использоваться), и всегда включайте значение на " ... "
в query.
Причина, по которой это не рекомендуется, вы можете забыть обработать переменную mysqli_real_escape_string()
или забыть простую "
. Конечно, только одна ошибка может привести все, что ниже.
, Если используется в сочетании с filter_input при получении данных, можно повысить уровень безопасности приложений?
Нет. Это может быть даже хуже, в конце концов, вы можете создать новый Wordpress и его многочисленные уязвимости XSS,, просто так "побег" данных и trucando них в базу данных.
Применить другие фильтры или салфетки до mysqli_real_escape_string
не оставит вас уязвимым для MySQL-Инъекции, но может создать другие проблемы.
, Какие функции могут быть объединены, чтобы приложение, чтобы стать более безопасным в этом случае Предотвращения SQL-Инъекции?
Нет. Просто используйте функции, которые были сделаны для желаемой цели. Использовать шаблон FILTER_SANITIZE_STRING
, например, может создать больше проблем, и не позволит решить SQL-Инъекции. Причина проста, этот фильтр был сделан не для SQL-Инъекции.
Используйте mysqli_real_escape_string
или использовать Prepared Statement, это те "роли", которые должны быть использованы для этой цели.
Ясно, что устраняет друга, пройдите тестирование, создание таблицы с помощью поля логин и пароль, а затем выполните следующие испытания (ПРИМЕЧАНИЕ: я отправляю пример, который я сделал, я использую класс для подключения к базе, но процесс-это даже не класс, что интересует SQL
):
<?php
include_once 'Query.class.php';
$login = "guilherme";
$senha = "1234";
$sql = 'SELECT * FROM `usuarios` WHERE login = "' . $login . '" AND senha = "' . $senha . '"';
echo "<pre>";
print_r(Query::Select($sql));
echo "</pre>";
?>
Этот код мне вернул Array()
с данными этого пользователя в базе:
Array
(
[0] => Array
(
[id] => 2
[email] => guilherme
[senha] => 1234
)
)
, То это означает, что SQL ищет информацию в базе правильно. Теоретически, как-то вернулся банк, только бы получить эту информацию и автоматически logaria парень, напр.:
<?php
... codigo imaginario anterior ...
$sql = 'SELECT * FROM `usuarios` WHERE login = "' . $login . '" AND senha = "' . $senha . '"';
$dados = Query::Select($sql);
if($dados != ""){
$SESSION["logado"] = $dados[0]; // Como só poderia retornar 1 conjunto de dados eu pego sempre o primeiro (não tem como existir 2 usuários iguais com senhas iguais)
}else{
// não achou nenhum user que combina com a senha
}
?>
Что произойдет, если не лечить-mos отправленные данные для входа в систему? пример:
<?php
include_once 'Query.class.php';
// SQL Injection
$login = '" or "1';
$senha = '" or "1';
$sql = 'SELECT * FROM `usuarios` WHERE email = "' . $login . '" AND senha = "' . $senha . '"';
echo "<pre>";
print_r(Query::Select($sql));
echo "</pre>";
?>
Возвращение этого будет следующий Array()
:
Array
(
[0] => Array
(
[id] => 1
[login] => administrator
[senha] => admin
)
[1] => Array
(
[id] => 2
[login] => guilherme
[senha] => 1234
)
[2] => Array
(
[id] => 3
[login] => carlos
[senha] => carlos
)
[3] => Array
(
[id] => 4
[login] => luiz
[senha] => luiz
)
)
Увидите, что он вернул всех пользователей базы, и, как первый пользователь, как правило, системный администратор в час, что этот Array()
, пройти мимо входа в сценарий человека, который поставил SQL Injection
вошли в систему как администратор (или с первого пользователя из таблицы зависит от того, как программист сделал правило входа на него).
Теперь, если мы оставим это, дорогая функция mysqli_real_escape_string()
вот результат:
<?php
include_once 'Query.class.php';
$login = '" or "1';
$senha = '" or "1';
/*
* A função Query::AntiSqlInjection() nada mais é que isso:
*
* static public function AntiSqlInjection($str) {
* self::AbreConexao();
* $str = mysqli_real_escape_string(self::$conn, $str);
* self::FechaConexao();
* return $sql;
* }
*
*/
$sql = 'SELECT * FROM `usuarios` WHERE login = "' . Query::AntiSqlInjection($login) . '" AND senha = "' . Query::AntiSqlInjection($senha) . '"';
echo "<pre>";
print_r(Query::Select($sql));
echo "</pre>";
?>
Таким образом, возврат будет VAZIO
, то человек, который пытается поставить на любой SQL Injection
в поля логин и пароль будут автоматически бежал и не признается (при условии, что вы не хранит SCAPED STRINGS
в базе ex: [ поле login = sergio/marques или поле "пароль" = edu'02"/3 ], чтобы избежать этого тип головной боли, всегда используйте md5
sha1
для шифрования данных и паролей, сохраненных в базе, требующих символов, пейзаж, таким образом вы позволите безопасности системы и позволяет избежать проблем, со сравнения данных. Это не применяется, если требуется расшифровать какие-либо данные, в этом случае используйте какие-либо функции, которая поддерживает режим шифрования, и для дешифрования, в интернете вы найдете несколько интересных функций).