Oops, sorry. I was trying too hard not to create a duplicate, and am surprised it isn't already on launchpad, having seen the Sourceforge report you mention. Should I resubmit as a new bug/request?
I'm using 2.1.12 and still seeing the error - I gather the fix was to add a lookahead exclusion based on the current options template. Having seen quite a few recent injected HTML attacks on the lines of Gumblar, I wonder if it would be adequate to block on the basis only of meta refresh, iframe, script src= and certain JS keywords like unescape and str_replace; on the other hand, the badwords list is probably not that comprehensive: it doesn't exclude possible XSS routes like embed, object or the obscure table background=javascript:....
IMHO a "trusted list admin" option would cover most needs most easily - giving SSH access to an (untrusted?) user might create greater security problems.
I shared the list administrator's misunderstanding of the FAQ reference because of context.
Oops, sorry. I was trying too hard not to create a duplicate, and am surprised it isn't already on launchpad, having seen the Sourceforge report you mention. Should I resubmit as a new bug/request?
I'm using 2.1.12 and still seeing the error - I gather the fix was to add a lookahead exclusion based on the current options template. Having seen quite a few recent injected HTML attacks on the lines of Gumblar, I wonder if it would be adequate to block on the basis only of meta refresh, iframe, script src= and certain JS keywords like unescape and str_replace; on the other hand, the badwords list is probably not that comprehensive: it doesn't exclude possible XSS routes like embed, object or the obscure table background= javascript: ....
IMHO a "trusted list admin" option would cover most needs most easily - giving SSH access to an (untrusted?) user might create greater security problems.
I shared the list administrator's misunderstanding of the FAQ reference because of context.