After some effort tuning performance, I've turned our reflective cross-site scripting (XSS) filter back on. Please be on the lookout for compatibility issues. The filter has been on by default in the WebKit nightly builds for about a month, so hopefully we've flushed out most of the false positives already.
Q: How do I recognize a compatibility issue with the filter? A: If a web site is acting strangely and you suspect the filter, take a look at the JavaScript console. If you see a message that says something about blocking an unsafe script, then please let me know. If you want to double check, you can run with --disable-xss-auditor and re-test the site. Q: Your filter is the suckz! I found a way to get XSS through. A: Great! Please file a bug at https://bugs.webkit.org/enter_bug.cgi?product=WebKit and CC me. Currently, we're targeting the simplest case of an unfiltered echo in between tags, so exploits that work in that scenario are most appreciated. Q: Nothing happens when we block XSS. Shouldn't we have a pony come out and do a happy dance? A: We haven't decided on a UX for the filter yet. We need to have a meeting of the minds between the security folks on the UI folks. Our current plan is to see get a feel for the false positive rate first. Q: This filter is pretty rad. How does it work? A: Basically, the filter checks each script before it executes to see whether the script appears in the request that generated the page. If it finds a match, it blocks the script from executing. We're planning to write up an academic paper that has all the details. Adam --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
