From: dino d. on 15 Feb 2010 16:37 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
From: Thomas 'PointedEars' Lahn on 15 Feb 2010 18:39 dino d. wrote: > [...] > 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 -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: dino d. on 15 Feb 2010 19:53 > 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>'). > 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 > PointedEars > -- > Danny Goodman's books are out of date and teach practices that are > positively harmful for cross-browser scripting. > -- Richard Cornford, cljs, <cife6q$253$1$8300d...(a)news.demon.co.uk> (2004)
From: Thomas 'PointedEars' Lahn on 15 Feb 2010 20:05 dino d. wrote: > [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
From: dhtml on 16 Feb 2010 21:51 On Feb 15, 5:05 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > dino d. wrote: > > [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
|
Next
|
Last
Pages: 1 2 Prev: image size onload in IE Next: How to create / map short-cut to some presentation features? |