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.token, objectTag))
349 didBlockScript |= filterObjectToken(request);
350 else if (hasName(request.token, paramTag))
351 didBlockScript |= filterParamToken(request);
352 else if (hasName(request.token, embedTag))
353 didBlockScript |= filterEmbedToken(request);
354 else if (hasName(request.token, appletTag))
355 didBlockScript |= filterAppletToken(request);
356 else if (hasName(request.token, iframeTag))
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]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_s21y59ourzr54wey5PE6YrXt8SP75Tj6D88HDnJqmwVRruBjq257hDqrnQPDjqD2gOMEjlBh4ZHVaTiFkH7Ik=s0-d)
No comments:
Post a Comment