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