Clerkendweller : Web Security, Usability and Design

User Tracking in the News

Tue, 07 Sep 2010 17:10:00 +0100

User tracking on web sites appears to be a growing concern amongst the public. The current What They Know campaign by the Wall Street Journal (WSJ) is making marketers techniques more widely known.

The mis-use of web cookies has received significant press coverage in the past, and now the mis-use of beacons (also known as web bugs) and Flash cookies (also known as Local Shared Objects or LSO cookies) is attracting attention. The WSJ examined popular sites and reported their findings online.

The value of personal data can be calculated in more than one way, is being debated and used for data protection business cases—marketers already know its value to them.

Marketers should be concerned that their own data collection and usage practices comply with legal and other requirements, and that these are described clearly to users in a comprehensible privacy notice. But if you have third-party content included within your pages, you also need to address those organisation's usage of the data they collect from your visitors. Third-party code may not just be from advertisers, but includes users analytics, embedded data feeds, video, photos and JavaScript libraries hosted elsewhere. For behavioural advertising purposes, check out the guidance from the IAB-UK.

Where possible try to ensure your web site's core functionality and design are unaffected if users choose not to accept content from other domains whilst viewing your pages.

Oh, and check your own site out with the Privacy Choice tool and ensure it is correct. Despite the name "privacy scan", it doesn't of course cover all the privacy aspects you need to take into account!

CAP Code Remit Extended Online

Fri, 03 Sep 2010 08:47:00 +0100

As mentioned previously, the Advertising Standards Authority is to extend its digit remit for consumer protection.

Advertisements and other marketing communications by or from companies, organisations or sole traders on their own websites, or in other non-paid-for space online under their control, that are directly connected with the supply or transfer of goods, services, opportunities and gifts, or which consist of direct solicitations of donations as part of their own fund-raising activities.

The announcement on Wednesday describes how the Committee of Advertising Practice (CAP) made the decision and published a guide to the new remit, exclusions and sanctions. The regulation covers advertisers' own marketing communications on their own websites and in other non-paid-for space online under their control (e.g. social networking sites).

Note that some user-generated content could fall under regulation—see section 3.9 for a description. Communications that do not constitute an advertisement or other marketing communication are excluded from the remit, as are marketing communications that promote causes or ideas, and anything already in list of content already excluded by the CAP Code (e.g. press releases, editorial content, corporate reports, natural listings on a search engine or a price comparison site).

CAP recommend all web site owners and agencies sign up to their free CAP Services to learn more about the code, its implications,ensure their web sites comply with the CAP code, and most importantly access to the free Copy Advice service. The remit will come into force on 1 March 2011.

New UK Advertising Codes were also published on Wednesday, and came into effect the same day.

HTTP Strict Transport Security

Tue, 31 Aug 2010 08:37:00 +0100

It's good to see different groups working together to improve security. This week another browser manufacturer announced future support for an initiative relating to Transport Layer Security (TLS, the successor to SSL).

HTTP Strict Transport Security (HSTS) describes a method for a web site to tell client browsers that they should only interact with it over secure transport, i.e. TLS Whilst there have been browser plugins which support this draft specification, support for HSTS was announced for v4 of Google Chrome in January, and last week for v4 of Mozilla Firefox. Hopefully Microsoft Internet Explorer 9 and ,a href="http://www.opera.com/">Opera will also adopt this.

Why is it important? Some attacks mean that TLS is vulnerable if there are redirects from non-TLS (e.g. http://www.example.com) to TLS (https://www.example.com) content. And if part, or all, of your web site is only meant to be accessed over SSL, HSTS should be implemented now, ready for mainstream adoption.

Further details are provided on the W3C page at Strict Transport Security (STS) and the draft IETF specification is at HTTP Strict Transport Security (HSTS).

Automated Attack Responses by Web Applications

Fri, 27 Aug 2010 08:52:00 +0100

I have been exploring further the possible response actions an application might make once it has detected a suspected or actual attack, as a contribution to the OWASP AppSensor project. There is now a draft document describing response actions, discussed and announced last week.

The draft document AppSensor - Response Actions describes thirteen response actions, provides examples of each, and discusses how they might be categorised in order to help with selection of appropriate responses.

It is still a working document. If you have any suggestions or comments on the draft document, please send them to the AppSensor project's mailing list, or perhaps add them below. In particular, I'd like to discuss whether there are any other responses which aren't covered by the ones already included.

There is additional background information and links relating to web application intrusion detection and the OWASP AppSensor project in my posts about presentations in Newcastle and London, but I hope to present again later in the year.

E-Commerce Due Diligence

Tue, 24 Aug 2010 08:27:00 +0100

Investment decisions for loans, mergers & acquisitions in primarily online businesses need just as much care as investing in more conventional businesses.

This month I contributed to the Autumn 2010 newsletter of DeVere & Co, risk management, fraud and asset recovery specialists, with an article about Ecommerce Due Diligence. In the article I discuss some of the specific issues relating to due diligence of online/e-commerce websites and applications including intellectual property, third parties, sensitive data, security operations and customers.

E-commerce sites often link many different systems and it is necessary to identify the relationships, boundaries, agreements and assumptions. Asset ownership is not always as clear-cut as expected. Let the buyer beware!

Avoiding Popular Passwords

Fri, 20 Aug 2010 07:00:00 +0100

A few weeks ago I mentioned two new research papers about the use of passwords on website. Another new paper from Microsoft Research and Harvard University discusses how to avoid, and protect web sites from, users selecting popular passwords.

The paper Popularity is Everything: A New Approach to Protecting Passwords from Statistical-Guessing Attacks describes online and offline threats and defences against the sue of common popular passwords.

Password implementation policies can be guided by legacy approaches and various standards, but as mentioned previously, economics plays a large part too. Following a much publicised successful brute force against Twitter accounts, the company increased its password requirements. But rather than forcing passwords to be more complex, they instead took the decision to prevent the use of 370 common passwords. Whilst the list is culturally-biased, due to other breaches, there is similar data from other sites (e.g. here and here). But how does banning popular passwords help, and if the lists of common passwords are known, does this matter?

Firstly I'll mention here a couple of typical online tools for determining password complexity:

Password meter providing an indication of complexity
Hammer of God providing an estimate of how long it would take to obtain the password using a brute force attack

Don't put your real passwords into these sites or any other checkers! But these types of tools do not take into account popularity (e.g. '123456') or common manipulations (e.g. is 'P@ssword' really that much more secure than 'password'?). If attackers try popular passwords first (i.e. a dictionary attack), the time to break into a user's account may be much shorter.

The research paper, which does include some mathematics, suggests that simple passwords should be allowed providing they are not subject to statistical guessing attacks and proposes attack detection methods.

Good reading and inspiration for password-based authentication systems. I'm off to the station now, to get a train to Newcastle which was cancelled last night.

Software Licensing

Thu, 19 Aug 2010 20:08:00 +0100

Software licensing may not be high on your agenda once a web site is operational. But software licences are an important part of ensuring your web site does not infringe any laws, regulations and contracts.

From 15:30 hrs today, train services from a number of operating companies including East Coast, First Capital Connect and Grand Central are being affected by a line-side fire involving acetylene cylinders near Grantham. This has led to cancellations and delays. But curiously an hour ago, the East Coast web site was showing something a little unexpected—only the words "LicenseException: License has expired." were being displayed:

Ooops. It is slightly odd that the web site issue is occurring at the same time as the fire—I wonder if it is due to a licence limit being reached caused by high demand from customers checking the status of their trains, or trying to make alternative arrangements. The wording "expiry" suggests it is simply time related, but it does seem a bit of a coincidence.

Doing a quick search for this error message suggests many other web sites have sent this response in the content whilst being indexed:

So that seems unexpectedly common. Interestingly, some of the sites seem to be development or staging sites (e.g. using just an IP address, or using a "staging." sub-domain). These might well have been using temporary licences, but why are search engines allowed access at all, and even if they are, why isn't the robots exclusion standard for compliant crawlers being used?

Apart from the legal aspects, commercial software licences need to be acquired to allow for the total number of installations, processors, usage (e.g. bandwidth) and concurrent users (however the licence is defined) for:

peak stress loads allowed to reach the web, application and database servers
supporting systems
development, testing, staging and production environments
clusterering, failover and disaster recovery.

Licensing of all components and third-party services (e.g. data providers, hosting) also need to be considered. Don't just cross your fingers and hope for the best! All types of licence, commercial or otherwise, need to comply fully with their terms (e.g. non-commercial use, one licence per server). Check what happens when licences expire or if limits are exceeded. The situation might occur when most eyes are looking at your organisation.

A lesser related issue is that your own site may be masking the server type quite well, but an error message like this can give the game away. Even if the message doesn't state the type of web server and operating system, another web site with the same message may provide the answer. This can help a malicious user who is probing the site for vulnerabilities.

Shortly afterwards, the normal East Coast Trains web site had returned; much sooner than you would expect if it needed a new licence agreed, purchased and installed. I'm still wondering if it was too many simultaneous users.

I'm hoping the fire is sorted soon so I can travel tomorrow morning, instead of this evening as originally planned.

Application Security Logging

Tue, 17 Aug 2010 11:22:00 +0100

I have been meaning to write again about web application security logging, but luckily read a paper last week which provides excellent guidance.

How to Do Application Logging Right is the best guidance I have come across to date. Co-written by Anton Chuvakin and Gunnar Peterson for the IEEE Security & Privacy Journal, the paper describes the problems with typical logging systems, what events need logging, and for those, what to include and exclude. They have also provided some broader guidance on log management and protection.

Previously, the most notable application security logging guidance existed buried rather deeply in the documentation for OWASP's ESAPI Java edition, the OWASP Logging Project, and more general guidance in NIST's SP 800-92 Guide to Computer Security Log Management.

If you read those in conjunction with the new paper, and perhaps Chuvakin's and Peterson's own comments, you'll be well up to speed.

The content of the "module", "object" and "action" fields will be dependent upon the degree of granularity required and how much additional event information is collected as additional details (e.g. stack trace, request headers, response body). I believe a transaction ID should always be included so that all events for a single request/response can be more easily correlated—this has a request scope rather than the session scope of a username/id. If I might suggest some other additional items for "what to include", I would also consider:

host address (e.g. host name and domain, or server IPv4 or IPv6 address) which is useful if clustering is being used, or to confirm logs are from live rather than staging systems
service (e.g. name, port and protocol)
full actual entry point URL (protocol, full domain, port, path and further parameters)
canonicalised entry point URL
HTTP method (for web applications)
responses seen by the user and/or taken by the application (e.g. status code, custom text messages, session termination, administrator alerts)
analytical confidence in the event detection (low, medium, high or a numeric value).

Full request headers and possibly the response body may be worth collecting for some events. But ensure these are sanitised for sensitive input such as passwords, session cookies or credit card numbers.

I would also tend to use a severity scale (0=emergency, 1=alert, ..., 7=debug) rather than the suggested "priority" field, for consistency with syslog protocol. But the paper's authors note that whatever scale is used, it will be different for each organisation due to their own priorities and views on risk.

You may also want to consider how the integrity of the logged information can be determined.

Whatever you log, bear in mind you probably want it to be relatively human-readable, but also done in a way you can share the information with other systems. For the moment, consider Common Event Format (CEF). But Common Event Expression (CEE) is an ongoing collaborative effort to develop an event interoperability format summarised in a presentation, and in more detail in a white paper. The CEE web site includes a description of alternative approaches for sharing data from event producers.

See also my previous web application logging related posts How Much Logging, Monitoring and Alerting?, Security Logging Requirements, Testing the Audit Trail, Don't Stop the Attack (Too Soon), and Application Log Management and Analysis.

Happy application logging!

PCI DSS and PA-DSS Standards Changes

Fri, 13 Aug 2010 08:36:00 +0100

PCI DSS and PA-DSS standards changes have been pre-announced by the Payment Card Industry Security Standards Council (PCI SCC).

Yesterday's announcement, which also includes notice of changes to PIN Transaction Security (PTS) requirements, provides a summary of the upcoming changes to v2.0 of PCI DSS and PA-DSS due in October 2010. Apart from increased alignment between the standards, the upcoming changes are meant to provide clarifications, additional guidance, new requirements and provide ways to improve organisations' flexibility to implement controls using a risk-based approach. There is also mention of a more forward-looking approach with guidance on managing evolving threats.

The indication that a risk-based approach is to be recommended for assessing vulnerabilities is a welcome change. This of course needs to be undertaken with a real regard of the risks to the business and its customers, clients and citizens, not just the data itself. The references to additional sources of good coding standards and vulnerabilities is encouraging.

The new standards are expected to be published on 28 October 2010 and will come into force on 1 January 2011. This will be quite a tight deadline for many operators to ensure they continue in compliance. The press release also includes details of upcoming meetings and webinars where additional information will be provided by the PCI SSC.

Phishing and Pharming Protection - Theory and Reality

Tue, 10 Aug 2010 08:45:00 +0100

The UK Centre for the Protection of National Infrastructure (CPNI) have published new guidance on understanding and managing the risks from phishing and pharming.

Whilst most readers of this blog won't work on projects considered part of the national infrastructure, that doesn't mean you should ignore good, free advice.

The CPNI document discusses the threats and impacts (on employees, customers, clients and citizens), the modes of attack and possible countermeasures. I'm pleased to see that countermeasures to reduce the likelihood of successful attacks include both technical and cultural measures. Measures to mitigate the effects of successful attacks are also discussed.

Although some of the document is necessarily technical in places, the case studies in Appendix C should make sense to everyone. Remember, this is about business risk, not technical risk. The "I don't understand technical things" argument does not stand up.

Of course, assessing and implementing information security policies and controls is hardly ever simple or quick. But with the government's aim to reduce the number of different web sites this process may be a little easier. It's good to see such guidance, especially when the Central Office of Information (COI) has to date avoided the subject of security in its own web standards and guidelines. In view of the perception that the government isn't keeping up with threats (for example see the response to the petition to upgrade away from Internet Explorer 6), how are the CPNI phishing and pharming countermeasures being implemented by the government?

Knowledge about the degree to which the cultural countermeasures have been adopted within the government sector cannot be adequately measured from outside, and it would be good to see these included in work performed by the National Audit Office. Similarly most of the technical countermeasures would require privileged access to government networks (and permission!). However "use of SSL and TLS" and "signing of digital communications" should be easily observable, without doing any testing, from the outside world.

These two measures have security benefits beyond protection against phishing and pharming. They can assist citizens wanting to verify the identity of, and rely on the integrity of the information they see on what looks like a government web site, or receive in an official-looking email or other form of correspondence, perhaps during a national emergency. These types of event can attract themed phishing attacks for example. I haven't received any official government electronic communications recently apart from reminders from HMRC about tax deadlines and the like, so can't comment on how the sender and data integrity is verified. The tax reminders don't contain any sensitive data, and occur when there are known forthcoming business events or relate to actions undertaken by myself, so correctly don't need the same degree of verification.

But anyone can visit a web site, so what about those? Well, the CPNI web site appears to also be available over SSL/TLS as we'd expect. But, looking at https://www.direct.gov.uk using SSL (now more correctly called transport layer security, TLS) in the Chrome web browser, I was a bit surprised to see:

and this is the same for the prime minister's web site at https://www.number10.gov.uk/. Another possible primary governmental address is https://www.hmg.gov.uk which gives:

Maybe these have been deemed to be acceptable risks. But let's hope the other recommended countermeasures have been implemented.

WCAG 2.0 Coming to More Commercial Websites Soon

Mon, 09 Aug 2010 18:31:00 +0100

Early last year I mentioned the security implications of the Web Content Accessibility Guidelines 2.0 and the scope for accessibility testing. I also spoke about whether an accessible web application be secure at the OWASP AppSec EU09 conference.

At that time, I found it fairly difficult to identify many web sites that were making WCAG 2.0 conformance claims.

The US Department of Justice is now seeking comments on proposed rule changes to the Americans with Disabilities Act that might make compliance to Level AA of WCAG 2.0 more widely mandated. A full analysis of the legal implications and timescales are presented on the Outlaw web site. As we see increased take-up in the US, it's likely similar levels of compliance will be required elsewhere.

In my conference presentation, I discussed how some security vulnerabilities could occur if WCAG 2.0 is implemented poorly.

E-Consumer Protection Consultation

Fri, 06 Aug 2010 09:02:00 +0100

The UK's Office of Fair Trading (OFT) promotes and protects consumers' interests by ensuring markets work well, and that businesses act fairly and competitively. The government has asked the OFT to develop a longer term national strategy for consumer protection and enforcement on the internet. The strategy is intended to promote a safe and vibrant internet market.

As part of this strategy development, the OFT has launched a consultation on E-consumer Protection. The objectives are to improve the effectiveness of online markets and increase the level of consumer trust, so that consumers have a real option to use the internet for transactions, as equally as any other channel. The aim is also to ensure that enforcement of consumer protection online is as good as anywhere else in the world.

The main consultation document outlines some useful statistics about the UK internet economy using data from the European Commission's Consumer Markets Scoreboard 2010, the OECD and the OFT's Attitudes to Online Markets (publication due shortly). For example, 71% of the UK's retailers use e-commerce/internet sales channel for retail, and internet/online accounted for 9.5% of UK retail trade (£38 billion) in 2009. Apparently UK consumers have a high level of trust in UK sellers/providers' protection of their consumer rights and that they are adequately protected. However, it is not all good news as almost 20% of UK internet users are not transacting online, with a third of these stating concerns about the security of their personal and financial information as the reason. Overall, two-thirds of all internet users are worried about unauthorised access to their personal information. There are also concerns about being conned by companies online. The consultation document outlines how consumers may be becoming complacent about security but that they lack awareness of issues such as mis-use of cookies and behavioural advertising.

The OFT suggests these problems reduce confidence, lead to lower levels of demand, and consequently lower levels of supply. Households can miss out on potential savings and this is especially problematic for low income households (LIH). The consultation document proposes that agencies should work together to empower consumers, promote business compliance and develop effective enforcement. It proposes a number of high-level actions under the themes of consumer education, tool provision and hardening, business information, cooperation and deterrence, and enforcement capability building, coordination and leveraging intelligence.

The outcome of this consultation will have a large impact on organisations in the business-to-consumer (B2C) sector (there is also some discussion of whether C2C should also be addressed). If you are an online retailer, perhaps get in touch with your trade organisation and ask them whether they are responding, or do so yourself.

There are five general response questions, and further more-detailed questions about the high-level actions and monitoring proposed. Responses can be submitted online, by email and by post. The consultation period closes on 13th October 2010.

Real World Enterprise Application Security Programmes

Tue, 03 Aug 2010 09:00:00 +0100

This year I have mentioned web application security programmes, how software vulnerability testing recommended risk-based, application security programmes and generalised results from a survey about web application security programs.

But what are enterprises doing in real life and what are the issues? During the second day of OWASP AppSec Research 2010, Michael Craigue of Dell presented on Secure Application Development for the Enterprise: Practical, Real-World Tips. Although I missed it, people who did attend this track were enthusiastic about it and the video recording has now been published. I watched it last weekend.

Michael described Dell's 10-strong Global Information Security Services group and how it works with 3,000-5,000 developers in internal teams and how their appsec work is built on a published and maintained secure application development standard. Some of the problems encountered at Dell were platform diversity, security expert retention, the need to develop self-help documentation for the low and medium risk projects, lack of good metrics around security awareness training, high overhead of conventional threat modelling and the need to build security into the development lifecyle slowly, and in a business-focused manner.

At Dell, the project risk is calculated from ten factors including data classification, compliance requirements, whether it is externally facing, and the security knowledge of the development team. Interestingly, in the final questions from the audience, Michael mentioned Dell are using Open SAMM to identify gaps, measure how well their security programme is performing and to focus improvement efforts. Even projects that the group does not get involved with directly, are subject to quality checks and audit such as using Control Self Assessments (CSAs), which look for the artifacts required in the self-help documentation, even for low-risk applications.

There is another description of how software assurance practices at Ford in 2009, and recently published on US DHS's best practices web site Build Security In. The Ford programme is quite different. Every application security programme is unique because every organisation's culture, application and acceptance of risk is different.

What is yours like?

Economics of Website Users' Passwords

Fri, 30 Jul 2010 08:45:00 +0100

Two great papers on web site password security were published this month. We are swamped with passwords and every daily activity is increasingly linked with an online version, which requires users to register to obtain some additional benefits. Every organisation, resource, activity and event encourages us to visit their own website and sign-up.

Firstly, in Where Do [Password] Security Policies Come From?, Dinei Florêncio and Cormac Herley of Microsoft Research discuss the password policies of 75 different web sites, in an effort to determine password strength requirements with other aspects such as size of site, assets protected, number of users and frequency of attacks.

The authors' findings suggest that none of these are the key factors, and in fact some of the largest sites, most attacked and with higher-value assets have the weakest password policies. The authors suggest stronger policies exist where organisations are more insulated from the consequences of poor usability, whereas online retailers and sites that rely on advertising revenues have to compete rigorously for users and traffic. The paper also discusses how strong passwords need to be, and how this is affected also by what attack methods you are considering (e.g. online vs. offline brute-force), and whether other security controls are implemented (e.g. account lock-out).

This idea of considering the whole password environment is taken further in The Password Thicket: Technical and Market Failures in Human Authentication on the Web by Joseph Bonneau and Sören Preibusch at the Cambridge University Computing Laboratory, and presented at this year's Economics of Information Security (WEIS 2010). Their study included 150 web sites looking at password implementations. the study looked more broadly at the protective measures used— not just complexity requirements—but whether these were applied consistently across the site's functionality (e.g. registration/enrolment, log-in/authentication, password change, password reset/recovery, log-out), encryption during transmission, storage of passwords in clear text, inclusion of passwords in emails, as well as protection from brute-force attacks.

The authors found that stricter security in one area was often undermined by weaknesses in another, suggesting that a lack of standards is harming security. The paper also discusses economic interpretations, such as how deploying passwords might be being used to justify collection of marketing data, and how password insecurity can be a negative externality.

When is a Vulnerability not a Vulnerability?

Tue, 27 Jul 2010 09:29:00 +0100

Until this week, I had thought this question would be answered by checking the vulnerability could be exploited and by determining whether there was any technical or business impact.

But I have just finished reading the Summer 2010 edition of Information Security Now, the quarterly magazine of the BCS Security Forum, incorporating the Information Security Specialist Group. One of the articles forced me to stop and think.

The article titled "Attack Spotting" describes the motivation for modern attackers and in particular attacks on application software. But the author introduces the idea of "non-vulnerability attacks". Just what might they be?

Non-vulnerability based threats aim to exploit weaknesses in server applications that cannot be defined as vulnerabilities.

I was even more confused. I thought a vulnerability was any weakness that could be exploited by a threat (and a similar definition). The article's author goes on to describe that in "traditional vulnerability-based attacks", there is always the possibility of creating a signature to block the attack or of developing a patch for the application. In "non-vulnerability-based attacks" the author says there is no malicious payload and therefore it is not possible to create an attack signature or patch. The author helpfully provides three examples of non-vulnerability attacks:

Brute force attack on authentication
Web application vulnerability scanning
Service flooding which exhaust server resources

No, no, no! These are all attacks against real vulnerabilities. These three are listed in Common Weakness Enumeration (CWE) (e.g. CWE-307, CWE-200 and CWE-410) and real examples are listed in Common Vulnerabilities and Exposures (CVE). The examples also fall into categories in the Web Application Security Consortium 's Threat Classification.

These attacks go unnoticed by existing protection technologies and can result in information theft, fraud activities and service disruption.

I have to disagree that these attack methods are new, and that they are not being detected. I may have misunderstood the article, but I believe there is plenty of guidance on building applications securely, security verification and for testing for these types of flaws. I also disagree with the article author's suggestion that the answer lies with expert systems to perform network behavioural analysis (NBA). Why bother? The application already knows right from wrong and doesn't need to guess. Implement application-based intrusion detection and prevention, on top of secure code, and benefit from very low false positives. At least, that's my view.

So, perhaps if it depends on your viewpoint. Maybe some traditional security folk see this other stuff as black magic? I hope not.