Как избежать SQL-инъекций, давая разрыв строки в textarea в PHP и MySQL?

Question

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

<textarea name"description" id="description" rows="4" cols="50">
//In The text area the user enter the text. Here I want if user gives html links then links becomes text and if user give line break then line break store in the database and I can get back as it is how user submitted the form. Also I want to store data securely for avoiding sql injection but dont have the exact idea how to do it.
</textarea>

$text = $_POST['description'];
$text = htmlentities($text); // Here I want to remove html entities for avoiding sql injection
$text = mynl2br($text);
// Now Fire Insert Query All the data save but while retrieving the data I am not able to get line break and turning links to the text.


function mynl2br($text) { 
   return strtr($text, array("\r\n" => '<br />', "\r" => '<br />', "\n" => '<br />')); 
} 

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

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

Answer 1

В этом вопросе есть ряд ложных предположений, которые необходимо устранить.

1. Вы не должны никогда вводить предоставленные пользователем данные в запрос. Вы должны экранировать эти данные, и самый простой способ сделать это с помощью подготовленных операторов с использованием значений заполнителей . То есть ваш запрос выглядит как INSERT INTO x (a,b) VALUES (?,?), а затем вы связываетесь с каждым заполнителем. Драйвер SQL позаботится обо всем остальном, вам не о чем беспокоиться. В качестве немедленного бонуса вы больше не будете тратить время на отслеживание простых синтаксических ошибок в ваших запросах, потому что их будет очень легко читать, а ошибки будут очевидны.
2. Вы должны никогда отображать пользовательский контент без экранирования, соответствующего контексту, в котором он отображается. То есть для HTML вы используете экранирующие HTML-функции, такие как htmlspecialchars, чтобы избежать XSS (перекрестный сценариев) атак.
3. Вы должны никогда предварительно экранировать содержимое при вставке в базу данных. Вы должны вставить как можно более сырой и нейтральный. Если вы предварительно экранировали HTML, вы рискуете дважды экранировать, что может привести к появлению таких вещей, как &amp&, если вы проскальзываете. Помните, что не все является HTML. Иногда это JSON. Иногда это CSV. Иногда это тема письма. У каждого есть свой особый метод побега.
4. Если вы чувствуете, что находитесь здесь над головой, и вас легко обескуражить, потому что безопасность - сложная и многоплановая проблема , вам следует начать с известной надежной основы и строить оттуда, используя лучшие практики. Базового PHP недостаточно, вам нужна инфраструктура, такая как Laravel , Fat-Free Framework или любая популярная, проверенная, поддерживаемая сообществом инфраструктура, которая обеспечивает защиту от этих проблем вне коробка.

Если принять все это во внимание, вашей проблемы не будет.

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

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

<div style="position:absolute;top:0;left:0;right:0;bottom:0;background:red">Uh oh</div>

Тест на проблемы с внедрением SQL:

It's not so <strong>"Bad"</strong>!

Тест на поддержку UTF-8, как 3-байтовые "символы", так и 4-байтовые эмодзи:

Do you want to build a ☃? How about a ❄️☃️?

Я также создаю случайные строки длиной 255, 256, 1024 и 65535, чтобы посмотреть, что происходит с форматированием страницы при вставке длинных неразбитых строк букв. Многие страницы будут полностью взорваны, если такого рода тестирование не будет выполнено явно. В некоторых приложениях происходит сбой при длинном вводе из-за патологически некорректных регулярных выражений, или они не могут обнаружить содержимое большой длины перед вставкой и обнаруживают неожиданную ошибку усечения.

В фреймворках часто есть способы выражения ограничений в вашей форме и для аккуратной обработки любых ошибок проверки входных данных перед развертыванием с экраном «Ошибка SQL».

Answer 2

Чтобы сохранить новые строки, вы должны сохранить исходные разрывы строк. Если вы замените их, вам придется либо заменить их обратно, либо использовать nl2br только при отображении текста на странице (рекомендуется), а не перед его сохранением или извлечением. для редактирования.

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

Чтобы избежать SQL-инъекций, вы не хотите использовать эти магические функции (htmlentities, strip_tags, magic_quotes и т. Д. - их много, но ни одна из них не идеальна) - лучшее решение - использовать подготовленные операторы: https://dev.mysql.com/doc/apis-php/en/apis-php-mysqli.quickstart.prepared-statements.html

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