Какой использовать, интервал или Целое число

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

Теперь мы хотим предотвратить угрозы безопасности, такие как атаки SQL-инъекций, вопрос с вопросом (как предотвратить атаку SQL-инъекций с использованием PHP), быть более реалистичным, фильтрация данных или очистка входных данных - это случай, когда вы используете пользовательские данные внутри такого запроса, используя PHP или любой другой язык программирования, не соответствуют действительности или, как рекомендовано больше людей, использовать современные технологии, такие как подготовленный оператор или любые другие инструменты, которые в настоящее время поддерживают предотвращение внедрения SQL-инъекций, считают, что эти инструменты не больше? Как вы защищаете свое приложение?

Мой подход к внедрению SQL: очистка пользовательских данных перед отправкой их в базу данных (прежде чем использовать ее в любом запросе).

Фильтрация данных для (Преобразование небезопасных данных в безопасные данные) Невозможно использовать PDO и MySQLi , как вы можете защитить ваше приложение? Вы заставляете меня использовать их? Как насчет других языков, кроме PHP? Я предпочитаю предлагать общие идеи, поскольку он может использоваться для более широкой границы не только для конкретного языка.

1. Пользователь SQL (ограничение полномочий пользователя): наиболее распространенными операциями SQL являются (SELECT, UPDATE, INSERT), а затем, почему предоставление привилегий UPDATE пользователю, который этого не требует? Например, логин и поисковые страницы используют только SELECT, то почему пользователи БД на этих страницах имеют высокие привилегии? ПРАВИЛО: не создавайте одного пользователя базы данных для всех привилегий, для всех операций SQL вы можете создать свою схему как (deluser, selectuser, updateuser) в качестве имен пользователей для удобства использования.

см. Принцип наименьших привилегий

2. Фильтрация данных: перед созданием любого запроса пользовательский ввод должен быть проверен и отфильтрован, для программистов важно определите некоторые свойства для каждой входной переменной: тип данных, шаблон данных и длина данных . поле, которое является числом между (x и y), должно быть точно проверено с использованием точного правила, для поля, которое является строкой (текстом): шаблон имеет значение, например, имя пользователя должно содержать только некоторые символы, позволяющие сказать [a- zA-Z0-9_-.] длина изменяется между (x и n), где x и n (целые числа, x & lt; = n). Правило: создание точных фильтров и правил проверки - лучшая практика для меня.

3. Используйте другие инструменты: здесь я также соглашусь с вами, что подготовленный оператор (параметризованный запрос) и хранимые процедуры, недостатки здесь - это способы, требующие передовых навыков, которых нет для большинства пользователи, основная идея здесь состоит в том, чтобы различать SQL-запрос и данные, которые используются внутри, оба подхода могут использоваться даже с небезопасными данными, поскольку данные, вводимые пользователем, не добавляют ничего к исходному запросу, например (любое или x = х). Для получения дополнительной информации, пожалуйста, прочтите OwASP SQL Injection Prevention Cheat Sheet .

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

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

[1] UNION SELECT IF(SUBSTRING(Password,1,1)='2',BENCHMARK(100000,SHA1(1)),0) User,Password FROM mysql.user WHERE User = 'root'

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

Последний момент - обнаружение неожиданного поведения, требующего больших усилий и сложности; это не рекомендуется для обычных веб-приложений. Неожиданным поведением в пользовательском вводе является SELECT, UNION, IF, SUBSTRING, BENCHMARK, SHA, root после обнаружения этих слов, вы можете избежать ввода.

UPDATE1:

Пользователь отметил, что этот пост бесполезен, ОК! Вот что OWASP.ORG предоставил:

Первичная защита:

Вариант № 1: Использование подготовленных заявлений (параметризованные запросы)
Вариант № 2: Использование хранимых процедур
Вариант № 3: экранирование всех входных данных пользователя

Дополнительная защита:

Также соблюдайте минимальную привилегию
Также выполните: подтверждение ввода белого списка

blockquote>

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

Update2:

Из руководства PHP, PHP: Подготовленные утверждения - Руководство :

[ 1163] Escaping и SQL injection

Связанные переменные будут автоматически экранированы сервером. Сервер вставляет свои экранированные значения в соответствующие места в шаблон оператора перед выполнением. Чтобы создать соответствующее преобразование, сервер должен указать подсказку для типа связанной переменной. Дополнительную информацию см. В функции mysqli_stmt_bind_param ().

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

blockquote>

Update3:

Я создал тестовые примеры, чтобы узнать, как PDO и MySQLi отправляют запрос на сервер MySQL при использовании подготовленного оператора:

] PDO:

$user = "''1''"; //Malicious keyword
$sql = 'SELECT * FROM awa_user WHERE userame =:username';
$sth = $dbh->prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY));
$sth->execute(array(':username' => $user));

Журнал запросов:

    189 Query SELECT * FROM awa_user WHERE userame ='\'\'1\'\''
    189 Quit

blockquote>

MySQLi: ]

$stmt = $mysqli->prepare("SELECT * FROM awa_user WHERE username =?")) {
$stmt->bind_param("s", $user);
$user = "''1''";
$stmt->execute();

Журнал запросов:

    188 Prepare   SELECT * FROM awa_user WHERE username =?
    188 Execute   SELECT * FROM awa_user WHERE username ='\'\'1\'\''
    188 Quit

blockquote>

Понятно, что подготовленный оператор также избегает данных, и ничего больше.

Таким образом, как указано в предыдущем заявлении The automatic escaping of values within the server is sometimes considered a security feature to prevent SQL injection. The same degree of security can be achieved with non-prepared statements, if input values are escaped correctly, это доказывает, что проверка данных, такая как intval(), является хорошей идеей для целочисленных значений перед отправкой любого запроса, кроме того, предотвращение вредоносных пользовательских данных перед отправкой запроса является [ 1183] правильный и действительный подход .

Подробнее см. Этот вопрос: PDO отправляет необработанный запрос в MySQL, а Mysqli отправляет подготовленный запрос, оба дают тот же результат

Ссылки:

1. ] Шифрование SQL Injection
2. SQL Injection
3. Защита информации
4. Принципы безопасности
5. Проверка данных