JAMWiki
  1. JAMWiki
  2. JAMWIKI-45

User specified URL redirection (Open Redirect)

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.6
    • Fix Version/s: None
    • Labels:
    • Environment:

      Tomcat 6.0.33 application server, Windows 2008 R2 OS

      Description

      I am a user of JAMwiki software and recently had it scanned with McAfeeSecure, a vulnerability scanning service that my company subscribes to. (https://www.mcafeesecure.com)
      McAfeeSecure identified this Open Redirect vulnerability in the JAMWiki 1.0.6 software. Here is the general advisory against Open Redirects from OWASP: http://www.owasp.org/index.php/Open_redirect

      It is possible that it is a false positive. However, it seems to work based on my own testing of the test cases provided by McAfee.

      I would like to know if this can/will be fixed in the JamWiki software.

      Description
      A parameter has been identified that can be modified to redirect clients to a user controlled page. An attacker could potentially construct a URL that will redirect a victim to a site that they control. This type of attack is typical seen in phishing attacks where the user is presented with a valid link on the site (i.e. http://www.mcafeesecure.com/main.jsp?state=4&page=http://mcafeesecure-evilsite.com) and mcafeesecure.com redirects the user to mcafeesecure-evilsite.com (The site the attacker controls). The fact that the server name in the modified link is identical to the original site helps the attacker by giving his phishing attempts a more reliable appearance.

      General Solution
      Remove the parameter that allows redirection from your site. If the parameter is required for operation then construct a list of valid links that the user can be redirected to [White List] and any other links that are specified the user will not be redirected to.

      Here is one of the demonstrations of the vulnerability that McAfeeSecure provided:
      ------------------------------------------------------------------------------------------
      URL
      Protocol https
      Port 443
      Read Timeout 10000
      Method POST
      Path /wiki/en/j_spring_security_check;jsessionid=F901B72AFC268EC5F1723EC05001EAC7
      Headers Referer=https%3A%2F%2F204.180.130.113%2Fwiki%2Fen%2FSpecial%3ALogin%3Freturnto%3DWiki_Home
      Content-Type=application%2Fx-www-form-urlencoded
      Body spring-security-redirect=http://www.mcafeesecure.com/
      j_username=0
      j_password=0
      _spring_security_remember_me=true
      function=Login

      Note that 204.180.130.113 is my publicly accessible wiki server.

        Activity

        Hide
        Ryan Holliday
        added a comment -

        That looks legitimate, and should be fixable. I'll take a look at this tonight and see about getting a 1.0.7 and 1.1.1 fix done - thanks for the report.

        Show
        Ryan Holliday
        added a comment - That looks legitimate, and should be fixable. I'll take a look at this tonight and see about getting a 1.0.7 and 1.1.1 fix done - thanks for the report.
        Hide
        Ryan Holliday
        added a comment -

        The fix for this appears to require changing the ServletUtil.viewLogin() method to validate that the Spring redirection URL is relative rather than absolute, although I'm still investigating the impact of that change and haven't yet committed any code.

        Show
        Ryan Holliday
        added a comment - The fix for this appears to require changing the ServletUtil.viewLogin() method to validate that the Spring redirection URL is relative rather than absolute, although I'm still investigating the impact of that change and haven't yet committed any code.
        Hide
        Ryan Holliday
        added a comment -

        Revision 3732 (and 3733, doh...) should fix this issue, but I'd like to give it some additional thought and time to cook since it is theoretically possible that Spring Security might be doing something internally that could conflict with this change on some configurations. Thus far I haven't found any problems, but if for some reason Spring was configured to redirect to an absolute URL and this parameter was used there could be issues.

        Show
        Ryan Holliday
        added a comment - Revision 3732 (and 3733, doh...) should fix this issue, but I'd like to give it some additional thought and time to cook since it is theoretically possible that Spring Security might be doing something internally that could conflict with this change on some configurations. Thus far I haven't found any problems, but if for some reason Spring was configured to redirect to an absolute URL and this parameter was used there could be issues.
        Hide
        Brian Clark
        added a comment -

        I upgraded my wiki to 1.0.7 and re-scanned with McAfee Secure. Unfortunately, your fix does not seem to resolve the issue. I request that this issue be reopened.

        Here is another example provided by McAfee in case that helps you identify and resolve the issue.

        Protocol https
        Port 443
        Read Timeout 10000
        Method POST

        Path /wiki/en/j_spring_security_check;jsessionid=FA0824CF5C21838DCD8EA115C12C43D2
        Headers Referer=https%3A%2F%2F204.180.130.113%2Fwiki%2Fen%2FSpecial%3ALogin%3Freturnto%3DWiki_Home
        Content-Type=application%2Fx-www-form-urlencoded
        Body spring-security-redirect=http://www.mcafeesecure.com//en/Wiki_Home?returnto=Wiki_Home
        j_username=0
        j_password=0
        _spring_security_remember_me=true
        function=Login

        Show
        Brian Clark
        added a comment - I upgraded my wiki to 1.0.7 and re-scanned with McAfee Secure. Unfortunately, your fix does not seem to resolve the issue. I request that this issue be reopened. Here is another example provided by McAfee in case that helps you identify and resolve the issue. Protocol https Port 443 Read Timeout 10000 Method POST Path /wiki/en/j_spring_security_check;jsessionid=FA0824CF5C21838DCD8EA115C12C43D2 Headers Referer=https%3A%2F%2F204.180.130.113%2Fwiki%2Fen%2FSpecial%3ALogin%3Freturnto%3DWiki_Home Content-Type=application%2Fx-www-form-urlencoded Body spring-security-redirect= http://www.mcafeesecure.com//en/Wiki_Home?returnto=Wiki_Home j_username=0 j_password=0 _spring_security_remember_me=true function=Login
        Hide
        Ryan Holliday
        added a comment -

        I'll need to look at this more closely to figure out if it's something that's exploitable - based on the original submission I was able to reproduce the exploit using a wiki link with a specific set of URL parameters, but that case is now fixed. If the only remaining way to reproduce this issue would be via a custom form submission then I'm not sure it's something that needs addressing, although if there is an exploitable use case then a fix would definitely be warranted. Any further information would be appreciated.

        Show
        Ryan Holliday
        added a comment - I'll need to look at this more closely to figure out if it's something that's exploitable - based on the original submission I was able to reproduce the exploit using a wiki link with a specific set of URL parameters, but that case is now fixed. If the only remaining way to reproduce this issue would be via a custom form submission then I'm not sure it's something that needs addressing, although if there is an exploitable use case then a fix would definitely be warranted. Any further information would be appreciated.

          People

          • Assignee:
            Ryan Holliday
            Reporter:
            Brian Clark
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: