Back to newsletter

Web 2.0's Thrills and Spills

How to stay secure in a brave new environment

by Barbara Morris, Editor, Federal Secure Software Advisory

Today's Web user -- whether a "digital native" born with a silver flash drive in one fist, or a "digital immigrant" having hard-won Web skills -- is probably handy with some aspect of Web 2.0. Since that term was coined in 2004, new uses of Internet technologies continue to introduce unique forms of collaboration and communication.

Nowadays, it seems that everybody is texting, uploading photos to Flickr, wiki-ing, blogging or just watching videos on YouTube. We live in a world of peer-to-peer communications, where workforce collaboration, online classrooms and video conferencing are becoming the norm. And here's the rub: All of these Web 2.0 uses by a multitasking, wired workforce make it harder to track the potential risks to organizations.

According to Deborah Snyder, chief information security officer (CISO) for the New York State Office of Temporary and Disability Assistance (OTDA), Web 2.0 applications aren't really new technologies, but new ways of using existing technologies -- changing the way the Web functions to meet what she refers to as the "voracious demands" of Web-savvy, younger users. They want to be mobile, have access to and share information instantaneously, as well as mix and match it to meet their needs. The versatility of Web 2.0 also supports many business needs and objectives.

Forrester Research's white paper, Web 2.0: Social Computing Dresses for Business, states that Web 2.0 offers "the ability to more efficiently generate, self-publish, and find information, plus share expertise in a way that's so much easier and cheaper than earlier knowledge management attempts." In addition, it harnesses the power of previously unexplored business models and collaborative processes.

New issues in the threat landscape

Snyder cautions that, while Web 2.0 offers an excellent and more interactive platform for the consumer, organizations must understand and be prepared to address associated risks, including:

• Web 2.0 tools may be susceptible to attacks. Web 2.0 applications and the tools used to create them can contain inherent vulnerabilities. The code that users create "on the fly" to publish, aggregate and share content isn't vetted through any traditional form of review or system development life cycle.

• Threats are hidden "under the covers." The nature of Web 2.0 programming mechanisms means there's a lot more happening on the client side compared to static sites of the past, where most of the workload was handled on the server side. Because Web 2.0 applications are more functionally interactive, they can present greater vulnerability to application layer attacks. Sites may also aggregate data from outside sources, which can be harder for organizations to manage and control.

• Open source code may have vulnerabilities. Open source code and reusable components can contain vulnerabilities. The cool applications users can use or import into MySpace or Facebook, for example, may contain inherent exploitable vulnerabilities.

• Developers may not have certain skills or adequate training. Developers may not be fully skilled and hardened in creating secure apps in Web 2.0. For example, Web-based technologies such as Google and AJAX do have inherent risks. Not all developers understand the security implications of asynchronous JavaScript and XML, and use may open up other attack vectors developers might not be aware of or test for. Hackers could gain access and execute common exploits such as SQL injection, cross-site scripting or cross-site request forgery.

Improving security

Organizations can use several general security principles to prepare for today's issues, as well as look down the road to upcoming risks. As Snyder says, "The epiphany is it's really the same risk management game and playbook, just a different day." She recommends the following proactive measures:

• Stick to the principle of "least privilege." Limit individual users' account permissions to the minimum required to perform their job functions. Clearly define and enforce user roles. Also, limit admin accounts.

• Validate input. Don't rely on client-side validation; mirror all checks and balances on the server side to prevent substitution or infusion of malicious code and database manipulation.

• Be mindful of session management issues. Proper session management controls are critical to prevent unintended exploit opportunities.

• Don't show your hand. Control the amount of information revealed in error code messages. Too much detail is generally not meaningful to users, and hackers could use it to further an attack. Use code references to help developers identify the underlying error.

Designing and building for security 

One of the first design considerations is building security into the system development life cycle. Snyder says that OTDA implemented an integrated, standards-based "Secure System Development Life Cycle (SSDLC) road map" that leverages the National Institute for Standards and Technology (NIST) security standards, and ensures security is properly considered at every phase. She adds, "No one really knew much about application security when we started ... We did a lot of talking about the threat landscape and the principles of how to create secure code, but to get the process to actually manifest itself, we had to step back, bring in training for our development workforce and acquire tools to automate burdensome processes, like code review and vulnerability assessment." 

Snyder believes that designing security into the application development process is much like building a house; you can't easily relocate the kitchen to the south side if your architectural blueprints show it on the north side and you've already laid the foundation, and installed plumbing and electric. You have to purposefully consider, plan and design applications with security built in properly from day one.

She offers the following guidelines to ensure that security is a primary focus in the design process:

• Ensure that developers are trained to code securely. They have to understand the importance of and buy into the work involved to detect and fix vulnerabilities early in development. Overall cost/effort will be less if developers design in secure controls and test apps to assure that they work.

• Think like a hacker. Developers create code that functions as required, while hackers find ways to make things function in unexpected, easily manipulated and, thus exploitable, ways.

• Use sound security practices and controls. Apply sound, security industry standards such as NIST 800-53, which reflects appropriate applications controls based on classification.

• Continuously consider and check for threats. Automated vulnerability scanning tools help reduce the testing burden and prioritize problems for resolution during development and quality assurance. Make rescanning a required component of change management cycles. You can't just "set it and forget it."

• Don't forget administrative controls. Ensure your business needs justify the use of Web 2.0 platforms and features. If you don't need something, don't engage the added risk. Update existing acceptable use and ethics policies, since user misbehavior often presents significant potential risk.

• Ensure proper oversight. Include administrative and automated content filtering and monitoring, access controls and audit logs review.

• Address accessibility compliance upfront. Validate that Web 2.0 applications meet accessibility compliance requirements, or you may have to retrofit or produce an alternative access method.

Barbara Morris is a freelance writer based in New York City.