Telegram Group & Telegram Channel
Как защититься от SQL-инъекций без prepared statements?

🔐 Альтернативные способы защиты от SQL-инъекций без prepared statements

1. Экранирование пользовательского ввода
Для MySQL можно использовать функцию mysqli_real_escape_string(), которая экранирует специальные символы в строке, делая её безопасной для использования в SQL-запросах.​

$login = mysqli_real_escape_string($conn, $_POST['login']);$query = «SELECT * FROM users WHERE login = '$login'»;


Однако этот метод не защищает от всех видов атак и может быть недостаточно эффективным, особенно если не учитывать кодировку и типы данных.​

2. Приведение типов и валидация данных
Если ожидается, что пользовательский ввод должен быть определённого типа (например, целое число), следует явно приводить его к этому типу и проверять допустимость значения.​


$id = (int)$_GET['id'];$query = «SELECT * FROM products WHERE id = $id»;



Это предотвращает внедрение вредоносного кода через параметры, ожидающие числовые значения.​

3. Белые списки допустимых значений
Для параметров, которые могут принимать ограниченный набор значений (например, порядок сортировки), следует использовать белые списки и проверять, что введённое значение входит в допустимый набор.​



$order = $_GET['order'];if (!in_array($order, ['ASC', 'DESC'])) {$order = 'ASC';}$query = «SELECT * FROM products ORDER BY price $order»;



Это предотвращает возможность внедрения произвольного SQL-кода через параметры.​
4. Использование хранимых процедур

Хранимые процедуры, определённые на стороне базы данных, могут помочь изолировать SQL-логику от пользовательского ввода. Однако они также могут быть уязвимы, если параметры не обрабатываются должным образом.​

⚠️ Почему эти методы менее надёжны

🔸 Экранирование и валидация требуют тщательной реализации и могут быть легко нарушены при изменении кода.​

🔸 Ошибки в логике проверки или упущенные случаи могут открыть путь для атак.​

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



tg-me.com/php_interview_lib/765
Create:
Last Update:

Как защититься от SQL-инъекций без prepared statements?

🔐 Альтернативные способы защиты от SQL-инъекций без prepared statements

1. Экранирование пользовательского ввода
Для MySQL можно использовать функцию mysqli_real_escape_string(), которая экранирует специальные символы в строке, делая её безопасной для использования в SQL-запросах.​

$login = mysqli_real_escape_string($conn, $_POST['login']);$query = «SELECT * FROM users WHERE login = '$login'»;


Однако этот метод не защищает от всех видов атак и может быть недостаточно эффективным, особенно если не учитывать кодировку и типы данных.​

2. Приведение типов и валидация данных
Если ожидается, что пользовательский ввод должен быть определённого типа (например, целое число), следует явно приводить его к этому типу и проверять допустимость значения.​


$id = (int)$_GET['id'];$query = «SELECT * FROM products WHERE id = $id»;



Это предотвращает внедрение вредоносного кода через параметры, ожидающие числовые значения.​

3. Белые списки допустимых значений
Для параметров, которые могут принимать ограниченный набор значений (например, порядок сортировки), следует использовать белые списки и проверять, что введённое значение входит в допустимый набор.​



$order = $_GET['order'];if (!in_array($order, ['ASC', 'DESC'])) {$order = 'ASC';}$query = «SELECT * FROM products ORDER BY price $order»;



Это предотвращает возможность внедрения произвольного SQL-кода через параметры.​
4. Использование хранимых процедур

Хранимые процедуры, определённые на стороне базы данных, могут помочь изолировать SQL-логику от пользовательского ввода. Однако они также могут быть уязвимы, если параметры не обрабатываются должным образом.​

⚠️ Почему эти методы менее надёжны

🔸 Экранирование и валидация требуют тщательной реализации и могут быть легко нарушены при изменении кода.​

🔸 Ошибки в логике проверки или упущенные случаи могут открыть путь для атак.​

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

BY Библиотека собеса по PHP | вопросы с собеседований


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/php_interview_lib/765

View MORE
Open in Telegram


telegram Telegram | DID YOU KNOW?

Date: |

Should I buy bitcoin?

“To the extent it is used I fear it’s often for illicit finance. It’s an extremely inefficient way of conducting transactions, and the amount of energy that’s consumed in processing those transactions is staggering,” the former Fed chairwoman said. Yellen’s comments have been cited as a reason for bitcoin’s recent losses. However, Yellen’s assessment of bitcoin as a inefficient medium of exchange is an important point and one that has already been raised in the past by bitcoin bulls. Using a volatile asset in exchange for goods and services makes little sense if the asset can tumble 10% in a day, or surge 80% over the course of a two months as bitcoin has done in 2021, critics argue. To put a finer point on it, over the past 12 months bitcoin has registered 8 corrections, defined as a decline from a recent peak of at least 10% but not more than 20%, and two bear markets, which are defined as falls of 20% or more, according to Dow Jones Market Data.

Mr. Durov launched Telegram in late 2013 with his brother, Nikolai, just months before he was pushed out of VK, the Russian social-media platform he founded. Mr. Durov pitched his new app—funded with the proceeds from the VK sale—less as a business than as a way for people to send messages while avoiding government surveillance and censorship.

telegram from es


Telegram Библиотека собеса по PHP | вопросы с собеседований
FROM USA