8

I have a web server with 2 page: index.html and secret.php.

The content of index.html is:

<html><body><h1>It works!</h1></body></html>

You can see the index.html file doesn't have any link to secret.php

I don't have file robots.txt. And if someone access to my web server. Can they know I have a secret.php pages?

I already test with scrapy and nutch crawler. It can not find secret.php file.

tkha
  • 89
  • 1
  • 2
  • 1
    The anwser is simple : no. The only way to find it, is to try random pagename until server return code 200 (ok) instead of 404 (not found) or if you have a link somewhere (even on another web site or web document) pointing to this page. – Froggiz Nov 14 '15 at 11:23
  • 2
    Did you even take the time to use the search slit on this site? Your question was asked several times before. – jk - Reinstate Monica Nov 14 '15 at 15:59
  • 1
    Yes, they can find that by guessing the name of it. You might want to use something other than `secret.php`. – Mark Buffalo Nov 14 '15 at 18:55

3 Answers3

16

When they don't know it is there and have only the domain name, they are unlikely to find it without guessing. But guessing is not uncommon. When you put a webserver online it won't take long until you will have bots probing it for vulnerabilities by flooding it with requests for all kinds of probably interesting files.

What you are doing is very insecure, because it relies on security through obscurity. It is the digital equivalent of storing the key to your house under your doormat. Should someone suspect it's there, there is nothing which stops them from accessing it. The existence can leak in various ways, for example because you access it without https from an unsecure network (You did set up https, did you?).

When you really want to protect the content and functionality of that script from unauthorized access, protect it with a password using .htaccess. It's not as beautiful as a html login page, but really simple to set up.

Philipp
  • 48,867
  • 8
  • 127
  • 157
  • @K.Lotus Agree with Philipp. But .htaccess won't work with all web servers, of course. Check your web server manual for more info or alternatives. – vic Nov 14 '15 at 11:26
  • You have answered the question, but I want to add that there are many tools that exploit this "security through obscurity" vulnerability. DirBuster was once the de-facto open tool to search for hidden pages. There are probably better tools out there now. – Dog eat cat world Nov 14 '15 at 11:35
  • 1
    +1. Also worth noting is that you may want to be sure to disable directory listings in your web server config. See https://wiki.apache.org/httpd/DirectoryListings for more info on this, and how this is done in apache. – mti2935 Nov 14 '15 at 13:07
  • 1
    Is accessing `http://www.example.com/account?token=1klJK45j3kl1A0fqoOfojwlkjdfKQF` via a GET also "security through obscurity"? – Nick T Nov 15 '15 at 04:40
  • @NickT You are explicitly not using https, so it's insecure anyway. When you would be using https, it depends on how long your tokens are valid. When they don't expire, they can be leaked. For example when a user posts a deep-link and forgets to remove their token. – Philipp Nov 15 '15 at 11:04
  • @NickT: Better use HTTPS, so the parameter is not transmitted in plain text. – sebix Nov 15 '15 at 11:07
  • @NickT Also, depending on how you generate your session ID's they might indeed be vulnerable to guessing attacks. See OWASP #68 [Insufficient Session-ID length](https://www.owasp.org/index.php/Insufficient_Session-ID_Length). This is not just theoretical: [Early versions of PHP session ID's were not sufficiently random so there were attacks at them](http://seclists.org/fulldisclosure/2010/Mar/519). – Philipp Nov 15 '15 at 11:14
3

If you were to access the secret page from your browser, it could send the URL to Google. Google then could add that page to it's database (since you didn't forbid that with robots.txt). After that, anybody can search 'site:yourdomain.com' and see your secret page.

dnt
  • 31
  • 2
  • 3
    I once used the obscure-and-nowhere-referenced url approach as poor man's file transfer. At that time it was just fastest to setup and tell the remote party what to do, and it was online for only a few hours. Surprisingly, the url was *additionally* retrieved from a very different part of the world, which did trigger some alarms. It turned out that the "hacker" was Microsoft being so kind to download and scan for malware on behalf of the intended recipient's IE - as per the recipients browser settings. You can't be sure it won't end up in search engines (bing in this case) – Hagen von Eitzen Nov 14 '15 at 22:48
  • 2
    It is worth noting that adding the path to the `robots.txt` file is not an effective solution as it is only respected by ethical crawlers and can be easily viewed by any user, giving away the location of all of your "secret" files. – WillS Nov 14 '15 at 23:17
0

There is, of course, no technical way to find that file as long as you don't have any vulnerable services running on your system. Its not very likely that someone is searching for hidden files without a reason. But, of course, you should use .htaccess when you can.

In a typical scenario, attackers scan for webapps that are known to be vulnerable or allow a wide specturm of access to your system if bad or default passwords are used. This basically applies to all administrative web applications such as PHPMyAdmin, for example. Then they try to exploit the vulnerablity or to enter the webapp using default or common passwords.

If exploits/bruteforce fails or the server has already been hacked and "secured" by the previous hacker, it frequently happens that the attackers then uses a "shell scanner". Shell scanners are simple scripts that check your server for a given list of filenames. Those filenames are often the ones commonly used for webshells like the c99. This is the moment where it can happen that your hidden file is found. I can't think of any other scenario where someone starts searching for hidden files without a reason.

vic
  • 546
  • 3
  • 11
davidb
  • 4,285
  • 3
  • 19
  • 31