Как избежать «межсайтовых скриптовых атак» - PullRequest
9 голосов
/ 09 августа 2010

Как избежать межсайтовых скриптовых атак?

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

Я уверен, что это может быть сделано FX.в PHP по проверке форм но я не достаточно опытен, чтобы fx.Запретите javascript или другие вещи, которые могут навредить вам.

Надеюсь, вы понимаете мой вопрос и можете мне помочь.

Ответы [ 2 ]

14 голосов
/ 09 августа 2010

Я уверен, что это можно сделать FX.в PHP путем проверки форм

Не совсем.Стадия ввода - совершенно неправильное место для решения проблем XSS.

Если пользователь вводит, скажем, <script>alert(document.cookie)</script> во ввод, нет ничего плохого в этом самом.Я только что сделал это в этом сообщении, и если бы StackOverflow не разрешил это, нам было бы очень трудно говорить о JavaScript на сайте!В большинстве случаев вы хотите разрешить любой ввод (*), чтобы пользователи могли использовать символ < для буквального обозначения знака «меньше».

Дело в том, что когда вы пишете какой-то текст в HTMLстраница, вы должны избегать его правильно для контекста, в который он входит.Для PHP это означает использование htmlspecialchars() на этапе вывода :

<p> Hello, <?php echo htmlspecialchars($name); ?>! </p>

[Подсказка PHP: вы можете определить функцию с более коротким именем, чтобы сделать echo htmlspecialchars, так какэто достаточно много печатать каждый раз, когда вы хотите поместить переменную в какой-то HTML.]

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

Например, если вы вставляете текст в строковый литерал JavaScript, вам придется экранироватьсимвол кавычки, обратный слеш и перевод строки.Если вы вставите текст в компонент запроса в URL-адресе, вам потребуется преобразовать большинство не алфавитно-цифровых символов в %xx последовательности.Каждый контекст имеет свои собственные правила;Вы должны знать, какая функция подходит для каждого контекста в выбранном вами языке / структуре.Вы не можете решить эти проблемы, искажая представления форм на этапе ввода - хотя многие наивные PHP-программисты пытаются, именно поэтому так много приложений путают ваш ввод в угловых случаях и по-прежнему не защищены.

(*:ну, почти любой. Есть разумный аргумент для фильтрации управляющих символов ASCII из представленного текста. Маловероятно, что их разрешение принесет какую-то пользу. Плюс, конечно, у вас будут проверки для конкретного приложения, которые вы захотите сделать, напримерубедитесь, что поле электронной почты выглядит как адрес электронной почты или цифры действительно являются числовыми. Но это не то, что может быть применено ко всем входным данным, чтобы избавить вас от неприятностей.)

9 голосов
/ 09 августа 2010

Межсайтовые скриптовые атаки (XSS) происходят, когда сервер принимает данные от клиента, а затем вслепую записывает эти данные обратно на страницу.Большая часть защиты от этих атак включает в себя выход из вывода, поэтому Javascript превращается в простой HTML.

Следует помнить, что не только данные, поступающие непосредственно от клиента, могут содержать атаку. Хранимая атака XSS включает запись вредоносного JavaScript в базу данных, содержимое которой затем запрашивается веб-приложением.Если база данных может быть записана отдельно от клиента, приложение не сможет быть уверенным в том, что данные были экранированы правильно.По этой причине веб-приложение должно обрабатывать ВСЕ данные, которые оно пишет клиенту, как если бы оно могло содержать атаку.

См. Эту ссылку для подробного ресурса о том, как защитить себя: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...