views:

88

answers:

3

Hi,

Our team have built a web application using Ruby on Rails. It currently doesn't restrict users from making excessive login requests. We want to ignore a user's login requests for a while after she made several failed attempts mainly for the purpose of defending automated robots.

Here are my questions:

  1. How to write a program or script that can make excessive requests to our website? I need it because it will help me to test our web application.

  2. How to restrict a user who made some unsuccessful login attempts within a period? Does Ruby on Rails have built-in solutions for identifying a requester and tracking whether she made any recent requests? If not, is there a general way to identify a requester (not specific to Ruby on Rails) and keep track of the requester's activities? Can I identify a user by ip address or cookies or some other information I can gather from her machine? We also hope that we can distinguish normal users (who make infrequent requests) from automatic robots (who make requests frequently).

Thanks!

+1  A: 

In regards to #1, there are many automation tools out there that can simulate large-volume posting to a given url. Depending on your platform, something as simple as wget might suffice; or something as complex (relatively speaking) a script that asks a UserAgent to post a given request multiple times in succession (again, depending on platform, this can be simple; also depending on language of choice for task 1).

In regards to #2, considering first the lesser issue of someone just firing multiple attempts manually. Such instances usually share a session (that being the actual webserver session); you should be able to track failed logins based on these session IDs ang force an early failure if the volume of failed attempts breaks some threshold. I don't know of any plugins or gems that do this specifically, but even if there is not one, it should be simple enough to create a solution.

If session ID does not work, then a combination of IP and UserAgent is also a pretty safe means, although individuals who use a proxy may find themselves blocked unfairly by such a practice (whether that is an issue or not depends largely on your business needs).

If the attacker is malicious, you may need to look at using firewall rules to block their access, as they are likely going to: a) use a proxy (so IP rotation occurs), b) not use cookies during probing, and c) not play nice with UserAgent strings.

macabail
I thought only a browser has fixed UserAgent. If a hacker uses an automated tool, he can hide UserAgent or change it at will. Am I right?
Bryan
Yes; but that is why the specific context matters. If you are protecting against a hacker, then automated firewall and server security rules are the way to go; if its protecting against users who just keep trying, then what I posted should work.
macabail
+1  A: 

RoR provides means for testing your applications as described in A Guide to Testing Rails Applications. Simple solution is to write such a test containing a loop sending 10 (or whatever value you define as excessive) login request. The framework provides means for sending HTTP requests or fake them

Not many people will abuse your login system, so just remembering IP addresses of failed logins (for an hour or any period your think is sufficient) would be sufficient and not too much data to store. Unless some hacker has access to a great many amount of IP addresses... But in such situations you'd need more/serious security measurements I guess.

Veger
Some users using NAT may actually share the same IP, isn't it? Will they be blocked if I use IP to identify a user?
Bryan
Yes, since they share their IP. But, those people (while abusing your login) will be mostly in a home network and all computers in that network are owned by them. Furthermore by remembering the failed logins for a certain period will not permanently block them (and other users using the same IP).
Veger
+1  A: 

One trick I've seen is having form fields included on the login form that through css hacks make them invisible to the user.

Automated systems/bots will still see these fields and may attempt to fill them with data. If you see any data in that field you immediately know its not a legit user and ignore the request.

This is not a complete security solution but one trick that you can add to the arsenal.

Harley Green
Thanks Harley. This one seems interesting!
Bryan