Как скрыть директорию на сайте

Как закрыть папку на сайте от просмотра

Admin 12.09.2017 , обновлено: 13.09.2017 Support

Для защиты данных на своём сайте важно закрывать директории от удалённого просмотра их содержимого. Особенно это касается папок созданных вручную, а не через CMS.

Потребовалось мне не так давно достать одно видео с бэкграунда одного из сайтов. В коде адреса на него не было и выводилось оно через base64. А это css ссылка имеющая в себе зашифрованный код изображения или видео, в котором ссылки на источник не видно. Выглядит она примерно так:

И такой код, например для видео, содержит череду беспорядочных знаков, которых хватило бы на несколько десятков страниц А4.

Я уже почти отчаялся в поисках ответов, как же достать ссылку из этого зашифрованного формата. Интернет «молчит» и сам похоже не знает как узнать ссылку из base64.

А потом совершенно случайно, подумал, а что если напрямую зайти в директорию изображения. Вдруг папка открыта.

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

Чтобы такого безобразия на вашем сайте не было надо защищать директории от посягательств из вне. Для этого в директории папки, которую нужно защитить от просмотра, надо создать файл «.htaccess». А в нём прописать следующее:

Теперь при прямой ссылке на эту папку будет возникать ошибка доступа к ней:

Как скрыть содержимое директории на сайте

Наверняка, Вы уже знаете, что при обращении к каталогу открывается файл по умолчанию (как правило, index.php, index.html или index.htm). Однако, что происходит, если такого файла не существует? По умолчанию показывается содержимое каталога, что, безусловно, не очень хорошо. Поэтому в этой статье я покажу самый простой способ, как можно скрыть содержимое каталога на сайте.

Первым делом откройте, либо создайте, если его нет, файл .htaccess в корне своего сайта. Теперь добавьте туда всего одну строку:

После этого все директории сайта, в которых нет index-файла, будут скрыты от пользователя.

Хочется отметить, что это не единственный способ скрыть содержимое каталога на сайте. Очень часто применяется способ загрузки пустого index-файла. То есть в каждую директорию, которую надо скрыть от пользователя, мы загружаем пустой файл, например, index.html. Таким образом, при обращении к директории пользователь не увидит ничего, кроме белого экрана.

Это два, на мой взгляд, самых лучших способа сокрытия содержимого директории на сайте. Я, лично, пользуюсь первым способом, так как он проще, но, возможно, Вам по тем или иным причинам захочется воспользоваться вторым.

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Она выглядит вот так:

Комментарии ( 7 ):

Здравствуйте,я хотел использовать .htacces для запрета копирования фото.я читал .htacces нужно вложить в папку с фото.А что там нужно написать,не в курсе.И хотелось бы одну страницу исключить из запрета.Как это можно зделать?

Пробовал использовать order deny,allow deny from all allow from 127.0.0.1 но снимки исчезают,блокировка правой кнопки мышки не работает для мобильных браузеров,может знаете специальный код?

понятно,но почему-то background в мобмльных не работает,спасибо.

htaccess с deny from all вообще нельзя добавлять в директорию с изображениями, которые выводятся на сайте.

Михаил,вопрос не столь значительный,а можно в .htaccess создать стиль background для изображений?Или сам файл .htaccess в папке уже уничтожает фото?пробовал оставить файл .htaccess пустым, изображения тоже отсутствовали.

Как скрыть папку с аватрами(изображения) от прямого доступа?

Изображения сохраняются в директорию images/ . Можно ли как то запретить прямой доступ по url, но дать возможность выводить с помощью тега img?
Я думал над альтернативным способом, но не уверен реализуемо ли, хранить картинки на уровень выше корня сайта. С помощью header заголовков получать изображения, преобразовать в base64 и отдавать клиенту в тег img.

Можно ли как то запретить прямой доступ по url, но дать возможность выводить с помощью тега img?

Какой-то особенный "прямой доступ" — это очень распространенное суеверие. В реальности же никакого "кривого доступа" не существует.

C точки зрения сервера, ВСЕ обращения к нему — "прямые"

И запретив "прямое" ты просто запретишь любые обращения вообще.

Поэтому любые фантазии про "закрыть прямой доступ но позволить бразуеру запрашивать" не имеют смысла.

Надо купить книжку Котерова, РНР7, и прочитать с самого начала. Там даются основы протокола НТТР, как раз для таких вот самоучек, которые всё изучают методом тыка.

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

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

Скрытые директории и файлы как источник чувствительной информации о веб-приложении

Скрытые директории и файлы, случайно оставленные на веб-сервере, могут стать очень ценным источником чувствительной информации. В корневой папке веб-приложения может быть множество скрытой информации: файлы и папки системы управления версиями исходного кода (.git, .gitignore, .svn), конфигурационные файлы проекта (.npmrc, package.json, .htaccess), файлы пользовательских конфигураций с популярными расширениями, такими как config.json, config.yml, config.xml и многое-многое другое.

В целом, эти источники могут быть разделены на несколько общих категорий:

Системы управлениями версиями исходного кода
Конфигурационные файлы проекта, которые создаёт IDE (интегрированная среда разработки — обычно, это редактор исходного кода с расширенными функциями)
Специфичные конфигурационные файлы и файлы настроек для данного проекта или технологии

Давайте взглянем на них более внимательно — где их искать и какого рода информацию ожидать от них.

Системы управления исходным кодом

Git это «бесплатная и с открытым исходным кодом распределённая система контроля версий, созданная для быстрой и эффективной работы с любыми проектами от маленьких до очень больших». С GitHub.com это сейчас одна из самых популярных систем контроля версия кода, особенно в мире открытого исходного кода. Также многие компании используют их собственные установки GitLab, а также GitHub Enterprise или Bitbucket.

Базовая информацию о Git проектах

Только что созданный Git репозиторий содержит несколько стандартных папок и файлов, где храниться вся информация. Это пример папки .git в которую уже был сделан один commit (этим словом называют любое изменение в проекте, например, изменение исходного кода какого-либо файла, создание нового файла, удаление строк из файлов или файла полностью и прочее).

Базовая структура папки .git:

Давайте взглянем на это с точки зрения атакующего. Содержимое репозитория Git записано в объекты. Все они хранятся в папке .git/objects.

Объекты могут быть одного из трёх типов: commit, tree и blob.

Commit — это информация о коммитах с текущим Tree (деревом, то есть структурой папок и файлов) хешей объектов.

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

Blob — это тип объекта Git, где храниться содержимое файлов. Если вы знаете хеш определённого файла, вы можете прочитать его содержимого используя команду git cat-file.

Если вы нашли папку .git на веб-сервере, тогда есть простой способ получить содержимое любого файла из неё, просто загружая и читая объекты Git. Иногда, если вам повезло, вы можете попробовать клонировать репозиторий, используя стандартную команду git clone или просто запустим команду wget с установленной опцией -r для рекурсивной загрузки всей папки .git. Но это не всегда возможно по нескольким причинам (такие как отсутствие требуемых учётных данных или отсутствие команды wget). Давайте предположим, что все эти опции невозможны.

Чтобы убедиться, что папка .git доступна, просто проверьте, получите ли вы ответ HTTP 403 (или что-то похожее, гавное чтобы это не был код ответа 404, поскольку он означает, что на этом сервере или в этом расположении нет папки .git):

Ответ 403 говорит о существовании папки .git на этом сервере:

Создание зеркала удалённых файлов и папок используя локальный Git репозиторий

Чтобы это можно было делать, вы должны создать ваш собственный, локальный «заготовочный» репозиторий .git со скелетом структуры папок и загрузить объекты Git с удалённого сервереа.

Начинаем с создания папки-заготовки Git:

Это инициализирует пустой репозиторий Git со всеми необходимыми файлами и папками.

Получение и чтение информации об объектах

Для получения информации из репозитория Git, в начале мы должны найти стартовую точку. Git сохраняет всю информацию в файле журнала и этот файл доступен по пути .git/logs/head

Пример содержимого файла .git/logs/head:

Если .git/logs/head не рабобтает, но .git возвращает Forbidden 403, что означает, что он там, попробуйте вместо этого .git/logs/HEAD.

Давайте взглянем немного ближе на пример строки из этого файла:

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

Вначале мы должны создать верный путь к объекту. Путь содержит: общий путь для всех объектов в этом репозитории, им является .git/objects, за ним следует две части воссозданные из хеша — имя директории (первые два символа хеша) и имя файла (оставшаяся часть хеша, начинающаяся с третьего символа). Поэтому для получения объекта, идентифицируемого хешем 07603070376d63d911f608120eb4b5489b507692, нам следует попытаться открыть следующий url: localhost/testapp/.git/objects/07/603070376d63d911f608120eb4b5489b507692

Вот то, что нам нужно — всплывающее окно загрузки файла:

Помните, вы должны сохранить этот файл в вашу созданную ранее заготовочную папку Git — это самый простой способ читать содержимое объектов Git, поскольку по умолчанию ваш git (программа) будет искать их там. Убедитесь, что вы сохранили их в точности в это же самое расположение:

Теперь git cat-file должен стать вашим лучшим другом. Для проверки типа объекта, вы можете использовать следующую команду:

Для отображения содержимого объекта используйте команду:

Теперь мы можем проверить тип и прочитать содержимое ранее сохранённого объекта (я делаю это в репозитории, созданном на моём localhost, но вы получите тот же самый результат на вашей машине для любого репозитория Git — только будет другой хеш).

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

Мы очень близко. Как вы можете видеть, там только один файл — index.php, и также мы знаем его хеш объекта и тип, которым является blob. И этот то, что нам нужно для просмотра содержимого файла, используя этот же самый метод, который до этого мы использовали для чтения содержимого комита и объектов дерева (в начале вам нужно сохранить объект с веб-сервера, как описано выше):

Важно помнить, что содержимое файла index.php показано в том виде, каким оно было когда был сделан комит описанный объектом 07603070376d63d911f608120eb4b5489b507692. Если вы загляните в файл журнала, вы сможете увидеть, что был сделан второй комит (идентифицирован хешем объекта 4db7a14eee2cd3ff529278b75e1653e677fe1d02) и что это последний комит — он содержит все последние изменения — может быть содержимое index.php отличается от того, что мы видели до этого?

Следуем по всем шагам (читаем содержимое комита для поиска хеша дерева, затем читаем дерево для поиска хеша index.php и так далее), мы увидим действительное содержимое index.php:

Поскольку ручное получение объекта неэффективно и требует много времени, был создан простой консольный инструмент на Python для автоматизации этого процесса. Вы можете взглянуть на него здесь.

Файл .gitignore

Ещё одна вещь о которой стоит упомянуть если мы нашли оставленную на веб-сервере папку .git — файл .gitignore. Цель этого файла простая — это место, куда вы можете добавить имена всех папок и файлов, которые НЕ должны добавляться в репозиторий (но это не означает, что их там нет — это только означает, что они просто не существуют как часть репозитория Git). То есть это самый простой способ найти всё содержимое, которое не должно раскрываться описанным выше способом.

Пример файла .gitignore, раскрывающего существование интересных папок и файлов:

Subversion (SVN)

Subversion (или SVN) — это система контроля исходного кода созданная в Apache Software Foundation и она ещё очень популярна и широко используется, особенно в корпоративной среде с огромной унаследованной кодовой базой.

Структура SVN папок и файлов выглядит примерно как на следующем скриншоте:

С нашей точки зрения самым важным является файл wc.db базы данных SQLite и содержимое директории pristine/. В wc.db мы найдём хеши используемые как имена файлов в pristine/, то есть мы должны начать с этого файла.

Чтобы получить информацию из Subversion нам нужно убедиться, что файл wc.db доступен. Попробуйте открыть следующий путь в вашем веб-браузере:

Если открылось окно скачивания файла, то это означаете что есть шанс, что остальные .svn файлы будут там. Для начала нам нужно прочитать содержимое wc.db для получения информации о хешах файлов (здесь нет директории .logs как была в описанном выше репозитории Git).

Для чтения содержимого wc.db, вы можете использовать консольный клиент SQLite (или любой другой инструмент для управления базами данных SQLite):

Увидели операции INSERT в таблицу NODES? Каждая из них содержит имя файла и SHA1 хеш, который соответствует записи в папке pristine/:

Для сопоставления значение из NODES и имён файлов нам нужно выполнить несколько шагов:

удалить префикс $sha1$
добавить постфикс .svn-base
использовать первые два знака как имя папки внутри директории pristine/ (в этом случае это 94)
создать полный путь, который в этом примере будет:

Когда мы попытаемся открыть этот путь в браузере, у нас должно получиться скачать файл или его содержимое должно отобразиться непосредственно в браузере. Как прочитать содержимое определённого файла из репозитория .svn:

Также запись в таблице REPOSITORIES указывает на оригинальный путь в репозитории, которым является:

Здесь множество информации. Оставление папки .svn на веб-сервере это огромная ошибка и может быть очень опасным. Это может даже означать полную компрометацию исходного кода веб-приложения.

Файлы проектов IDE

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

Вначале давайте взглянем немного ближе на то, что создаёт JetBrains (https://www.jetbrains.com/).

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 содержат примерно такую информацию:

или даже больше как файл dataSources.local.xml:

Всё зависит от самого проекта, используемых в IDE плагинов (таких как отладчики, контролёры версий исходного кода или менеджер БД). В общем, стоит оглядеться и исследовать каждый узел component.

Как вы можете видеть, это очень интересный источник информации. Я рекомендую вам загрузить любую JetBrains IDE (они предлагают 30 дневный пробный период почти для всех продуктов, даже больше — вы можете загрузить IntelliJ Idea Community или PyCharm Community и использовать их бесплатно), затем создайте пробный проект, добавьте несколько папок и файлов, попробуйте поуправлять Git или SVN, создайте пример соединения с базой данных, и поиграйтесь с Database Manager. А затем углубитесь в изучение папки .idea/, чтобы увидеть, что вы можете там найти.

NetBeans IDE

NetBeans (https://netbeans.org/) — это другая очень популярная, бесплатная IDE для Java, C/C++, PHP, HTML5 и JavaScript разработки. В настоящее время поддерживается и принадлежит Oracle, NetBeans стала официальной IDE для Java приложений, и при этом она абсолютно бесплатная и с полностью открытым исходным кодом.

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 и запустите следующую команду в той же директории, куда вы его только что сохранили:

в конце процесса вы получите информацию вроде такой:

теперь запустите команду audit (вероятно, вам в начале необходимо зарегистрировать аккаунт на веб-сайте npmjs.org чтобы получилось сделать этот шаг):

после выполнения предыдущей команды, у вас будет отчёт, который содержит все уязвимости, идентифицированные этим инструментом:

Вероятно, это хорошая идея сохранить этот вывод в отдельном файле, поскольку иногда вы найдёте даже сотни выявленных слабостей по нескольким 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 и их нелегко прочитать, хотя можно найти некоторые онлайн инструменты парсинга. Одним из лучших источников, описывающим этот формат (а также Python библиотека для парсинга) — это Parsing the .DS_Store file format от Sebastian Neef. Подробности вы найдёте в статье Утечка имён файлов в .DS_Store: как просмотреть содержимое и как эксплуатировать.

Ищите скрытые папки и файлы в ваших любимых инструментах с готовыми для использования словарями

Один из самых простых способов обнаружить скрытые папки и файлы — это использовать инструменты перечисления (DirBuster, Dirb, wfuzz — и многие другие) со словарями, содержащими сотни тысяч имён самых популярных папок и файлов. Загляните в файл robots.txt, другие популярные места и т. д. Некоторое время назад автор этой статьи (bl4de) собрал такой словарь из нескольких найденных онлайн (например здесь https://github.com/danielmiessler/SecLists или здесь: https://github.com/danielmiessler/RobotsDisallowed — почёт Daniel Miessler за поддержку этих двух шикарных репозиториев!) и добавил парочку собственных записей.

В настоящее время этот словарь содержит

80k записей, и он очень эффективен, когда используется в отношении типичного публично доступного веб-сервера. Вы можете скачать его и сами попробовать с инструментом по вашему выбору.

Заключение

Всегда стоит проверить, существуют ли на веб-сервере какие-либо из описанных в этом посте папок. Обнаруженный Git или SVN репозиторий это просто катастрофа, так как за этим последует загрузка исходного кода веб-приложения. Также как и найденные конфигурационные файлы проекта IntelliJ IDE приведут к этому же. Иногда вам не нужно ничего кроме единственной «подсказки» от такого источника чтобы «сломать» веб-приложение целиком (вместе с самим веб-сервером).