Home › Forums › My bug bounty target leaks an internal domain name. What could be done to investigate this further? › Reply To: My bug bounty target leaks an internal domain name. What could be done to investigate this further?
Bug bounties typically do not cover internal domains even when exposed on the internet. Make sure to check it against the scope of the consent page on their website or the BB listing.
The reason the pages might not be loading could be how the URL rewrite/config and default documents are configured within the host service. Adding the / might be invoking the default document line of the host config and pulling something like “index.php” or “~*.php” and loading specific or any file of said type, however the directory as an object is blocked or locked down.
For instance, you can deny access to a directory to prevent viewing all the contents of the directory when there is no browsable page configured as the default document and you can only view documents with explicit URL paths, or if the directory is browsable but not default doc set, you’ll get a list of all files within the directory. This is similar to how in many sites you can view multiple css files by removing the filename.css as many developers dump the css into a shared folder open to all to simplify permissions issues.
Sorry if you already know this, just covering a few items as I know not everyone has equal exposure to certain setups. I’ve learned by hosting Apache2, IIS, and nginx environments and trying to follow gardening documentation. You can probably work backwards from hardening docs to determine the behavioral risk as you’ve experienced, I know this specific serve or not serve content was covered.