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

Поиск старых версий веб-приложения, скрытых файлов и резервных копий
Резюме

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

Важным источником угроз являются файлы, которые не имеют никакого отношения к работе веб-приложения и появляются в результате редактирования файлов или создании резервных копий. Резервные копий могут генерироваться автоматически при редактировании файлов или же создаваться вручную, например, администратором, архивирующим данные. Подобные файлы крайне легко забыть, особенно если копии создаются с расширениями, отличными от первоначальных, например, .tar, .zip или .gz архивы. Также не стоит забывать о том, что многие редакторы создают автоматические копии (например, emacs генерирует резервную копию файла при его редактировании, добавляя к первоначальному имени файла «~»). Создание резервных копий вручную может привести к тому же эффекту (например, к первоначальному имени файла добавляется .old). Также в некоторых случаях используемая вами операционная система может время от времени создавать снепшоты, доступные через веб, даже без вашего ведома.

Все описанные ранее файлы, не только ненужны в открытом доступе, но являются крайне опасными, так как они не выполняются в отличии от оригинальных файлов. Давайте рассмотрим пример, если мы создадим копию login.asp и назовем ее login.asp.old, то дадим возможность пользователям загружать исходный код login.asp. Это происходит из-за того, что login.asp выполнится сервером, а login.asp.old просто отобразится в текстовом виде.

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

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

Угрозы

Старые версии веб-приложений, скрытые файлы и резервные копий привносят различные угрозы безопасности веб-приложений:

• В скрытых файлах может содержаться важная информация, которая может значительно упростить проведение атаки, например, учетные данные для подключения к базе данных, информация о других скрытых файлах, абсолютные пути и т.д.
• В скрытых файлах может содержаться функционал, который можно использовать для атаки, например, различные административные интерфейсы.
• Старые версии веб-приложений и резервные копии могут содержать уязвимости, которые были исправлены в более поздних версиях, например, в viewdov.old.jsp содержит уязвимость path traversal, исправленную в viewdoc.jsp, но ее может проэскплуатировать атакующий, обнаруживший старую версию.
• Резервные копии могут раскрывать исходный код страниц, созданных для выполнения на сервере, например, загрузив файл viewdoc.bak и изучив его атакующий может найти даже сложно обнаруживаемые уязвимости. Данная угроза характерна скриптовым языкам: PHP, ASP, shell scripts, JSP и т.д., но не ограничивается исключительно ими, что будет описано в следующей угрозе.
• Архивы резервных копий могут содержать копии всех файлов как из веб-рута, так и вне его, благодаря чему атакующий может быстро изучить веб-приложения, включая скрытые файлы, исходный код, конфигурационные файлы и т.д. Например, если вы забыли файл myservlet.jar.old, содержащий копию вашего сервлета, то атакующий может в дальнейшем его декомпилировать и получить различную ценную информацию.
• В некоторых случаях копирование или редактирование файлов не изменяет расширение файла, а изменяет его имя. Подобное происходит, например, в Windows системах, в которых при копировании созается файл в котором к первоначальному имени добавляется «Copy of» или локализованная версия данной строки. Так как расширение файла не изменяется он все еще остается исполняемым, поэтому нельзя получить его исходный код. Однако подобные файлы все еще остаются опасными, потому что они могут содержать ошибки или неправильную логику.
• Лог файлы содержат важную информацию о действиях пользователей, например, значения GET параметров, сессионные идентификаторы, посещенные URL-ы (некоторые могут раскрывать информацию о скрытых файлах) и т.д. Прочие лог файлы (например, логи ftp) могут содержать информацию об обслуживании веб-приложения системным администратором.
• Снепшоты файловой системы могут содержать старые уязвимые версии веб-приложения.

Как тестировать
Тестирование по методу черного ящика

Поиск скрытых файлов производится как вручную, так и с использованием средств автоматизации:

Определение скрытых файлов исходя из схем именования опубликованого контента

Определить все доступные страницы — это можно сделать вручную с помощью браузера или используя автоматизированного паука. Большинство веб-приложений используют определенную схему именования — разработчики именуют файлы и директории, стараясь описать их функционал. Исходя из схемы именования опубликованого контента можно предположить имена и расположения скрытых файлов. Например, если была обнаружена страница viewuser.asp, то стоит также посетить edituser.asp, adduser.asp и deleteuser.asp. Если была обнаружена директория app/user, то стоит также посетить /app/admin и /app/manager.

Подсказки в опубликованном контенте

Во многих веб-приложениях разработчики оставляют подсказки, которые могут привести к обнаружению скрытых файлов. Эти подсказки зачастую находятся в комментариях HTML и JavaScript кода. Исходный код всего опубликового контента необходимо вручную изучить, чтобы найти озвученные ранее подсказки (прим. переводчика: можно также воспользоваться поиском в OWASP ZAP). Пример:

Разработчики заккоментировали ссылку к скрытому контенту и добавили свои комментарии о ней:


<!-- <a href="uploadfile.jsp">Upload a document to the server</a> -->
<!-- Link removed while bugs in uploadfile.jsp are fixed -->


JavaScript может содержать ссылки, обрабатываемые пользовательским интерфейсом при определенных обстоятельствах:


var adminUser=false;
:
if (adminUser) menu.add (new menuItem ("Maintain users", "/admin/useradmin.jsp"));


HTML страницы могут содержать скрытые формы:


<FORM action="forgotPassword.jsp" method="post"<
<INPUT type="hidden" name="userID" value="123">
<!-- <INPUT type="submit" value="Forgot Password"> -->
</FORM>


Еще одним источником подсказок о скрытых файлах является файл robots.txt:


User-agent: *
Disallow: /Admin
Disallow: /uploads
Disallow: /backup
Disallow: /~jbloggs
Disallow: /include

Брутфорс

Наиболее простым способом обнаружения скрытых директории и файлов является брутфорс. Примерный скрипт для брутфорса директорий и файлов приведен ниже:


#!/bin/bash

server=www.targetapp.com
port=80

while read url
do
echo -ne «$url\t»
echo -e «GET /$url HTTP/1.0\nHost: $server\n» | netcat $server $port | head -1
done | tee outputfile

Для ускорения брутфорса можно заменить GET запросы на HEAD. При брутфорсе важно обращать внимание на коды ответов — код 200 (ОК) свидетельствует о том, что ресурс существует (иногда сервер также возвращает сообщение об ошибке с кодом 200, это также стоит учитывать); коды 301 (Moved), 302 (Found), 401 (Unauthorized), 403 (Forbidden) и 500 (Internal error) также могут свидетельствовать об обнаружении директорий и файлов.

Брутить необходимо веб-рут и все обнаруженные директории. Можно увеличить шанс брут форса следующими способами:

• Определите используемые веб-приложением расширения файлов (например, jsp, aspx, html) и запустить брут форс по словарю, используя обнаруженные расширения (если позволяют ресурсы, то можно запустить брут форс с большим количеством расширений).
• Собрать все обнаруженные имена файлов в словарь, взять словарь с наиболее часто встречаемыми расширениями (включая ~, bak, txt, src, dev, old, inc, orig, copy, tmp и т.д.), далее необходимо каждое расширение подставлять перед, после или вместо первоначального расширения файла.

Информация полученная из-за уязвимостей сервера или его неправильной настройки

Наиболее очевидный способ которым неправильно настроенный веб-сервер раскроет информацию о скрытых файлов — это отображение содержимого директорий. Пройдите по всем обнаруженным директориям, чтобы определить какие из них отображают свое содержимое. Подобные уязвимости встречались в Apache, различных скриптах IIS и IIS WebDAV.

Информация из общедоступных источников

Скрытые файлы могут быть поступны с посторонних доменов:

• Страницы, которые ранее не были скрыты, могут быть доступны в веб-архивах.Например, 1998result.asp сейчас является скрытым, хотя ранее таковым не являлся и потому мог сохранится в базе поисковиков и веб-архивах. Этот старый скрипт может содержать уязвимости, с помощью которых может быть скомпроментированного веб-приложение. Оператор site: поисковика Google позволяет искать страницы в пределах выбранного домена, например, site:www.example.com. Используя поисковик подобным образом можно получить крайне интересные результаты, конечно вы врядли найдете резервные копии, так как на них не ссылается ни одна страница, но если они находятся в директориях, раскрывающих свое содержимое, то поисковик может о них знать.
• Google и Yahoo сохраняют кешированную версию проиндексированных страниц. Даже если 1998result.asp был удален с сервера, остается его кешированная версия, которая может содержать ссылки на скрытые файлы или различные подсказки.
• Скрытые файлы могут быть доступны на сайтах партнеров.

Тестирование по методу серого ящика

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

Инструменты

• Сканеры уязвимостей производят поиск распространенных директории и сообщают о директориях, раскрывающих свое содержимое.
• Веб-пауки: wget (http://www.gnu.org/software/wget/, http://www.interlog.com/~tcharron/wgetwin.html), Xenu (http://home.snafu.de/tilman/xenulink.html), curl ( http://www.interlog.com/~tcharron/wgetwin.html).

Рекомендации

Для обеспечения безопасности веб-приложения тестирование должно дополнятся политикой безопасности, явно запрещающей небезопасные практики, такие как:

• Редактирование файлов на веб-сервере. Это крайне плохая привычка, так как случайно редактором могут быть сгенерированы резервные копии. Крайне удивительно как часто это встречается, даже в больших организациях. Даже если вам действительно необходимо отредактировать файл на веб-сервере, убедитесь в том, что не остается никаких случайных файлов.
• Отслеживать все действия в файловой системе веб-сервера, даже если их осуществляет администратор. Например, если вы захотите сделать снепшот некоторых директорий, убедитесь что вы не забыли убрать эти архивы.
• Конфигурационные файлы, логи, файлы с данными и т.д. не должны быть доступны веб-серверу, во избежание утечки информации.
• Снепшоты файловой системы не должны быть доступны через веб, кроме того к ним необходимо ограничить доступ:


<Location ~ ".snapshot">
Order deny,allow
Deny from all
</Location>