Каков самый безопасный способ добавления html / css / js в mysql?

В настоящее время я использую следующий класс PHP для хранения кода html, css и javascript в моей базе данных mysql.

function filter($data) { $data = trim(htmlentities(strip_tags($data))); if (get_magic_quotes_gpc()) $data = stripslashes($data); $data= strip_tags($data); $data = mysql_real_escape_string($data); return $data;} 

Мне действительно интересно, безопасен ли используемый код для хранения кода HTML / CSS / JS в базе данных mysql?

Solutions Collecting From Web of "Каков самый безопасный способ добавления html / css / js в mysql?"

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

Mysql не отличается между содержимым текста, поэтому не имеет значения, является ли это HTML, CSS, JS-код или ваши друзья последним.

Однако, если вы выведете текст позже, вы должны позаботиться о том, чтобы после ввода данных из mysql не было ненужной инъекции кода. Но на самом деле это не связано с MySQL.

Чтобы сделать вас более безопасным, передайте дескриптор базы данных в mysql_real_escape_string или еще лучше используйте MySQLi и / или PDO и подготовленные операторы.

Ваш код

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

 function filter($data) { $data = trim(htmlentities(strip_tags($data))); if (get_magic_quotes_gpc()) $data = stripslashes($data); $data= strip_tags($data); $data = mysql_real_escape_string($data); return $data;} 

Нормализовать данные перед их обработкой

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

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

 function filter($data) { // normalize $data because of get_magic_quotes_gpc $dataNeedsStripSlashes = get_magic_quotes_gpc(); if ($dataNeedsStripSlashes) { $data = stripslashes($data); } // normalize $data because of whitespace on beginning and end $data = trim($data); // strip tags $data = strip_tags($data); // replace characters with their HTML entitites $data = htmlentities($data); // mysql escape string $data = mysql_real_escape_string($data); return $data; } 

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

Больше проблем с вашей функцией

Даже функция теперь выглядит лучше, она все еще имеет много проблем. Например, непонятно, что делает функция на самом деле. Он делает много вещей сразу, а некоторые из них противоречат друг другу:

  • Он удаляет теги HTML, которые являются признаком того, что $data не должны содержать HTML
  • Но тогда вы преобразовываете текст $data чтобы фактически содержать объекты HTML.

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

Поэтому вы должны просто выбросить код и рассмотреть следующее:

  • Если вход в ваше приложение недействителен, не фильтруйте его. Вместо этого предотвратите дальнейшее использование недопустимого ввода. Поэтому вам необходимо выполнить функцию проверки ввода, прежде чем использовать ее.
  • Не изменяйте данные только потому, что считаете, что это может сделать что-то более безопасным. Вместо этого измените и закодируйте данные там, где это необходимо и уместно.
    • Сделайте свое приложение только работающим с магическими котировками. Опираясь на эту функцию, очень не рекомендуется. И тогда нет необходимости проверять все это в коде.
    • Чтобы что-то безопасно хранить в базе данных, избегайте данных, прежде чем использовать их только в запросе. Не в каком-то другом месте вашего заявления. Для этого используйте Подготовленные утверждения.
    • Не нужно перебивать данные, прежде чем вносить их в базу данных, если они действительны. Но вам нужно правильно закодировать его, когда вы выводите его на веб-страницу . И только там приложение знает, в какой кодировке это должно быть. Вы не знаете, что когда вы помещаете данные в базу данных.

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

  1. Никогда не доверяйте данным пользователя.
  2. Обеспечьте, чтобы данные находились в том формате, в котором вы нуждались в предварительной обработке .
  3. Используйте правильный инструмент для работы в нужном месте.
  4. Никогда не используйте инструменты. Получайте знания вместо этого, которые платят не только безопасность.