What you need to know before migrating procurement apps to the Web

Computerworld - Companies from all industries are moving their customer relationship management, supply chain and procurement applications from private electronic data interchange networks to the Internet to improve service and to save money and time. These applications can improve the efficiency of managing manufacturing, payroll, purchasing and personnel by more easily moving money and assets between corporations, their partners and customers.
But what if the off-the-shelf products your company purchased as Web-based business applications have security flaws that can be easily exploited by malicious hackers? What if within 30 days of going live on the Web, your company finds significant vulnerabilities in these applications that could expose its most valuable data to hacking threats?
What's more, the traditional security measures you've implemented, including operating system and network-layer security, don't protect against these types of attacks. Theft and manipulation of corporate and customer data can hurt the business, leading to legal action, loss of revenue and loss of confidence from customers and business partners.
A case example
A large manufacturing company discovered significant vulnerabilities during a security audit of its online procurement application, an off-the-shelf product from an enterprise resource planning software vendor. Tight schedules and opportunity costs made it impractical to hold the deployment until the vendor could issue security patches.
The procurement application is mission-critical for the company and is used by thousands of individuals worldwide, including suppliers, customers and internal groups. It provides access to some of the company's most valuable data, including inventory information, pricing, product availability and supplier contracts. The vulnerabilities in the application exposed the company to potential data theft by hackers seeking personal financial gain or insider information for corporate espionage.
The vulnerabilities identified included the following:

• Parameter tampering: Web applications often rely on hidden or fixed fields -- such as URL parameters or hidden values in forms -- to maintain information about the client session. In the case of the procurement application, a hacker could manipulate parameters in the critical business logic of the application, such as those used in the log-in forms, password-reset page and other transactional forms, in order to pass a malicious character string to the back-end infrastructure. In doing so, a hacker could force the application to respond with confidential information, including pricing data.


• Cross-site scripting: The application was also vulnerable to cross-site scripting attacks, which could be used by a hacker inside the corporate network to hijack the session of another user. For example, the hacker could embed an attack script within an order form and upload this to a site accessible by other users. Following this, any time a user submits the form the malicious code is executed, infecting the user's account with the attached payload (a backdoor attack) or sending log-in credentials over the Web to the attacker. The user remains unaware, since the transaction request is still submitted to the application.


• SQL injection deflection latency: As is often the case, SQL injection attacks were addressed in the application itself. Special characters, such as single quotes (which can preface a SQL injection attack), weren't allowed. So what was the issue? We simulated an attack by entering a single quote in a log-in name field and found that rejections took up to two minutes each. When running four of these "attack" instances simultaneously, CPU usage increased dramatically. It would be relatively easy for anyone to wage a denial-of-service attack on this application.