[webkit-reviews] review denied: [Bug 24533] Add a test to ensure that obfuscated javascript: URLs don't allow XSS : [Attachment 28508] New test + result

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 12 00:38:20 PDT 2009

Alexey Proskuryakov <ap at webkit.org> has denied Pam Greene <pam at chromium.org>'s
request for review:
Bug 24533: Add a test to ensure that obfuscated javascript: URLs don't allow

Attachment 28508: New test + result

------- Additional Comments from Alexey Proskuryakov <ap at webkit.org>
I don't think that this test needs to use js-test resources at all - it already
prints FAIL on mistake, which is sufficient for both automated tests and manual
inspection. Comparing "PASS" to "PASS" just to print "PASS" seems less than

+	 Also add appendTestDialogue() to js-test-pre.js for use by this and
+	 other tests that need to wait until completion.

A typo, it's appendTestEpilogue. But I do not think that this is the right
approach - the whole point of checking successfullyParsed is that it is
performed from a separate script, so a failure to execute the test script
doesn't affect it. But within the test script, it just won't be checked in
failure case (which is when we want it to be checked).

This test doesn't do what it attempts to do, for two reasons. First, due to bug
8961, document.write("FAIL") doesn't write "FAIL" into the target, it only
clears it. Second, the test performs frame navigation, which happens from a
timer - so checking frame content synchronously doesn't work. Indeed, if it
worked, then the last test (which uses a plain javascript: URL) would have

It's confusing that the ChangeLog talks about XSS, but the frame being scripted
is not from a different domain (especially after the first programmatic
navigation). So, I'm not sure what the potential bug is - is it about bypassing
packet filters, or bypassing engine security checks?

More information about the webkit-reviews mailing list