Tuesday, 8 January 2008

User Enumeration - Part 2

In my previous post, I had discussed how an attacker may enumerate valid usernames on a vulnerable web site. The details of my previous post can be found here. In this post, I will describe what measures can developers take to prevent these types of attacks.


Safeguarding New User Registration Process

This is the most effective way of enumerating usernames without alerting system administrators or end users, but can also be the most difficult to prevent. It is not really possible to make user registration 100% secure against these attacks but the impact can be reduced considerably by taking appropriate measures.

One approach may be to log the IP address from where the request is coming. If a web site is receiving a lot of user registration requests from the same IP address in a very short period of time, it may indicate that an automated attack is taking place. This type of attack can be prevented by limiting the number of requests from that IP address. The main problem with this approach would be that the users may be behind a proxy server and thus the IP address of the proxy would be logged instead of the actual machine from where the request is coming. So the best approach would be to put a time limitation for the number of requests coming from a particular IP address.

The second approach may be to introduce the use of CAPTCHA to prevent automated tools to send registration requests to the server.


Safeguarding User Authentication Process

The main approach to safeguard user authentication would be to generate a generic error message like this: "Username or Password is wrong". This would not reveal if the username is wrong or the password is wrong. Sometimes developers try to make the authentication process more secure by using a two step authentication. The web site may still be vulnerable if this functionality is not implemented properly e.g. an error message is generated just after the first step if the user details on the first page are wrong, or the user is directed to the second page if the details on the first page are correct. The proper way of implementing two step authentication would be to generate a generic error message only at the end of the authentication process and not revealing the actual cause of failure.


Safeguarding Password Reminder Functionality

One thing to consider to prevent password reminder functionality from user enumeration is to return a generic message such as this "An e-mail has been sent to the registered e-mail address" every time a password reminder request is made. There is no way for an attacker to find out if the request failed or succeeded. But at the same time, an e-mail is sent to the registered e-mail address if that address existed, or nothing will happen otherwise.

One more thing to consider here is that separate user details may be used for authentication and password reminder functionality e.g. a username instead of an e-mail address may be used for user authentication, while an e-mail address may be used for password reminder functionality. The benefit of doing this would be that even if an attacker is able to enumerate an e-mail address, he would still have no clue about the username, making the knowledge of e-mail address useless to him.


Safeguarding User Enumeration through Directory Enumeration

Some web applications would allocate a separate directory to the registered users where the name of the directory is same as the username. This type of web site functionality is very rare in high profile web sites, but still can be seen at some places. Because of the nature of error messages coming back from the web site for existing (HTTP Error code: 403 Forbidden) and non-existing (HTTP Error code: 404 Not Found) directories, this type of functionality is best avoided.

By implementing the above steps, developers can reduce the risk of user enumeration considerably on their web sites.

I have tried to list the user enumeration prevention techniques above to the best of my knowledge. If anyone reading this post knows better ways of preventing these attacks, please leave a comment and I will try to add them here.

0 comments: