Enterprise 2.0 optimize

Security in the Web 2.0 Era

At the Gartner Symposium ITxpo 2008 in Sydney this week, Andrew Walls, the research director and security analyst at Gartner presented "Security in the Age of E-Commerce and Web 2.0".

At the Gartner Symposium ITxpo 2008 in Sydney this week, Andrew Walls, the research director and security analyst at Gartner presented "Security in the Age of E-Commerce and Web 2.0".

Anyone can be a developer

The simple and user-friendly nature of Web 2.0 technologies allows everyone to be a developer. While these technologies can encourage creativity in less tech-savvy employees, they can also jeopardise an enterprise's security and intellectual property.

Mashups allow individuals to construct their own websites and applications by using bits and pieces from different sources, but the quality of these creations can be questionable.

Additionally, social networks like Facebook can be culprits for sensitive information leaking out, as individuals can unintentionally reveal company secrets.

Power of individuals vs. power of enterprises

Web 2.0 is bringing increasing power to the individual, while at the same time taking away the power from the enterprise. This new power given to the individual can potentially be destructive for the enterprise. In addition to open source technologies like Apache and PHP, there are also free application security testing tools that let individuals discover application logic. If an individual was to misuse some of these technologies for an attack, they could easily get training and support from expert communities.

Openness and Collaboration

The open and collaborative nature of Web 2.0 tools like blogs and social networks can be risky, as individuals can unknowingly leak company information.

In a distributed environment it becomes very easy for individuals to inspect applications. By reverse engineering application code, individuals could potentially steal intellectual property.

Input

Cross-site scripting (XSS), Cross-site request forgery (XSRF) and SQL injections are the most common forms of attack and occur when user input isn't validated properly.

  • XSS: occurs when malicious code is inserted into a web page viewed by the user.
  • XSRF: as opposed to XSS, this type of attack takes advantage of the trust a particular website has for a user. Malicious and illegal commands are sent by a trusted user on a website.
  • SQL injection: malicious user input dynamically includes SQL statements which a database then executes.

Service-oriented architecture (SOA)

The shift from buying software from a vendor to buying services introduces new threats. Some of these are:

  • A distributed setting puts intellectual property at risk.
  • Web application security testing is restricted by the HTML-only interface and HTTP protocol.
  • Web Services Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI) could reveal information to hackers.

Making applications more secure

The purpose of security testing should be to reveal if an application's regular behaviour could be manipulated. Security procedures should be built into all the stages of the software life cycle (SLC). Making changes when the application is already developed could be costly, so the earlier security checking is performed, the better.

A number of tools are available to help companies achieve greater security.

Application security scanners DAST (dynamic) and SAST (static) should be built into the SLC to detect any vulnerabilities. Similarly, there are database and network scanners available to ensure database and network configurations and properties match the company policies.

Furthermore, adequate security should be built into the application itself. Firewall-like features that can detect attacks automatically and end such sessions, as well as code change detection tools, capable of self-repairing the application.

Best Application Development Practice

  1. All input going to browsers, servers and DBMS should be validated. XSS attacks can be prevented by validating all input before it is stored.
  2. Validate APIs – if third-parties have access to your APIs there is a risk of an attack and hence the returned data stream should be validated by using either whitelists or blacklists.
  3. Perform Software Composition Analysis – validate different IP components, security patches and releases.

Making Mashups Secure

Whether you are building your own mashup or your content is used in someone else's mashup, security threats exist. Full security on the server side, as well as having a whitelist of allowed actions can minimise the risk. All content should be validated, especially if it's viewable by clients.

According to Walls, Web 2.0 is here to stay and companies should be looking to implement security procedures rather than trying to block these technologies.

0 comments