BotDetect ASP CAPTCHA Known Issues
- [#4220862] Google Chrome clients and audio CAPTCHA
- [#4220861] SSL offloading and audio CAPTCHA in IE
Google Chrome clients and audio CAPTCHA
Issue ID
#4220862
Affected products
BotDetect ASP CAPTCHA v2.0.*
Affected clients
Google Chrome 0.2.149.27, 0.2.149.29
Status
3rd party issue - can not fix
Description
In beta versions of Google Chrome the audio CAPTCHA played by clicking the speaker icon always contains a different code than is displayed in the CAPTCHA image.
Steps to reproduce
- Open a page using the BotDetect ASP CAPTCHA in Google Chrome
- Click the speaker icon - the spoken code will be wrong
- Try to validate the CAPTCHA using the spoken code - validation will fail
- Try to validate the CAPTCHA using the displayed code - validation will succeed
- Right-click the speaker icon and select "Open link in new tab", then click the captcha.wav file - the spoken code will be correct
Explanation
The issue cause can be seen in the following IIS logfile sample (slightly edited for easier reading):
05:19:21 GET /LanapBotDetectHandler.asp Command=CreateImage Chrome 0.2.149.29 - 05:19:26 GET /LanapBotDetectHandler.asp Command=CreateImage&d=1221085161052 Chrome 0.2.149.29 +ASPSESSIONIDQAQCSDRR=IBCNCFFAPJBKGFDNLIBFIBLO 05:19:28 GET /LanapBotDetectHandler.asp Command=CreateSound&d=1221085163229 Windows-Media-Player/10.00.00.4051 ASPSESSIONIDQAQCSCQQ=KNGDHDFAGDIFBPCPMBDAPIGC; +ASPSESSIONIDSCRBSCQR=GELBCEFAJEMMHGEGHOICCBEN 05:19:28 GET /LanapBotDetectHandler.asp Command=CreateSound&d=1221085163229 IE 6.0 ASPSESSIONIDQAQCSCQQ=KNGDHDFAGDIFBPCPMBDAPIGC; +ASPSESSIONIDSCRBSCQR=GELBCEFAJEMMHGEGHOICCBEN; +ASPSESSIONIDQAQCSDRR=JBCNCFFAIMEHBAPPIPAEAEFH
Those are the log entries generated by the following sequence of operations:
- Load the page in Google Chrome, inlcuding the CAPTCHA image
- Click the Reload Button to generate a new image (so we can see the ASP Session cookie used for the Chrome session)
- Click the Speaker icon to get the CAPTCHA sound
As the logfile shows, Chrome forwards the sound CAPTCHA request to Windows Media Player, which for some reason makes the sound request with the wrong ASP Session cookie (or in other cases, with no cookie at all). This was the case in all 10 test runs we did, and if you take a look at your IIS log entries, you will probably find a similar pattern.
Since ASP Session state is dependent on the cookie value, and there is no way to change it (short of writing our own ASP Session replacement), and since we are not sure why does Windows Media Player make the request with an invalid cookie value, there is little we can do to resolve this issue.
Workarounds
Note that the ASP.NET version of BotDetect doesn't have this problem (as you can test on our online demo), since it includes a fix for a similar issue caused by Windows Media Player (details in the FAQ item). Unfortunately, we can not use the same workaround in the ASP version of our product - since the ASP.NET version fixes it by modifying the Session state not to be dependent on cookies, and ASP Session state doesn't provide any equivalent customization options.
One thing you can try is changing the sound CAPTCHA link in your form from:
<a href='LanapBotDetectHandler.asp?Command=CreateSound'
onclick='LBD_LoadSound("SampleForm_SoundPlaceholder",
"LanapBotDetectHandler.asp?Command=CreateSound");return false;'
title="Speak the code">
<img src="speaker.gif" alt="Speak the code"/>
</a>
to
<a href='LanapBotDetectHandler.asp?Command=CreateSound'
title="Speak the code">
<img src="speaker.gif" alt="Speak the code" />
</a>
This will disable the JavaScript automatic playback of the sound file and show the standard file download dialog; since in that case the sound file will first be downloaded by Chrome (using the correct cookie) and only then opened in Windows Media Player, the pronounced code should match the CAPTCHA image. This makes for a less "smooth" user experience, but if Chrome users are a significant portion of your site's users it might be worth the trade-off. Or if you really want to provide full functionality to users with newest browsers, you might consider porting the page you want to protect with a CAPTCHA to ASP.NET.
SSL offloading and audio CAPTCHA in IE
Issue ID
#4220861
Affected products
BotDetect ASP CAPTCHA v2.0.*
Affected clients
IE 6.0, IE 7.0
Status
Pending
Description
If you use SSL offloading, i.e. HTTPS requests to your site are decrypted by a special proxy and forwarded to your web server over plain HTTP , IE users will be unable to use the audio CAPTCHA.
Steps to reproduce
- Open a page using the BotDetect ASP CAPTCHA over HTTPS in Internet Exploree 6.0 or 7.0
- Click the speaker icon - no sound will be played
- Right-click the speaker icon and select "Open link in new tab" - an error will occur, saying IE is unable to download the file
Explanation
The problem is caused by IE file downloads not working if the server sends a file over SSL with the no-cache header. IE interprets the header as a strict prohibition to save the file locally, which means the sound file is not downloaded on the client. Since the sound file first needs to be downloaded to be played, this means the CAPTCHA sound is never played.
In other browsers we tested this against (Firefox, Opera, Safari), this header is interpreted differently, meaning the sound file can be downloaded (and played), but is not reused. IE also works properly when not using SSL. In other words, it's the no-cache + SSL + IE use case that is problematic.
When not using SSL, the no-cache header is required, otherwise there are use cases when changing the CAPTCHA image doesn't result in the equivalent change in the CAPTCHA sound, since the browser reuses the old sound file.
So the solution we used in the latest versions of BotDetect is to send the no-cache header only if SSL is not used. In other words, the code is similar to:
If (Request.ServerVariables("HTTPS")="off") Then
Response.CacheControl = "no-cache"
Response.AddHeader "Pragma", "no-cache"
Response.Expires = -1
End If
Since this code is obviously executed on the web server, this will only work if the request is sent to the web server over SSL. But if the SSL offloading means that SSL requests are made to a special network device, which then decrypts the traffic and sends plain HTTP requests to the web server, the web server will not know the current request is made over SSL.
In other words, Request.ServerVariables("HTTPS") will be set to "off" at the point of execution even though the original request was made over SSL. This in turn will result in the no-cache header being sent to IE clients, returning the original problem.
Workarounds
Our component needs to handle the broadest possible range of browsers and use cases, so the general solution is non-trivial - despite SSL offloading, the web server still needs to know the request was originally sent over SSL, and send the appropriate headers accordingly. This could be achieved by sending a special sound request querystring parameter, which is set in the sound playing JavaScript depending how the client sees the page (HTTPS or plain HTTP), for example. We will investigate this solution in future versions of BotDetect.
You can try looking up your SSL offloading settings, maybe there is an existing solution for cases when the server needs to know it's being accessed via SSL even if it's offloaded. If the ASP built-in Request.ServerVariables("HTTPS") property can be made to work properly, that would solve the problem.
Also, if you are only going to use the CAPTCHA on pages accessed over SSL, you don't have to handle the plain HTTP use case – which means you can remove the SSL-detecting logic from the code altogether and just assume SSL is always used. You can make this change in the LanapBotDetectHandler.asp file your page uses.
