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

Я уверен, что это можно сделать 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 из отправленного текста. Очень маловероятно, что их разрешение принесет какую-либо пользу. Плюс, конечно, у вас будут проверки для конкретного приложения, которые вы захотите Например, убедитесь, что поле электронной почты выглядит как адрес электронной почты или что числа действительно являются числовыми.

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

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

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