Тестирование безопасности веб- сервисов на примере WCF- сервисов Ultra Light
О чем речь Основные понятия о тестировании безопасности Особенности поиска уязвимостей в web сервисах (на примере wcf сервисов)
Кому? У кого: Публичный сервис – кто угодно в мире может начать использовать ваше приложение как «оружие» Множество пользователей – есть чем поживиться (персональные данные) On Demand – люди покупают подписки. Если они считают, что есть опасность - они перестают это делать.
Зачем? Чтобы ограничить свободу действий потенциальным злодеям Избавиться от простейших уязвимостей Повысить свой авторитет в глазах заказчика Пусть выбеут не вас Усложнить использование атакующим вашего продукта в качестве инструмента Это интересно и полезно знать Стимулирует познакомиться с продуктом «ближе» Повышает вашу ценность как специалиста
Как это все у «взрослых» Сертификации ПО Для работы с платежами пластиковыми картами (PCI) Для работы с правительственными структурами ( примеры ) Сертификации профессионалов Примеры Наборы инструментов Отдельный недешевый сервис
С чего можно начать Injections (A1) XSS (A3) Insecure Direct Object References (A4) A2 пропущен, т.к. Access Control проблема не уровня сервиса, а выше.
Was ist das? OWASP – некоммерческое объединение, накапливающее знания по тестированию безопасности. (A1) Injections – внедрение кода, который выполнится доверчивым интерпретатором. (A3) XSS – «отложенная инъекция». Срабатывает в браузере в момент обращения к ресурсу браузером. (Не путать с Cross Site Request Forgery, A8 ) (A4) Insecure Direct Object References лишняя информация в варнингах и эксепшенах позволяющая злоумышленнику получить информацию для усовершенствования атаки.
Веб сервисы Не имеют красивого пользовательского интерфейса в привычном виде Предоставляют доступ к функционалу приложения для сторонних разработчиков В случае WCF широко используются и внутри приложения часть работы за программиста делает фреймворк
Что с ними не так Injections через параметры методов. Метод с кучей параметров принимающий еще и sortField – направляет его напрямую в базу. XSS можно передать другому пользователю системы «отравленный» объект. Сообщение об ошибке может отображать (выполнять) вредоносный код Слишком информативные эксепшены и варнинги Все это может быть доступно по разным протоколам
Исправительные работы Обработка всего, что потом попадет в базу Конфигурация уровня детялизации ошибок в сервисах: < behaviors > < serviceBehaviors > < behavior name = " Default " > < serviceDebug includeExceptionDetailInFaults = " false " /> </ behavior > </ serviceBehaviors > </ behaviors > Конфигурация запрета встраивания страниц приложения в iframe. (TBD: фрагмент конфига) И так на разных протоколах Тестировать по wsdl надо сгенерить и склеить все wsdl чтобы передать в сканер Актуальные обновления на сервере
Jquery Можно испльзовать, чтобы прикрепить в багу и не описывать шаги воспроизведения. При проверке не надо будет заново все проделавать, можно только нажать кнопку. Что для этого достаточно знать: как встраивать скрипт в HTML Как посылать запросы на сервер Адрес гугла
Fin Не стоит полагать, будто это что-то гарантирует. При желании, всегда найдутся умельцы покруче. Главное – знать меру. Не надо зарываться и тратить уйму времени. Помните – самолечение опасно, доверьтесь профессионалам. Если серьезные данные, то такое «секурити» тестирование не подходит. Однако, это полезно знать тестировщику.
Инструменты: Acunetix – платный, крутой Burp Suite - дешевле, крутой QualysGuard – он-лайн сканер. Не достанет за VPN. Jquery – бесплатно, крутой WSDLMerge – склейка всех зависимостей wsdl файла в единый wsdl
Пример Пример простейшей самописной тулзы, написанный для прикрепления в баги:
Ссылки: OWASP Top10 security risks, 2013(PDF): http://owasptop10.googlecode.com/files/OW ASP%20Top%2010%20-% 202013.pdf MSDN, How To: Prevent Cross-Site Scripting in ASP.NET - http://msdn.microsoft.com/en- us/library/ff649310.aspx