4 ms·

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

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 machine to another (even the same user). Ever. * Binaries might be an exception, but even then possibly not (e.g. virus checking).

schrototo 16y ago
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...
kennu 16y ago
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.
- drdaeman 16y ago
  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.
  - d1b 16y ago
    this isn't going to fix anything that wouldn't be fixed via ensuring that stuff is escaped already on the page...
Xk 16y ago
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.
- mcorrientes 16y ago
  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.
  - Xk 16y ago
    > 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?
  - d1b 16y ago
    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.
- nupark 16y ago
  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.
deleted 16y ago
[deleted]
16s 16y ago
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.

schrototo 16y ago

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

kennu 16y ago

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.

drdaeman 16y ago
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.
- d1b 16y ago
  this isn't going to fix anything that wouldn't be fixed via ensuring that stuff is escaped already on the page...

Xk 16y ago

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.

mcorrientes 16y ago
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.
- Xk 16y ago
  > 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?
- d1b 16y ago
  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.
nupark 16y ago
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.

deleted 16y ago

[deleted]

16s 16y ago

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.