---
title: Enumeration
---

> Agent instructions:
> **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown.
>
> - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version.
> - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt).

Enumeration, in terms of security, is a vulnerability, which enables a potential attacker to guess some hidden system information. There are many types of enumeration threats, but we will discuss only two of them in this topic:

- [Username enumeration](#username-enumeration)
- [File enumeration](#file-enumeration)

## Username enumeration

The username enumeration is an activity in which an attacker tries to retrieve valid usernames from a web application. The web applications are mostly vulnerable to this type of attack on login pages, registration form pages or password reset pages.

If the system is vulnerable to the username enumeration attack, the attacker may be able to obtain a list of existing usernames in the system by submitting input (valid and invalid user names) and analyzing the server response (error messages). The attacker can then run a dictionary attack to further exploit the obtained information.

### Real-world example of a username enumeration attack

There was one well-known username enumeration vulnerability related to previous versions of Apache web server. Some distributions contained a misconfiguration, which enabled potential attackers to identify existing usernames.

When an attacker submits an HTTP request for a possible user's home page, _http://www.example.com/\~_, the server responses differently depending on whether the username exists or not:

- If the username exists and does not have a homepage, the server responses with HTTP result code 403, and the server message "_You don't have permission to access /\~username on this server._"
- If the username does not exist, the server responses with HTTP result code 404 and the message "_The requested URL /\~username was not found on this server._"

Because the server responses differently in these cases, the potential attacker can test and enumerate existing usernames. The attacker can then exploit this data for further attacks on the server.

### Example of a web application username enumeration vulnerability in web application

When you create a web part in your web application, which enables users to log in, do not reveal information about existing usernames:

> **Warning:** **Wrong**
>
> If the submitted username is incorrect:
>
> ```csharp
>
> Entered login does not exist.
>
> ```
>
> If the submitted username exists, but the password is incorrect:
>
> ```csharp
>
> Entered password is incorrect.
>
> ```

This way, the attacker can learn, which usernames exist in the system and which do not.

### How to prevent username enumeration attacks in Kentico

The default configuration of Kentico is protected against this type of attack.

If you plan to create a custom login web part, be sure to **show only generic error messages**:

> **Tip:** **Correct**
>
> In both situations (username does not exist or the password is incorrect):
>
> ```csharp
>
> Authentication failed. 
>
> ```

This way, the attacker cannot distinguish between valid and invalid usernames.

In registration web parts, you cannot completely eliminate this vulnerability, because you have to check (and tell the user) if the submitted username already exists. Therefore, **always include CAPTCHA** in these web partsto prevent automatic collecting of the data by scripts.

## File enumeration

In this type of enumeration attack, the attacker tries to guess the file names on the server and manage to gain access to them.

In Kentico, the attacker can for example try to guess the name of an export file. The export files are generally located in the _\CMSSiteUtils_\*\\\*_Export_ folder. The attacker can learn the structure of the file name and eventually guess an existing one (for example, by trying out different time stamps).

To protect your servers against this type of attack, **forbid access to sensitive directories** in the _web.config_ file. See [Restricting access to directories](https://docs.kentico.com/k11/securing-websites/deploying-websites-to-a-secure-environment/restricting-access-to-directories.md).

## Summary

- Do not reveal username and password details on your web pages (how long the username/password should be, which characters it should contain, etc.)
- Show only generic error messages (_Login failed._ / _The combination of username and password is invalid._) in custom login web parts.
- Use CAPTCHA in registration forms.
- Forbid access from the outside to directories, whose names could be guessed by potential attackers.