By Tin Zaw, Director of Security Solutions
In April, Sherie Low logged into her Singapore Airlines account and saw that all her frequent flyer miles were gone. Instead, there was a note that four Russian names she didn’t recognize had redeemed 76,000 in miles—enough for four international coach flights.
Low had never shared her password with anybody, had never used anything except the official website to log in, and had not been the victim of a phishing scam. The fault lay entirely with an automated threat, a malicious program that had hacked into Low’s account via a brute-force attack.
When it comes to designing effective web security, websites often make the fatal mistake of not planning for this type of attack. As one article pointed out, Singapore Airlines had users sign in with a six-digit PIN number. Guessing the correct six numbers to gain access to an account is hard for humans, but it’s easy for computers. An automated program that simply guesses random strings of six-digit numbers could have found Low’s password in 25 seconds.
Hackers aren’t always human, and security systems need to not only keep out bad actors, but they must also keep out bad bots. At the same time, developers need to make sure their barriers block automated threats and not innocent people who want to use the website.
Automated threats are an emerging concern for web developers. They have the ability to quickly compromise a website and steal from users like Low by bypassing regular security systems. These automated threats are so intriguing to me that they led me to coauthor a book, Automated Threat Handbook, on the subject.
Here is why we can’t underestimate automated threats, and how we can defend against them.
Originally, programmers designed websites with people in mind. It was reasonable to believe that human beings alone would be browsing, searching, and clicking. However, human beings are also capable of writing programs sophisticated enough to mimic these same actions—only the programs can perform them thousands of times per minute.
That capability makes possible all sorts of automated threats. For example, say you have a website with products that regularly fluctuate in price. A developer might write a program that continually checks that website for the lowest possible prices. This would be fine if the developer were simply trying to get a good deal, but more commonly, they will scrape that pricing data from the website and sell it to a competitor. Armed with that knowledge, the competitor can undercut the price by a few pennies and snag the sale.
This practice isn’t illegal, but it certainly qualifies as an automated threat. Not only does it enrich the website’s competitors, but it also creates a slower loading experience for legitimate users. Because the malicious program is continually refreshing the site to get new data, it sucks up computing resources on the website’s servers.
When attackers have access to a list of stolen usernames and passwords, automated threats become even more powerful.
Here’s how it works: attackers buy usernames and passwords on the black market. They find a login page on the website they want to attack and use a program to automatically try tens of thousands of password combinations in order to log in. Whenever they manage to log in, they will scrape the user’s personal information and sell whatever they can. Some version of this might have been how hackers were able to access Low’s frequent flyer miles on Singapore Airlines if they didn’t get in by guessing her PIN.
If hackers are deploying automated threats against your website, what’s a developer to do? Scraping looks a lot like checking and rechecking a website, which is something a human user might do manually. A human user who had forgotten their password for a website might try inputting random combinations just like a malicious bot would. The trick is finding a way to detect and deter automated attacks without annoying legitimate human users. Just like you wouldn’t want to treat every shopper in your store like a criminal, you won’t want to make your secure website so difficult to use that even humans can’t access it.
When determining whether a user is automated or not, there are two major differences:
While a person will browse at a reasonable speed, automated attacks are rapid-fire. If someone is zipping around a website as quickly as each page loads, it’s likely they aren’t a human.
There are a few reasons a person would need to look at the same webpage 60 times in one hour. As for 600,000 times—that would be impossible! It’s a big hint that you’re dealing with a bot.
To avoid inconveniencing innocent human users, any website’s defensive strategies should focus on these aspects that characterize automated threats.
There’s no perfect solution for resolving automated threats. Sometimes, it is a cat and mouse game: as security professionals safeguard websites against the nonhuman activity, hackers work to make their automated attacks act more human all the time.
However, there are actions developers can take. A vital tool in this game of spot the bot is the website’s content delivery network (CDN). A good CDN will have years of legacy records about how humans typically use websites. Combined with a smart algorithm, like the one we’re developing at Verizon Digital Media Services, it should also be capable of using its pattern recognition functions to recognize anomalies before it is told. If there’s a sudden shift in activity away from the norm, it should be dynamic enough to mitigate the threat in real time.
Automated threats are always evolving, but a good CDN can keep a website from having to deal with them face to face. As the battle of the bots rages on, it’s best to have a program you can count on in your corner.
Visit our website to discover how our Edgecast CDN’s multilayered security can protect your website against bad bots.