BotDetect CAPTCHA Known Issues

This page lists known issues with BotDetect ASP.NET Captcha, with explanations why they occur and workaround suggestions.

Table of Contents

CAPTCHA Sound Doesn't Replay in Google Chrome when Served from the Visual Studio Development Web Server

Issue ID

#4130852

Affected products

BotDetect ASP.NET Captcha v3.0.15+

Affected servers

Visual Studio 2013 and Visual Studio 2012 built-in development web server

Affected clients

Google Chrome

Status

3rd party issue – cannot fix

Description

Clicking the BotDetect sound Captcha icon multiple times in Google Chrome usually replays the exact same audio; however, if the development web server coming with Visual Studio is used to serve the page, audio will only play once.

Steps to reproduce

  • Run a page using the BotDetect ASP.NET Captcha from Visual Studio and open it in Google Chrome
  • Click the speaker icon - Captcha audio will play correctly
  • Click the speaker icon again - the sound will fail to play
  • Deploy the same page to IIS and open it in Google Chrome
  • Click the speaker icon - Captcha audio will play correctly
  • Click the speaker icon again - Captcha audio will play correctly

Explanation

Since the Visual Studio built-in devleopment web server doesn't support setting Accept-Range Http response headers, Google Chrome can't replay the exact same Captcha audio on consecutive sound icon clicks without reloading the Captcha image in between clicks.

Workarounds

The issue only occurs when testing ASP.NET forms protected with BotDetect Captcha using Visual Studio. When the form is deployed to an actual web server (using IIS or any other server that supports ASP.NET), Captcha audio will function correctly.

Server-Side Compression Causes Problems With BotDetect CAPTCHA Sound

Issue ID

#4130851

Affected products

All versions of BotDetect ASP.NET Captcha

Affected servers

All versions of IIS

All versions of the .NET Framework

Affected clients

Internet Explorer 6.0, Firefox 2.x, 3.x

Status

3rd party issue – cannot fix

Description

If you have IIS dynamic content compression enabled on your servers for BotDetect Captcha paths, the Captcha sound will not play in IE 6.0, and will only play the first few characters of the Captcha code in Firefox.

Steps to reproduce

IE 6.0:

  • Open a page using the BotDetect ASP.NET Captcha in IE 6.0
  • Click the speaker icon – the Captcha sound will not be played
  • Right-click the speaker icon and select "Save target as..." – the sound file saved will contain the full Captcha code

Firefox:

  • Open a page using the BotDetect ASP.NET Captcha in Firefox 2.0 or 3.x
  • Click the speaker icon – only the starting characters of the code will be played (for example, the first 3 characters of a 5-character Captcha code)
  • Right-click the speaker icon and select "Open link in new tab" – the sound file will contain the full Captcha code

Explanation

This issue only occurs when you have IIS dynamic content compression enabled for .ashx paths on your servers.

Since downloading the file (by right-clicking the speaker icon and selecting "Save target as...") and playing it in Winamp works properly, there is probably a problem in communication between browsers and the sound player plug-ins they use. Maybe the compressed content length is passed to the player instead of the full (uncompressed) one, which could cause the sound file playback to break.

Workarounds

The issue can be resolved by disabling gzip compression for the Captcha sounds. The simplest way to do is by setting the IIS metabase property:

cscript c:\Inetpub\AdminScripts\adsutil.vbs SET 
  W3SVC/Filters/Compression/gzip/HcDoDynamicCompression "FALSE"
		
iisreset

Please note that this will disable compression for all content with types defined in the HcScriptFileExtensions property.

You can also continue compressing your .aspx pages and other dynamic content, but disable compression for BotDetect requests. Assuming the .ashx extension is not included in the HcScriptFileExtensions IIS metabase property for gzip compression, you can keep dynamic content compression turned on, and the CAPTCHA sounds will not be compressed, which should solve the problem.

Captcha Validation Fails / Captcha Audio Contains the Wrong Code for Visitors Using Samsung Galaxy Tab 3 when the Form Uses Old ASP.NET WebForms Validator Controls

Issue ID

#4130863

Affected products

All versions of BotDetect ASP.NET Captcha

Affected servers

All versions of IIS

.NET Framework 2.0 and newer

Affected clients

Samsung Galaxy Tab 3 default Android 4.2.2 browser

Status

3rd party issue – cannot fix

Description

If the ASP.NET WebForm protected with BotDetect Captcha validation uses old ASP.NET Validator controls, clicking the Captcha sound icon in the Samsung Galaxy Tab 3 default browser will always produce audio containing a different Captcha code than is shown in the Captcha image, and all Captcha validation attempts with the code shown in the image will fail.

Steps to reproduce

  • Open an ASP.NET form containing a validation control (such as a RequiredFieldValidator) and BotDetect Captcha in the default browser on Galaxy Tab 3
  • Try to submit the form using the Captcha code shown in the image - Captcha validation will fail
  • Click the sound icon - the pronounced Captcha code will differ than the one shown in the Captcha image
  • Update the form so it uses the newer, "unobtrusive" validation client-side code implemented in ASP.NET 4.5
  • Try to submit the form using the Captcha code shown in the image - Captcha validation will succeed
  • Click the sound icon - Captcha audio will work correctly

Explanation

The old ASP.NET WebForms validation client-side code (issue was reproduced using JavaScript include starting with var Page_ValidationVer = "125") was written before Android devices became common, and seems to cause multiple Captcha image requests on one form load.

We're not sure which part of the validation code makes the second Captcha image request (which doesn't update the image shown in the browser with the received Http response), but this causes the Captcha code stored on the server to change.

Consequentially, Captcha audio will contain the new code while the image still shows the old one, and Captcha validation attempts with the epxired Captcha code shown in the image will always fail.

Workarounds

Update your form to use ASP.NET 4.5 unobtrusive client-side validation based on jQuery, which works correctly on Android devices. You will need to add jQuery and set the following web.config setting:

<add key="ValidationSettings:UnobtrusiveValidationMode" value="WebForms" />

BotDetect Audio CAPTCHA Not Playing in IE When Using Global no-cache Headers and SSL

Issue ID

#4130861

Affected products

All versions of BotDetect ASP.NET Captcha

Affected servers

All versions of IIS

All versions of the .NET Framework

Affected clients

All versions of Internet Explorer

Status

3rd party issue – cannot fix

Description

If you configure your server to send no-cache headers with every Http response on a site that is accessed over SSL, BotDetect Captcha sound will not work for IE users.

Steps to reproduce

  • Modify the IIS settings for Http Headers, adding the following custom Http header for the whole site / virtual directory: Pragma: no-cache or Cache-Control: no-cache.
  • Open a page to which these settings apply and which is using BotDetect Captcha over Https
  • Click the speaker icon – the sound will not be played
  • Right-click the speaker icon and select "Save target as..." – when you try to download the .wav file it will fail with the following error: 'Internet Explorer cannot download BotDetectCaptcha.ashx from localhost. Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later.'

Explanation

This issue is caused by IE treating all no-cache headers as a strict prohibition the save files when using SSL. Since the .wav file with the Captcha sound can not be saved on the client, it can also not be played. BotDetect Captcha automatically detects SSL and avoids sending no-cache headers in such cases, but if you apply a server-wide or site-wide custom Http header by modifying IIS settings, you will override this logic and your users will experience this problem.

Workarounds

Change your IIS settings, excluding BotDetect Captcha paths from the custom Http header declaration.

BotDetect Captcha Validation Fails for Brazilian Visitors Using IE With Gbplugin (G-Buster Browser Defense)

Issue ID

#4130862

Affected products

BotDetect ASP.NET Captcha v1.0.1 - v3.0.7

Affected servers

All versions of IIS

All versions of the .NET Framework

Affected clients

All versions of Internet Explorer

Status

Fixed in v3.0.8

Description

When using IE with Gbplugin, validation of the Captcha code displayed in the Captcha image will always fail, while validation of the code spoken in the Captcha image will work correctly.

Steps to reproduce

  • Open a page using BotDetect ASP.NET Captcha in IE with Gbplugin
  • Retype the Captcha code from the image – Captcha validation will fail
  • Click the Captcha sound icon, and retype the spoken code – Captcha validation will succeed
  • Restart IE with Gbplugin disabled, and revisit the page
  • Retype the Captcha code from the image – Captcha validation will succeed

Explanation

Gbplugin makes a second Captcha image request which doesn't update the image displayed in the browser. The Http request workflow is simple:

  • The first Captcha image request (made by IE) comes to the server, and generates the first Captcha code.
  • A second Http request for the exact same Captcha image comes (made by Gbplugin), and changes the code stored on the server for that particular Captcha test instance to another value.
  • If the Captcha sound icon is clicked, the Captcha sound request uses the most up-to-date code stored on the server for the given ASP.NET Session.

Since the request made by Gbplugin doesn't update the image in the browser, IE is still displaying the first code generated. Consequentially, the Captcha code from the image is not the one stored on the server and can't be validated, while the code from the Captcha sound is up to date and validates correctly.

BotDetect always generates a new Captcha code for each incoming Captcha image request. This is a security requirement: to prevent automated analysis, each Captcha image is randomized within the given parameters and it's not possible to reuse Captcha codes. So these "invisible" requests made by Gbplugin are a problem.

Workarounds

BotDetect v3.0.8 implements a workaround for this issue, recognizing GbPlugin requests by user agent and avoiding new Captcha image generation.

For older versions of BotDetect: If there is a way to configure Gbplugin to either update the image displayed in the browser when it makes its request, or use a different Session cookie to avoid overwriting user data, it should take care of the problem. Otherwise, it will probably be necessary to disable Gbplugin to make the Captcha Http request workflow normal.

Cookieless ASP.NET Session State Causes Problems With Search Engine Indexing

Issue ID

#4130741

Affected products

All versions of BotDetect ASP.NET Captcha

Affected servers

All versions of IIS

.NET Framework 2.0 and newer

Affected clients

Googlebot, Yahoo! Slurp, msnbot, other crawlers

Status

3rd party issue – cannot fix

Description

If you allow cookieless ASP.NET Session state in your application (the <sessionState> element cookieless attribute set to "true" or "AutoDetect" in of your web.config file), your ASP.NET pages and some BotDetect Captcha paths might get indexed multiple times in various search engines, with different URLs.

Steps to reproduce

  • Check that the Google, Yahoo or Live index of your website contains at least one ASP.NET page (using the site: operator) – for example, test/default.aspx
  • Set the cookieless attribute to "true" or "AutoDetect" in your application's web.config file
  • Re-check the Google, Yahoo or Live index of your website periodically – as the crawlers visit your ASP.NET pages, they will add many different copies of the same page with different URLs – for example, test/(S(xihahl55btbse4qpvz45qj55))/default.aspx, test/(S(upoy35555j25grr4dacr1bz1))/default.aspx, test/(S(3aebky5512wexi45oylubwud))/default.aspx...

Explanation

ASP.NET cookieless Session State is meant to ensure your ASP.NET pages work properly even for users who have disabled cookies in their browser. As an alternative to the regular Session State storing the SessionID in a cookie, it rewrites the URLs of your pages to contain the SessionID instead. This is useful for your site's visitors but can influence the indexing of your ASP.NET pages in search engine indexes.

Since various crawlers (Googlebot, Yahoo! Slurp, msnbot, ...) all visit your site without any cookie support, the ASP.NET runtime rewrites your pages' URLs to contain the SessionID. And since the SessionID is highly dynamic and changes on every crawler visit, your pages will always have a different URL for the crawler, causing it to consider those URLs as new pages and index them separately. Over time, your site's index can accumulate a huge number of different entries for the same page. This in turn can cause the search engine to consider them duplicate content and move those pages to supplemental results, effectively removing them from user searches.

Workarounds

Add a <link href="..." rel="canonical" /> element in your page <head> to tell Google which Url to use for indexing. In the example above, you would use Default.aspx as the canonical link href. You should do this for every ASP.NET form on your site that you want to be indexed.

You can also try to prevent ASP.NET from using cookieless Session Urls for Googlebot, Yahoo! Slurp, msnbot and other search engine bots you choose. According to this article, just create an App_Browsers folder in your project's root folder and follow the instructions to create a genericmozilla5.browser file there. This should have the effect that the bots in question will always get the same Url, despite the fact they don't have cookie support.