Testing bad cookie attributes is nice and simple.  There are automated tools that will alert you if these are not set.

But it is good to understand the technical detail as well.

So from an automated point of view, you could use a proxy such as the Burp Suite that is designed for web application testing. If it sees a cookie being set that isn’t given the “HttpOnly” flag, it will tell you.  The same applies for cookies that are provided over an SSL connection (i.e. when the pages are returned over HTTPS) that don’t have both the “HttpOnly” flag and the “secure” flag set.

• The “HttpOnly” flag tells the browser that the only way the cookie can be accessed is over the HTTP protocol.  In other words, no requests from Javascript etc are allowed.
• The “secure” flag tells the browser that the only way the cookie can be accessed is over an SSL encrypted connection.

Even if you don’t want to use an automated tool, you are looking for the same items.  In the response header provided by the server, you should see a header declaration “Set-Cookie:”. After which you will have the name of the cookie and the value that it is being set to.  The crucial bit is immediately after this as it should have the relevant flags set.

Cookie flags are important because they are used as an identifier for the server to recognise the user.  By recognising the user, the server is able to maintain a “session”.  This session holds details about the users experience with that web application.  For example, when a user logs into a web service, their session is recorded on the server as being an authenticated session.  If I were to gain a copy of someone elses session cookie, I would very easily be able to send that to the server and impersonate the user who the cookie belongs to, gaining access to everything the legitimate user had access to.  As a result it is vital that these session cookies are kept safe.

YGHT can help you increase your cybersecurity

Learn how by contacting us