На моем веб-сайте у меня есть переменная с именем $user_data которая содержит входные данные из формы. Затем я показываю эту переменную на странице пользователя (через эхо).
Каков наилучший способ избежать любых рисков безопасности с помощью этой переменной? Я использую strip_tags() , но этого недостаточно.
Эта переменная также сохраняется в базе данных MySQL.
Есть две очень важные вещи, которые вы должны сделать, чтобы избежать серьезных проблем безопасности.
Перед тем, как поместить его в свой SQL-запрос, вам нужно избежать ввода пользователя. Escaping означает escape всех специальных символов, таких как ' ; к счастью, есть функция, которая уже делает это автоматически: mysql_real_escape_string .
Если вы не избегаете ввода пользователя, могут произойти неприятные вещи. Представьте, что ваш запрос INSERT INTO userdata VALUES ('$user_data') . Теперь представьте, что пользователь написал '; DROP DATABASE userdata; '; DROP DATABASE userdata; ,
Если вы не избежите этого, ваш запрос станет следующим: INSERT INTO userdata VALUES (''; DROP DATABASE userdata;') . Как вы можете себе представить, это нехорошо: если у вас включено несколько операторов, вы можете поцеловать прощание с вашей базой данных. Это называется атакой SQL Injection .
Когда вы выводите свою переменную пользователю, вам также необходимо правильно заменить специальные символы HTML на объекты HTML. К счастью, есть функция сделать это тоже: htmlspecialchars () . Он преобразует специальные символы HTML, такие как < to < ,
Это, кажется, проблема, которая часто недооценивается, но на самом деле это очень серьезно. Представьте, что $user_data содержит <script>SomeNastyScript()</script> . Он может использовать существующие уязвимости в браузере ваших пользователей или может отправить злоумышленнику cookie, не относящемуся к HTTPOnly (который может содержать сохраненные пароли), или он может обмануть пользователя в написании пароля в форме, сгенерированной путем манипуляции DOM (возможно в javascript) или много других плохих вещей.
Это называется XSS (межсайтовый скриптинг).
Вызовите mysql_real_escape_string в строке перед тем, как вставлять ее в ваш SQL-запрос (но не при mysql_real_escape_string ).
Вызовите htmlspecialchars в строке перед отображением ее пользователю (но не тогда, когда вы поместите ее в базу данных).
Когда вы собираетесь что-то выводить, strip_tags или htmlspecialchars в порядке. Я предпочитаю последнее, так как тогда вы не полностью уничтожаете <3 и т. Д., Которые никогда не назывались HTML-тегами.
При непосредственном вводе значения в запрос mysql_real_escape_string является подходящим способом выхода или просто использованием PDO и подготовленных операторов.
Конечно, лучше всего использовать эти методы эвакуации только тогда, когда они вам понадобятся, а не применять оба значения ко всем переменным. Это всегда больно, чтобы вырезать черты обратно из переменной с экранированием MySQL, если вы хотите работать с ней прежде, чем поместить ее в базу данных, и это не лучше, чем волшебные цитаты PHP4. Аналогично, вы не хотите превращать чей-то пароль «один <два» в «один и два», прежде чем вставлять его в базу данных. (Очевидно, вы не должны хранить пароли открытого текста, но общий пример стоит.)
Нет такой вещи, которая называется «секретность».
Невозможно просто защитить абстрактную переменную. Все зависит от сценария.
Презервативы, обычно используемые для обеспечения безопасности. Не могли бы вы защитить свои деньги презервативом? Полагаю, нет.
Тоже самое. Вам лучше выделить эти два вопроса – безопасность базы данных и отображение безопасности.
База данных немного сложнее, чем просто «Вызовите mysql_real_escape_string». Я полностью описал все правила в этом ответе
Вы также можете сделать это:
$way = preg_replace('#[^a-z0-9]#i', '', strip_tags(htmlentities(htmlspecialchars(mysqli_escape_string($db_conx, $_GET['way'])))));