Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Captcha jacking is an attack to bypass a captcha by coercing a human into solving the challenge response. Prof of concept code that uses a proxy can be found here.
Is there a good method of preventing this type of attack? How can an application prevent bruteforce attacks or automated account creation in light of captcha jacking attacks?
A CAPTCHA is meant to ascertain that, at some point in a computerized procedure, a human being was involved. In the case of "CAPTCHA-jacking", well... that's entirely true ! The CAPTCHA works. What this shows is that the security characteristic provided by the CAPTCHA is not exactly the fabled "One Filter to kick them all".
So I would say that the "good way" to prevent CAPTCHA-jacking attacks is to accept that a CAPTCHA is just a partial heuristic filter which will find its place among with other heuristic filters, like the number of requests for a given resource, indexed per IP address, time,...
Still, we can include some countermeasures for some specific scenarios. For instance, suppose that the attacker redirects the CAPTCHA challenges (from site siteA.com) to another site (siteB.com), so that the humans who solve them actually believe that they are requested the CAPTCHA in order to enter siteB.com. The maintainer of siteA.com may include the string "this is for siteA.com" as part of the picture, e.g. as some grey text in the background (with some random placement). The idea being here that if the CAPTCHA-solving humans are involuntary accomplices, then making them aware of the possible foul play may trigger faster reaction and retaliation against the attacker.
The concept is to farm out the hard-for-computer, but easy-for-humans problem to other humans in return for something they want. However, the action to the target being attacked is still a single source. You would do best to apply filters and heuristics beyond the CAPTCHA as well. Too many requests from the same IP, increased rate of some activity, etc. Also, a bot is usally programmed for a certain HTML layout, variables, etc. If you change up your code you may be able to defeat bots which are not under active update by their author. I am not sure you can do anything about the CAPTCHA itself being farmed out.
You can only lock the malware server out of the loop if you use a secure channel like HTTPS. However, browser implementations and SSL validation companies focus mostly on proving that the server endpoint is trustworthy, not whether the client endpoint is trustworthy (or a human). Without client authentication, there is no effective difference between computer rerouting human proof-of-work and an indifferent human spammer using a computer to post the selfsame message.
You would need the equivalent of VeriSign/GeoTrust client certification service but free, pseudonymous and only caring that you are a human. At this stage, I haven't heard on any service like that. A web-of-trust certification chain might be another approach; but no robust, populous or frankly trustworthy web has been established yet.
A micro-payment escrow could also work but raising the deterrent high enough to counteract the value proposition of spam, would lockout or discourage many users regardless of the escrow feature - for how many of us trust server admins and site moderators enough to escrow spam fines?
Best answer at this point is either don't worry about CAPTCHA hijacking or routinely fiddle with the AJAX/HTML post interface in a fashion that requires the spammer's human intervention to re-code.
Essentially your human adjustment of site API vs. spammer's incentive to adjust their API for your site. You might want to lower these incentives through spam filtering, etc.
