Tapestry 5
  1. Tapestry 5
  2. TAP5-47

Cookie is not a secure cookie even though all connection are HTTPS connections

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.0.15
    • Fix Version/s: 5.0.16
    • Component/s: None
    • Labels:
      None

      Description

      A lot op applications are vulerable to a sniffing 'attack' even though
      SSL is used. The vulnerability is caused by allowing the cookie to be
      sent over http (the cookie is not a secure cookie)

      See:

      http://www.theregister.co.uk/2008/09/11/cookiemonstor_rampage/

      My application always uses HTTPS because I have set
      MetaDataConstants.SECURE_PAGE to true. The cookie however is not a
      secure cookie because Tapestry does set the Cookie#setSecure attribute.

      What I would like is that Tapestry does sets Cookie#setSecure when
      SECURE_PAGE is true.

      It seems that tomcat does set the secure setting but not with Jetty.

        Activity

        Hide
        Howard M. Lewis Ship added a comment -

        I think the best I can do is setSecure(true) when the request itself is secure.

        Show
        Howard M. Lewis Ship added a comment - I think the best I can do is setSecure(true) when the request itself is secure.
        Hide
        Martijn Brinkers added a comment -

        I agree. If the connection is initiated over a secure channel the session should be secured as well. There can however be a problem when a web application's login page uses HTTPS but other pages do not. If other pages do not use HTTPS the cookie won't be sent and the user is therefore not authenticated (I think). Although I think that it's better to always use HTTPS, because you are otherwise vulnerable to the 'cookie monster attack', it would be nicer if there is a setting that can disable the setSecure option. The default setting would be that setSecure is true if the connection was secure.

        Show
        Martijn Brinkers added a comment - I agree. If the connection is initiated over a secure channel the session should be secured as well. There can however be a problem when a web application's login page uses HTTPS but other pages do not. If other pages do not use HTTPS the cookie won't be sent and the user is therefore not authenticated (I think). Although I think that it's better to always use HTTPS, because you are otherwise vulnerable to the 'cookie monster attack', it would be nicer if there is a setting that can disable the setSecure option. The default setting would be that setSecure is true if the connection was secure.
        Hide
        Filip S. Adamsen added a comment -

        So there is no way to turn this functionality off? I'm setting a cookie on a secured page that I need access to on subsequent insecure pages. With this change, it doesn't work anymore.

        Show
        Filip S. Adamsen added a comment - So there is no way to turn this functionality off? I'm setting a cookie on a secured page that I need access to on subsequent insecure pages. With this change, it doesn't work anymore.

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Martijn Brinkers
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development