Tag: cookie

SameParty cookie attribute

While Google has made strides to remove cookies, there was a recent addition to the Chromium product upon which Chrome, Safari, and Edge are based.

I saw this written up as the following:

The SameParty attribute takes no value, and requires that the cookie also specify the “Secure” attribute, and not specify “SameSite=Strict”. If either of these constraints is violated, the cookie will be considered invalid, and will not be set. “SameSite=Strict” is not supported because “SameSite=Strict” is intended as a security boundary, rather than a privacy boundary (which First-Party Sets aims to establish). Valid use-cases of “SameSite=Strict” in cross-site contexts should not be loosened even when the sites are same-party.

Better stated…

  • The SameParty attribute is specified without a value (as are Secure and HttpOnly) as ;SameParty;
  • The Secure attribute is required in order to use the SameParty attribute. Any cookie specifying SameParty without Secure will be rejected as invalid.
  • Additionally, any cookie specifying SameParty in the presence of SameSite=Strict will be rejected as invalid.

While I’ve seen this implemented in versions of Chrome 89+, it is not yet adopted in Firefox (and may never be).

References:

Cookie Priority attribute

While Google has made strides toward removing cookies, this new feature was recently added in Chrome 81+ in what appears to be a method for developers to better manage cookie lifespans when the browser client limit is being reached. This value can be seen in the DevTools, it appears that some cookies can be elevated even when the attribute is not specified.

This is added to the cookie string like any other attribute with value:
;Priority=High;

NOTE: this appears to be implemented only in Google Chrome.

References

SameSite cookies

Recently, while reading through the updated 2017 OWASP Top Ten RC1 documentation, last updated in 2013, I noticed a recommendation to use Cookies with the “SameSite=strict” value set to reduce CSRF exposure in section A8.

Consider using the “SameSite=strict” flag on all cookies, which is increasingly supported in browsers.

Similar to the way that HttpOnly and Secure attributes have been added, SameSite allows for additional control.

Per the documentation, as of April 2017 the SameSite attribute is implemented in Chrome 51 and Opera 39. Firefox has an open defect, but I would expect it to be added soon to follow Chrome.


Set-Cookie: CookieName=CookieValue; SameSite=Lax;
Set-Cookie: CookieName=CookieValue; SameSite=Strict;

According to the specification you can issue the SameSite flag without a value and Strict will be assumed:


Set-Cookie: CookieName=CookieValue; SameSite

As many programming languages and server runtime environments do not yet support this for session cookies, you can use the Apache Tier1 configuration to append them.


Header edit Set-Cookie ^(JSESSIONID.*)$ $1;SameSite=Strict
Header edit Set-Cookie ^(PHPSESSID.*)$ $1;SameSite=Strict

It looks like PHP.INI might support the following attribute in a future release, but it’s not there yet!

session.cookie_samesite

REFERENCES:

Renaming PHPSESSID

Like in Java, securing/renaming the PHP Session ID is simply a configuration item, generally this value is set as a cookie, but occasionally gets used in cases of URL Rewriting.

On Ubuntu your settings can be changed as follows, Windows will use the same settings in the appropriate file:

  1. sudo vi /etc/php5/apache2/php.ini
  2. Modify the following values as needed:

    session.name = "PHPSESSID"
    session.cookie_httponly = 1

REFERENCES

Renaming JSESSIONID

Older versions of Apache Tomcat, as well as the older servlet specifications required that several configuration values need to be set. With servlet 3, you can now modify the name of the session cookie (as well as the ‘rewriting’ attribute name) in the web.xml file

In web.xml: (servlet 3.x)

<session-config>
<session-timeout>30</session-timeout>
<cookie-config>
<name>mysessionid</name><!-- default is jsessionid -->
<http-only>true</http-only>
<!-- secure>true</secure-->
</cookie-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>

Alternately for Tomcat7, modify TOMCAT_HOME\conf\context.xml:
<Context path="/exampleApp" sessionCookieName="myid">

If you are using spring security, then you should try setting disable-url-rewriting attribute of <http> element to true.

REFERENCES:

HTTP Cookie Header

Obviously “Cookies” have a lot of advantages in web applications to maintain “state”, unfortunately using standard server configurations leads to even static content serving them up un-necessarily wasting some (minimal) bandwidth.

Adding the following to the Apache httpd.conf file is a start:
#Remove Cookie from all static content (except HTML as javascript could use it)
<FilesMatch "\.(html|htm|js|css|gif|jpe?g|png|pdf|txt|zip|7z|gz|jar|war|tar|ear|java|pac)$">
<IfModule header_module>
Header unset Cookie
</IfModule>
</FilesMatch>

REFERENCES:

Cheers!

HTTP Session Hijacking (Firesheep)

This topic, and Firefox add-on have received a lot of press lately, as such I figured that I’d capture some comments on the topic. HTTP Session hijacking is nothing new, anyone with the ability to monitor your non-secured network traffic can do this with little effort… what’s happened here is that there are now some really simple to use tools to do the job.

In the past, someone would have to passively monitor your network traffic with a tool like WireShark, and all they’d really have to do is wait for you to access a website to watch the ‘HTTP Cookies’ (or even a URL that contains a ‘session id’). With that information, they simply need to use the same value that you do to essentially take over your session and your current state. Banks are particularly at risk for this, but in most cases they use HTTPS/SSL for all secure data including logins. Social websites such as Facebook and even GMail, often default to non-secure logins to maximize their server and network performance.

Best defense here… never use non-secure login forms, especially when using a public wireless (or wired) network.

Interesting enough, there’s now a Firefox add-on that monitors for usage of Firesheep on the network, unfortunately neither of these currently work in Linux… links below!

Flash Cookies / Website Storage

If you’ve been online at all in the last decade, you’ve heard of the “dangers” of HTTP Cookies. More nefarious and harder to remove are Flash Cookies as they are handled by a plugin/extension/addon to the browser and exist outside of the normal security settings.

To see or delete Flash data, you’ve got to visit the following URL:
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html

You will probably be suprised to see many of the sites listed, as Flash is often being used to present you with ads in addition to the interactive elements that you might expect.

REFERENCES:

Flash ‘Cookies’ and Security Settings

I’ve found that a large percentage of Internet users don’t realize just how they are being tracked on a website. Most people are aware of HTTP Cookies, but very few realize that browser plugin technologies like Adobe Flash also maintain data about a user’s activities.  Worse yet, while HTTP Cookies are limited to 4k, Flash can store up to 100k per website.

Clearing of standard HTTP cookies is relatively easy to do in mainstream browsers.   However, while Flash is almost ubiquitous, it’s settings are not easy to locate… in fact you cannot even find them in your browser or computer settings, you have to visit a website!

When you visit this link you will first see the sites and amount of data they have stored about you,
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager06.html

Secondly, if you look on the other tabs or follow the next link you’ll be able to control Flash access to your microphone and webcam (provided that you have them connected).
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager02.html

Other tabs will allow you to control various settings related to updates and global security settings, as documentation is provided for each tab it should be relatively easy for you to decide which configuration you prefer in each case.

FYI – I can see some real potential for misuse of these settings if they could be altered externally by a motivated hacker.

References:

Cheers!

P3P 1.0 Implementation guide

Standards documentation is available from W3C at:

NOTES:

  1. Version P3P 1.1 is currently in the works.
  2. Throughout the specifications you’ll see references to “Well-Known Location”, this refers to the default path and naming of these files in the /w3c/ folder.
  3. In my examples below, I have left MOST data empty, the “

xxx” indicates a field that must match between these files.
HTML:


<html>
<head>
<link type="text/xml" rel="P3Pv1" href="/w3c/p3p.xml" />
</head>
<body>
...
</body>
</html>

HTTP Header:

p3p: policyref="/w3c/p3p.xml", CP="TST"

/w3c/p3p.xml:


<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<META xmlns="http://www.w3.org/2002/01/P3Pv1">
<POLICY-REFERENCES>
<POLICY-REF about="/w3c/privacy.xml#xxx">
<INCLUDE>/*</INCLUDE>
<COOKIE-INCLUDE name="*" value="*" domain="*" path="*" />
</POLICY-REF>
</POLICY-REFERENCES>
</META>

/w3c/prixacy.xml


<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">
<POLICY name="xxx" discuri="/index.html" xml:lang="en">
<ENTITY>
<DATA-GROUP>
<DATA ref="#business.name"></DATA>
<DATA ref="#business.department"></DATA>
<DATA ref="#business.contact-info.postal.name.given"></DATA>
<DATA ref="#business.contact-info.postal.street"></DATA>
<DATA ref="#business.contact-info.postal.city"></DATA>
<DATA ref="#business.contact-info.postal.stateprov"></DATA>
<DATA ref="#business.contact-info.postal.postalcode"></DATA>
<DATA ref="#business.contact-info.postal.country"></DATA>
<DATA ref="#business.contact-info.online.email"></DATA>
<DATA ref="#business.contact-info.telecom.telephone.intcode"></DATA>
<DATA ref="#business.contact-info.telecom.telephone.loccode"></DATA>
<DATA ref="#business.contact-info.telecom.telephone.number"></DATA>
<DATA ref="#business.contact-info.online.uri"></DATA>
</DATA-GROUP>
</ENTITY>
<ACCESS><nonident/></ACCESS>
<DISPUTES-GROUP>
<DISPUTES resolution-type="service" service="/index.html" short-description="Customer Service">
<LONG-DESCRIPTION></LONG-DESCRIPTION>
<REMEDIES><correct/></REMEDIES>
</DISPUTES>
</DISPUTES-GROUP>
<STATEMENT>
<CONSEQUENCE>We record some information in order to serve your request and to secure and improve our Web site.</CONSEQUENCE>
<PURPOSE><current/><develop/><admin/></PURPOSE>
<RECIPIENT><ours/></RECIPIENT>
<RETENTION><stated-purpose/></RETENTION>
<DATA-GROUP>
<DATA ref="#dynamic.clickstream"/>
<DATA ref="#dynamic.http"/>
</DATA-GROUP>
</STATEMENT>
</POLICY>
</POLICIES>

REFERENCES:

  • http://www.w3.org/TR/2000/CR-P3P-20001215/
  • http://msdn.microsoft.com/en-us/library/ie/ms537343%28v=vs.85%29.aspx#unsatisfactory_cookies