BotDetect ASP.NET CAPTCHA Known Issues

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

Table of Contents

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.

[back to top]

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.

[back to top]

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 re-use 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.

[back to top]

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.

[back to top]


© Lanapsoft, Inc. 2004-2013. All rights reserved.

BotDetect, BotDetect CAPTCHA, Lanap, Lanap CAPTCHA, Lanap BotDetect, Lanap BotDetect CAPTCHA, Lanapsoft, Lanapsoft CAPTCHA, Lanapsoft BotDetect, Lanapsoft BotDetect CAPTCHA, and Lanap Software are trademarks of Lanapsoft, Inc. All other product, brand, and company names are mentioned for identification purposes only and are trademarks or registered trademarks of their respective owners.