My Top 6 Honeytokens

A few years ago, I was looking for a new developer to join our team. Of course, the hard part was to find a developer that was up to the task. I don't believe much of what people say in their resumes, so I rather had them show me a site they coded and give me permissions to take a closer look. Many of the sites failed miserably after only some minor probing. The result was a small guide I published to summarize my experience, Web Application Auditing over Lunch. Sadly, a lot of attacks are just so simple. But then again, lets see how we can turn this around and use it against the attacker. An attacker will likely try to use simple tricks just like the once outlined in the guide. As a counter measure, I am using a set of "honeytokens". Simple tripwires to alert me of an attacker.

1. Don't hand session credentials to automated clients: Whenever a browser identifies itself a "wget", or a search engine, don't bother setting a session cookie for them. They shouldn't log in. Yes, it is easy to fake the user agent. But many attackers don't bother.
2. Add fake admin pages to robots.txt: Add a fake admin page as "Disallowed" to your robots.txt file. We all know of course that robots.txt should not be used as a security tool. But many websites still use it that way and as a result, attackers use it as a road map to attack a site. Whenever someone hits your fake "admin" page, you know they are up to no good.
3. Add fake cookies: Add a fake "admin" cookie and set it to "FALSE", or "No". This is a classic mistake attackers are looking for. But you are of course not using this cookie to assign admin privileges. Instead, you detect attacks whenever the cookies value changes.
4. Add "spider loops": Little redirect loops to send spiders in a loop. Be nice, and add "NOFOLLOW" tags to not annoy legit search engines too much. See if anybody falls for it. It is kind of like a La Brea tarpit for web application vulnerability scanners.
5. Add fake hidden passwords as HTML comments: On your login page, add a comment like <!- NOTE: developer test login, user: alkhewr password: 234kjw -> ... Wait for someone to use it
6. "Hidden" form fields: This is different from the <input type="hidden"> form field. Instead, add a regular form field <input type="text"> but set the style to "display: none" . That way, the form field will not be visible to normal browsers. But vulnerability scanners will happily fill it in. Note that this can be a problem for "audio browsers" used by the blind. You may want to pre-fill the form with something like "do not change this field".

Now isn't that all just about hiding more serious vulnerabilities? Security through obscurity? Sure ... it is... but it works. In my opinion, a good defensive technique is easy to implement but hard to bypass. These techniques only take minutes to implement, but break most automated tools and will cost hours of the attackers time.

You have to decide for yourself what to do once you detected an attacker. Maybe just hope for the attacker to go away? A more aggressive, but dangerous approach is to automatically shun attackers. It all depends on how much you are willing to lock out the wrong person. In particular the hidden URLs in robots.txt are dangerous as someone who discovers the trick my now spam this hidden URL to your customers and lock them out of the side if they click on it. If you decide to shun attacker: Have a plan ready to mass "unblock" a large number of false positives.

Got your own tricks like that? Let us know and write a comment below!