running on a Web server, and interacting with flat files instead of databases.
The systems were heterogeneous; that is, each component was distinct and separate.
As Web technologies matured, vendors such as Microsoft and Sun Microsystems came up
with homogeneous e- commerce framework technologies and other vendors joined the race.
Web storefront technologies began to feature multilayered applications involving
middleware and middle-tier binary components such as ISAPI filters and Java beans.
Integration with databases allowed applications to migrate from flat files to relational
databases RDBMS, such as MS-SQL server, Oracle, and MySQL. Similarly, for storefronts,
technologies such as Dynamic HTML DHTML and Flash started gaining popularity,
because they made the shopping experience both visually appealing and pleasant.
However, each stage of evolution brought new vulnerabilities and new dimensions of attack.
Incidents of robberies from electronic storefronts rose dramatically, and stealing
information and money on the Web became intolerable, desperately needing technical attention.
Where do hackers find loopholes in e-business systems? Whenever a business decides to establish
or upgrade an electronic presence, things don't happen all at once. At one stage or another,
different technologies are integrated with existing systems. Businesses thrive on evolution,
not software. Mixing and matching various technologies over a period of time leaves
opportunities for vulnerabilities to creep.
The root causes of vulnerabilities plaguing electronic storefronts are:
Poor input validation
Improper use of cookies
Poor session or state tracking
Assumptions that HTML and client-side scripting cannot be tampered with.
Improper database integration
Security loopholes in third-party products
Tthese issues throughout the remainder of this chapter by following the experiences
of a company that decided to place its business on the Web.
The second obvious mistake was using client-side scripts to perform input validation.
Code developers are always tempted to use JavaScript or VBScript to have code executed
on the client side and remove the burden from the server. However, client-side scripts are as
fragile as hidden fields when it comes to the lack of tamper resistance. Client-side scripts
only are to be used for smooth navigation or adding extra interactivity and presentability to
the Web page. An attacker can easily bypass or modify client-side scripts and circumvent any
checks enforced by them. As in the Acme case, attackers can inject negative quantities with ease,
bypassing any restriction imposed by the embedded JavaScript. Similarly, some Web-based storefront
systems perform arithmetic operations on the client side, such as computing the total quantity and
price of an order within the fill-out form itself. To the customer, it is a nice feature when they
can see prices updated on the browser without submitting the values to the server and waiting for
a response.
