2010-08-09 3 views
7

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

Cross-site script attacks (или межсайтовый скриптинг), если вы, например, есть гостевая книга на главной странице и клиентом сообщения некоторых Javascript код, который Fx перенаправляет вас на другой сайт или отправляет куки в письме к злоумышленник, или это может быть много другого материала, который может оказаться действительно вредным для вас и людей, посещающих вашу страницу.

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

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

+0

Целевая структура? PHP? – Arthur

+0

Есть варианты для любого языка/рамки/и т. Д. Вы получите более конкретные ответы - например, htmlencode - если вы предоставите дополнительную информацию о своей настройке. (Stack). – Tobiasopdenbrouw

+0

Вы правы, Tobiasopdenbrouw, но на самом деле это было похоже на общий вопрос, который другие люди могли бы получить от :) – Latze

ответ

12

я уверен, что это может быть сделано 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

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

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

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

+0

Отличная точка - я вижу слишком много разговоров, как правило, о «очищающих входах», когда на самом деле это не всегда возможно или даже разумно, и это все равно не полностью решает проблему. Решения должны выполняться во время вывода. Кроме того, важно отметить, что HTML не является единственным уязвимым контекстом - SQL Injection - это просто вариация на ту же тему. – Pointy

+0

Проверка входов, выходных выходов –

Смежные вопросы