4 ms·

Can you think of a case where it would be helpful to store XSS in the database until removed by clicking this button? What happens if we view the admin panel

Can you think of a case where it would be helpful to store XSS in the database until removed by clicking this button? What happens if we view the admin panel and trigger one of these malicious scripts, because I haven't clicked this button recently enough? Oh, maybe someone should click it very frequently! Or... Hmm, maybe rather than storing data that may be mass deleted by a script, with no review, after possibly compromising our security, we should just reject it in the first place and log a security incident for that user.

mgkimsal 9y ago
my view would be 'escape on output' is always better, regardless. there may be reasons I'd want to keep it in there - for analysis, to prove someone was trying to be malicious, or perhaps to demonstrate there's actually a real problem getting past some input mechanisms. However, the 'defender' in me can think of a situation where this would be good: Input filtering mechanisms have improved to deal with new attacks/problems, but old data is not 'new input', so you'd apply the updated algorithms to existing data.
- code_duck 9y ago
  I guess my thinking is that should be part of the upgrade or update process - whenever antiXSS rules are changed, they are applied at that time. It's having this button there as if it's something you'd run for periodic maintenance that seems insane. I'd definitely save input that breaks the rules when received, too - but maybe in a separate table.
koolba 9y ago
XSS is a malicious version of the more general problem of not escaping user inputs. its much easier to escape on output rather than input as you can't really tell what's "acceptable". It's also more robust as out of band updates (say direct database updates of comments) get outputted correctly too. If I have a comment forum with input filtering (rather than output escapong) I can't restrict it to just letters numbers and punctuation or the user's can't discuss HTML tags!
- code_duck 9y ago
  That makes sense. The objection I feel here is the inconsistency - why accept the input in the first place, only to delete it with this button? An above comment suggests rules may be updated over time, which could explain their thinking.
  - koolba 9y ago
    Because they don't properly escape things everywhere (anywhere?) and the DB update button is a kludge to deal with existing messed up data breaking pages they don't know about. It was probably less than an hours work to add that button vs. hundreds of hours to track down all the unescaped outputs.
dfox 9y ago
In many cases XSS and similar vulnerabilities (SQLi and even some buffer overflows) are also and primarily functional problem as some classes of valid input cause some kind of breakage. Correctly escaping on output solves both the security and functional problem, filtering on input usually aggravates the functional issue even more. On the other hand in context of CRMs, helpdesks and other things that have to process received emails and then show them in web interface this gets hairy because escaping on output while correctly handling variously weird or outright broken input is non-trivial. For example every helpdesk solution I've seen gets confused by some combination of nested MIME (ie. email with attachments forwarded with additional attachments) and notionally non-text email bodies (ie. bounces from Postfix). [Edit: and in this case storing whatever was on input without any transformations and sanitisations enables you to recover the content WHEN (not if) the breakage occurs, by either manually examining the input or, in the email case, importing it into desktop MUA. I even had once to do this with message that was unreadable in otherwise surprisingly well-behaving gmail's web interface]

mgkimsal 9y ago

my view would be 'escape on output' is always better, regardless. there may be reasons I'd want to keep it in there - for analysis, to prove someone was trying to be malicious, or perhaps to demonstrate there's actually a real problem getting past some input mechanisms. However, the 'defender' in me can think of a situation where this would be good: Input filtering mechanisms have improved to deal with new attacks/problems, but old data is not 'new input', so you'd apply the updated algorithms to existing data.

code_duck 9y ago
I guess my thinking is that should be part of the upgrade or update process - whenever antiXSS rules are changed, they are applied at that time. It's having this button there as if it's something you'd run for periodic maintenance that seems insane. I'd definitely save input that breaks the rules when received, too - but maybe in a separate table.

koolba 9y ago

XSS is a malicious version of the more general problem of not escaping user inputs. its much easier to escape on output rather than input as you can't really tell what's "acceptable". It's also more robust as out of band updates (say direct database updates of comments) get outputted correctly too. If I have a comment forum with input filtering (rather than output escapong) I can't restrict it to just letters numbers and punctuation or the user's can't discuss HTML tags!

code_duck 9y ago
That makes sense. The objection I feel here is the inconsistency - why accept the input in the first place, only to delete it with this button? An above comment suggests rules may be updated over time, which could explain their thinking.
- koolba 9y ago
  Because they don't properly escape things everywhere (anywhere?) and the DB update button is a kludge to deal with existing messed up data breaking pages they don't know about. It was probably less than an hours work to add that button vs. hundreds of hours to track down all the unescaped outputs.

dfox 9y ago

In many cases XSS and similar vulnerabilities (SQLi and even some buffer overflows) are also and primarily functional problem as some classes of valid input cause some kind of breakage. Correctly escaping on output solves both the security and functional problem, filtering on input usually aggravates the functional issue even more. On the other hand in context of CRMs, helpdesks and other things that have to process received emails and then show them in web interface this gets hairy because escaping on output while correctly handling variously weird or outright broken input is non-trivial. For example every helpdesk solution I've seen gets confused by some combination of nested MIME (ie. email with attachments forwarded with additional attachments) and notionally non-text email bodies (ie. bounces from Postfix). [Edit: and in this case storing whatever was on input without any transformations and sanitisations enables you to recover the content WHEN (not if) the breakage occurs, by either manually examining the input or, in the email case, importing it into desktop MUA. I even had once to do this with message that was unreadable in otherwise surprisingly well-behaving gmail's web interface]