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: |

Telegram Gives Up On Crypto Blockchain Project

Durov said on his Telegram channel today that the two and a half year blockchain and crypto project has been put to sleep. Ironically, after leaving Russia because the government wanted his encryption keys to his social media firm, Durov’s cryptocurrency idea lost steam because of a U.S. court. “The technology we created allowed for an open, free, decentralized exchange of value and ideas. TON had the potential to revolutionize how people store and transfer funds and information,” he wrote on his channel. “Unfortunately, a U.S. court stopped TON from happening.”

That growth environment will include rising inflation and interest rates. Those upward shifts naturally accompany healthy growth periods as the demand for resources, products and services rise. Importantly, the Federal Reserve has laid out the rationale for not interfering with that natural growth transition.It's not exactly a fad, but there is a widespread willingness to pay up for a growth story. Classic fundamental analysis takes a back seat. Even negative earnings are ignored. In fact, positive earnings seem to be a limiting measure, producing the question, "Is that all you've got?" The preference is a vision of untold riches when the exciting story plays out as expected.

telegram from nl


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