Hackers2DevNull

Hackers2DevNull

Monday 16 September 2013

Weaknesses in google Chrome XSSAuditor - a bypass found!







The Chrome XSSAuditor is open source- I noticed that the auditor is weaker in certain branches of markup than others such as in the <head>. Filtering by element is handled in a slightly different manner depending on where the injection appears within the major sections of markup, as in this case. Extract:



ASSERT(request.shouldAllowCDATA || !m_scriptTagNestingLevel);    346 ASSERT(request.shouldAllowCDATA || !m_scriptTagNestingLevel);
    
347 m_scriptTagNestingLevel++;
    
348 } else if (hasName(request.tokenobjectTag))
    
349 didBlockScript |= filterObjectToken(request);
    
350 else if (hasName(request.tokenparamTag))
    
351 didBlockScript |= filterParamToken(request);
    
352 else if (hasName(request.tokenembedTag))
    
353 didBlockScript |= filterEmbedToken(request);
    
354 else if (hasName(request.tokenappletTag))
    
355 didBlockScript |= filterAppletToken(request);
    
356 else if (hasName(request.tokeniframeTag))
    
357 didBlockScript |= filterIframeToken(request
); 

I found two tags which XSSAuditor can be bypassed if we can close the <body> tag with our injection,

Before I got a reply from Chrome team, I found that there was a deeper flaw in the timing of these checks - if malformed markup is auto-corrected or mutated by the browser within the <head> then the check is done too late before resolving in the doc.

[Image: B2d9b1a.png]


No comments:

Post a Comment