Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taking over your code repositories with xss

blog.mu-cs.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Taking over your code repositories with xss

#11

Post by Xk »

mcorrientes wrote: post #10
Xk wrote: post #6

Earlier 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…

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.

> especially code hosting sites, should be a bit more concerned.

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?

Re: Taking over your code repositories with xss

#12

Post by nupark »

Xk wrote: post #9
nupark wrote: post #8

Earlier quoted context omitted.

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.

The fix IS that simple. Stop using non-sanitizing APIs. Your equated that with saying "stop making mistakes," which is what I objected to. The original poster was right: people need to simply stop using frameworks that do not sanitize their data by default.

Re: Taking over your code repositories with xss

#13

Post by Xk »

nupark wrote: post #12
Xk wrote: post #9

Earlier quoted context omitted.

> 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.

The fix IS that simple. Stop using non-sanitizing APIs. Your equated that with saying "stop making mistakes," which is what I objected to. The original poster was right: people need to simply stop using frameworks that do not sanitize their data by default.

All you've done now is shipped off the responsibility to the API. The API is not bug free, I guarantee you. There will still be XSS vulnerabilities, but they'll just live in the API now.

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.

Re: Taking over your code repositories with xss

#14

Post by 16s »

SoftwareMaven wrote: post #2

I 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…

It's been my experience that most programmers don't care. Apps work without input validation/output sanitation. They see this as extra work so it's not a priority to them. Unless mgt makes it a priority (and fires guys who don't do it) or they learn the hard way, they'll never care.

Re: Taking over your code repositories with xss

#15

Post by drdaeman »

kennu wrote: post #4
SoftwareMaven wrote: post #2

I 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.

Perl has awesome feature called "taint mode", where data derived from outside of the program may not be used to affect something else outside of the program. Every variable has a "taint flag", and it's a programmer's job to "launder" the data. Any attempt to use tainted data except for use in specifically permitted cases (like in print or syswrite calls) will result in a error. Concatenating tainted string with untainted one will result in a new tainted string.

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.

Re: Taking over your code repositories with xss

#16

Post by d1b »

mrspeaker wrote: post #5

I 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.

I spent about around 3 hours on github(found the bugs after like 2 hours and spent another 1 playing with wiki markup --- it is sanitized don't bother), 1 hour on bitbucket, 30minutes on gitorious(obviously the bug I found was found very quickly after signing up) and ~1 1/2 hour looking at the launchpad subdomain.

I did this over like the past 100 days.

Re: Taking over your code repositories with xss

#17

Post by d1b »

drdaeman wrote: post #15
kennu wrote: post #4

Earlier quoted context omitted.

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.

Perl has awesome feature called "taint mode", where data derived from outside of the program may not be used to affect something else outside of the program. Every variable has a "taint flag", and it's a programmer's job to "launder" the data. Any attempt to use tainted data except for use in specifically permitted cases (like in print or syswrite calls) will result in a error. Concatenating tainted string with untai…

this isn't going to fix anything that wouldn't be fixed via ensuring that stuff is escaped already on the page...

Re: Taking over your code repositories with xss

#18

Post by d1b »

mcorrientes wrote: post #10
Xk wrote: post #6

Earlier 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…

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.

I think in the github and launchpad case the security that a WAF normally offers would have been broken because the data to trigger the vector did not come through http nor https. I suggest you have a play around with github wiki's they already have 'html sanitization' built in.

Re: Taking over your code repositories with xss

#19

Post by nupark »

Xk wrote: post #13
nupark wrote: post #12

Earlier quoted context omitted.

The fix IS that simple. Stop using non-sanitizing APIs. Your equated that with saying "stop making mistakes," which is what I objected to. The original poster was right: people need to simply stop using frameworks that do not sanitize their data by default.

All you've done now is shipped off the responsibility to the API. The API is not bug free, I guarantee you. There will still be XSS vulnerabilities, but they'll just live in the API now. 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 a…

I honestly have no idea what you're talking about or advocating, if anything.

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.

Post reply on HN