Я хочу проверить мои данные от пользователя для XSS и SQL-инъекций, и вот как я пытался
if (isset($_GET['membernumber'])) { $mem = htmlentities($_GET['membernumber']); $memberparamter = cleanData($mem); } Но какой метод является лучшим / правильным способом проверки?
Способ 1
function cleanData($data) { $data=mysql_real_escape_string($data); $data=trim($data); $data=stripcslashes($data); $data=htmlspecialchars($data); $data=strip_tags($data); return $data; }
Способ 2
function cleanData($data) { $data=mysql_real_escape_string($data); $data=trim($data); $data=strip_tags($data); return $data; }
method3
htmlspecialchars(stripcslashes(trim($data)))
Как уже упоминалось, подготовленные операторы являются одним из лучших способов предотвращения инъекций SQL. т.е. вы не должны добавлять свои параметры как часть окончательной строки запроса. Вы должны использовать заполнитель параметров и добавить параметры через массив ключей / значений.
Если вы используете PDO, посмотрите на эту страницу, которая более подробно описывает подготовленные заявления:
http://php.net/manual/en/pdo.prepared-statements.php
Подробное объяснение входных фильтров PHP (и хорошая статья о санитации) можно найти здесь:
http://coding.smashingmagazine.com/2011/01/11/keeping-web-users-safe-by-sanitizing-input-data/
Посмотрите здесь, что касается собственных фильтров / санитариев PHP:
http://www.php.net/manual/en/filter.filters.php
Вероятно, вас интересуют функции filter_var и filter_input:
Кроме того, у этого вопроса есть несколько хороших указателей: какой лучший метод для дезинфекции ввода пользователя с помощью PHP?
У этого вопроса также очень хорошие указатели: Каковы наилучшие функции дезактивации ввода PHP?
Если вы хотите предотвратить атаки SQL-инъекций, используйте подготовленные инструкции. Когда вы делаете что-то вроде
SELECT * FROM TABLE WHERE id = $_GET['x']
Проблема с этим запросом – это переменная, которая считается частью оператора SQL. Это означает, что СУБД будет анализировать / компилировать и выполнять переменную вместе с остальной частью запроса. Так эффективно, я мог бы предоставить что-то вроде
$x = "1); DROP TABLE users;"
и поскольку его часть инструкции сервер выполнит эту команду.
Когда вы вводите подготовленные операторы, область видимости переменной будет ограничена областью действия параметра и не будет влиять на оставшуюся часть запроса, даже если она не экранирована. Это связано с тем, что SQL-оператор анализируется / выбирается / скомпилируется и т. Д. В базе данных, и все, что вам нужно сделать, это привязать параметры. Оператор sql является шаблоном .
SELECT * FROM TABLE WHERE id = ?
Дополнительным преимуществом использования подготовленных операторов является скорость. Поскольку шаблон уже разобран / скомпилирован и т. Д., База данных не потребуется повторять этот процесс, и поэтому его можно использовать повторно, все, что вам нужно сделать, это заменить параметры.
В PHP функции PDO и mysqli_ * поддерживают подготовленные операторы.
Для mysqli см. http://php.net/manual/en/mysqli.prepare.php. Для PDO см. http://php.net/manual/en/pdo.prepare.php.
Что касается XSS-атак, вы можете сделать несколько подходов к этому. Во-первых, просто избегать ЛЮБОГО пользовательского ввода, когда печатается на странице. Столь опасные символы:
<>"" // and so on
Будет заменен их эквивалентом сущности html. Таким образом, в случае <script> он будет преобразован в <script> ,
Вы также можете настроить белый список, в котором вы разрешаете только теги X для ввода пользователем. Это особенно полезно для сайтов, ориентированных на контент, где пользователям может потребоваться доступ к определенным тэгам html, таким как divs, p tags и т. Д., Но, например, не теги скриптов. Любые теги, не входящие в белый список, будут отфильтрованы. Это довольно сложно полностью покрыть, поскольку существует так много способов сделать что-то, но тем не менее оно может обеспечить дополнительную безопасность. Подробнее см. http://php.net/manual/en/function.filter-var.php .
Третий подход заключается в замене html-тегов на пользовательские теги (например, SO). Таким образом, звезда infront слова может представлять <strong> html и т. Д.
Обратите внимание: если вы заняли последние два, вы должны ВСЕГДА избегать данных. Все входные данные пользователя должны рассматриваться как потенциально опасные, даже если они отфильтрованы, потому что, как говорится, всегда есть несколько способов кошки кошки.
Ни один из них не является достаточно эффективным.
Вы должны искать дезинфекцию, как и вы, и использовать подготовленные заявления.
XSS $ data = htmlspecialchars ($ data); sql injection $ data = stripcslashes ($ data);
если данные будут сохранены в db, а затем отобразятся на веб-странице, вы должны оба из них.