@ Tim :

Javascript Sandbox functionality -
1) HTTPOnly. Which has a broken implementation and design
2) Content-restrictions. I already mentioned these, which are improvements to HTTPOnly. Browser developers need to put this stuff in the browser so that web application developers can start using it

Signing JavaScript code is by far one of the best options we have. I mention this very often. I think it does have a place in NTPolicy, but in all seriousness, I think it’s the least likely for any organization to implement. I would say in 100% of cases, it will be the last thing to implement, thus a waste of time in comparison to everything else. I guess maybe the same can be said of content-restrictions, but I try to be optimistic since it is so badly needed.

thanks for the info. We follow noscript development very closely.

Roland,

yes, full-text feeds are disabled for now. We are experimenting with a few things at the moment. We are going to keep the situation as such till the end of the month. Then, we are going to decide which way to go.

1. Unconditional XSS filters on every request (GET/POST/…) originated by untrusted origins (i.e. non whitelisted sites or external applications, e.g. email client) landing on whitelisted pages – http://noscript.net/features#xss
2. “Light” script injection detection on every GET request (even from trusted sites), triggering the aforementioned XSS filters on suspicious URL patterns
3. Java, Flash and other plugin content blocking – http://noscript.net/features#contentblocking

Other relevant Anti-XSS and Anti-CSRF features in the works are:

1. A better implementation of the LocalRodeo concepts (made easy by the request interception framework already used by Anti-XSS filters)
2. A facility to flag some IFrames as “scriptless” and “XSS checked”, usable either by the web developer or by the user (sort of “” preview leveraging currently available browser technology)
3. A “Mashup manager” to declare web application trust boundaries (i.e. whitelists of sites that are allowed to perform cross-site requests in a certain “mashup”), definable either by the web developer dropping a “mashup.txt” file on the web-app root directory or on the client side via UI. This will overcome the inherent unreliability of REFERER header checks.
4. Finer grained per site permissions/restrictions

Many thanks!

Jeremiah said, “Restrict websites with public IP’s from including content from websites with non-routable IP address” as seen here: http://jeremiahgrossman.blogsp.....-over.html

and he also said it slightly differently here: http://jeremiahgrossman.blogsp.....urity.html

As much as I dislike making changes (which usually means adding features instead of fixing bugs) to protocols and languages – there are two things going in the short term future would could affect XSS and similar attacks in the future.

1) ECMAScript 4 progress
2) httpbis BOF at the IETF-69

What would we want to design into these to make them safer and provide security with a higher level of assurance?

Otherwise, I enjoyed how you summarized (edited?) my suggestions. Here’s one point I wanted to elaborate further on:

Security testing is optional. I said that Web Application Security Scanners and WAF’s are optional. Testing should be done by the developers, as I described. If you are a developer and feel that you are missing tools that will help you eliminate XSS in your code completely – let me know and I’ll find something to help you or make the process almost completely automatic. Or we’ll take it up as a project and make it happen. Even for ColdFusion.

If we rely on pen-testers and vulnerability hunters to find XSS, and do nothing else, then we’ll continue to be in the same situation we are right now. Elimination of CSRF is step two, but near-pointless if we don’t have a global strategy to defend against XSS worms.