how does recaptcha get around XSS protection?

[dino d.]

hi - i'm building widget, and i'd like the user to be able to request
a new widget by clicking an ajax link in the widget itself. it
doesn't work, and i presume it's because of the built in xss
protection in browsers (to prove this to myself, i placed an html file
that contains the widget in the public directory of the widget server,
and this works fine).

however, recaptcha has managed to work around this, you add some
javascript to your page, and that javascript writes a captcha widget
into your form. in that widget, there is a 'request a new challenge'
link which works fine. it does exactly what i'm trying to do. - it
goes to the recaptcha server, renders a new widget, and replaces the
div of the widget, even though the page and the widget are from
different domains.

now, going through the code, they're doing something weird- the actual
code that you put in your web page looks like this:

var RecaptchaState = {
... //several variables
programming_error : '',
is_incorrect : false
};

document.write('<scr'+'ipt type="text/javascript" s'+'rc="' +
RecaptchaState.server + 'js/recaptcha.js"></scr'+'ipt>');
(function() {
var _recaptcha = document.createElement('script');
_recaptcha.type = 'text/javascript';
_recaptcha.async = true;
_recaptcha.src = (document.location.protocol == 'https:' ?
'https' : 'http') + '://www.google.com/recaptcha/api/challenge?
k=asdfasdfasdf (your key) &darklaunch=1'; //i've removed my key here
(document.getElementsByTagName('head')[0] ||
document.getElementsByTagName('body')[0]).appendChild(_recaptcha);

})();

somehow, this is tricking the browser into thinking that the widget is
the same source as the web site that is embedding it?

before i dig any deeper, does anyone know how to get around XSS
security precautions the way recaptcha does?

thanks,
dino

 

[Thomas 'PointedEars' Lahn]

[...]
var RecaptchaState = {
... //several variables
programming_error : '',
is_incorrect : false
};

document.write('<scr'+'ipt type="text/javascript" s'+'rc="' +
RecaptchaState.server + 'js/recaptcha.js"></scr'+'ipt>');
(function() {
var _recaptcha = document.createElement('script');
_recaptcha.type = 'text/javascript';
_recaptcha.async = true;
_recaptcha.src = (document.location.protocol == 'https:' ?
'https' : 'http') + '://www.google.com/recaptcha/api/challenge?
k=asdfasdfasdf (your key) &darklaunch=1'; //i've removed my key here
(document.getElementsByTagName('head')[0] ||
document.getElementsByTagName('body')[0]).appendChild(_recaptcha);

})();

somehow, this is tricking the browser into thinking that the widget is
the same source as the web site that is embedding it?

before i dig any deeper, does anyone know how to get around XSS
security precautions the way recaptcha does?

There is no trick to it, and barring `Recaptcha.server' being generated by
another resource, XSS has nothing to do with it. Any script resource can
be referred to from any document (which is what powers Google Analytics,
Google Maps, aso.).

If you look more closely, you will observe that this script simply causes a
SCRIPT element to be inserted (in an expectedly stupid way, though, it is
the `</' that would need to be escaped, not the `<script>' or the
`</script>').


PointedEars

 

[dino d.]

Any script resource can

be referred to from any document (which is what powers Google Analytics,
Google Maps, aso.).

If you look more closely, you will observe that this script simply causesa
SCRIPT element to be inserted (in an expectedly stupid way, though, it is
the `</' that would need to be escaped, not the `<script>' or the
`</script>').

thanks for the reply. i don't quite understand. are you saying that
if i make my script insert another script that contains a function
that makes an ajax call and updates a div's contents, that should
work? but if my script simply inserts a link that, when clicked,
creates a fresh object (like an AjaxUpdater) that is forbidden? in
other words, it's the timing of the updating object's creation that is
taken into consideration when forbidding access?

thanks again,
dino

 

[Thomas 'PointedEars' Lahn]

[Thomas 'PointedEars' Lahn wrote:]

Any script resource can be referred to from any document (which is what
powers Google Analytics, Google Maps, aso.).

If you look more closely, you will observe that this script simply
causes a SCRIPT element to be inserted [...]

thanks for the reply. i don't quite understand. are you saying that
if i make my script insert another script that contains a function
that makes an ajax call and updates a div's contents, that should
work?

Yes, in a manner of speaking. (There is no such thing as an "ajax call".)

but if my script simply inserts a link that, when clicked,
creates a fresh object (like an AjaxUpdater) that is forbidden?

No; I did not say that.

in other words, it's the timing of the updating object's creation
that is taken into consideration when forbidding access?

No, it is the context in which the object is created that matters.
Search for "Same Origin Policy".


Please keep the attribution lines, use the Shift key of your keyboard as
orthographically correct for the language you are using, and do not quote
signatures.

<http://jibbering.com/faq/#posting>


PointedEars

 

[dhtml]

[Thomas 'PointedEars' Lahn wrote:]

Any script resource can be referred to from any document (which is what
powers Google Analytics, Google Maps, aso.).
If you look more closely, you will observe that this script simply
causes a SCRIPT element to be inserted [...]

thanks for the reply.  i don't quite understand.  are you saying that
if i make my script insert another script that contains a function
that makes an ajax call and updates a div's contents, that should
work?

Yes, in a manner of speaking.  (There is no such thing as an "ajax call".)

but if my script simply inserts a link that, when clicked,
creates a fresh object (like an AjaxUpdater) that is forbidden?

No; I did not say that.

in other words, it's the timing of the updating object's creation
that is taken into consideration when forbidding access?

No, it is the context in which the object is created that matters.
Search for "Same Origin Policy".

Please keep the attribution lines, use the Shift key of your keyboard as
orthographically correct for the language you are using, and do not quote
signatures.

<http://jibbering.com/faq/#posting>

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

 

[dhtml]

Whoops looks like I submitted the wrong message (empty) not the reply
I typed. Againn....

That was right advice and is included in the code guidelines doc that
I will update soon with new comments from kangax.

Problems with ReCaptcha:
* Tends to break kbd a11y by messing up tab index order. This is a
real problem with laptop users who are stuck with a trackpad.
* hard for humans to read. ReCaptcha creates usability problems with
hard-to-read, obscure words.
* requires javascript, provides no fallback. This violates WCAG and
Section 508.

 

[dino d.]

I found the answer to my question- You cannot do an ajax call this
way - You can accomplish updating a widget by adding a javascript
element to the DOM, whose src is your widget server, which then can
modify your widget. You can see a good writeup here:

http://www.ibm.com/developerworks/library/x-ajaxsecurity.html

Dino