Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
8 replies Latest Post - ‏2011-09-28T09:55:14Z by SystemAdmin
SystemAdmin
SystemAdmin
403 Posts
ACCEPTED ANSWER

Pinned topic CSRF - false positive?

‏2011-09-02T01:49:01Z |
Hi

I got issue from AppScan, for some reason it expects 'x-requested-with' header for non-Ajax requests and marks every URL as CSRF-vulnerable. Moreover, responses are not identical (I mean response body) so it's even more stranger. Any advice how to deal with that?


ID: 50819

Description: Remove the HTTP 'x-requested-with' header

Difference:
N/A

Reasoning:
The same request was sent twice in different sessions and the same response was received. This shows that none of the parameters are dynamic (session identifiers are sent only in cookies) and therefore that the application is vulnerable to this issue.

CWE ID:
352#http://cwe.mitre.org/data/definitions/352.html


WBR Kir
Updated on 2011-09-28T09:55:14Z at 2011-09-28T09:55:14Z by SystemAdmin
  • SanjSawale
    SanjSawale
    3 Posts
    ACCEPTED ANSWER

    Re: CSRF - false positive?

    ‏2011-09-19T18:47:22Z  in response to SystemAdmin
    With my experience with Appscan stand. 8.x
    If you are using a POST call then I think Appscan isn't smart enough to change the post parameters to resemble real life scenario. It just steals the same original request as test request and changes few headers which your server code really don't care but it's still safe from security point of view.

    If you are certain that your code handles CSRF like it uses CSRF tokens in requests and server check those then you can ignore this as noise based on your server logs.
    • SystemAdmin
      SystemAdmin
      403 Posts
      ACCEPTED ANSWER

      Re: CSRF - false positive?

      ‏2011-09-19T19:34:14Z  in response to SanjSawale
      @SanjSawale

      AppScan definitely changes POST parameters for tests where that is applicable. In the case of XSRF though the whole idea is to be able to store a request and get the victim to inadvertently trigger it. So AppScan tests which sensitive requests can be stored. POST requests send data to the web server so the probability that they would be targeted is high.

      The difference is a bit misleading . What AppScan is trying to do is prove that the same request can be sent with different session cookies. The protection against XSRF is to add session parameters which would prevent an attacker from persisting the request. Session parameters help protect against other client side attacks as well, for example XSS because the attacker could not store a malicious request to send to the user, although other secure coding practices should be employed for XSS as well: input validation and output encoding.

      Read more about XSRF here : https://www-304.ibm.com/support/docview.wss?uid=swg21298693
      • gtanuel
        gtanuel
        19 Posts
        ACCEPTED ANSWER

        Re: CSRF - false positive?

        ‏2011-09-26T07:15:04Z  in response to SystemAdmin
        @Paul, I find it gets even more confusing:

        "What AppScan is trying to do is prove that the same request can be sent with different session cookies"

        The above definition in practice demonstrates a legitimate request rather than a forged one. What happens in CSRF is an attacker tries to ride on existing active/authenticated user session, typically during a parallel browsing session.

        "The protection against XSRF is to add session parameters which would prevent an attacker from persisting the request"

        If the above still extended from the previous sentence (i.e. parameters = cookies), all cookies will also be sent during a forged request, i.e. it's not the remediation/mitigation we'll look for.
        • SystemAdmin
          SystemAdmin
          403 Posts
          ACCEPTED ANSWER

          Re: CSRF - false positive?

          ‏2011-09-26T12:01:33Z  in response to gtanuel
          @gtanuel
          RE: If the above still extended from the previous sentence (i.e. parameters = cookies), all cookies will also be sent during a forged request, i.e. it's not the remediation/mitigation we'll look for.

          The attacker doesn't have access to the cookie values due to the same origin policy. So they will not know what the values of the parameters are even if the parameters = cookie values. However there's nothing to say that you shouldn't make the two completely different.
          • gtanuel
            gtanuel
            19 Posts
            ACCEPTED ANSWER

            Re: CSRF - false positive?

            ‏2011-09-27T04:52:00Z  in response to SystemAdmin
            @Paul:
            We might already refer to the same thing. I just want to highlight that putting CSRF prevention token in cookie is useless because the whole of point of forging a request is to ride on user's existing browsing session - which will transmit all cookies including any CSRF token if it's put there. It's also acknowledged by the IBM technote you referred earlier:

            "There have been many questions as to why AppScan uses a new session when the actual exploit uses the same session that the logged in user has."

            The reason AppScan sends the test case in different sessions is because, as an automated tool, it doesn't have the intelligence to tell which parameter is supposed to be the CSRF token. It relies on the assumption that, in different sessions, the CSRF tokens are different so that replayed request - which the only difference is the session ID (or all cookies) - doesn't go through.

            You're right that attacker doesn't have access to cookie value due to SOP. But it's not needed, i.e. in CSRF, the focus is only to forge the request (on behalf of victim user) and attacker doesn't need the response.
            • SystemAdmin
              SystemAdmin
              403 Posts
              ACCEPTED ANSWER

              Re: CSRF - false positive?

              ‏2011-09-27T15:43:10Z  in response to gtanuel
              @gtanuel I understand now where the misunderstanding is. For me there is a clear delimitation between request parameters and cookies. When you said parameters = cookies I though you meant parameter values = cookies values, when you actually meant to use the term parameters for cookies.

              I do see though that you do have a clear understanding of the fix from your latest post. I do think you need a bit more clarification on the test.

              AppScan can even automatically detect if a parameter is a session id or not, (or CSRF token). However that is not relevant. What is trying to test is that the CSRF prevention actually works, for example the app could have a CSRF token but ignore it.

              So then AppScan does exactly what an attacker does. It tries to persist the request across sessions. The only changing element is the cookies header. If indeed the token is present either in the post data or query or other headers when AppScan tries to send the request in the new session cookies it should get an invalid response. This means that the request was not successful and that the CSRF token works.

              The only shortcoming from the automated tool perspective is understanding the functionality of that request. It is up to you to understand that aspect and if CSRF is applicable to it.
              • gtanuel
                gtanuel
                19 Posts
                ACCEPTED ANSWER

                Re: CSRF - false positive?

                ‏2011-09-28T04:25:06Z  in response to SystemAdmin
                @Paul:
                Thanks for clarifying. I too don't want to drag this longer than necessary but, for completeness' sake, just wanted to highlight the situation where the following can be incorrect:

                So then AppScan does exactly what an attacker does. It tries to persist the request across sessions. The only changing element is the cookies header. If indeed the token is present either in the post data or query or other headers when AppScan tries to send the request in the new session cookies it should get an invalid response. This means that the request was not successful and that the CSRF token works.

                First of all, I don't doubt if internally AppScan has certain capability/intelligence to deduce which parameter(s) are the CSRF prevention token. However, different from session IDs where it can be deduced e.g. from recorded login, I suspect this will be based on a form of pattern-matching, similar to existing parameters & cookies tracking and therefore won't be 100% accurate hence the need for different-sessions testing.

                The situation where this test will generate a false positive is when the application uses a time-based CSRF token (not the most optimum solution but still a mitigating factor) e.g. changed every 5 minutes across multiple sessions (associated with the user account/ID).

                In this regard, while human's perception can rather easily recognize the randomized CSRF token, automated tool such as AppScan will have difficulty in identifying such thing, especially when there are other seemingly "random" parameter values in the same request.

                Thanks for the discussion. Apologies for OP if we "hijacked" the threat.
                • SystemAdmin
                  SystemAdmin
                  403 Posts
                  ACCEPTED ANSWER

                  Re: CSRF - false positive?

                  ‏2011-09-28T09:55:14Z  in response to gtanuel
                  So the issue is not recognizing the token, it is testing that it works.

                  AppScan logs out before sending these tests. So if the token continues being valid after logout this is actually a vulnerability.

                  CSRF is tightly tied into the user's session so the token should be dependent on the validity of the session as well.