Taking over your code repositories with xss
blog.mu-cs.com
blog.mu-cs.com
1. Sanitize everything you can on the way in.
2. Anything that can't be sanitized on the way in must be marked as unsafe and sanitized on the way out.
Nothing* should ever, ever, ever go directly from one end-user's machine to another (even the same user). Ever.
* Binaries might be an exception, but even then possibly not (e.g. virus checking).
Giving that advise is really, really easy. Every competent web developer knows that. The hard part is actually implementing it.
For example, lots of programs written today still have buffer overflow vulnerabilities. Those are even older. The fix is also very simple: "Check the bounds of your arrays before you use them". That is, again, just telling the developer to not make mistakes.
Designing security into your app can help with preventing XSS attacks, but there is no single perfect way.
Actually, the fix isn't to stop making mistakes. The fix is to stop using APIs and/or runtimes that make it easy to make mistakes. Design your APIs such that buffer overflows aren't possible.
The same thing applies to web development and escaping of output data. In a proper API, it should literally not be possible to accidentally write unescaped data to the page.
I know that. I wrote "The fix is also very simple: "Check the bounds of your arrays before you use them"" in order to demonstrate that saying "Sanitize your input" is equally wrong.
Imagine you decide to fix buffer overflows by switching from C to Java. You're no longer relying on the fact that your code won't have buffer overflows, you're relying on the fact that (1) the JVM code doesn't have buffer overflows and (2) the JVM will catch all your buffer overflows and throw exceptions.
I feel very confident Java has few, if any, bugs. I do not, however, hold that same level of confidence with most APIs in use today. They simply haven't had the time to become as robust.
However, even then, this does not solve all of your issues. There are times when you need to insert tags dynamically, and once you start doing that, there are a million more ways things can go wrong. Sure, you can put another restrictive API in front of that which requires the programmer to take ten lines to describe the single tag she wants, but those APIs will rarely get used because of this.
At the end, for any class of vulnerabilities, there is always a way to entirely eliminate it. Rarely is it the case, however, that you can do so without dramatic losses in other areas.
If you switch to the JVM, a buffer overflow triggers determinate behavior -- it throws an exception rather than writing over the saved return address or the heap.
The attack surface is by it's nature is much smaller than if you rely on programmer correctness in C.
As for inserting tags "dynamically," this sounds like a broken templating system if that means exposing the programmer to fail-fast (instead of fail-safe) escaping APIs.
Using a WAF and white listing parameters, may be a good start too.
Just another reason why I keep the code internal.
Not really. There are many examples of sites which should be more concerned. Anything with your credit card information, say.
> Using a WAF and white listing parameters
Yeah, that's a good start. But you need to make sure everything goes through the white list, and that's the hard part.
> Just another reason why I keep the code internal.
What does this have to do with security?
I guess GitHub is using Rails 2, which doesn't escape output by default.
Django has similar, albeit somehow weaker concept with SafeString. Unfortunately, I'm not familiar with Ruby/Rails.
However, consider outputting data as JSON for some fancy AJAX client-side stuff. While I doubt someone will forget to properly escape JSON, forgetting to escape strings as HTML is fairly easy, and no taint checks would prevent you from doing this.
We really need to pull back on the super-cool-awesome new feature bloat of HTML5 and get back to basics: sort this out in a meaningful way.
I did this over like the past 100 days.