09 April 2014

Leakage

Posts relating to the category tag "leakage" are listed below.

09 April 2014

Third-Party Tracking Cookie Revelations

A new draft paper describes how the capture of tracking cookies can be used for mass surveillance, and where other personal information is leaked by web sites, build up a wider picture of a person's real-world identity.

Title page from 'Cookies that give you away: Evaluating the surveillance implications of web tracking'

Dillon Reisman, Steven Englehardt, Christian Eubank, Peter Zimmerman, and Arvind Narayanan at Princeton University's Department of Computer Science investigated how someone with passive access to a network could glean information from observing HTTP cookies in transit. The authors explain how pseudo-anonymous third-party cookies can be tied together without having to rely on IP addresses.

Then, given personal data leaking over non-SSL content, this can be combined into a larger picture of the person. The paper assessed what personal information is leaked from Alexa Top 50 sites with login support.

This work is likely to attract the attention of privacy advocates and regulators, leading to increased interest in cookies and other tracking mechanisms.

The research work was motivated by two leaked NSA documents.

Posted on: 09 April 2014 at 10:02 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

16 January 2014

More Bad News From The Banks

It seems that although banks might be "where the money is", they may not be spending it in the right places when it comes to information security.

Partial screen capture from the blog post about smartphone banking apps and their security vulnerabilities

In December I mentioned a study of vulnerabilities in banks' websites, especially the high prevalence of cross-site scripting (XSS).

Last week, the results of a one-week study of 40 iOS personal banking mobile apps, provided by major banks throughout the world. The study reveals the rather poor state of client-side software security, with all the apps deployable on jailbroken devices, most had non-SSL links, almost half were susceptible to Man in The Middle (MiTM) attacks since they did not validate the authenticity of SSL certificates, and half were vulnerable to cross-site scripting (XSS). Read more bad news in the blog post.

The list of security tests mentioned in the study would be worthwhile undertaking for any mobile app development plan.

I am quite surprised about this is such a highly-regulated sector. Although each compromised bank account may not have much significance to the bank, the impact on individuals is very high, and financial services regulators are likely to show concerns.

Posted on: 16 January 2014 at 11:30 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

16 August 2013

Colourful Range of Mobile App Risks for Developers

Veracode, who publish the excellent State of Software Security reports, has created a security awareness diagram for mobile app developers.

Partial screen capture of Risk 5 - Sensitive Data Leakage from Veracode's Developer's Guide to Building Secure Mobile Applications Infographic

Developer's Guide to Building Secure Mobile Applications in an infographic which summarises some phone theft/loss data, and the prevalence of sensitive data exposure. It then goes on to highlight five "top risks to mobile apps", which it lists as:

  1. Unsafe sensitive data storage
  2. Hardcode password/key
  3. Unauthorized dialing/SMS/payments
  4. Unsafe sensitive data in transmission
  5. Sensitive data leakage.

In this context "sensitive data" is identified as banking and payment system PINs, credit card numbers, online service passwords/keys and personal data.

The risks are based on Veracode's own Mobile App Top Ten [Malicious Functionality and Vulnerabilities], and other sources such as the OWASP Top Ten Mobile Risks and the ENISA Smartphones: Information Security Risks, Opportunities and Recommendations for Users. The five included in the infographic appear to be biased towards the impact on users (consumers, citizens, employees, etc) rather than the more common ranking of impact on organisations (company, educational/professional body, charity, etc). And I quite like that approach.

The infographic promotes and links to a document called Understanding The Risks of Mobile Applications which is rather short, and weaker in content than expected. It is free to download after providing contact information and a valid email address.

As an awareness tool, it would be good to have a higher-resolution version of the infographic to print out and paste up in developer meeting areas, or alternatively remake it into coasters (for coffee and/or beer) so that the messages reach, and stay on, developers' desks.

Posted on: 16 August 2013 at 07:46 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

27 July 2013

Data Disclosure Incident Database

The Verizon 2013 Data Breach Investigations Report provides a useful insight into a range of recorded data disclosure incidents.

Partial screen capture showing the data charting and drill down features available on the VERIS Community Database

For the first time, this data is now available to download or browse/mine interactively. The initial data set includes information from 1,200 incidents mainly during 2012 and 2013. Note these are heavily biased to the health sector.

The downloadable data are available free-of-charge without registration in JSON on GitHub such as this example. The data sets are recorded using the Vocabulary for Event Recording and Incident Sharing (VERIS). The interactive visualisation includes predefined views based on threat actors/motives (e.g. external, internal, partner), actions (e.g. hacking, malware, misuse, physical), assets affected (e.g. media, network, people, servers, user devices) and timeline/discovery.

As more data are added, especially from alternative sources, this will be a very valuable resource. See also the Data Loss DB, Breach Watch and the Web Hacking Incident Database (WHID).

Posted on: 27 July 2013 at 16:33 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

18 June 2013

Website Security Statistics Report 2013

WhiteHat Security in the United States has published another edition of its Website Security Statistics Report. This would seem to be the 13th edition, although the numbering label appears to have been dropped.

Partial image of one of the industry scorecards from the WhiteHat Website Security Statistics Report 2013

Like previous editions, the 2013 report contains a wealth of valuable information about the prevalence of web site security vulnerabilities, the time required to resolve them, the drivers for application security, accountabilities for system/data breaches, and what type of security activities are being undertaken in the software development processes to prevent vulnerabilities occurring in production releases.

Information leakage and cross-site scripting continue to be the most prevalent issues found. SQL injection is still notable, although its prevalence has reduced slightly over the last eight years, but it is certainly not yet extinct. The most common drivers for security are reported to be compliance and risk reduction.

But I am most excited about the industry-sector scorecards included for banking, financial services, healthcare, retail and technology industry. These summarise the report's data for each sector in an easily comprehensible manner. They are ideal templates for an organisation's own high-level web site security metrics dashboards.

As mentioned before, the definition of "serious vulnerabilities" in previous versions of this report included only those with a High, Critical or Urgent severity as defined by PCI DSS naming conventions, exploitation of which "could lead to server breach, user account take-over, data loss or compliance failure". The current edition seems to have changed this to "those in which an attacker could take control over all, or some part, of the website, compromise user accounts on the system, access sensitive data, violate compliance requirements, and possibly make headline news". So somewhat wider, but it would be good to know more about this definition.

Registration is required to download the report at the link provided above.

Posted on: 18 June 2013 at 18:17 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

23 April 2013

Data Disclosure Incidents in 2013

The Verizon 2013 Data Breach Investigations Report has been published drawing on data from 19 organisations including the European CyberCrime Center.

Payment cards have been a lock as the most oft-stolen data type since this study began, and 2012 was no different. They are the universal currency of the cybercrime marketplace.

The report includes information on 621 confirmed data breaches, the majority of which were financially motivated crime, followed by state-affiliated espionage. Although 93% of the breaches were attributable to outsiders, a significant proportion (14%) were attributable to insiders alone or insiders working with external agents. Attempts to intentionally access or harm information assets without authorisation by circumventing or thwarting logical security mechanisms (labelled "hacking" in the report" accounted for 52% of incidents. Of these, 22% related to the use of web applications.

The report can be downloaded free of charge without registration.

Posted on: 23 April 2013 at 06:46 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

09 January 2013

Website Information Leakers

I just came across KPMG's review of information leakage from corporate web sites, published in September.

Partial image of a figure from '' showing the top 10 countries vulnerable to potential attack via vulnerable server software

Hopefully nothing new, but the report sums up the typical state of configuration of many web sites. Most web sites leak information publicly which is useful to an attacker to craft their subsequent search for vulnerabilities. KPMG simply reviewed the public-facing resources on 2,000 companies, from a wide range of sectors, in the Forbes 2,000 list to identify many missing security basics.

Publish and be Damned, Cyber Vulnerability Index 2012 is a quick read; what can you expect to discover?

  • Large number of sensitive file locations and "hidden" functionality such as administrative interfaces (with banking the worst affected sector)
  • Exposure of sensitive information in millions of online forum and newsgroup postings (with software & services the worst sector)
  • Thousands of web servers with missing security patches or out-dated software (with Japan, Switzerland and Kazakhstan the worst countries, and Utilities the worst sector)

How well would your organisation do?

Posted on: 09 January 2013 at 08:41 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

27 December 2011

Guide to HTML5 Web Security

Further to my previous notes about HTML 5 security, a superb reference document was published earlier this month.

An extract from a page in Michael Schmidt's document HTML5 Web Security showing how HTML5 vulnerabilities and attacks are described and illustrated in diagrammatic form

Michael Schmidt (Compass Security) wrote his master's thesis about HTML5 security in May 2011 and has published an extract for everyone to access.

HTML5 Web Security describes issues, vulnerabilities, threat & attack scenarios and countermeasures across 80 pages including numerous well thought-out diagrams, and is backed up with detailed references and an appendix full of attack details.

The main sections are:

  • 2.2 Cross-origin resource sharing
  • 2.3 Web storage
  • 2.4 Offline web application
  • 2.5 Web messaging
  • 2.6 Custom scheme and content handlers
  • 2.7 Web sockets API
  • 2.8 Geolocation API
  • 2.9 Implicit relevant features of HTML5
    Web workers, new elements, attributes and CSS, Iframe sandboxing and server-sent events

If you are already developing HTML, or planning to, read this document as soon as possible and update your requirements documents, specifications, design documents, coding standards, and test plans to incorporate the knowledge.

The document would be worth buying if it were a book, but it has generously been made available publicly. Yes, I am still reading the document, and so far have only one very minor complaint — it would be good to have a content list. Maybe in version 1.1?

Posted on: 27 December 2011 at 09:07 hrs

Comments Comments (4) | Permalink | Send Send | Post to Twitter

12 August 2011

The Lush Topic of Security, Data Protection and PCI DSS

Do you remember Lush Cosmetics' rather public payment card data and personal data loss announced in January 2011? After 4 months of being compromised, the problem was recognised, customers were notified and the web site was shutdown.

Photograph of the entrance and display windows of a Lush Cosmetics shop in London

Lush had allowed people's data to be stolen via its own web site. We still await to hear what the fines and other penalties will be levied under the Payment Card Industry Security Standards Council (PCI SSC) Data Security Standard (DSS) if they are found to have been non-compliant at the time. However the UK's Information Commissioner's Office (ICO) became involved due to the related loss of 5,000 individual's personal data and confirmed in a press release on Wednesday this week that Lush Cosmetics had also breached the Data Protection Act 1998. Formed in 1994-1995, Lush Cosmetics has been a registered data controller (No. Z8189523) since late 2003.

As expected, no enforcement notice or monetary penalty has been issued, but Lush Cosmetics Limited's Managing Director, Mark Constantine, has signed an undertaking to ensure that personal data are processed in accordance with the seventh data protection principle concerning security, and in particular take the following measures to improve the protection of personal, and cardholder data:

  1. Appropriate technical and organisational measures are employed, and maintained, to prevent the unlawful processing of customer data, particularly within web based systems;
  2. Only the minimum amount of customer personal data is stored and that this is retained only for as long as a relevant business need exists;
  3. Computer systems storing customer personal data must be subject of regular penetration testing , with activity logs retained for an appropriate period of time and frequently interrogated for evidence of malicious attack;
  4. The processing of customer credit card data is conducted by a PCI compliant external service provider;
  5. The data controller shall implement such other security measures as it deems appropriate to ensure that personal data is protected against unauthorised and unlawful processing, accidental loss, destruction, and/or damage.

...as long as the Data Protection Act, or succeeding legislation are in force. So correctly a focus on Lush's web systems, including penetration testing of systems holding personal data. But also other appropriate security measures as necessary. Let's hope Lush aren't left thinking penetration testing is the answer — security needs to be considered at all stages of acquisition, development, deployment and operation.

And yes, that's right, the ICO is insisting on compliance with PCI DSS. The ICO made it clear in the press release of its expectations for PCI DSS compliance by other online retailers, that will otherwise risk enforcement action by the ICO.

This seems to be a valid approach, since fines, investigation costs, etc may still be levied for lack of PCI DSS compliance too. But I have some concerns with how Lush are portraying their squeaky-clean new status in the web site's terms and conditions:

Our website (www.lush.co.uk) is now operating under level one PCI-DSS compliance. If you don't have your geek-speak handbook around, that means Personal Card Industry - Data Security Standard. Level one is the highest level achievable; we don't want to take any risks with our customers' money or data. Although this doesn't guarantee that our website is impervious to hacking, it does guarantee that your card details are safe and secure. You can read more about PCI compliance here [missing link]

I'm not entirely sure that moving all cardholder data off-site to a PCI DSS compliant third party processor necessarily means much about the security of other data on the Lush web site and elsewhere at Lush, or much about systems outside the cardholder data environment. Is this just meaningless bubbly rhetoric to provide false assurance, or maybe Lush still does not understand what they are doing? Complying with regulatory and contractual mandates isn't the same as believing in "filling the world with perfume and in the right to make mistakes, lose everything and start again". Some of that "honest meaning" mentioned by Lush would be welcome here too.

Personally I think the PCI SSC should be a bit more strict about how their name can be used to endorse systems. Hey, clerkendweller.com meets PCI DSS compliance criteria too! There's no cardholder data to begin with...

Posted on: 12 August 2011 at 08:22 hrs

Comments Comments (2) | Permalink | Send Send | Post to Twitter

21 June 2011

Not Recommended

I had the chance to read a recent paper on the privacy risks of collaborative filtering. These are the types of systems which provide recommendations and suggestions based on other users' activity, such as products bought or looked at.

Partial view of the paper 'You Might Also Like:' Privacy Risks of Collaborative Filtering showing some of the mathematics included

The paper "You Might Also Like:" Privacy Risks of Collaborative Filtering by Joseph A. Calandrino, Ann Kilzer, Arvind Narayanan, Edward W. Felten and Vitaly Shmatikov is summarised on Joseph Calandrino's blog, but describes inference of individual transactions from the outputs of collaborative filtering systems, thus revealing information without a user's knowledge or consent.

The approach described in the paper does not require the creation of fake user accounts or enter purchases or ratings into the target systems, and it does not assume the target user's transactions are available in either an identifiable or anonymised form. Instead the algorithm monitors changes to the recommender systems over a period of time, which when combined with auxilliary information, can be used to infer some of the target user's previous transactions i.e. not to predict future events but to infer past events.

There is some fairly serious mathematics in the paper, but don't let that put you off reading the rest of the paper.

I wonder if this approach could be used to infer answers in personal knowledge question based password recovery functions?

Posted on: 21 June 2011 at 22:14 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

More Entries

Leakage : Web Security, Usability and Design
http://www.clerkendweller.com/leakage
ISO/IEC 18004:2006 QR code for http://clerkendweller.com

Page http://www.clerkendweller.com/leakage
Requested by 54.205.160.82 on Sunday, 20 April 2014 at 21:56 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use http://www.clerkendweller.com/page/terms
Privacy statement http://www.clerkendweller.com/page/privacy
© 2008-2014 clerkendweller.com