06.06.2017 @ 10:56 Перевод OWASP Testing Guide. Часть 3.5. owasp, web security Представляю вашему вниманию очередную часть перевода OWASP Testing Guide. В данной статье речь пойдет о передаче пользовательских данных. Предыдущие статьи Тестирование: введение и задачи Сбор информации с помощью поисковых систем Определение веб-сервера Поиск информации в метафайлах веб-сервера Определение веб-приложений на сервере Поиск утечек информации в комментариях и метаданных Определение точек входа веб-приложения Составление карты веб-приложения Определение фреймворка веб-приложения Определение веб-приложения Составление карты архитектуры веб-приложения Тестирование конфигурации инфраструктуры веб-приложения Изучение расширений файлов Поиск страрых версий веб-приложения, скрытых файлов и резервных копий Поиск административных интерфейсов Тестирование HTTP методов Тестирование HSTS Тестирование кросс-доменной политики Изучение ролей пользователей Тестирование процесса регистрации Предоставление учетных записей Определение имен пользователей Определение правил генерации имен пользователей Резюме В идеале все авторизационные данные пользователей должны передаваться в шифрованном в виде во избежание перехвата их злоумышленниками. При проведении тестирования необходимо убедиться в безопасности пользовательских данных — создателями веб-приложения были приняты все меры для обеспечения безопасности данных, например, ипользуется протокол HTTPS. Протокол HTTPS использует TLS/SSL для шифрования, также с помощью данного протокола можно быть уверенным том, что пользовательские данные отправляются исключительно целевому веб-приложению. Естественно шифрование траффика не является панацеей, многое зависит от алгоритма шифрования и надежности ключей, используемых веб-приложением, но данная тема не будет освещенна в этой статье. Для большей информации о тестировании надежности TLS/SSL каналов обратитесь к разделу Testing for Weak SSL/TLS. В данной статье же речь пойдет о том, как проверить безопасность передачи пользовательских данных. Наиболее часто не безопасная передача пользотельских данных встречается в формах авторизации. Зачастую для авторизации пользователь должен заполнить простую форму, которая передает данные веб-приложению с помощью HTTP метода POST. Однако эти данные могут переданы с помощью протокола HTTP в открытом виде или же с помощью протокола HTTPS, который шифрует передаваемые данные. Кроме того возможны ситуации, когда форма авторизации доступна по HTTP (заставляя нас предположить, что данные передаются в открытом виде), но все пользовательские данные отправляются по HTTPS. Пентестер должен убедиться в том, что злоумышленник не сможет получить пользовательские данные перехватывая траффик. Как тестировать Тестирование по методу черного ящика В последующих примерах будет использоваться перехвтывающих прокси для изучения передаваемого запроса. Вы можете использовать любой перехватывающих прокси. Пример 1: отправка данных POST запросом через HTTP Предположим, что форма авторизации содержит поля User, Pass и кнопку Submit. В перехватывающем прокси мы можем увидеть следующий запрос: POST http://www.example.com/AuthenticationServlet HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://www.example.com/index.jsp Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S! Content-Type: application/x-www-form-urlencoded Content-length: 64 delegated_service=218&User=test&Pass=test&Submit=SUBMIT Из данного запроса видно, что он был отправлен POST методом на страницу www.example.com/AuthenticationServlet по HTTP, то есть данные передавались в открытом виде и злоумышленник мог получить логин и пароль пользователя просто перехватывая траффик, например, с помощью Wireshark. Пример 2: отправка данных POST запросом через HTTPS Предположим, что веб-приложение использует HTTPS для шифрования передаваемой информации (или, как минимум, чувствительной информации, например, авторизационные данные). В данном случае, при попытке авторизации POST запрос будет выглядеть следующим образом: POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml,text/html Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: https://www.example.com/cgi-bin/login.cgi Cookie: language=English; Content-Type: application/x-www-form-urlencoded Content-length: 50 Command=Login&User=test&Pass=test В приведенном примере видно, что запрос отправляется на www.example.com:443/cgi-bin/login.cgi POST запросом по HTTPS. Благодаря чему обеспечивается безопасность передаваемых данных, исключая возможность их перехвата злоумышленником. Пример 3: отправка данных POST запросом по HTTPS формой, доступной по HTTP Теперь представьте веб-страницу, поступную по HTTP, которая отправляет авторизационные данные пользователя по HTTPS. Данная ситуация возможна, например, на порталах больших компании, предоставляющих публично доступную информацию, не требующую идентификации пользователя. Кроме того, на данном портале также доступна зарытая информация, но доступна она только после авторизации. В данной ситуации запрос авторизации может выглядеть следующим образом: POST https://www.example.com:443/login.do Host: https://www.example.com:443/login.do User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml,text/html Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://www.example.com/homepage.do Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F Content-Type: application/x-www-form-urlencoded Content-length: 45 User=test&Pass=test&portal=ExamplePortal Запрос отправлялся на www.example.com:443/login.do по HTTPS. Но обратите внимание на заголовок Referer (страница, с которой мы пришли), в нем указана страница www.example.com/homepage.do и она доступна по HTTPS. Хотя данные отправляются по HTTPS, но подобная реализация может привести к SSLStrip (разновидности атаки Man-in-the-middle). Пример 4: отправка данных GET запросом по HTTPS В последнем примере предположим, что веб-приложение отправляет данные GET запросом. Данный метод никогда не должен использоваться при передаче чувствительной инмформации, напрмиер, имен пользователей и паролей, так как отображаются в открытом виде в URL и приводит к ряду проблем безопасности. Например, запрошенные URL доступны в логах сервера или из истории браузера, что делает вашу чувствительную информации доступной неавторизаванным пользователям. Данный пример является исключительно демонстрацией и на практике крайне рекомендуется использовать только POST запросы: GET https://www.example.com/success.html?user=test&pass=test HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml,text/html Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: https://www.example.com/form.html If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT If-None-Match: "43a01-5b-4868915f" В запросе видно, что данные передаются в открытом виде в URL, а не теле запроса, как раньше. Но необходимо учитывать то, что SSL/TLS — протоколы пятого уровня, то есть их уровень ниже чем HTTP, поэтому весь HTTP пакет является зашифрованным и URL не доступен злоумышленнику, перехватывающему траффик. Однако, как было обозначенно раннее, использование GET запросов при передаче чувствительнрой информации является ни в коем случае не стоит, так как информация, содержащяяся в URL, может сохранятся во многих местах, например, в логах прокси или веб-сервера. Тестирование по методу серого ящика Поговорите с разработчиками и убедитесь, что они понимают различия между проколами HTTP и HTTPS и то что они должны использовать HTTPS при передаче чувствительной информации. Затем убедитесь, что они всегда используют HTTPS, когда это необходимо. Инструменты WebScarab OWASP Zed Attack Proxy (ZAP) Рекомендации информационные бюллетени HTTP/1.1: Security Considerations — http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html SSL is not about encryption abychutkin 9079 Web security Читать дальше >>