• Use authentication measures which are appropriate to the data being accessed: for example, login and check account status using just a plain password, but to do financial operations,
re-authenticate using a one-time password token. See vulnerability [WEAK AUTHENTICATION]. • Use TLSSSL based encryption wherever sensitive data such as passwords and personal data are
transmitted. See vulnerability [LOW USE OF TLSSSL].
6.1.6 Developer IssuesBrowser Vendors
There already exists quite a large body of development best-practice and descriptions of common pitfalls so, rather than re-inventing the wheel, we would refer the reader to the following as
examples: The OWASP Guide to Building Secure Web Applications 84, Learn to Work Safely with Web 2.0 85, and Security Survival Tips for the Web 2.0 World 86. We do, however, recommend
some more general initiatives for mitigating risks arising from poor development:
• Develop and encourage secure development processes for Web 2.0: as in all areas of software development, recent experience has shown that code security can only improve by using a
comprehensive approach throughout the development process, eg, by training in security-by- design, threat modelling, code review and penetration testing.
• Provide built-in features for IDEs to facilitate secure development: development environments eg, Google Mashup Editor, Eclipse, CodeGear IDE, Komodo IDE used for creating Web 2.0
applications should incorporate defaults, code templates and hints which aid secure development. See vulnerability [DEVELOPMENT PROCESS ISSUES].
• Security features of APIs: security features eg, access control features and models should be built, by-design, into APIs eg, jQuery, script.aculo.us, dojo shipped for Web 2.0 applications.
See vulnerability [DEVELOPMENT PROCESS ISSUES]. • Anonymous strong authentication: strong authentication is traditionally opposed to anonymity
since it binds a particular identifier to a claim made about that identifier in a number of different contexts, thereby increasing the ability to trace the actions of a user. Also certificates used in
authentication contexts typically contain a fixed set of fields name, date of birth, ID number, etc, which are always disclosed in every authentication event, no matterwhat the actual needs of
the service. There are however privacy-preserving authentication technologies such as Credentica 87and Idemix 88 which offer both strong and privacy preserving authentication. Such
technologies offer strong authentication in combination with unlinkability between transactions and selective attribute disclosure. Very few services actually use such technology however and
considerable development effort, building on prototypes developed by projects such as PRIME 89, is needed in order to integrate them successfully into Web 2.0 applications. In particular,
effort is needed to make them useable and intelligible to users. See vulnerabilities [WEAK AUTHENTICATION, PRIVACY VIOLATIONS].
6.2 Concluding Remarks
Overall, Web 2.0 is a very positive social and technological development which has created many opportunities both for businesses and for interaction among private individuals. It supports the
open-source ethos encouraged by the European Union by providing access to knowledge regardless of location or socio-economic standing. It has provided greater efficiency through allowing browser
access to application features previously confined to the desktop and a wealth of previously undreamt of possibilities for social interaction.
Its rapid development has however, led to many security threats and vulnerabilities which have not yet been addressed. By the adoption of a comprehensive set of measures aimed at addressing these
vulnerabilities by governments, service-providers, standardisation bodies and developers, the threats presented by the current wave of Malware 2.0 and other Web 2.0 related problems can be
significantly reduced in order to realise the full benefits of this new technology.
Web 2.0 Security and Privacy
37
