Безопасность сайтов для веб-мастеров

Четверг, 12 мая 2011 г.

Пользователей учат защищаться от вредоносных программ путем установки сложного антивирусного ПО, но часто они также могут доверять свою личную информацию таким сайтам, как ваш, и в этом случае важно защищать их данные. Также очень важно защищать ваши собственные данные; если у вас есть интернет-магазин, вы не хотите быть ограбленным.

За прошедшие годы компании и веб-мастера усвоили — зачастую на горьком опыте, — что безопасность веб-приложений — это не шутка; мы видели утечки паролей пользователей из-за
SQL injection
атак, кражи файлов cookie с помощью
XSS, а также захвата сайтов хакерами из-за небрежной проверки входных данных.

Сегодня мы покажем вам несколько примеров того, как можно использовать уязвимости веб-приложения, чтобы вы могли учиться на них; для этого мы будем использовать
Gruyere, специально уязвимое приложение, которое мы также используем внутри компании для обучения безопасности. Не проверяйте чужие сайты на наличие уязвимостей без разрешения , так как это может быть воспринято как хакерство; но вы можете — более того, мы поощряем вас — запускать тесты на Gruyere.

Манипулирование состоянием клиента — Что произойдет, если я изменю URL?

Допустим, у вас есть сайт для хостинга изображений, и вы используете PHP-скрипт для отображения изображений, загруженных пользователями:

Итак, что сделает приложение, если я изменю URL на что-то вроде этого, а userpasswords.txt является реальным файлом?

Получу ли я содержимое userpasswords.txt?

Другим примером манипулирования состоянием клиента является отсутствие проверки полей формы. Например, допустим, у вас есть такая форма:

Кажется, имя пользователя отправителя сохраняется в скрытом поле ввода. Что ж, это здорово! Означает ли это, что если я изменю значение этого поля на другое имя пользователя, я смогут отправить форму от имени этого пользователя? Вполне может случиться; пользовательский ввод, по-видимому, не аутентифицируется, например, с помощью токена, который можно проверить на сервере.

Представьте ситуацию, если бы эта форма была частью вашей корзины покупок, и я изменил цену товара с 1000 до 1 доллара, а затем разместил заказ.

Защитить приложение от такого рода атак непросто; взгляните на третью часть Gruyere , чтобы узнать несколько советов о том, как защитить ваше приложение.

Межсайтовый скриптинг (XSS) — Введенным пользователем данным нельзя доверять

Простой, безвредный URL:

Но действительно ли он безвреден? Если я декодирую
процентно-кодированные
символы, я получаю:

Gruyere, как и многие сайты с
пользовательскими страницами ошибок, предназначен для включения компонента пути в HTML-страницу. Это может привести к ошибкам безопасности, таким как XSS, поскольку внедряет пользовательский ввод непосредственно на отображаемую HTML-страницу веб-приложения. Вы можете сказать: «Это всего подумаешь, просто всплывающее окно с предупреждением?» Дело в том, что если я могу внедрить окно предупреждения, то, скорее всего, я смогу внедрить и что-то еще, и, возможно, украсть ваши файлы cookie, которые я мог бы использовать для входа на ваш сайт под вашим именем.

Другой пример — когда сохраненный пользовательский ввод не очищается. Допустим, я пишу комментарий в вашем блоге; комментарий прост:

Если другие пользователи кликнут по моей невинной ссылке, их файлы cookie у меня:

Вы можете узнать, как находить XSS-уязвимости в собственном веб-приложении и как их исправить, во второй части
Gruyere; или, если вы опытный разработчик, ознакомьтесь с функциями автоматического экранирования в системах шаблонов, о которых мы писали в нашем
Online Security блоге.

.

Межсайтовая подделка запроса (XSRF) — Стоит ли доверять запросам с evil.com? 404 Ой, сломанная картинка. Она не может быть опасной — в конце концов, она сломанная, — а это значит, что URL картинки возвращает

или просто поврежден. Верно ли это во всех случаях?

Нет, неверно! Вы можете указать любой URL в качестве источника изображения, независимо от его типа контента. Это может быть HTML-страница, файл JavaScript или какой-либо другой потенциально вредоносный ресурс. В этом случае источником изображения был URL простой страницы:

Эта страница будет работать только в том случае, если я вошел в систему и у меня установлены некоторые файлы cookie. Поскольку я действительно вошел в приложение, когда браузер попытался получить изображение, обратившись к URL-адресу источника изображения, он также ударил по моему первому фрагменту. Это не звучит особенно опасно, но если я немного знаком с приложением, я также могу вызвать URL-адрес, который удаляет профиль пользователя или позволяет администраторам предоставлять разрешения другим пользователям.
Чтобы защитить приложение от XSRF, вы не должны разрешать вызов действий, изменяющих состояние, черезGET ; метод POST был создан для такого рода запросов, изменяющих состояние. Это изменение само по себе могло бы смягчить вышеуказанную атаку, но обычно этого недостаточно, и вам нужно включить непредсказуемое значение во все запросы, изменяющие состояние, чтобы предотвратить XSRF. Перейдите на Gruyere

, если вы хотите узнать больше об XSRF.

Внедрение межсайтовых скриптов (XSSI) — Все ваши скрипты принадлежат нам

Многие сайты сегодня могут динамически обновлять содержимое страницы с помощью асинхронных запросов JavaScript, которые возвращают данные JSON. Иногда JSON может содержать конфиденциальные данные, и если не приняты надлежащие меры предосторожности, злоумышленник может украсть эту конфиденциальную информацию.

Представим следующий сценарий: я создал стандартную HTML-страницу и отправил вам ссылку; так как вы доверяете мне, вы переходите по отправленной мной ссылке. Страница содержит всего несколько строк:

Поскольку вы вошли в Gruyere и у вас есть личный фрагмент, вы увидите на моей странице окно предупреждения, информирующее вас о содержимом вашего фрагмента. Как всегда, если мне удалось запустить окно предупреждения, я могу делать все, что захочу; в данном случае это был простой фрагмент, но это мог быть и ваш самый большой секрет.

Защитить приложение от XSSI не так уж сложно, но это все равно требует тщательного обдумывания. Вы можете использовать токены, как описано в разделе XSRF, настроить скрипт так, чтобы он отвечал только на запросы POST, или просто начать ответ JSON с символа ‘n’, чтобы убедиться, что скрипт не является исполняемым.

Инъекции SQL — Все еще считаете, что пользовательский ввод безопасен?
Что произойдет, если я попытаюсь войти в ваше приложение под именем пользователя вроде

JohnDoe’; DROP TABLE members;–

Хотя этот конкретный пример не приведет к утечке пользовательских данных, он может доставить немало хлопот, поскольку потенциально может полностью удалить таблицу SQL, в которой ваше приложение хранит информацию об участниках.
Как правило, вы можете защитить приложение от SQL-инъекций с помощью упреждающего мышления и проверки входных данных. Во-первых, вы уверены, что пользователю SQL необходимы права на выполнениеDROP TABLE members Разве не было бы достаточно предоставить только права SELECT

Тщательно настроив разрешения пользователя SQL, вы сможете избежать неприятного опыта и множества проблем. Вы также можете настроить отчет об ошибках таким образом, чтобы имена базы данных и ее таблиц не раскрывались в случае сбоя запроса.

Во-вторых, как мы узнали на примере XSS, никогда не доверяйте пользовательскому вводу: то, что кажется вам формой входа, для злоумышленника выглядит потенциальной дверью. Всегда очищайте и заключайте в кавычки данные, которые будут сохранены в базе данных, и по возможности используйте инструкции, обычно называемые подготовленными или параметризованными инструкциями, доступными в большинстве программных интерфейсов баз данных.
Знание того, как можно использовать уязвимости веб-приложений, — это первый шаг к пониманию того, как их защитить. В связи с этим мы рекомендуем вам пройтикурс Gruyere
, пройти другие курсы веб-безопасности от
Google Code University
и заглянуть в
skipfish
, если вы ищете автоматизированный инструмент тестирования безопасности веб-приложений. Если у вас возникли дополнительные вопросы, пожалуйста, задайте их на нашем.

форуме помощи веб-мастерам
Автор:Gary Illyes