Certain user management actions are vulnerable to XSS

Fixed in -r964:

• cleanse paramter value before comparing with the keywords
• include 'javascript' as xss keyword
• added tests

Re-opening issue

hi i proposed to modify the interceptor to check for a pattern using regular expressions cause currently it only checks for the presence of the <script> tag it should also cover the standard HTML events will upload my patch with-in 24hr

I think the interceptor is the wrong approach. It could easily miss something, or incorrectly trap something (e.g. a user called MrJavaScript)

Though it's burdensome, it'd be good to revise the validation for all the actions that take input that gets displayed on the page (either as an error response or as a result of being successfully stored). This can prevent the problem and tighten the error handling overall.

point taken brett revising the validation would be a better way thanks.
properly displaying the EL with <c:out /> would also help.

thanks i hope i could upload my patch soon.

will be using the regex pattern [a-zA-Z_0-9\\s.,!?]* to check for validating user input

that won't be appropriate for every field - it probably needs to be more specific. There are probably built-in validators for the typical "letters and numbers" ones.

Committed the following changes in -r980:

• applied changes in displaying user data using <c:out> and validation checks for username, fullname and rolename provided by Mark John Kennedy Magallanes (tweaked the validation fix a bit)
• escape values of query string in useredit, userlist and roleedit actions that are affected by xss
• added selenium tests for the validation checks and the xss affected actions

Merged to trunk in -r981.

Additional changes made in 1.2.x branch -r1002:

• removed validation for user full name so we won't have problems with i18n, xss scripts dont get executed anyway since they are escaped when rendered
• updated selenium tests

Additional changes merged to trunk -r1003.