Phpstorm показывать скрытые папки и файлы
Обновлено: 06.07.2024
Для сопоставления значение из NODES и имён файлов нам нужно выполнить несколько шагов:
- удалить префикс $sha1$
- добавить постфикс .svn-base
- использовать первые два знака как имя папки внутри директории pristine/ (в этом случае это 94)
- создать полный путь, который в этом примере будет:
Когда мы попытаемся открыть этот путь в браузере, у нас должно получиться скачать файл или его содержимое должно отобразиться непосредственно в браузере. Как прочитать содержимое определённого файла из репозитория .svn:
Также запись в таблице REPOSITORIES указывает на оригинальный путь в репозитории, которым является:
Здесь множество информации. Оставление папки .svn на веб-сервере это огромная ошибка и может быть очень опасным. Это может даже означать полную компрометацию исходного кода веб-приложения.
Файлы проектов IDE
IDE (интегрированные среды разработки) используются многими разработчиками, чтобы собрать в одном месте разные вещи — они сохраняют настройки проектов и множество дополнительной информации в их собственных файлов, создаваемых отдельно для каждого проекта. Если такая папка оставлена на веб-сервере — то это ещё один источник информации о веб-приложении.
JetBrains IDEs — IntelliJ IDEA, WebStorm, PHPStorm, RubyMine
Каждый разрабатываемый проект в одном из продуктов JetBrains создаёт свою собственную скрытую папку .idea/. Эта директория содержит всю информацию о текущем проекте, его файлах, директориях и настройках IDE.
Пример содержимого папки .idea JetBrains:
Один из этих файлов крайне ценен с точки зрения исследователей безопасности. Файл workspace.xml содержит множество полезной информации, которая позволяет перечислить все файлы и папки приложения, информацию системы контроля исходного кода и многое другое.
Рассмотрим, что именно нам раскрывает этот файл:
Все узлы в component name="FileEditorManager" содержат все файлы и их относительные пути (в корневой директории проекта). Проще говоря, это просто XML обёртка результатов Bash команды ls выполненной в главной папке проекта
Если вы взгляните ближе на каждый узел component, вы найдёте информацию об используемой системе контроля версий, как в этом примере:
Также там в узле component name="TaskManager" есть информация о комитах и других выполненных задачах над файлами проекта:
Другие интересные вещи могут быть в истории изменений, хранимой в узле с именем component name="ChangeListManager":
а также в узле component name="editorHistoryManager":
Если разработчик управлял базой данных через интегрированный менеджер БД, то значит есть другой очень интересный файл: dataSources.ids где вы можете найти структуру базы данных, dataSource.xml, dataSources.xml, dataSources.local.xml и dbnavigator.xml содержат примерно такую информацию:
Всё зависит от самого проекта, используемых в IDE плагинов (таких как отладчики, контролёры версий исходного кода или менеджер БД). В общем, стоит оглядеться и исследовать каждый узел component.
Как вы можете видеть, это очень интересный источник информации. Я рекомендую вам загрузить любую JetBrains IDE (они предлагают 30 дневный пробный период почти для всех продуктов, даже больше — вы можете загрузить IntelliJ Idea Community или PyCharm Community и использовать их бесплатно), затем создайте пробный проект, добавьте несколько папок и файлов, попробуйте поуправлять Git или SVN, создайте пример соединения с базой данных, и поиграйтесь с Database Manager. А затем углубитесь в изучение папки .idea/, чтобы увидеть, что вы можете там найти.
NetBeans IDE
NetBeans создаёт свою собственную папку в корневой папке проекта, содержащую все настройки проекта — nbproject/ (наподобии папки .idea, создаваемой JetBrains IDEs).
NetBeans не такая вербальная как IntelliJ, PHPStorm или WebStorm, но вы всё равно можете найти некоторую интересную информацию, которая может оказаться полезной когда вы ищите определённый вектор атаки в отношении уязвимого веб-приложения. Файл project.xml является хорошей стартовой точкой для исследования конфигурации проекта NetBeans.
Пример содержимого директории .nbproject:
Прочие конфигурационные файлы
Конфигурационные файлы специфичные для NodeJS/JavaScript
Если вы когда-либо работали с современными сборками проектов с JavaScript, вероятно вы были удивлены, сколько много разных *.json и .rc* файлов в корневой папке таких приложений.
Имеется множество подобных конфигурационных файлов, содержащих большое количество информации об используемых библиотеках. Некоторые директории недоступны напрямую из браузера или их даже невозможно обнаружить инструментами, используемых для обнаружения (перечисления) скрытых папок и файлов, но некоторые из них встречаются повсюду. Примеры конфигурационных файлов npm (package.json, package-lock.json), которые содержат все зависимости приложения; конфигурационные файлы linters для JavaScript таких менеджеров пакетов как ESlint или JShint или Bower (файл bower.json) — перечислены только некоторые.
Давайте взглянем в пример файла bower.json, который содержит конфигурацию для Bower и содержит список используемых в веб-приложении пакетах (на стороне пользовательского интерфейса):
Намного более интересно с точки зрения безопасности это похожий файл для Node.js или io.js серверной части приложения — package.json. Поскольку это список подробностей о сервере — используемые пакеты, такие как коннекторы баз данных, компоненты промежуточного программного обеспечения и так далее — эти файлы могут содержать множество ценной информации о потенциально уязвимом программном обеспечении.
Если вы можете загрузить package.json с сервера, то есть простой метод идентифицировать любой потенциально уязвимый npm пакет, используемый приложением. Просто следуйте этим шагам:
- убедитесь, что у вас установлен NodeJS с npm версией 6 или выше
- сохраните загруженный package.json и запустите следующую команду в той же директории, куда вы его только что сохранили:
в конце процесса вы получите информацию вроде такой:
после выполнения предыдущей команды, у вас будет отчёт, который содержит все уязвимости, идентифицированные этим инструментом:
Вероятно, это хорошая идея сохранить этот вывод в отдельном файле, поскольку иногда вы найдёте даже сотни выявленных слабостей по нескольким npm модулям. Важно не быть пойманным в «кроличью нору» - некоторые из этих проблем больше теоретические, чем подходящие для эксплуатации уязвимости, некоторые модули могут просто не использоваться этим проектом.
Этот пример package.json показывает, что вероятно используется база данных MySQL и некоторые коммуникации клиент-сервер через WebSockets:
Информация такого рода позволяет вам быстро понять, что нет смысла пробовать популярные NoSQL инъекции, поскольку приложение использует стандартную реляционную базу данных SQL и может быть вам следует попробовать проверить, уязвимо ли приложение к SQL инъекции.
Также есть файлы вроде .bowerrc, .eslintrc, .jshintrc и похожие. Даже если они не содержат очень чувствительную информацию, всегда есть шанс, что вы можете найти подробности об архитектуре веб-приложения, используемых библиотеках и/или платформах, или даже какую-нибудь ценную информацию в комментариях. Всегда стоит заглянуть в них, если вы нашли их во время фазы разведки.
Конфигурационные файлы GitLab CI/CD .gitlab-ci.yml
Когда проект использует GitLab Continous Integration (GitLab CI/CD), то в корневой папке проекта существует один очень специальный, недолговечный файл: .gitlab-ci.yml. Этот файл может содержать тонны чувствительной информации: подробности о тестировании и процессе сборки с подробными командами запуска на каждом шагу таких процессов и многую другую критическую информацию.
Вы можете найти пример файла .gitlab-ci.yml здесь.
Файл Ruby on Rails database.yml
Если вы достаточно удачливы и этот файл будет для вас читаемым, то это обычно означает «конец игры» для приложения RoR (Ruby on Rails). Это конфигурационный файл главной базы данных, содержащей всё что вам нужно для подключения к базе данных: имена пользователей, пароли и другие подробности настройки.
Файл macOS .DS_Store
Одна специфичная вещь в macOS системах — это файл с названием .DS_Store. Этот файл создаёт Finder (файловый менеджер) в macOS и он очень часто добавляется в проект по ошибке и попадает в репозиторий контроля версий исходного кода.
Что делает .DS_Store файлы такими полезными — это факт, что они хранят информацию о настройках окна Finder, включая макет иконок, представляющих файлы и папки, отображающиеся в конкретном окне Finder. А это в свою очередь означает, что мы также знаем имена файлов и папок в этом окне. Если вы нашли файл(ы) .DS_Store на веб-сервере, то есть шанс, что они раскроют эту информацию для вас и позволят «перечислить» ресурсы, которые вы не смогли бы найти другим путём (например, используя инструменты поиска скрытых файлов и папок). Убедитесь, что ваши словари, которые вы используете с Dirb, Dirbuster, wfuzz или любыми другими инструментами, содержат .DS_Store в качестве искомого файла.
Пример файла .DS_Store. Мы можем идентифицировать файлы config, LICENCE, loader и package.json, а также папки node_modules/, pages/ , utils/ и wrappers/ - типичная структура приложения NodeJS:
Главная проблема файлов .DS_Store в том, что они используют специфичный формат Apple и их нелегко прочитать, хотя можно найти некоторые онлайн инструменты парсинга.
Ищите скрытые папки и файлы в ваших любимых инструментах с готовыми для использования словарями
В настоящее время этот словарь содержит
80k записей, и он очень эффективен, когда используется в отношении типичного публично доступного веб-сервера. Вы можете скачать его и сами попробовать с инструментом по вашему выбору.
Заключение
Всегда стоит проверить, существуют ли на веб-сервере какие-либо из описанных в этом посте папок. Обнаруженный Git или SVN репозиторий это просто катастрофа, так как за этим последует загрузка исходного кода веб-приложения. Также как и найденные конфигурационные файлы проекта IntelliJ IDE приведут к этому же. Иногда вам не нужно ничего кроме единственной «подсказки» от такого источника чтобы «сломать» веб-приложение целиком (вместе с самим веб-сервером).
Читайте также: