Cloud

9/27/2017
10:30 AM
Ido Safruti
Ido Safruti
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

How to Live by the Code of Good Bots

Following these four tenets will show the world that your bot means no harm.

Although my company fights problems caused by malicious bots on the Internet, many bots are doing good things. These beneficial bots may help a site get better exposure, provide better product recommendations, or monitor critical online services. The most famous good bot is the Googlebot, which crawls links to build the search engine many of us use.

To keep their access to the Web open, the makers of good bots must understand how to tell the world about their bots' intentions. At PerimeterX, we defined a "Code of Good Bots" that provides basic rules of good behavior. If legitimate bot makers follow this code, then websites and security services (like PerimeterX) can easily identify such bots.  

If you're a bot developer, we recommend following the Code of Good Bots:

1. Declare who you are.
The Internet is awash in spoofed and poorly identified traffic. This includes bad bots that seek to harm sites. To avoid suspicion, a bot developer should make its bot declare its identity in the user-agent HTTP header when communicating with a site. We also recommended that bot developers provide a link in the user-agent header to a page describing the bot, what it's doing, why a site owner should grant it access, and methods a site owner can use to control the bot.

Googlebot, for example, will always include the word "googlebot" in the user-agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

2. Provide a method to accurately identify your bot.

Good bot builders should provide a defensible method to verify a bot is what it declares itself to be. While declaring a specific user-agent is important, malicious bots can pretend to be legitimate by copying the user-agent header of a beneficial bot (also known as user-agent spoofing). For this reason, validating the good bot's source IP address is crucial.

The bot maker should provide a list of IP ranges as an XML or JSON file on its website. This list also can be provided as a DNS TXT record in the bot owner's domain. We recommend an expiration time for the list, to indicate the frequency at which this list should be retrieved.

Another method used by many crawlers was introduced by Google and calls for a sequence of reverse DNS and DNS lookups to validate the source IP address. You can read more about this method here. Although Google's verification method is common and offers the required safety, it is very inefficient for the validating site. Providing a list of IP ranges enables a much more efficient validation process.

We recommend that bot makers specify the verification method in the URL provided in the user-agent string.

The validation method should be strong enough that bad bots can't pass this test. Specifically, the method should restrict the IP address ranges to those controlled or owned by the bot operator. For example, suggesting that a site owner verify that the IP address is in the Amazon Web Services (AWS) IP ranges isn't a good idea. Anyone can purchase an AWS virtual server and use it to send requests across the Web.

3. Follow robots.txt.
The robots.txt file is the de facto standard used by websites to communicate to bots and crawlers the general access policies of the site. The standard specifies how to inform the bot about which areas of the website shouldn't be crawled or scraped, rate and frequency in which a bot can access the site, and more. Good bots are required to download the robots.txt file from the site before accessing it, parse it, and follow the instructions.

4. Don't be too aggressive.
This is related to robots.txt and requires some common sense. Overly aggressive behavior can slow down a site or even take it offline. Different websites have different capacities to handle bot traffic. Some are set up to scale up quickly should massive traffic appear; others are not and will choke on even a small amount of additional traffic. While a bot may want to collect data quickly, this desire must be tempered against the realities of what the site can handle. We've seen cases where good bots contribute over 90% of the requests coming to a site.

Bots should respect the "Crawl-delay" instruction if specified in robots.txt. For example, site owners could use this to instruct a 10-second delay between requests. Some bots, such as Googlebot and Bingbot, provide more enhanced methods to control their crawlers, and specifically crawling rates.

If a site owner doesn't provide instructions on crawl speed and crawl access, the bot maker should default to a moderate, generally acceptable crawling rate.

The Code of Good Bots is Good for Us All
The importance of bot makers following the Code of Good Bots grows more urgent because of the rise of sophisticated bot attacks that piggyback on users via malicious browser extensions or on poorly secured Internet of Things devices. Site owners may default to more aggressive anti-bot policies in the effort to defend their user experience, site performance, and site integrity. The Code of Good Bots is critical for making sure that even then we continue to benefit from the good things good bots offer for users and businesses.

Related Content:

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.

Ido Safruti is the founder and CTO at PerimeterX, a provider of behavior-based threat protection technology for the Web, cloud, and mobile apps that protects commerce, media, and enterprise websites from automated or non-human attacks. Previously, Ido headed a product group ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
12 Free, Ready-to-Use Security Tools
Steve Zurier, Freelance Writer,  10/12/2018
Most IT Security Pros Want to Change Jobs
Dark Reading Staff 10/12/2018
Most Malware Arrives Via Email
Dark Reading Staff 10/11/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-1744
PUBLISHED: 2018-10-15
IBM Security Key Lifecycle Manager 2.5, 2.6, 2.7, and 3.0 could allow a remote attacker to traverse directories on the system. An attacker could send a specially-crafted URL request containing "dot dot" sequences (/../) to view arbitrary files on the system. IBM X-Force ID: 148423.
CVE-2018-1747
PUBLISHED: 2018-10-15
IBM Security Key Lifecycle Manager 2.5, 2.6, 2.7, and 3.0 is vulnerable to a XML External Entity Injection (XXE) attack when processing XML data. A remote attacker could exploit this vulnerability to expose sensitive information or consume memory resources. IBM X-Force ID: 148428.
CVE-2018-18324
PUBLISHED: 2018-10-15
CentOS-WebPanel.com (aka CWP) CentOS Web Panel 0.9.8.480 has XSS via the admin/fileManager2.php fm_current_dir parameter, or the admin/index.php module, service_start, service_fullstatus, service_restart, service_stop, or file (within the file_editor) parameter.
CVE-2018-18322
PUBLISHED: 2018-10-15
CentOS-WebPanel.com (aka CWP) CentOS Web Panel 0.9.8.480 has Command Injection via shell metacharacters in the admin/index.php service_start, service_restart, service_fullstatus, or service_stop parameter.
CVE-2018-18323
PUBLISHED: 2018-10-15
CentOS-WebPanel.com (aka CWP) CentOS Web Panel 0.9.8.480 has Local File Inclusion via directory traversal with an admin/index.php?module=file_editor&file=/../ URI.