owasp

Большая подборка стандартов
Стандарты и методики по ИБ (файлы, ссылки, поиск)
В этой теме собираем и обмениваемся стандартами, методиками и другими документами по тематике ИБ.
http://bankir.ru/dom...?t=79998&page=1

Ошибки в конфигурации IIS можно найти, для этого нужны админские права и утилита WACA 2.0
ссылка: http://www.microsoft...ion.aspx?id=573
описание: http://www.xakep.ru/...720/default.asp

Ошибки в исходном коде (полагю это ASP/VB.NET/...) тоже можно найти автоматически/полуавтоматически.

Статический анализатор кода от Microsoft: CAT.NET
http://www.microsoft...ang=en&id=19968

Утилита OWASP Code Crawler
очень хорошая разработка, проверяет код на C#, сайт, который надо было проверить и проверить быстро, был на на VB.NET, поэтому помогла связка .NET Reflector 5.1.6.0 + OWASP Code Crawler 2.5.1
ссылка: https://www.owasp.or...SP_Code_Crawler

Ответы утилит (а их будет много) придётся проверять руками. Для этого использую Браузер (любой, но лучше тот в котором нет XSS-фильтра, то есть не IE8/IE9, а Opera, FireFox+плагины) + OWASP WebScarab (сначала написал WebGoat) или Fiddler2.

Для поиска XSS с помощью Fiddler2 есть хорошая разработка Watcher (это плагин для Fiddler2, скачать можно с сайта Fiddler2: http://www.fiddler2..../extensions.asp). Принцип использования такой:
1. Настроить работу браузера через Fiddler2
2. Запустить Watcher (галочку в Fiddler2 отметить - Enable)
3. Поработать с сайтом, вводя данные в поля форм, например в поля поиска - Watcher будет пропускать все запросы через свой алгоритм анализа.
4. Если было такое, что введённные данные отображались на странице без экранирования или были опасные/подозрительные конструкции в javascript/html, то Watcher об этом скажет.

Добрый день!
Подскажите, кто знает, почему считается недопустимым использование в пароли пробелов? Очень интересно)
Спасибо

1. connection string имеет свой формат
“Data Source=Server,Port; Network Library=DBMSSOCN; Initial Catalog=DataBase; User ID=Username; Password=pwd;”
использовать в пароле ; уже не получится, если разрешить пропскать в символы ; те же пробелы, то пользователь сможет изменить строку соедиения, добавить в неё свои параметры.

2. Ограничения существующих книптографических библиотек, которые просто не поддерживают обработку пробелов, кириллицы, ...
Много кода для почтовых систем написано на C/C++ и написано давно, обработка кириллицы там не предусмотрена. А пересобирать библиотеки не все хотят. И таких библиотек много, они используются во многих приложениях. Допустим, есть почтовый сервер, с веб-интерфейсом. И там введены такие ограничения на пароли, это сделано с заделом на будущее, вдруг придётся расширить функциональность, добавить к веб-интерфейсу ещё и FTP, социальную сеть, форум, персональные блоги, ... (как правило это лишь мечты). И чтобы при этом не было проблем интеграции (чтобы текущий пароль принимался везде), заранее делаются ограничения на логины и пароли. Ведь может быть так, что конкртный форумный движок не воспринимает логины на русским, и как тогда быть - заставить пользователей регистрироваться по новой? - можно конечно, но не все станут.

3. Для веб-приложений часто не все хотят разбираться в том, что +, %20 - это пробел, а также в прочих тонкостях с кодировками. Всё что пришло на запрос пароля подставляется в пароль, если пришло %20, то эти 3 (а не 1) символ будут считаться частью пароля. Довольно просто выделить символы, которые можно передавать без экранирования - латинские буквы, цифры, подчёркивание и ещё ряд символов.

А на русском литературы нет? А то у меня с инглишем не сростается как то.

А на русском литературы много. Если интересуют электронные книги - то "Library Genesis" в помощь, ключевые слова: хакер, безопасность, взлом, защита (если не знаете адреса "Library Genesis", то поисковик в помощь). В качестве источника статей рекомендую журнал хакер, полезно, хотя бы для того, чтобы знать что означают очередные новые слова и в каком контексте их надо понимать. Так как читать английский текст всё равно придётся.

Кое-что пробовал делать сам. Вот моделирование угроз, к примеру, очень долгий процесс, меня хватило только на модель верхнего уровня и текствое описание всех угроз. Сделать многоуровневую модель, как в книге Защищенный код, не хватило терпения.

И про тест-кейсы. Не писал их до настоящего времени. Так как не мог предположить, что меня ждёт, будет ли доступен код, смогу ли я его расшифровать, ... Но сейчас попробовал с тест-кейсами. Строил тесты от возможных слабых мест (можно шагать от требований, от здравого смысла, а в безопаности можно от конкретных слабых мест - проверять есть оно или нет).
1. Открыл иерархию уязвимостей на http://cwe.mitre.org/
2. Выбрал те, которые могут быть (точно есть) в тестируемом приложении.
3. Описал их в документе, применительно к текущему контексту, и отправил его разработчикам (они почти ничего не вычеркнули)

Тесты получились не как пишутся обычно ("Корректная работа механизма ..."), а все заголовки написаны наоборот ("Ошибки механизма защиты"). Если почитаете Research View (http://cwe.mitre.org...raphs/1000.html) то поймёте почему так - там описаны возможные слабые места, я так и описал их в документе, как слабые места, а не как требования.

Что ещё замечу из опыта. Утилиты активного сканирования веб-приложений имеют очень низкий кпд. Гораздо больший толк от утилит пассивного сканирования, это когда, тестируешь веб-приложение, а трафик который генерируется для твоих ручных действий, проходит через сканер, который следит - не нарушиась ли структура html-разметки, и не попали ли значения из URL в текст страницы без изменений.

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

Про планирование - война план покажет. Не планируйте пока ничего, перед Вами открылось непаханное поле. Если Вы - тестировщик конкретной фирмы, то просто найдите как можно больше уязвимостей (простых XSS, SQL-inj и того, что при том можно получить - доводите уязвимость до эксплуатации, на деле, не все они эксплуатируемы, и оттого некритичны), потом перейдите к сложным, архитектурным дефектам. А уже когда набьете руку в эксплуатции, можно и за pentest взяться (это же сложная задача, вот так просто - как одну очередную фазу тестирования, pentest не осилить). OWASP Testing Guide v3 можно считать руководством по пентесту. Но если ознакомиться со всем тем, что проверяется при пентесте (например, тут: http://www.pentest-s...x.php/Main_Page), то станет понятно: пентест - задача сложная.