The dangers of third-party code for cloud security

Imperva announced a new report which examines the dangers of third-party code in cloud computing.

In December 2012, a hacker breached Yahoo! with an SQL injection attack that took advantage of a vulnerability in a third-party application that was provided on the Yahoo! Web site.

This attack highlights the risk that many Web applications face: Web applications may contain some sort of third-party code, such as APIs, that was not created by the developers.

“The weak link in the Yahoo! attack was not programmed by Yahoo! developers, nor was it even hosted on the Yahoo! Servers, and yet the company found itself breached as a result of third-party code,” said Amichai Shulman, CTO, Imperva. “The challenge presented by the Yahoo! breach is that Web-facing businesses should take responsibility to secure third-party code and cloud-based applications.”

Technically, security teams should:

  • Protect third-party Web applications against SQL injection and other Web attacks: Incorporate security into the software development life cycle, perform penetration tests and vulnerability assessments on the application, and deploy the application behind a Web Application Firewall (WAF).
  • Harden your system: When the application is promoted from development to production, the system configuration must be hardened to disable any irrelevant parts that may help the attacker. In the hardening process detailed error messages should be disabled, excessive file and directory permissions should be restricted, source code leftovers should be deleted, and so on.

From a business standpoint, executives should always assume third-party code – coming from partners, vendors, mergers and acquisitions – contains serious vulnerabilities.

Although our technical recommendations take precedence, we recommend:

  • Put in place legal requirements in a contract for what you will and will not accept from a security perspective.
  • Incorporate security due diligence for any merger or acquisition activity.
  • Require coding standards and security requirements in every specification between you and the third party.
  • Demand metric reports for security of the vendor’s code that are repeatable and verifiable.
  • Require that all security requirements are met prior to the first time the code is executed in your environment.
  • Require a comprehensive review of possible vulnerabilities resulting from new external services operating in conjunction with your current services.
  • Require a report specifying security issues and measures taken to address them for every task and deliverable from the vendor.

The complete report is available in PDF here.

Don't miss