Tag: policy

Google Federated Learning of Cohorts (FLoC) – optout

Google Chrome 89 and other browsers based upon it such as Chromium Edge have introduced a new capability known as FLoC. This approach removes the need for third-party cookies by passing a group identifier in the HTTP Headers in a manner similar to how Cookies are exchanged. While FLoC should allow for users to remain more anonymous as advertisers only receive a group identifier for the user, it would not be difficult to use their IP address or other features available via device fingerprinting to track the individual.

As a web user, you would need to use several approaches to avoid this:
1. Use a browser without FLoC support. Hopefully, this will be added to the configuration menus to allow users to prevent it, similar to DNT.
2. Use a browser plugin (or other software/proxy) to remove the FLoC headers.

As a web-developer, you can add configuration to opt-out of all FLoC cohort calculation by sending the following HTTP response header:


Permissions-Policy: interest-cohort=()

If you really want to see the data, the following javascript will expose it:

const { id, version } = await document.interestCohort();
console.log('FLoC ID:', id);
console.log('FLoC version:', version);

REFERENCES:

Content-Security-Policy: block-all-mixed-content

If you are running a secure website, it’s a good idea to prevent non-secure assets from being included on your page. This can often happen through the use of content management system, or even through website vulnerabilities. A simple change in HTTP headers will help browsers to defend against them.


Content-Security-Policy: block-all-mixed-content

Most modern browsers, except MSIE, currently support this approach.
– Firefox 48+

REFERENCES

Content-Security-Policy: upgrade-insecure-requests;

As the web has been shifting to HTTPS for security and performance reasons, there are many methods to migrate users. One simple method is via the use of the Content-Security Header.


Content-Security-Policy: upgrade-insecure-requests;

Most modern browsers, except MSIE, currently support this approach.
– Chrome 43+

REFERENCES

Sender Policy Framework (SPF) Email

This is a simple mechanism, using DNS to certify that email from your domain comes from authorized servers. This is accomplished by adding a DNS record to identify the servers from which you send legitimate email. Emails sent from other servers MAY then be assumed as forged (SPAM) and blocked by the receiving email server.

NOTE: This can be easily spoofed, as such it should be a portion of your email security strategy, look into DKIM and DMARC too!

One thing that I initially did not understand… if you are supporting IPv6 and IPv4, you should merge your records onto a single DNS TXT entry:


example.com TXT v=spf1 a mx ip4:xxx.xxx.xxx.xxx ip6:xxxx:x:xxx:xxxx:xxx:xxxx:xxxx:xxx -all

REFERENCES:

clientaccesspolicy.xml

Similar to ‘crossdomain.xml’, Silverlight has some security features, this too is often noticeable by large number of HTTP 404 errors for a file named ‘clientaccesspolicy.xml’ in my webserver logs.

The most simple solution to the 404’s that restricts Silverlight is to add an empty file at the root of your websites.

REFERENCES:

Content-Security-Policy HTTP Header

There’s yet another new means to ‘help’ client User-Agents with preventing XSS on your websites.

In it’s simplest form you can simply use the following HTTP Header(s), the second one is for earlier versions of Webkit (Chrome/Safari):

Content-Security-Policy: default-src 'self'
Webkit-CSP: default-src 'self'

You can also add to the above to permit assets to load from other sources.
For example, if you were to permit javascript files from example.com you could include:

Content-Security-Policy: default-src 'self'; script-src http://example.com

Additionally, while failures are noted in the client’s browser console (that most users are not aware of), you can have them sent back to your server by adding a ‘report-uri’ attribute with an appropriate handler:

Content-Security-Policy: default-src 'self'; report-uri http://example.com/csp-report.php

REFERENCES:

crossdomain.xml

Adobe FlashPlayer 7 added several security features. I first became aware of this one as I saw a large number of HTTP 404 errors for a file named ‘crossdomain.xml’ in my webserver logs. (see also clientaccesspolicy.xml)

If you use flash on your website, I’d suggest adding an appropriate copy of this file to limit your exposure to some potential security issues.

Restricted domains

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.example.com" />
<allow-access-from domain="example.com" />
</cross-domain-policy>

Open to all domains (not recommended, but fully backward compatible)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>

REFERENCES:

java.policy file

While it’s not preferred or even ‘secure’, sometimes the need arises to ‘open’ up the Java security model.   Fortunately this is an easy task.

This is located in a file named ‘java.policy’ in the “JRE/lib/security” folder.

Default file (from JRE 1.5.0.x) resembles the following…

// Standard extensions get all permissions by default

grant codeBase “file:${{java.ext.dirs}}/*” {
permission java.security.AllPermission;
};

// default permissions granted to all domains

grant {
// Allows any thread to stop itself using the java.lang.Thread.stop()
// method that takes no argument.
// Note that this permission is granted by default only to remain
// backwards compatible.
// It is strongly recommended that you either remove this permission
// from this policy file or further restrict it to code sources
// that you specify, because Thread.stop() is potentially unsafe.
// See “http://java.sun.com/notes” for more information.
permission java.lang.RuntimePermission “stopThread”;

// allows anyone to listen on un-privileged ports
permission java.net.SocketPermission “localhost:1024-“, “listen”;

// “standard” properies that can be read by anyone

permission java.util.PropertyPermission “java.version”, “read”;
permission java.util.PropertyPermission “java.vendor”, “read”;
permission java.util.PropertyPermission “java.vendor.url”, “read”;
permission java.util.PropertyPermission “java.class.version”, “read”;
permission java.util.PropertyPermission “os.name”, “read”;
permission java.util.PropertyPermission “os.version”, “read”;
permission java.util.PropertyPermission “os.arch”, “read”;
permission java.util.PropertyPermission “file.separator”, “read”;
permission java.util.PropertyPermission “path.separator”, “read”;
permission java.util.PropertyPermission “line.separator”, “read”;

permission java.util.PropertyPermission “java.specification.version”, “read”;
permission java.util.PropertyPermission “java.specification.vendor”, “read”;
permission java.util.PropertyPermission “java.specification.name”, “read”;

permission java.util.PropertyPermission “java.vm.specification.version”, “read”;
permission java.util.PropertyPermission “java.vm.specification.vendor”, “read”;
permission java.util.PropertyPermission “java.vm.specification.name”, “read”;
permission java.util.PropertyPermission “java.vm.version”, “read”;
permission java.util.PropertyPermission “java.vm.vendor”, “read”;
permission java.util.PropertyPermission “java.vm.name”, “read”;
};

The replacement to remove all restrictions…

grant {
permission java.security.AllPermission;
};

Just be sure to restore your settings back to ‘normal’ before visiting any untrusted websites or java applications.

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