Are cookies a wise way to handle an opt-out?
I happened to see this javascript about a month ago and almost immediately noticed a potential problem with the way the opt-in works. As the issue would be blinding obvious to anyone with a minimal knowledge of web design and security, and the system isn't live, and the issue does not represent a security risk, and because the difference in opting in or out is questionable, I posted about it in a forum that was being frequented by PhormUKTechTeam at the time.
Contained within this javascript is the URL to enable or disable webwise, which is called with a single parameter which requests either an opt-in cookie with an unique ID, or an opt-out cookie from the webwise.net server. It seemed fairly likely that just by embedding a hidden image or iframe on a webpage, it would be possible to remotely enable targeted advertising for visitors to that webpage from a "phorming" isp without their knowledge, let alone consent.
All that would be required is an image tag with the source pointing to the opt-in URL, something like this:-
"<img src="Webwise_opt_in_URL" width=1 height=1>"
Now this opt-in method was no doubt "just a test" and I expect this will be fixed by the time Phorm's webwise system finally goes live, but for me it raises concerns about the quality of the design and coding.
I don't expect it to work for long, but for the time being here are a couple of buttons to opt-in or out of webwise. They do nothing more than use javascript to open the opt-in or opt-out URL in a hidden iframe. Opting in will create a cookie in the a.webwise.net domain UID=xxxxxxxxxxxx|| where xxxxxxxxxxx is a 22 character (128 bit base64 encoded unique ID) and if present remove the webwise.net OPTED_OUT cookie (and vice versa).
Leaking Webwise UID
Richard Clayton notes in point 24 of his analysis of the Phorm "webwise" system that the webwise UID of visitors to a website will be visible to that website if any subsequent accesses to it use "https" protocol (also see points 20 to 26). He also reports that the Layer 7 switch only inspects traffic on port 80, this would suggest that the webwise UID will also be visible to a website if it uses a port other than 80 for a subsequent access.
Richard Clayton notes in point 24 of his analysis of the Phorm "webwise" system that the webwise UID of visitors to a website will be visible to that website if any subsequent accesses to it use "https" protocol (also see points 20 to 26). He also reports that the Layer 7 switch only inspects traffic on port 80, this would suggest that the webwise UID will also be visible to a website if it uses a port other than 80 for a subsequent access.
Linking email addresses to webwise UID by spamming?
The email itself could purport to have been sent by a major retailer and to contain a printable £10 discount voucher, it might prove incentive enough to encourage recipients to view it, but I'm sure spammers could devise even better inducements.
Spammers could also capture the webwise UID and associate it with the user's email address by tricking the Phorm user into clicking on a link within the email (which contains the email address it was sent to encoded/obfusticated within the link). This wouldn't be limited to webmail.
The Phorm user's browser would attempt to open the page, phorm would intercept it and add its UID cookie to the domain, the spammers website would redirect the request to an https: page, and the phorm user's browser would re-request the https: page, passing the phorm webwise cookie to the site.
Phorm's selling point to users is anti-phisishing protection, so the users who might benefit from Phorm (if they didn't already have anti-phisihing protection), would be the same users who would be likely to click on the link.
Please sign the petition against ISPs monitoring your browsing activity for advertising purposes
Do any modern email clients still share cookies with a browser? Hmm, I guess webmail services.
Only it occurred to me that by spamming everybody @a_phorming_isp.com with an html email that contained a webbug designed to capture the UID, it might be possible for a spammer to compile a database of UIDs linked to email addresses.
The webbug could be an http: image link containing the email address it was sent to (ie your email address) suitably encoded eg:-
"http://Spammer.con/phormbug_YourEmailAddressHere.jpg"
If you view the email, your email client would request the image.
Phorm would use its triple redirect jiggery-pokery to intercept this request and copy the webwise.net UID to a webwise cookie in the "Spammer.con" domain, and redirect the client so that it resends the original request.
The spammer's server would then reply with a redirect to a php script with an https: URL in the same domain. eg
"https://Spammer.con/phormbug_YourEmailAddressHere.php"
The email client automatically requests this https: url sending the webwise UID cookie.
Using https: encryption bypasses phorm's intercept of the UID cookie, delivering the UID (cookie) and email address (encoded in the URL) to the spammer.
The spammer then sells a service to websites that allows them to email targeted spam to visitors to their website.
Only it occurred to me that by spamming everybody @a_phorming_isp.com with an html email that contained a webbug designed to capture the UID, it might be possible for a spammer to compile a database of UIDs linked to email addresses.
The webbug could be an http: image link containing the email address it was sent to (ie your email address) suitably encoded eg:-
"http://Spammer.con/phormbug_YourEmailAddressHere.jpg"
If you view the email, your email client would request the image.
Phorm would use its triple redirect jiggery-pokery to intercept this request and copy the webwise.net UID to a webwise cookie in the "Spammer.con" domain, and redirect the client so that it resends the original request.
The spammer's server would then reply with a redirect to a php script with an https: URL in the same domain. eg
"https://Spammer.con/phormbug_YourEmailAddressHere.php"
The email client automatically requests this https: url sending the webwise UID cookie.
Using https: encryption bypasses phorm's intercept of the UID cookie, delivering the UID (cookie) and email address (encoded in the URL) to the spammer.
The spammer then sells a service to websites that allows them to email targeted spam to visitors to their website.
The email itself could purport to have been sent by a major retailer and to contain a printable £10 discount voucher, it might prove incentive enough to encourage recipients to view it, but I'm sure spammers could devise even better inducements.
Spammers could also capture the webwise UID and associate it with the user's email address by tricking the Phorm user into clicking on a link within the email (which contains the email address it was sent to encoded/obfusticated within the link). This wouldn't be limited to webmail.
The Phorm user's browser would attempt to open the page, phorm would intercept it and add its UID cookie to the domain, the spammers website would redirect the request to an https: page, and the phorm user's browser would re-request the https: page, passing the phorm webwise cookie to the site.
Phorm's selling point to users is anti-phisishing protection, so the users who might benefit from Phorm (if they didn't already have anti-phisihing protection), would be the same users who would be likely to click on the link.
Please sign the petition against ISPs monitoring your browsing activity for advertising purposes
Using the webwise UID with a third party tracking system?
Tracking cookies are used by "data mining" companies to collect data as your visit partner websites. Some people consider them a privacy issue, and programs such as Ad-Aware identify and remove a large number of tracking cookies.
A leaking webwise UID could be captured by such a tracking system and by doing so, should its own Unique ID cookie be deleted, it could use the webwise UID to re-identify the visitor and restore its original UID cookie.
If a user opts out of webwise and subsequently opts back in, it would be possible for the third party tracking system to associate the new UID to the user's old UID, something webwise claim not to be able to do themselves.
Only by deleting both the tracking cookie and ALL webwise created cookies, including those stored in other domains, would it be possible for a user to ensure that they could not be re-identified by a third party tracking system.
No comments:
Post a Comment