20 February 2015


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

05 March 2013

Direct.uk Revisited

Do you remember Nominet's consultation regarding a new .uk domain name?

Over the coming months, this work will explore... Measures to improve security across the whole of the .uk namespace. This would include increased focus on encouraging the adoption of DNSSEC.

Nominet has produced an comprehensive summary of the consultation, a response analysis and an update which identifies the next steps being taken. There is much useful commentary on the proposed security aspects (Part II of the summary document, pp18-38) including:

  • Concern that enhanced security requirements for direct.uk would devalue existing .co.uk and .org.uk domain names
  • General consensus that making DNSSEC mandatory for new domains
  • Security features not comprehensive enough or rigorous enough
  • Malware monitoring is the responsibility of the registrant, not the registry
  • Malware monitoring may not be effective
  • The proposed trustmark could be misleading and be a large burden on registrars and registrants
  • Consider applying the proposed security features to existing third level domain names

The current proposal will not proceed and Nominet are reviewing alternatives. It notes there was widespread support for DNSSEC, but concern about the use of a trustmark, and a need to address security more widely than just a subset of new domain names.

Posted on: 05 March 2013 at 07:12 hrs

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

02 November 2012

Trust Direct.UK?

Nominet, the .uk internet registry, is consulting on a proposal to create unlimited second level domains (SLDs) using .uk (e.g. clerkendweller.uk instead of clerkendweller.co.uk).

The cover title from Nominet's 'Consultation on a New .uk Domain Name Service'

The consultation document steps through the proposals and asks for responses to a number of aspects:

  • Security
  • Verification of registrant contact data
  • Third level sub-domains
  • Reserved and protected names
  • Phased release and rights management
  • Channel to market
  • Existing second level domains
  • General views

The security section proposes malware monitoring and notification, a mandatory digital signature to prevent the hijacking of a domain name (DNSSEC), and discusses how the new SLDs could be used as a trust mark. This would appear to reflect ideas published by the House of Commons Science and Technology Committee for a software security kitemark (at least for web sites).

I welcome the idea of building trust, but the bar is far too low.

I do not believe use of DNSSEC, initial and subsequent periodic verification of contact details, combined with some sort of commercial malware monitoring and notification are sufficient indicators of the safety of a web site for users and their data. The spread of malware is not the only risk to web site users. Trust needs to consider availability, prevention of misuse, protection of the data from breaches in confidentiality, maintenance of accuracy, and compliance with various mandates (e.g. legislative, regulatory and contractual such as PCI DSS). The processes for web site development, configuration and operation can all affect users and their data. These issues require a balanced combination of administrative, technical and physical controls, and thus are are not simple and cannot be determined by an automated scan.

Whatever measures are finally agreed, they should apply to new registrations and renewals of third level domains (e.g. co.uk and org.uk), not just for the proposed SLDs. Otherwise lack of trust in the current domains will undermine trust in the others.

The consultation closes on 7th January 2013. Responses can be sent by post, email or using an online form.

Posted on: 02 November 2012 at 07:48 hrs

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

27 July 2012

Consultation on .UK Domain Renewal Expiry

Following recent work by on of Nominet's issue groups, a consultation has been published on the current policy that provides registrants with a 90 day expiry period in which to rectify a mistaken non-renewal.

The current policy indicates that the expiry period is for the benefit of the registrant, however the policy does not further elaborate as to what is intended by "benefit of the registrant."

The Domain Expiry Policy Consultation describes the current recommendations which are the result of feedback from an initial version in February. The Domain Expiry Policy Issue Group has asked for feedback to be sent by email to policy@nominet.org.uk by 3 September 2012. Feedback may be published anonymously.

Nominet has provided some statistical data on .UK renewals.

Posted on: 27 July 2012 at 07:27 hrs

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

22 March 2011

Legal Issues Relating to Suspension of .UK Domain Names

In December I mentioned Nominet had begun a policy review jointly with the UK-wide Serious Organised Crime Agency (SOCA), concerning Dealing with Domain Names Used in Connection with Criminal Activity.

Extract from a page of the background report 'Dealing with Domain Names Used in Connection with Criminal Activity - Background Report on Views Expressed' showing the large number of references

Since the announcement in December, Nominet has received over 200 written responses to the brief and also met with some groups to hear their views and concerns. Last month, Nominet invited stakeholders to take part in the issue group and the list of participants has now been announced. Their first meeting will be on the 4th April 2011.

To aid the discussion, Nominet appointed an independent expert to review the responses received to date, summarise them and also set the issue in the appropriate legal context. The background report has been published, and Nominet are seeking feedback on its completeness before the end of next week (31 March). Section 3 lists 13 suggested questions for the issue group to focus on.

The reason I mention this topic again, is because the 19-page background report is really an excellent read, and although not legal advice (of course!), it does give a good insight into some of the most important legal issues of operating a web site in the UK e.g. the diverse range of organisations in the supply chain (or "value chain" as it is referred to in the report), contractual obligations of registrars, extraterritorial effects, and useful reminders about the implications of the Digital Economy Act 2010 and the Terrorism Act 2000.

The report also includes good nuggets of information such has how various agencies interact with Nominet, and that Nominet has "locked" 2,667 domains to date. If you do just two things today, check domains are registered under your own organisation's name and ensure all the details provided to Nominet, and other registries, have been recorded accurately.

Update 24th March 2011: The link to the background report has been altered, following the discovery by Nominet of an error in the original text.

Posted on: 22 March 2011 at 08:13 hrs

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

02 July 2010

Web Site Security Basics for SMEs

Sometimes when I'm out socially and people ask what I do, the conversation progresses to concerns about their own web site. They may have a hobby site, run a micro-business or be a manager or director of a small and medium-sized enterprise (SME)—there's all sorts of great entrepreneurial activity going on.

It is very common for SMEs not to have much time or budget for information security, and the available information can be poor or inappropriate (ISSA-UK, under the guidance of their Director of Research David Lacey, is trying to improve this). But what can SMEs do about their web presence—and it is very unusual not to have a web site, whatever the size of business.

Photograph of a waste skip at the side of St John Street in Clerkenwell, London, UK, with the company's website address written boldly across it

Last week I was asked "Is using <company> okay for taking online payments?" and then "what else should I be doing?". Remember we are discussing protection of the SME's own web site, not protecting its employees from using other sites. If I had no information about the business or any existing web security issues, this is what I recommend checking and doing before anything else:

  • Obtain regular backup copies of all data that changes (e.g. databases, logs, uploaded files) and store these securely somewhere other than the host servers. This may typically be daily, but the frequency should be selected based on how often data changes and how much data the SME might be prepared to lose in the event of total server failure.
    • check backup data can read and restored periodically
    • don't forget to securely delete data from old backups when they are no longer required
  • Use a network firewall in front of the web site to limit public (unauthenticated user) access to those ports necessary to access the web site. If other services are required remotely, use the firewall to limit from where (e.g. IP addresses) these can be used.
    • keep a record of the firewall configuration up-to-date
    • limit who can make changes to the firewall
  • Ensure the host servers are fully patched (e.g. operating system, services, applications and supporting code), check all providers for software updates regularly and allow time for installing these.
    • remove or disable all unnecessary services and other software
    • delete old, unused and backup files from the host servers
  • Identify all accounts (log in credentials) that provide server access (not just normal web page access), such as used for transferring files, accessing administrative interfaces (e.g. CMS admin, database and server management/configuration control panels) and using remote desktop. Change the passwords. Keep a record of who has access and remove accounts that are no longer required and enable logging for all access using these accounts.
    • restrict what each account can do as much as possible
    • add restrictions to the use of these accounts (e.g. limit access by IP address, require written approval for use, keep account disabled by default)
  • Check that every agreement with third parties that are required to operate the web site are in the organisation's own name. These may include the registration of domain names, SSL certificates, hosting contracts, monitoring services, data feeds, affiliate marketing agreements and service providers such as for address look-up, credit checks and making online payments.
    • ensure the third parties have the organisation's official contact details, and not those of an employee or of the site's developers
    • make note of any renewal dates
  • Obtain a copy of everything required for the web site including scripts, static files, configuration settings, source code, account details and encryption keys. Keep this updated with changes as they are made.
    • verify who legally owns the source code, designs, database, photographs, etc.
    • check what other licences affect the web site (e.g. use of open source and proprietary software libraries, database use limitations).

Do what you can, when you can. Once those are done, then:

  • Verify the web site and all its components (e.g. web widgets and other third party code/content) does not include common web application vulnerabilities that can be exploited by attackers (e.g. SQL injection, cross-site scripting).
  • Check what obligations the organisation is under to protect business and other people's data such as the Data Protection Act, guidance from regulators, trade organisation rules, agreements with customers and other contracts (e.g. PCI DSS via the acquiring bank).
    • impose security standards and obligations on suppliers and partner organisations
    • keep an eye open for changes to business processes that affect data
  • Document (even just some short notes) the steps to rebuild the web site somewhere else, and to transfer all the data and business processes to the new site.
    • include configuration details and information about third-party services required
    • think about what else will need to be done if the web site is unavailable (does it matter, if so what exactly is important?)
  • Provide information to the web site's users how to help protect themselves and their data.
    • point them to relevant help such as from GetSafeOnline, CardWatch and Think U Know
    • provide easy methods for them to contact the organisation if they think there is a security or privacy problem
  • Monitor web site usage behaviour (e.g. click-through rate, session duration, shopping cart abandonment rate, conversion rate), performance (e.g. uptime, response times) and reputation (e.g. malware, phishing, suspicious applications, malicious links) to gather trend data and identify unusual activity.
    • web server logs are a start, but customised logging is better
    • use reputable online tools (some of which are free) to help.

That's just the basics. So, what would be next for an SME? If the web site is a significant sales/engagement channel, the organisation has multiple web sites, is in a more regulated sector or one that is targetted particularly by criminals (e.g. gaming, betting and financial), takes payments or does other electronic commerce, allows users to add their own content or processes data for someone else, the above is just the start. Those SMEs probably need to be more proactive.

This helps to protect the SME's business information, but also helps to protect the web site users and their information. After all, the users are existing and potential customers, clients and citizens.

Oh, the best response I had to someone when I was explaining my work: "You're an anti-hacker than?". Well, I suppose so, but it's not quite how I'd describe it.

Any comments or suggestions?

Posted on: 02 July 2010 at 08:18 hrs

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

18 May 2010

Email Address Formats

I've mentioned input validation and knowing your data previously, but a vulnerability came up in a recent project regarding email addresses. People make many different assumptions about what might be a valid email address format.

Photograph of part of a dot-matrix printer manual page showing the patterns for a range of ASCII characters

Don't! As this recent post states, go to the source i.e. RFC 3696. Inform your developers what types and formats they should allow for each input field and how mismatches should be handled—and verify these.

The e-commerce project I had been working on had some client-side validation for the email address field in a check-out registration form and this excluded lots of valid possibilities; it was using the regular expression "\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*". This might prevent some people becoming customers. Is this classified as a security vulnerability? Normally not, but it could affect data integrity and will affect the availability to some users. But, it is an indicator of possible data validation problems elsewhere. In fact we found the server-side validation for the same form data had different constraints to the client-side (browser) checks, and yes, plenty of other input validation problems. Security problems are often related to revenue problems.

And remember, it's not just Latin characters in domain names you need to worry about now. From last week, you might begin to see unexpected problems with users who have email accounts using domains related to the United Arab Emirates, Saudi Arabia, the Russian Federation and Egypt.

Posted on: 18 May 2010 at 09:30 hrs

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

08 December 2009

Your UK Web Site Can Be Shut Down

The use of particular top-level country domain names (e.g. .co.uk or .com) does add an element of trust to a visitor's impression of the site. On Thursday, the Metropolitan Police's Central e-Crime Unit (PCeU) closed 1,219 web sites selling fake designer goods.

Photograph of a painted wooden shop shutter with the word 'CLOSED' painted on it

Whilst I'm not suggesting that any readers of this blog were operating these sites, it is worth bearing in mind the sanctions that can be applied by the government for illegal trading. In this case, Nominet who maintain the register for .uk domains, were asked to take down the domain names to protect consumers and companies selling legitimate goods.

If the fake sites had not been on .co.uk domain, they may have been less able to con consumers into parting with their money and not receiving anything or buying counterfeit products, and the PCeU would have had a harder time taking action. Providing sufficient evidence has been gained, it appears these measures were appropriate in the circumstances.

Posted on: 08 December 2009 at 11:31 hrs

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

25 October 2009

From Whiteboard to Web Application

Sometimes finding all the web applications in an organisation can be the difficult part in trying to assess what risks exist.

Transport for London don't just have web sites and, I suspect, an intranet. They have been gradually moving from whiteboards for live underground travel news at tube stations:

Photograph of a transport information board at Great Portland Street station where the information is provided on magnetic tiles and by hand written wipe-dry pens

And now have electronic versions:

Photograph of a transport information board at Farringdon station where the information is provided on an LCD or plasma display

I don't know what technology is being used here, but other information boards have been seen to display web browser error messages leaking network information:

Photograph of a transport information display showing an 'address not found' error message from Firefox

But, what about elsewhere? I saw this on the live electronic advertisement boards at Bond Street station this weekend:

Photograph of an advertisement display board at Bond Street station elevators showing the words 'System Name' followed by a code and what looks like an IP address, written vertically up the portrait-orientated unit

Sorry it's a bit blurred, but I was going up the escalator at the time. Several, but not all the displays had their system names shown rather than an advertisement. It certainly looks like an IP address, but is there a web application inside? I've previously highlighted other information systems and displays that seem to be IP-enabled.

An investigation of your network, examining what is listening on which ports, and correlating this with the actual network traffic, might reveal more web applications than you thought.

Posted on: 25 October 2009 at 18:46 hrs

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

02 October 2009

Don't Mix and Match Those Domains

Many organisations like to do land grab with domain names by purchasing the same name with different generic top-level domains (e.g. .com, .net, .info), country code top-level domains (e.g. .uk, .es, .fr), and multiple second-level domains (e.g. .co.uk, .org.uk). Then of course there are mis-spellings, similar sounding words, brand names and trademarks.

Well all that leads to complexity, and it's not uncommon for many domains to be aliased to the same site in a way that any of them can be used to access the complete web site.

But it can get especially messy when SSL is enabled on some or all of the site too. Inevitably there end up being certificate warnings. Some organisations should know better. So when I was searching for providers of online and business privacy "seals",

Partial screen capture showing search engine results including SSL links to pages on the www.truste.org domain including https://www.truste.org/pvr.php?page=complaint

I was very surprised to click on the link to an SSL page which was reported as using an invalid certificate.

Partial screen capture showing the browser's warning message about the page's SSL certificate that says 'www.truste.org uses an invalid security certificate' and 'The certificate is only valid for *.truste.com'

Actually the certificate was fine, it just wasn't valid for the .ORG domain. Perhaps they had hoped the wildcard SSL certificate *.trust.com would somehow cater for *.truste.* - no.

Partial screen capture showing the browser's information about the certificate which says 'You are about to override how Firefox identifies this site - Legitimate banks, stores and other public sites will not ask you to do this' and 'Certificate belongs to a different site, which could indicate an identity theft'

Identity theft? Privacy? But apart from these configuration issues, isn't it just very confusing to have many different domains appearing in search engine results? How does this duplicate content affect their search engine ranking? Does it undermine trust in the brand? Should the SSL part of the site be indexed at all? Perhaps. Who makes these decisions? Is it the developers, the person who configured the site or does the business have a viewpoint?

I overheard a (loud) mobile telephone conversation this week in which a marketing manager* was apologising for a problem but they "did not know any of the technicalities". Mmmm, who is accountable? Make it your business to know.

[* Security and technology managers should also understand their organisation's business objectives.]

Posted on: 02 October 2009 at 07:56 hrs

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

13 November 2008

A Cry for Help Which Made Me Want to Cry

E-consultancy.com has many excellent online marketing and e-commerce resources, and I read the blogs and forums regularly. The following posting appeared on the forum a couple of days ago:

Partial screen capture of posting to the e-consultancy.com forums asking 'Can anyone tell me if there is a way of finding out who hosts your website? We  need to find out who is hosting our website any help would be appreciated.'

This cry for help worried me. Although the forum replies were helpful, it did make me wonder how many other web site owners have no idea where their web site is hosted.

If this is really the case here, it probably means the owner doesn't have all the resources to rebuild the site elsewhere and possibly is without back-ups of the data. And what about the intellectual property ownership? It's something which all developers should be discussing with their customers. My first suggestion would have been to contact the development company. A cursory examination of the source code reveals:

Partial screen capture of page source code with a commented out hyperlink to the designers Osmodus

This company even showcases the site:

Partial screen capture showing the Gluttonous Gardener web site featured on the Osmodus portfolio pages

Now, we have no idea of the background and cannot guess if there is anything amiss. But the site is a card payment enabled e-commerce site, and surely the owner has had to comply with the Payment Card Industry (PCI) Security Standards Council's Data Security Standard (DSS)? Knowing where your web site is hosted would be one of the earlier things to discover.

Let's hope it's sorted soon.

Posted on: 13 November 2008 at 14:52 hrs

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

More Entries

Domains : Application Security and Privacy
ISO/IEC 18004:2006 QR code for https://clerkendweller.uk

Requested by on Friday, 27 November 2015 at 04:31 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 https://www.clerkendweller.uk/page/terms
Privacy statement https://www.clerkendweller.uk/page/privacy
© 2008-2015 clerkendweller.uk