Полнота проверки на xss атаку

Большинство тестировщиков, которые не специализирутся на секюрити тестировании, при его выполнении (проверить то надо) пользуются стандартной процедурой:

1. Ввести во все поля тестируемой формы следующее:

2. Запостить форму

3. Зайти на форму просмотра результата

4. Открыть запись

Результат: если скрипт выполняется, то атака получилась.

Но как оказалось, xss атака может скрываться не только в скриптах, но еще и в тегах.

Например, в нашем проекте, где не срабатывал вышеуказанный пример, отлично сработал следующий:

Так что "век живи, век учись". Кстати, кто еще знает как можно запостить xss атаку, кроме этих двух способов? Делитесь знаниями :)

Брутфорс атака

Брутфорс атаки являются самым легким но эфективным способом взлома. Суть атаки состоит в подборе паролей пользователей.

Эффективность такой атаки напрямую зависит от ленивости администраторов и пользователей.

Для проверки на наличие уязвимости к брутфорс атакам мы не будем перебирать пароли :) Это дело скучное, занимает много времени да и пользы нам от этого не много. Ведь подобрав пароль какого-то юзера, мы всего лишь докажем что это сделать возможно. А никто и не говорил, что это не возможно. Имея достаточное количество времени и ресурсов, можно подобрать всякий пароль.

Задача хорошо продуманной компьютерной системы - не дать пользователям создать пароль, который легко ломается. Например, Петя, 1234, pass.

Поетому, при тестировании нужно обратить внеимание на следующие моменты:

• не рекомендуется длина пароля меньше 8-ми символов;
• пароль должен содержать комбинацию букв, цифр и символов;
• должно быть ограничение на кол-во попыток аутентификации за промежуток времени (например, не более 4-х раз в течении 1 минуты);
  
• пароли должны храниться обязательно в зашифрованном виде;
• пароли не должны передаваться методом GET;
• при работе с важной информацией должна использоваться защищенная передача данных (https протокол).
  

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

Security testing. Php-including.

Php-including это, казалось бы, самая изветсная "дыра" в безопасности сайта, но в то же время и самая распространенная. Возникает она, когда данные, переданные сценарию в виде параметров, используются без дополнительной проверки.

Стратегия обнаружения уязвимости следующая.

Например, на тестируемом сайте мы видим url - http://www.testsite.ru/index.php?file=file.php
Изменяем немного этот url, вот так - http://www.testsite.ru/index.php?file=[test] и выполняем.

Если уязвимость имеет место, то увидим что-то вроде этого:

«Warning: main([test].php): failed to open stream: No such file or directory in /home/user/www/file.php on line 3»

Но, стоит заметить, что подобное сообщение мы получим только в том случае, если на сервере в опциях PHP включен режим отладки. Иначе, придется вникнуть в хакерство поглубже.

Пишем запрос вида http://www.testsite.ru/index.php?file=/etc/passwd. Если нам повезло, то мы получим содержимое файда passwd на сервере.

Это основные и самые простые примеры как можно протестировать на php-including уязвимость. Далее включаем фантазию и google!

Security testing. XSS атака.

В этой статье пойдет речь о том как найти на тестируемом сайте уязвимое место для XSS атаки. Вначале немного об этой атаке.

XSS атака - это атака на сайт, использующая уязвимость, когда некорректно работают фильтры входящей информации. Информация не проверяется должным образом или вообще не проверяется :) перед тем как вернуть результат пользователю. Это дает возможность атаки на пользователя.

Как проверить, есть ли на сайте подобные уязвимости?

1. Ищем на сайте места, где данные отправляются на сервер.Например, стандартная форма регистрации .
2. По очереди вставляем в поля следующий код

1. Сабмитим форму.

Если поле не фильтруется, то скрипт успешно отправится и выполнится. В результате вы увидите следующее окошко


Все! Уязвимость найдена :).Репортуем баг программистам.

Кстати, в пост пришлось скрипт вставлять как картинку, иначе он выпонялся :)
Вот тебе и XSS атака.

Что ж тут такого страшного, спросите Вы. Ну подумаешь, вывели сообщение.
Ну, вообще то, делать страшные вещи и реально ломать сайт – это не наша работа. Для этого есть хакеры :) Наша работа найти уязвимость и мы ее нашли.

Но для убедительности, приведу примерную последовательность действий, как используя эту уязвимость на странице, хакер может атаковать пользователя.

Итак.
Первое. Для успешной атаки, пользователь должен быть залогинен (чтобы в его куках сохранилась информация о его авторизации в системе).
Второе. Хакер, должен подготовить XSS код, который будет указывать на уязвимую страницу.

Третье. Хакер должен заманить на данную страницу пользователя. Для этого он должен каким-то образом дать жертве ссылки на данную страницу (тоесть подготовленный URL) и заставить пользователя зайти на эту страницу.
Не буду вдаватся в подробности как он это сделает. В инете существует множество способов.

После того как жертва пойдет по ссылке, сработает XSS код и хакер получит куки жертвы (с авторизационной информацией). При этом жертва ничего даже не заметит.

После получения данных с куками пользователя системы, хакер может использовать их для входа в систему от имени этого пользователя.
А представьте, если пользователем окажется админ :)....

Как защититься от sql injection

Думаю, самые любопытные тестеры (тоесть, настоящие тестеры) после прочтения предыдущего поста об sql injection задали себе вопрос "А как же защититься от sql injection ?"

Хотя над этим вопросом должны ломать голову не тестеры, а программисты, но тестерам, думаю, эта информация тоже будет полезной. Как минимум, ею можно поделиться с программистами. Ведь тестеры и программисты - друзья! Правда ?! :)

Так вот, существуют три простые правила, как защититься от sql injection:

• Самое главное - фильтровать кавычки.
• Если используется оператор сравнения строк LIKE фильтровать знаки “%” и “_”
• Не использовать при сравнении переменных без кавычек типа select …where id=$id а использовать так select ...where id='$id' и обратиться к пункту 1

Вот как, оказывается, все просто.
Но опыт показывает, что именно в тех местах, где программистам все кажется очень простым, как раз и сидят самые жирные, упитанные, веселенькие баги :)

Security testing. SQL injection.

Итак, начнем разбирать виды атак и методы тестирования подверженности сайта этим атакам.

Sql injection атака представляет собой уязвимость, которая возникает из-за того, что программист в коде недостаточно хорошо проверяет (или, вообще не проверяет) принятые от пользователя данные.

Как проверить?
Ищем на сайте место, где в url передаются какие-то параметры.
Например, http://site/test.php?id=12
Немного изменяем значение параметра (самый элементарный способ – добавляем кавычку :) ), вот так
http://site/test.php?id=12’ и выполняем.

Если вы получили что-то вроде
«You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' ORDER BY p.pid DESC LIMIT 0, 20' at line 12»

Радуйтесь! Вы нашли уязвимость на сайте :)

PS: «Радуйтесь» - это я для тестеров написала. Программисты тут, конечно, должны очень огорчаться :)

Вот, собственно и все. Для хакеров, которые будут ломать сайт, это, конечно, только начало. Дальше они начнут составлять всякие каверзные запросы, подбирать количество полей, имена колонок таблиц, потом сами названия таблиц … в конечном итоге – стырят логин и пароль админа :) И сделают с сайтом, все, что захотят.

Ну а для нас, скромных тестеров, подтверждения наличия уязвимости вполне достаточно, чтобы репортовать страшный баг :) и, не теряя в этом месте больше драгоценного времени, идти далее заниматься своим делом, тоесть ломать сайт в других местах и другими методами ;)

Ведь столько всего еще нужно поломать... :)

Security testing. Введение.

Хочу рассказать о таком виде тестирования как тестирование безопасности или security testing. Речь пойдет о тестировании безопасности веб-сайтов. Кратко о том, что такое тестирование безопасности, какие его цели и как его проводят (что именно тестируют и как). Также, расскажу о том, какие инструменты используются для проведения тестирования безопасности сайта (по крайней мере, расскажу о тех, что я использовала).

Итак, что же это такое тестирование безопасности или security testing ?

Тестирование безопасности (Security testing) – это оценка уязвимости программного обеспечения к различным видам атак.

Виды атак бывают:

• sql injection атака
• xss атака
• php including атака
• подстановка параметров в url
• DoS атака
• брутфорс атака
  

Вообще-то атак больше :), но я расскажу только о тех, с которыми я сталкивалась и знаю, как проверить приложение на уязвимость к этим атакам.

Так что, читайте подробно о каждой атаке в следующих постах.
Надеюсь информация будет полезна.