This url presents the user with an invoice that is connected to a recent order, which he made at the example store. As IDs normally increment with each new data input, we could imagine that the next invoice might have the ID 43. Even in cases where it isn't that simple, we could find a pattern in comparing the url for two different invoices we received from the same store. We could now execute fuzzing on this website by replacing the ID with random data until we find a match. By incrementing/decrementing the ID we could for example try to access different invoices, which should not work if the invoice ID does not match the invoices I am allowed to access. In this example case, we observed the ID parameter from the websites normal behaviour and tried to alternate it with different data.
2. Fuzzing without previous knowledge
Not all applications communicate their parameters to the users interface and therefore are easily readable. In addition it is also possible to look for hidden applications, features, endpoints that are not directly linked on the website.
There are multiple examples of URLs, which can be accessed by non-authorised users. By finding these entry points, an attacker can learn a lot about the structure of an application and potentially access data that should not be publicly available.
To prevent being exploitable by Fuzzing attacks, it is important to secure all endpoints that should not be publicly accessible. Examples for such security measures are the following:
Disable directory listing on your server. This can easily be done by adding "Options -Indexes" into the .htaccess file. If directory listing is enabled, a user can navigate to a folder and if there is no index-file located, the server will return a list of all containing folders instead.
If you use version control to develop your application, never publish the meta data folders to your production/development servers. .git .svn folders and so forth contain all non-compiled files including their development history and offer very detailed information on how the application works. These folders may also include passwords, usernames and other credentials.
If you have an admin endpoint, secure it with credentials that contain secure passwords for each user. In addition to a normal username/password form, these endpoints can be secured by basic auth .htaccess protection.
If you provide files on your webserver, these should not be directly accessible. So instead of providing your users with the following url: "http://www.example.com/files/invoice42.pdf", they should receive the download over a URL like this: "http://www.example.com/invoice/download?id=42". This servers multiple purposes: The application can first confirm if the user is actually allowed to access this file and additionally the user cannot simply execute fuzzing on the folder directly and try to access other files.