Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    XSRF protection

    Hi,
    Our penetration testers have opened a security issue and I hope you can help us to solve it.

    We need to integrate a XSRFtoken in all our Client/Server request, IDACall ones included. Is there a best practice to implement that? We use SmartGWT Power 3.0.

    Maybe we can use the GWT provided classes (https://developers.google.com/web-toolkit/doc/latest/DevGuideSecurityRpcXsrf)?

    Thank you!

    #2
    Just use RPCManager.setActionURL() to add the token as a URL parameter added to the default actionURL. Then all requests to IDACall will contain it.

    Comment


      #3
      Hi, using 3.0p

      we need to change
      the xsrf token again, when session expired and user loggs in again. The session expired due to security reasons every 5 minutes when a user is logged in.
      After session is expired AND user does a server request, a relogin dialog appears.

      After logged in, and a new xsrf token was created, we want to call RPCManager.resendTransaction , but with the new actionUrl,

      but it's still taking the OLD action url.

      1. Do you agree, that this is the right approach.
      2. Can you expand API to get previous RPCRequest, or change setAction URL also for stored queued transactions?


      Thanks a lot

      Comment


        #4
        In this case we would recommend using the same XSRF token for the new session. There is no particular security reason to believe it's been compromised - certainly requiring a new token would be inconsistent with allowing a request initiated in the old session to complete in the new session.

        Comment


          #5
          The relogin is required because the authentication cookie is expired on the server (after X minutes).
          Once the user re-authenticates using the relogin process the browser receives another authentication cookie.
          Now we allow the suspended transactions to be resubmitted with the new authentication cookie.
          Those transactions cannot be processed anymore on the server with the old authentication cookie, even if it was not compromised, but because of the X minutes expiration rule.
          Why should we use another rule for the XSRF token?
          If we keep the same XSRF token with the new authentication cookie that means that the token will be used for days, as long as the user uses the Relogin process.
          With such a token valid for many days the probability that a hacker finds it and creates a XSRF attack increases.
          I think that a XSRF token with a long validity is of no security use.
          Please see this "the token is only valid for the lifetime of the session" from "Disclosure of Token in URL" chapter of https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet

          Please advise how to set the new XSRF token in the Relogin process so that we can resend the suspended transactions with the new XSRF token?

          Comment


            #6
            If you're concerned about the longevity of the XSRF token, then we would suggest allowing the old XSRF token just once, for the resubmitted transaction, then requiring the new XSRF token to be used.

            Comment


              #7
              In some situations there are more transactions to be resubmitted, so the old token should be allowed not only once but many times.

              But my question was clear, can we send the new XSRF token with the resubmitted transactions or not? If yes please advice how to do it? If not please tell us that is not possible.

              Comment


                #8
                If it wasn't clear before, we don't currently have an API to change the target URL of an already-submitted transaction.

                Comment


                  #9
                  Another question. On the server side we have a normal filter that checks the token. In case the token is invalid we would like to display in the browser a warning that tells the user to reload the application.
                  What should be the response we should send in this case to the client?

                  Comment


                    #10
                    You probably want to implement this as a replacement IDACall servlet (as a subclass of the default IDACall servlet) rather than a servletFilter. This will allow you to use normal error handling, send back a standard error response, and add a client-side HandleErrorCallback to RPCManager to cause the page to reload (or reload after user confirmation).

                    Comment

                    Working...
                    X