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.  

 

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

 

Hello, Andy Steingruebl here.

I'm posting for one of colleagues who is hiring a manager to head PayPal's application security efforts, specifically focused on Secure Development Lifecycle (SDL) work as well as foundational application security capabilities.

A job description is here: http://bit.ly/nP9Afr

An official posting will be up soon with instructions on how to post.  I will update this blog entry when the official job posting is available.

Comments on this blog are moderated. If you'd like more details you can post a comment for us to review or email me, my work email address is fairly easy to find online.

 

Bil Corry here:

I'm hiring an Information Security Engineer for our internal Consulting team.  While the position is listed for our Scottsdale office, the location is flexible and other locations are possible.

Brief description of the position:

Providing information security consulting services to internal groups and development teams to assess risk and ensure implementations are consistent with security standards. These services will include architecture review, vulnerability assessment, threat analysis, exception review, and more.

More information and how to apply is here:

http://rfer.us/EBRc-zIKf

Apply soon!

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.

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.

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.

 

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/