[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]

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
XSS
https://bugs.webkit.org/show_bug.cgi?id=24533

Attachment 28508: New test + result
https://bugs.webkit.org/attachment.cgi?id=28508&action=review

------- 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
useful.

+	 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
failed.

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?