The Security Practice

PayPal supports reform at the CA/Browser Forum

PayPal is pleased to note the creation of a working group at the CA/Browser Forum to address rechartering itself as a more mature and capable organization with a broader scope of action. We are entirely supportive of the work; indeed, we believe it is vital. Through collaborative efforts like Extended Validation Certificates, the CA/Browser Forum has already played an important role in promoting consumer trust online. However, recent events such as the DigiNotar compromise have demonstrated that the foundations of Internet trust are under increasingly serious threat, and that the community is reaching the limits of our ability to respond, in both the technical and policy arenas.

In the short term, technical innovation will be a key part of that response, and a forum is needed to host collaborative requirements gathering, research, and alignment among various stakeholders in the HTTPS ecosystem. In the medium and long term, better governance and incentives for the consumer PKI market are needed to insure that it can accommodate and adapt to the rapid growth and diversity of both legitimate uses and emerging threats. PayPal believes that an open, public, multi-stakeholder process provides a proven model for these activities. PayPal, our users and our merchant community depend on the security and trust of the X.509 and TLS technologies. As a longstanding industry leader, PayPal would continue to commit significant resources towards advancing and defending a secure Internet at a reformed CA/Browser Forum.

We believe a reformed CA/Browser Forum should:

• Represent the voices of all stakeholder communities
  • Certification authorities
  • Software vendors of web browsers and other PKI trust stores
  • CA customers, governments and the browser-using public
  • Experts in the technical, legal, audit and privacy communities
• Deliver market reform, operational guidance, audit frameworks and management policies
• Include uses of certificates beyond the browser in its considerations and recommendations
• Avoid the creation of new technical standards
  • Minimize overlap and conflict with existing bodies such as the IETF
  • Minimize the intellectual property rights commitments required to participate
• Provide a pre-standards track incubation and discussion space
  • Organize industry opinion, provide problem statements, requirements and indications of interest to support the charter of working groups in standards setting organizations such as the IETF or W3C
• Operate publicly and transparently
• Advance recommendations by voting rights, rather than a consensus-driven, process
• Structure representation in the decision process via a constituency-based, election process
  • Provide a balance of power by giving each stakeholder constituency a meaningful voice
  • Prevent minority interests or a single constituency group from controlling outcomes
• Be enabled to provide necessary ongoing operational capabilities, including but not limited to marketing and outreach
• Deliver recommendations that may be freely and voluntarily adopted by members and non-members alike

These reforms represent a somewhat radical departure from the current, closed structure of the CA/Browser forum, but the industry is at a time of great challenges. We fear that missing this opportunity to embrace change from within will inevitably lead to change being forced on the industry from the outside. The consequences of governmental or ITU takeover of PKI governance – Internet trust fractured across national borders and cumbersome regulatory regimes that impair growth and innovation in secure online services – would be costly and please few.

By reforming the organization along the lines proposed here, Certification Authorities and other industry stakeholders can be flexible, responsive and agile in a way that government regulation and more rigid, centralized oversight cannot. We sincerely hope the CA/Browser Forum will embrace the opportunity to act decisively and credibly, and take on broader responsibility for promoting the growth and maintenance of the public PKI and certificate ecosystem in the interests of Internet security and the broader public good.

We have submitted these remarks as our public position to the CA/Browser Forum reform working group, and encourage other interested stakeholders to submit comments and support these important goals at: [email protected].

-Brad Hill

PayPal domains are now using DNSSEC

We're pleased to announce that all PayPal owned and operated DNS domains are now secured using DNSSEC. They are all signed, and DS records uploaded to their respective TLD's.

This announcement is the culmination of months of work by PayPal's Site Operations teams, along with our domainname administrator.  Congratulations to them for their hard work on making this fully operational.

If you'd like to see a small visualization of the "trust chain" involved for paypal.com, you can see it here: http://dnsviz.net/d/paypal.com/dnssec/

Note:  Be aware that in cases where a domain name is a pointer (CNAME) to another domain that does not yet use DNSSEC, the full DNS lookup path will not be protected.  If you're curious to learn more, please read the Technical Note section below.

- Andy Steingruebl

 

Technical Note

PayPal has DNSSEC signed all of our zones.  However, the technically-oriented observer will notice that some PayPal domains are actually served by a Content-Delivery-Network (CDN) and the DNS records of that CDN are not yet secured using DNSSEC.  

 

The Future of Web Application Security at W3Conf 2011

This week I had the honor and pleasure of presenting at W3Conf, the W3C's first ever developer conference.  I saw some truly amazing work that is expanding the idea of what the Web can be, and all built using open standards.  

In that theme, Scott Stender of iSEC Partners and I gave a talk for developers titled "The Future of Web Application Security".  We highlighted how growing complexity and capability, new data flows, and the use of Web APIs in all types of clients means that Web App Security can no longer be a strictly server-side concern.  Client-side apps must be designed, built and tested to be able to defend themselves.  Luckily, standards being developed in the W3C Web Application Security WG and elsewhere, such as Cross-Origin Resource Sharing and the Content Security Policy, are finally giving developers better ways to build securable client-side mashups in a least-privilege environment.

Watch the video of the talk (and check out the other fantastic presentations) at http://www.w3.org/conf/#presentations or get our slides here.

-Brad Hill

 

The Folly of Detecting Tracking from Cookies

Hi, Bil Corry here:

Earlier this year, Andy Steingruebl and I wrote a position paper on Do-Not-Track that criticized the push of a technology solution that did not have a corresponding comprehensive public policy, a public policy that contained input from all stakeholders. Our position is that an early push with Do-Not-Track has not properly define “tracking”, nor does it provide proper guidance for legitimate business use-cases.

To that last point, there has been two research projects that purport to show how user privacy is being violated, both of which rely on observing the behavior of the “tracking” websites to validate their claim.

Jonathan Mayer’s  “Tracking the Trackers” findings include:

• Half of the NAI members we tested did not remove their tracking cookies after opting out.
• At least eight NAI members promise to stop tracking after opting out, but nonetheless leave tracking cookies in place.

Ashkan Soltani’s  “Respawn Redux” findings include:

• In our follow up study, we found that Hulu was still respawning deleted user cookies using homegrown Flash and Javascript code present on the Hulu.com site. Additionally, Hulu, Spotify, and many others were also respawning using code provided by analytics firm KISSmetrics.

The problem with both studies above is that they conflate cookies with tracking.  One cannot determine if tracking is occurring by observing cookies – let’s look at a few examples:

1. Example: user sends the Do-Not-Track (DNT) header, the NAI member does not remove their “tracking” cookie.
   • The NAI member may have server-side logic that detects the DNT header and does not record (track) any information related to this user.  That would allow continued tracking in the future should the user turn off the DNT header while preserving the user's choice.
   • If data was collected prior to the DNT header, does the DNT header mean, “erase everything you already have about the user” and/or “do not use anything you already know about the user”?  What if the data collector provides an alternative mechanism to view and remove data, such as BlueKai’s Registry?  This area is very unclear.

2. Example: server detects their cookie has been removed and respawns it.

   • If the cookie being respawned was the opt-out cookie, would there be a privacy concern?  Cookie respawning can be used as a feature for users that erase all cookies, yet have asked the website to remember them.  Or to prevent fraud.  Or to prevent multiple views of the same ad.  One can argue that there should be a way to remove the respawning, but respawning in and of itself does not necessarily mean tracking is occurring.
   • The removal of a cookie does not necessarily represent user choice to not be tracked.  Cookie storage is finite in all browsers; cookies are removed according to a Least-Recently-Used (LRU) policy.  In addition, it’s possible for an attacker to force out all cookies by creating numerous bogus cookies (cookie eviction).

3. Example: servers collect tracking information based on email address and share it via a backend process.

   • The user will see no indication that they are being tracked and profiled.  There isn’t any mechanism being used to uniquely track the user on the browser side, instead their user profile with their email address is used to track them.  The user would have to rely on the website to honor the DNT header, there isn’t a technology solution to this scenario.

From the above examples, it is clear that it is impossible to determine tracking of users by viewing website behavior.  The only way to know if tracking is occurring is to view the behavior on the server-side.  Until studies actually account for server-side behavior, they are merely speculating as to whether tracking is occurring.

A comprehensive public policy is needed to define tracking and to define the obligations of providers when presented with Do-Not-Track and/or other privacy mechanisms.

Combating Cybercrime

Hello, Andy Steingruebl here:

We've just published a whitepaper titled "Combating Cybercrime: Principles, Policies, and Programs".

You can read a quick summary at this blog post, or download and read the paper itself.  While we don't believe we have all of the answers to combating crime online, we do believe we've presented a set of principles as well as several workable policy and technology options that will help make progress against this problem.

Please do let us know your thoughts.

Thank you

Where is the Comprehensive Online Privacy Policy?

Hi, Andy Steingruebl and Bil Corry here:

Our friends at Mozilla have been hard at work creating a Do-Not-Track behavioral advertising opt-out mechanism, which shipped with the recently-released Firefox 4.  A stated goal for Mozilla’s Do-Not-Track mechanism is as follows:

This header is intended to be a signal equivalent to the presence of an opt-out cookie. We believe only a small number of changes from websites and advertisers are necessary to switch from looking for opt-out cookies to looking for the header.

Yesterday, Mozilla reported  that the AP News Registry service implemented their Do-Not-Track mechanism in just a few hours with a single engineer, which appears to confirm Mozilla’s assertion that this feature is a relatively easy one for websites with an existing opt-out cookie mechanism.

While we applaud Mozilla and the Associated Press for their hard work on this issue, we are concerned that this frames the Do-Not-Track discussion around replacing existing opt-out cookie solutions.  Admittedly, Mozilla does acknowledge that this is not a complete solution, and indeed, it is our belief that online privacy needs a much more thorough discussion with all stakeholders.

We recently submitted a position paper to the upcoming W3C Workshop on Web Tracking and User Privacy; we argue that it is premature to push technical mechanisms for controlling privacy before having a more substantial discussion with all stakeholders to define a complementary policy framework.  Clearly online privacy extends beyond just an alternative opt-out cookie mechanism, but how far?  What does it look like?  Should public regulation also be included?  What is the definition of “tracking”?  The answers to those and many other questions will then determine what a technical solution will look like, which may be entirely different than any technical solution currently being proposed.

We strongly believe an online privacy system needs to be developed, but strongly disagree with the current effort to define a technical solution before a policy framework with stakeholders has been developed.

You may view our position paper here:

                http://www.thesecuritypractice.com/the_security_practice/papers/W3C-WhereIsTheFramework.pdf

We welcome your feedback.

Web (In)Security: Remediation Efforts - Status and Outlook

Hi, Jeff Hodges and Andy Steinguebl here.

We gave a "status and outlook" talk on the topic of "Web (In)Security: Remediation Efforts" at a major security conference in Feburary.

The thrust of the talk is that currently "the Web" has some issues, and..

• there has been work going on in various fashions to address aspects of this, though it is unfortunately fairly uncoordinated,
  
  
• as a result, there are some "knobs and buttons" you as a web application operator can use today to aleviate some of the issues (and here's how),
  
  
• there are various high-priority issues that are being addressed in various fora, notably the IETF and the W3C, and you can/should participate.

A facsimile of our presentation is here.

Enjoy!

 

 

'HTTP State Management Mechanism' to Proposed Standard

Hi, Jeff Hodges and Bil Corry here:

The IESG recently approved the Internet-Draft 'HTTP State Management Mechanism' (draft-ietf-httpstate-cookie-23.txt) for publication as a Proposed Standard RFC...

<http://www.ietf.org/mail-archive/web/http-state/current/msg01257.html>

This is great news in that the prior two IETF RFCs specifying "cookies", as well as the original informal and incomplete "cookie spec", have not been implemented uniformly across browsers and servers. Thus how cookies are actually constructed, parsed, and used in practice has been essentially folklore. Anyone wanting to craft a new browser or some other application or tool that needs to consume or send cookie headers had to reverse engineer how the browsers were actually doing it as there wasn't (until now) an accurate specification an implementer could use for reference. This has led to  divergence on edge-cases for cookies within various browsers, servers, and other tools.

The new specification, draft-ietf-httpstate-cookie, differs from the prior specs in that it specifies how cookies are actually used on the Internet today. Anyone crafting a new client or server can implement the spec and have an interoperable implementation as a result. [note that an RFC number is not yet assigned, it ought to be done in several weeks, and the proper RFC published in a couple months]


A Bit of History..

Before getting to the present-day spec, a bit of history will provide appropriate context:

The original Netscape "cookie spec"  was written by Lou Montulli sometime in the mid-nineties. By late 1995, three proposals for adding "state management" to HTTP were circulating in the technical community. A subgroup of the IETF HTTP working group formed to address this "state management" question, and eventually produced RFC2109, which attempted to be backwards compatible with the "netscape cookies" while offering some enhancements. After three more years, they produced RFC2965, which offered yet more enhancements and was distinct from the "netscape cookies". There are many fascinating details this terribly brief summary overlooks, not the least of which is that the cookie effort participants found themselves unexpectedly situated at the intersection of technology and public policy when privacy concerns began to be raised. Dave Kristol, who was co-author with Montulli on RFCs 2109 and 2965, wrote a detailed account of the entire process, which curious parties are encouraged to read..

   Kristol, D., "HTTP Cookies: Standards, Privacy, and
   Politics", ACM Transactions on Internet Technology Vol. 1,
   #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.

Now, fast forward to late 2008, when Bil Corry, a web app security specialist who participates in the OWASP and other web app security fora, connected with Jim Manico, another figure in that cohort, to try to foster some cohesiveness with respect to the fragmented approach to a relatively commonly implemented, but unspecified cookie "flag" named "HttpOnly". Bil and Jim saw the security issues arising from how the browser vendors were implementing HttpOnly in varying ways due to a lack of a specification and formed an ad-hoc working group to tackle the issue.

When Bil approached the IETF about forming a charter for an official working group. He was told that he was <quote> "wasting [his] time" because cookies themselves did not have a "proper specification" -- i.e. one that accurately reflected their use on the Internet today -- so it didn't make sense to work on a spec for the HttpOnly cookie flag. Soon after, they pursued reopening the IETF httpstate Working Group to tackle the entire cookie spec issue, not just the HttpOnly flag. Eventually Adam Barth would become the specification editor and Jeff Hodges the (reconstituted) IETF httpstate working group chair.


Now, Some Thanks..

We thank the participants of the original ietf-httponly-wg effort, especially Jim Manico, for helping to kick-start this effort.

Thanks to Adam Barth, the specification editor, and also the keeper, and implementor of, the test cases and test harness, for hanging in there with an unfamiliar IETF process and crowd, taking the time to travel to some IETF meetings, and plugging away until we have a finished spec.

Thanks to our area director, Peter Saint-Andre, whose expert navigation of the IETF document and IESG processes was also an instrumental contribution.

We also thank the broad array of participants in the IETF httpstate working group, both online and in person at our sessions at IETF meetings -- your contributions were critical to crafting a high-quality spec and navigating the approval process. Here's the acknowledgements section from draft-ietf-httpstate-cookie where all these folks are noted..

   This document borrows heavily from RFC 2109 [RFC2109].  We are
   indebted to David M. Kristol and Lou Montulli for their efforts to
   specify cookies.  David M. Kristol, in particular, provided
   invaluable advice on navigating the IETF process.  We would also like
   to thank Thomas Broyer, Tyler Close, Alissa Cooper, Bil Corry,
   corvid, Lisa Dusseault, Roy T. Fielding, Blake Frantz, Anne van
   Kesteren, Eran Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim
   Hoffmann, Georg Koppen, Dean McNamee, Alexey Melnikov, Mark Miller,
   Mark Pauley, Yngve N. Pettersen, Julian Reschke, Peter Saint-Andre,
   Mark Seaborn, Maciej Stachowiak, Daniel Stenberg, Tatsuhiro
   Tsujikawa, David Wagner, Dan Winship, and Dan Witte for their
   valuable feedback on this document.



In Summary..

This spec is a milestone in that HTTP "cookie" syntax and behavior has been
effectively a matter of undocumented folklore all these years. Getting this
finally explicitly documented will be a key underlying piece of moving "the
Web", and the wider Internet its built upon, on towards its next stage(s).

Note also that although the HttpOnly flag is now nominally documented in draft-ietf-httpstate-cookie, there remains undocumented behavior, for example, interactions with XMLHttpRequest. So now with a firm foundation, Bil (or others) can address these HttpOnly spec deficiencies.

 

Phishing Metrics Demystified

Lisa Kelly and Brett McDowell here:

According to a recent external report from OpenDNS, PayPal has been deemed the most phished brand of 2010.

http://www.net-security.org/secworld.php?id=10487

Phishtank’s original report presented this graph:

    This recent report showcases the results from PhishTank’s database for the 2010 year, and concludes that PayPal was the most phished brand for this time period. It also states PayPal was “targeted nine times more frequently than the next most frequent target, Facebook”.  This is a bold statement, and prompted many questions within our organization about the validity of this specific report.  

        In this blog post, we will share our concerns with the original PhishTank data report for 2010, and  l outline our key methods of properly measuring and reporting the overall phishing threats.  In looking at overall phishing statistics, it is important to understand that they can get distorted based on which organizations contribute their data and the manner in which they do so. We want to share our findings as well as outline the key areas to measure to accurately report the overall phishing attack landscape. When industry can confidently report phishing data, we can aggressively manage the negative impact phishing has caused in our internet ecosystem and continue the fight against this type of fraud.

        First, a few thoughts on the original PhishTank report. In small font under the graph it is noted that this is a “sample of phishing sites” and overall they analyzed 117,102 phishing URLs to arrive at their conclusion. PayPal is the leading provider of known data to Phishtank.com, and knowingly we submitted all of our phish sites to this organization. PayPal currently manages a fraudcast which distributes our known sites to third parties in order to create awareness and help clean the ecosystem. In 2010, we sent over 46,000 phish alerts to this company which weighed heavily on the report that was distributed. By our data alone, we skewed the overall results to at least 40% of total volume. PhishTank’s data is dependent on external feeds (such as the one PayPal supplies), and this is important to note when reviewing their overall findings.

                Another key item to address in this report is the way volume is outlined. Evaluating phishing attacks solely by volume of URLs is not an accurate measure of overall threats. Key areas to look at when evaluating the overall phishing threats are: 1) how many emails were actually delivered to the end user, 2) what types of trends are identified during the phishing attacks, 3) how quickly spoof URLs become deactivated and what other preventative measures are in place to decrease attacks. These are all key areas that PayPal closely monitors and executes strategy to ensure we are disrupting the attempts that fraudsters make to defraud our consumer base.

• Email delivery: we currently work with internet service providers and block phishing emails to end users by a technology called domain key identified mail (DKIM). We now cover 40% of our user base, and deliver only PayPal approved messages to the inbox.
• Trends: PayPal is a victim to what is known as the “rockphish” attack trend, regarding spoof URLs. This means that fraudsters can launch a large quantity of sub-domains from one root domain to increase the success rate of the phishing attack. Our current 2010 reports show that 36.5% of our volume was associated with this trend. When we see this attack occur, we deactivate the root domain which will in turn deactivate all sub domains.
• Deactivation: with every detected PayPal phishing site, we have a team that deactivates 100% of the known threats. Working around the clock, PayPal is able to deactivate these sites in a short amount of time, and supports worldwide take downs.
• Prevention: PayPal works closely with consumers and reviews all forwarded phishing emails from this source. We look at headers and evaluate any emails associated with phishing attacks and immediately report to ISPs. On average, we are able to eliminate the risk in 3 hours and stop further phishing attempts from that exact email.

                In short, there are reasons why we may appear to be the most phished brand of 2010. In reality, because of all of our strides with our anti-phishing strategies, fraudsters have to create large quantities of spoof URLs in their attempts for a successful attack. When reviewing reports made by other organizations, it is important to understand the source of data as well as how they arrive at their conclusion.

                OpenDNS/PhishTank has also posted a response to their 2010 overall phish findings. They have confirmed that PayPal has skewed the data by submitting a high number of phishing sites to their product. They have pulled the data based on API-based submissions and the numbers are considerably different:

Facebook 8.64%
HSBC Group  6.73%
World of Warcraft   5.35%
Internal Revenue Service  4.87%
Sulake Corporation  3.21%
Bradesco 3.15%
PayPal  3.03%
Orkut  2.9%
Steam 1.95%
Tibia 1.72%n=72,404

Updated response from OpenDNS; http://blog.opendns.com/2011/02/28/phishing-paypal-and-the-challenges-of-reporting-accurate-data/

 

Do-Not-Track Must First "Do No Harm"

Hello, Brett McDowell here:

Mozilla went on the record over the weekend with their specific proposal for how to implement Do-Not-Track (DNT) mechanisms via HTTP-header (with the goal to enable users to opt-out of Online Behavioral Advertising (OBA) at internet-scale, if they wish).  Here are the relevant links:

Privacy Positioning Blog Post (Alex Fowler):

Firefox Technical Proposal Blog Post (Sid Stamm):

Proposal Itself (header implementation):

Proposal Itself (UI implementation):

Technical Analysis of Do-Not-Track proposals (Mike Hanson):


Mike Hanson's blog post is the best analysis on the topic I've seen so far, but it still fails to call-out anti-fraud tracking explicitly as a behavior that should not be interfered with by DNT.  He lists: advertising, personalization, and metrics as functions DNT should avoid interfering with, but given the nature of the Mozilla DNT proposal, sites still have to implement an interoperable OBA opt-out mechanism to avoid even that level of interference.  Will every browser vendor have their own interface we have to interoperate with to avoid having all "3rd-party tracking" -- which of course doesn't actually mean 3rd-party, but simply means "from domains other than the one in the location bar" -- blocked by their browser?

I continue to be disappointed by the Do-Not-Track discussion as captured by the media and blogosphere for its continued disregard for the security considerations of this new header.  Our concern is not about some geeky, low-level afterthought.  We are talking about a fundamental negative consequence on internet security brought about by an industry-wide knee-jerk reaction to the FTC that is currently poised to remove mission-critical consumer protection mechanisms (commonly used by sites that require user authentication, including but not limited to financial services and commerce) if security considerations remain in the shadows of this policy debate much longer. The internet community must come together and explicitly carve-out anti-fraud tracking as a behavior to sustain, if not embolden, in the post-DNT world.  

Carving-out first-party tracking is a reasonable step that I don't intend to criticize, but it's a blunt instrument that is insufficient for the task.  Anti-Fraud tracking is not always exclusively conducted via first-party cookies, nor is OBA exclusively negated by blocking 3rd-party cookies (as Mike Hanson points out in his post).  Whatever DNT turns out to be, it must be based on a use-and-obligations model, i.e. a mechanism that triggers the required obligation for the specific use being addressed by the mechanism, which is OBA in this case.  I'm pleased to see Mozilla headed in that direction, but there is still a long way to go before we've got this right.  

The core issue is introduced in this sentence from Mike Hanson's post:
"I propose that the user's intent can be captured in a simple rule: If the Do-Not-Track header is present, and the site has a "tracking opt-out" mechanism, the mechanism should be activated. If the site does not have an explicit opt-out mechanism, the user should experience only content from their first-party relationship with the page being viewed."

I interpret the intent of that to mean:

1. Sites must implement an interface between the HTTP "DNT" Header and their current opt-out mechanisms
2. This implementation must be interoperable across all browsers and sites
3. If anything goes wrong and the browser cannot interpret the confirmation from the site that it has implemented it's OBA opt-out mechanism in compliance with the DNT header setting in the browser, then the browser will initiate the "more harmful than helpful" behavior of blocking all but obvious domain-based, first-party content and tracking mechanisms.

Step 3 highlights the nest of issues we need to resolve if we want to ensure the post-DNT-web is better at protecting personal information from unauthorized disclosure than the web we have today.  

Because this is a tractable problem, we are not against the DNT movement per se.  We are against DNT gone wrong.  What we need now is an all-hands standardization effort inclusive of the many proposals, all the various influencers, under a collaborative framework with a proven track record of facilitating timely compromise on thorny standardization issues, to bang out a rough consensus set of policies and protocols for DNT.  This is not a call to stop the DNT effort, but to elevate DNT out of the noise of media coverage and into serious analysis and standardization work... before it's too late to get it right.