Taking over your code repositories with xss
blog.mu-cs.com
Taking over your code repositories with xss
1–10 of 19 posts
Re: Taking over your code repositories with xss
#2I don't understand why sites are still subject to bugs like these. After 15 years of poor-escaping bugs and the security problems inherit in them, why is it so hard to understand the two critical rules:
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).
Re: Taking over your code repositories with xss
#3I don't understand why sites are still subject to bugs like these. After 15 years of poor-escaping bugs and the security problems inherit in them, why is it so hard to understand the two critical rules: 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 m…
Because once one generation of programmers has figured it out, the next one is already hard at work making the same mistakes all over again...
Re: Taking over your code repositories with xss
#4I don't understand why sites are still subject to bugs like these. After 15 years of poor-escaping bugs and the security problems inherit in them, why is it so hard to understand the two critical rules: 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 m…
Frameworks like Django and Ruby on Rails 3 do a good job of HTML-escaping everything that goes out. It's better to escape _everything_ by default and let the programmer explicitly say if something should not be escaped.
I guess GitHub is using Rails 2, which doesn't escape output by default.
Re: Taking over your code repositories with xss
#5I don't know if that guy spent months and months searching for those vectors - but casually lumping XSS attacks in all the big source control sites is a frightning thing to see.
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.
Re: Taking over your code repositories with xss
#6I don't understand why sites are still subject to bugs like these. After 15 years of poor-escaping bugs and the security problems inherit in them, why is it so hard to understand the two critical rules: 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 m…
Those two pieces of advice really are like telling programmers "just don't make mistakes".
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.
Re: Taking over your code repositories with xss
#7I don't understand why sites are still subject to bugs like these. After 15 years of poor-escaping bugs and the security problems inherit in them, why is it so hard to understand the two critical rules: 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 m…
[deleted]
Re: Taking over your code repositories with xss
#8I don't understand why sites are still subject to bugs like these. After 15 years of poor-escaping bugs and the security problems inherit in them, why is it so hard to understand the two critical rules: 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 m…
Those two pieces of advice really are like telling programmers "just don't make mistakes". 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…
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.
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.
Re: Taking over your code repositories with xss
#9Earlier quoted context omitted.
Those two pieces of advice really are like telling programmers "just don't make mistakes". 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…
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. 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 buf…
> Actually, the fix isn't to stop making mistakes.
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.
Re: Taking over your code repositories with xss
#10I don't understand why sites are still subject to bugs like these. After 15 years of poor-escaping bugs and the security problems inherit in them, why is it so hard to understand the two critical rules: 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 m…
Those two pieces of advice really are like telling programmers "just don't make mistakes". 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…
that's true but especially code hosting sites, should be a bit more concerned.
Using a WAF and white listing parameters, may be a good start too.
Just another reason why I keep the code internal.