Redback
  1. Redback
  2. REDBACK-276

Certain user management actions are vulnerable to XSS

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.7
    • Fix Version/s: 1.2.8
    • Component/s: web integration
    • Labels:
      None
    • Number of attachments :
      0

      Activity

      Hide
      Maria Odea Ching added a comment -

      Fixed in -r964:

      • cleanse paramter value before comparing with the keywords
      • include 'javascript' as xss keyword
      • added tests
      Show
      Maria Odea Ching added a comment - Fixed in -r964 : cleanse paramter value before comparing with the keywords include 'javascript' as xss keyword added tests
      Hide
      Maria Odea Ching added a comment -

      Re-opening issue

      Show
      Maria Odea Ching added a comment - Re-opening issue
      Hide
      mark john magallanes added a comment -

      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

      Show
      mark john magallanes added a comment - 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
      Hide
      Brett Porter added a comment -

      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.

      Show
      Brett Porter added a comment - 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.
      Hide
      mark john magallanes added a comment - - edited

      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.

      Show
      mark john magallanes added a comment - - edited 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.
      Hide
      mark john magallanes added a comment -

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

      Show
      mark john magallanes added a comment - will be using the regex pattern [a-zA-Z_0-9\\s.,!?] * to check for validating user input
      Hide
      Brett Porter added a comment -

      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.

      Show
      Brett Porter added a comment - 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.
      Hide
      Maria Odea Ching added a comment -

      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
      Show
      Maria Odea Ching added a comment - 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
      Hide
      Maria Odea Ching added a comment -

      Merged to trunk in -r981.

      Show
      Maria Odea Ching added a comment - Merged to trunk in -r981.
      Hide
      Maria Odea Ching added a comment -

      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
      Show
      Maria Odea Ching added a comment - 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
      Hide
      Maria Odea Ching added a comment -

      Additional changes merged to trunk -r1003.

      Show
      Maria Odea Ching added a comment - Additional changes merged to trunk -r1003.

        People

        • Assignee:
          Maria Odea Ching
          Reporter:
          Maria Odea Ching
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved: