After arriving in Dublin last night, I walked to Trinity College this morning and had a little time for a coffee and to greet people I knew before we moved into the lecture theatre.

Following the welcome to OWASP Ireland 2010 by Eoin Keary, Fabio Cerullo & Rahim Jina of the OWASP Ireland Board, John Viega delivered a thought-provoking keynote speech on "Application Security in the Real World". John described real-world problems and approaches to application security need to prove their value. He described seven practices: awareness & training, assessments & audits, development & Q&A, vulnerability response, operational security, compliance and security metrics which, when applied appropriately can demonstrate a return on investment.

OWASP Board members Eoin Keary & Dinis Cruz provided an overview of OWASP's current status, its activities including many of its projects and of the global committees. They described how OWASP's mission "is to make application security VISIBLE for buyers and INVISIBLE for developers". Samy Kamkar was given a brief slot to describe how cross site scripting (XSS) can be used against user's routers to eventually gain the MAC address and ultimately a user's geolocation using Google data.

After a short break and opportunity to look at the sponsor booths, the conference split into two streams for the rest of the morning. Fred Donovan spoke on the topic of "Counter Intelligence as a Defense", describing how gathering information and taking approved action can help identify, assess and potentially neutralise threats to an organisation's ability to conduct business, and to enhance the protection of corporate assets and customer data. He also described sources of information including web application firewalls (WAFs), server logs, application logs, the media, list servers, MITRE, honeypots and from the source of the threat itself. some of the impediments and do's and dont's in this pro-active approach.

Ryan Berg gave a lively and fast-paced description on the "Path to a Secure Application". He described what isn't working, and the need to mitigate the damage that attackers can do, rather than assuming you can keep them outside your network, He provided numerous examples of how security can be built into to all stages of the software development process, but made the point that organisations should make efforts to improve their existing application development processes, rather than creating new ones.

Dan Cornell described how Android and iPhone smartphone applications are coded, deployed and, how and when the source code can be reverse engineered. He presented an example Android application and some tools to demonstrate how embedded URLs, file paths and host names can be extracted to help determine its workings. He recommended that, like other applications, smartphone applications should undergo threat modelling, care should be taken on what information is stored and where, and to be careful when consuming any third-party services, and ensure that enterprise web services are approved and deployed securely.

After lunch which was held in the beautiful Dining Hall of Trinity College Dublin, Professor Fred Piper (Royal Holloway College) presented the second keynote on "The changing face of cryptography". Prof Piper described that people do not need to attack algorithms when they can attack the implementation or cryptographic system instead. He provided an engaging and personable talk about algorithms, implementation weaknesses, real-life cryptography and the related political and social issues, clearly demonstrating his wide and deep knowledge.

Tyler Shields' presentation "Application Security Scoreboard in the Sky" described the results from Veracode's State of Software Security, which I have discussed before but is worth remembering as a good source of information when building business cases for secure development processes. The first volume had examined the differences between open source, commercial and out-sourced software. The second volume is due to be released in the next fortnight.

Rory Alsop & Rory McCune (co-chairs of OWASP Scotland) "The 'Real' Application Security Pentest." described why penetration test companies and purchasers of their services need to understand the requirements clearly and to make best use of the budget. They described that penetration testing is increasingly being used but there are inconsistencies in how it is undertaken and customers don't always receive what they want. The speakers described common myths and what buyers should do.

Vinay Bansal and Martin Nystrom jointly presented Cisco's experiences of "How to Defend Fragile Web Applications". Cisco know they are constant attack on their perimeter, but they have to concentrate their resources on defending DMZ & internal systems and minimising the damage from compromises. Cisco use architectural assessments, developer training, secure coding techniques, verification practices and more recently using web application firewalls (WAFs) in a reverse proxy mode using Apache httpd, ModSecurity and ModProxy. They described the problems and benefits of using WAFs in front of Cisco's tens of thousands of applications, and how they are trialling using the WAFs for virtual patching, where the applications cannot be modified.

The final keynote "Hackers and Hollywood: The Implications of the Popular Media Representation of Computer Hacking" was presented by Damian Gordon (School of Computing, Dublin Institute of Technology). Damian gave a light-hearted look at "Hackers and Hollywood: The Implications of the Popular Media Representation of Computer Hacking". He has researched whether or not movies accurately portray hackers and the implications of that portrayal, based on filtering 200 potential movies down to 50 clearly relating to computer hackers and not just cyberpunk, sci-fi or where hacking is only a peripheral activity. The conclusion? Movies are doing quite well but are missing out on some hacking features such as denial of service, phishing, organisation identuty theft and e-harassment of employees. Maybe next year?

Congratulations for a very successful and informative day to all the organisers, helpers and speakers. A little late, but off to the social event...

My company recently received a leaflet from (HMRC) with an invitation to attend one of their EmployerTalk seminars about payroll and tax including pay as you earn (PAYE). On the way from my hand to the recycling bin, something caught my eye:

Character set encoding problems are very common in web sites and web applications, but it is quite unusual to see this type of thing in print. I suppose the ñ character is perhaps meant to be a dash or tilde of some sort, and some sequence of conversion processes from design to print has changed it into the ñ. Perhaps there was a Mac using Mac OS Roman somewhere in the chain.

Transmitting and display of text in web systems suffers the same manner. Begin by agreeing what character sets will be used for the database application and rendered HTML, and then stick to them. Make sure the character set is defined in the application's configuration and defined as a header with every HTML response.

Oh, and HMRC repeated the mistake further into the leaflet too; so there's a problem with proof reading (testing) too!

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.

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).
  • use resources such as the OWASP Top Ten and WASC Threat Classification
  • build security requirements into future developments
• 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?

Input validation and output encoding are key aspects of web application security. This morning I've just been using a data search on a website and came across this when no results were found:

I imagine "escape(escape())" is some attempt at preventing cross-site scripting (XSS), but implemented correctly. Interestingly, when search results are found there are several "-->" appearing. Another indicator of output encoding problems.

It doesn't have to be difficult - read the OWASP XSS Prevention Cheat Sheet.