XSS- и SQL-инъекции — две основные угрозы безопасности из-за непроверенного пользовательского ввода.
XSS можно предотвратить (когда нет WYSIWYG) с помощью htmlspecialchars(), а внедрение SQL можно предотвратить с помощью параметризованных запросов и связанных переменных.
Используя эти два метода, безопасно ли использовать весь несанитизированный ввод?
Вы всегда должны учитывать контекст, в котором используются данные. Потому что упомянутые функции и методы работают только в том случае, если они используются в соответствии с целью их использования. Это относится не только к HTML и SQL, но и к любому другому языку/контексту.
Что касается XSS, поскольку htmlspecialchars экранирует специальные символы HTML <, >, &, " и ' с помощью ссылок на символы HTML. , он защитит вас, только если вы поместите данные в контекст в HTML, где <, >, &, " или ' являются контекстом разделители, но не помогут, если применяются другие разделители (например, значение HTML-атрибута без кавычек, или вы уже ввели другой контекст в HTML (например, значение HTML-атрибута, которое рассматривается как код JavaScript, как атрибуты события on…; или в HTML-элементах, которые относятся к другому языку, например , <script> или <style>, где применяются другие/дополнительные правила). XSS, где ввод обрабатывается не сервером, а с помощью клиентского JavaScript. Так что бывают ситуации, в которых htmlspecialchars вам не поможет.
Однако, что касается эмулированных или реальных подготовленных операторов, вы должны быть в безопасности, так как уровень соединения с базой данных или СУБД возьмут на себя заботиться о правильной обработке данных. Если, конечно, вы все еще не создаете подготовленный оператор, используя неправильно обработанные данные.
Вот лишь некоторые возможные проблемы помимо XSS и SQL-инъекций:
simplexml_load_[file|string](): https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processingunserialize(): http://www.exploit-db.com/exploits/22398/system(), popen() и т. д.strcmp() обход с помощью массивовЭто всегда зависит от того, где вы передаете пользовательский ввод и как вы его дезинфицируете. Например, всегда используйте PDO для операций SQL, потому что даже при правильном экранировании злоумышленник может внедрить код SQL вообще без кавычек:
SELECT title, content FROM cms WHERE id = 1
Злоумышленник может изменить это на:
SELECT title, content FROM cms WHERE id = -1 UNION SELECT username AS title, password AS content from users LIMIT 1
В этом случае может помочь только intval(), а экранирование (mysql_real_escape_string, magic_quotes, addlashes и т.д...) вообще не поможет.
Также взгляните сюда: Используемые функции PHP
intval() на случай, если вы не используете PDO. PDO всегда должен быть правильным, потому что он предотвращает ввод вредоносных параметров.
- person thebod; 19.02.2014
Внедрение SQL — это лишь один из случаев более широкой угрозы внедрения кода. То есть любой случай, когда пользовательский ввод (или любой другой ненадежный контент) выполняется как код.
Это включает в себя такие вещи, как eval(), а также немало других векторов. Ответ от @thebod включает ссылку на отличный поток StackOverflow: Используемые функции PHP.
Даже внедрение SQL не может быть решено на 100% с помощью параметров или экранирования. Оба эти метода помогают очистить только отдельные значения в выражениях SQL. Вам также может потребоваться разрешить ввод данных пользователем для выбора таблиц, столбцов, ключевых слов SQL или целых выражений. Для них параметры и экранирование не помогают. Пример:
$sql = "SELECT * FROM mytable ORDER BY $sortcolumn $asc_or_desc";
В этом примере имя столбца для сортировки и направление (ASC против DESC) основаны на переменных. Были ли переменные установлены из доверенных входных данных или параметры $_GET использовались дословно, что привело к уязвимости SQL-инъекций?
Лучшим решением для таких случаев является белый список. То есть возьмите пользовательский ввод, сравните его со списком имен столбцов, которые разрешены для этого динамического запроса, и, если пользовательский ввод не соответствует ни одному из этих предопределенных вариантов, либо сбой, либо используйте значение по умолчанию.
Используя эти методы, ваш пользовательский ввод по большей части уже очищен. Если вы хотите сделать еще один шаг, вы можете выполнить проверку ввода перед запуском кода SQL. Например, проверка чисел только числовая, проверка длины пользовательского ввода и т. д.
