I replaced the _ with a zero-width joiner (‍ it still breaks the search (I think) but visually it looks right and should have the same effect.

Why hasn't there been a more robust fix for this? And can we assume that this forum has the protection off, or is there some security/usability fix it's running that hasn't been mentioned?

A good solution should take into account that words (like link, layer, etc) are bad only, if there is no white space, punctuation or special characters (like ampersand, asterisk, apostrophes, ellipses, etc) on the left or the right of the word.
I could live with a ­ around bad words that are not part of a bigger word (like link in blink).

BTW: Those with the shy solution: Are you absolutely sure, that these shy character are not simply ignored by the javascript interpreter?

birdie60

Many Thanks for this fix - sorted! I'll watch this thread with interest

danialt,

I removed potentially valid words that can be entered by users, such as "base", "blink", "link", "object", "style", "frame", "layer", "title".

Is this going to open my Fireboard to XSS attacks? This seems like a conundrum. How do we allow users to enter valid English words and still prevent XSS attacks?

I can live with the work around - humans are pretty good at working out what's meant to be there.

My problem is that I've put in some "url" strings and they are being changed and therefore broken.

By the way - it's worth point out that the underscores are not stored in the database so when "we" find a fix to this all will be well....

well, had the same problem with a fresh install..
now (as a non expert in security stuff and programming), im not sure what to do:
remove the scripts 1st line?.. do nothing?

it would be wonderful if someone could post any solution, which enables users to actually write words (like: multip_layer_ , for example..) without underscores..
please
cheers
ka
www.ninc.at
www.nnw.at

There were a couple of solutions posted in this thread. Did you try any of them?

no, because there was no destinct answer, if those solutions are dangerous (because of those xss attacks) or not..
nice greetings!
ka
www.ninc.at

Yes they are dangerous. You put your site at risk because you are in effect circumventing (overly aggressive) security measures. Until this bug is worked out in future releases there has only been these workarounds presented.

The work arounds (for what is in effect a work around itself) work fine thanks.