On the 26. March this year, I gave a quiet special guest lecture. I was teaching students at the Bern University of Applied Sciences Engineering and Information Technology which are all studying the same as me (computer science) but they are nearly finished with their studies. This means I was once more the young and long-haired guy who came to talk about security or to be more specific web application security. Of course it was a special situation for me and I think also for the other students. Anyway, it was interesting to work with them and I think that my presentation and also the demos I made, helped them to understand the topic I was talking about: XSS.
Unfortunately it’s not that easy to upload the demos I made but I’d like to make my presentation available to the public because I think, that people can learn out of it and also if someone needs to give a lecture on XSS he/she can probably use some stuff out of my presentation.
Download the XSS presentation now
Hope you enjoy the presentation 
I am confused by your statement (from the presentation) that “[...] we don’t have any universal remedy against XSS”. This, to me, sounds like you’re saying that it’s not possible to design an application that is not vulnerable to XSS, which is, of course, not true. While there are some very tricky areas that are best avoided, taking care to properly transform all data prior to it being emitted into HTML responses should take care of XSS.
Hi Ivan,
of course this doesn’t mean, that it’s not possible to secure an application against XSS. It just means, that we can’t say that you have to use a specific filter or something else to become secure. For example you can use a WAF to secure your application but depending on how the application works and it’s architecture, the filter has to be different to the one we should use for another application. So there’s no “universal remedy against XSS”.
Unfortunately I have just the presentation and not everything I was saying during my lecture, else I think many things would be much more easy to understand
I think I understand what you are saying, I just disagree. I think that there is a remedy for XSS and it’s called proper programming. What is true, however, is that there is a severe lack of documentation explaining how to prevent XSS problems in applications. In fact, I’ve been looking for a single accurate document for days now.
Thanks for presentation!
@Ivan
I think both of you are trying to say the same thing, but in two different directions. I understand perfectly your stance. As a fellow programmer, I know it is my responsibility to do due diligence in making my applications as hard as possible to break. However, I think what Disenchant is getting at is that there is no “magic wand” that a non-programmer can wave to fix an already broken site. There is no one-size fits all solution that everyone could apply.
A big problem we have now are sites that are running applications that were written many years ago, often by a contractor or 3rd party. The people/person in charge of the application didnt design it, and many cases lacks the necessary skills to correct it. OR, in the case of .NET apps, dont have the original source code to make the corrections.
So while proper programming CAN prevent XSS attacks, that doesnt help the situation where the application is already built and in production. I think that is what Disenchant meant when he said that there is no “universal remedy against xss.”
Hi Ivan,
Sorry, but I find that difficult to believe. Between the complexity needed for some filters, various character encodings, and changing browser standards and implementations among other things, it would be incredibly difficult to build a non-trivial web application that is perfectly secure against XSS. In fact, given that browsers may behave differently in the future, it may be impossible to build such a web application.
@AC
I have to dissagree with you. I’m working now with the java mvc framework ‘wicket’ and I think that they designed this in a right way, because every output is html-encoded and leaves almost no choice for a programmer to do it not right.
I have tried to exploit things in this framework, but I couldn’t get any payload to work, so I think regarding to XSS this framework is secure.
And this leads to my assumption that it is possible to design secure web-apps.
and btw: really good presentation!
First of all, very nice presentation!
Which program have you used to design this presentation?
Hi qowaz,
nice to see, that you like the presentation
I’ve used the LaTeX Beamer Class for my presentation.
Nice primer on XSS. I think your statement about black lists is not too valid, where you say one should never use blacklists under any circumstances:
Even though perfect whitelists are inherently more effective, blacklists are very helpful to prevent known attacks. There are even very promising approaches to generic blacklists such as done by PHPIDS (http://php-ids.org/)
Hi Gabriel,
I think both of us like to say the same thing:
If there’s a possibility to use a whitelist instead of a blacklist, one should do this.
When we have a look at the PHPIDS project you mentioned, then we have to keep in mind, that it’s ready to be used within most web applications without rewriting all of it’s standard rules. Because of the developers don’t know in which applications the PHPIDS will be used, they can’t use whitelists even if they want to.
Well, generally speaking, I think one should do both, blacklist and whitelist filtering.
You mention the problem yourself: for good whitelist filtering you need to exactly know what the requirements of the application are. That may not always be obvious nor easy to find out, especially if it is a commercial application that you want to protect nonetheless.
However, if you’re the developer of the application – and that’s maybe your point – you’d rather resort to whitelist filtering and should never rely upon blacklist filtering alone. I totally agree.