Computers & Security (2005) 24, 208e217

www.elsevier.com/locate/cose

INTERNET TECHNOLOGY & E-COMMERCE

Secure business application logic fore-commerce systems

Faisal Nabi

Information Security Systems, Applied Research Centre of Applicable Computing,University of Luton, Park Square, Luton, United Kingdom

Received 12 May 2004; revised 10 August 2004; accepted 11 August 2004

KEYWORDSE-commerce;Security;Privacy;Client trust;Business application

logic;SSL;CGI scripts

Abstract The major reason why most people are still sceptical about e-commerceis the perceived security and privacy risks associated with e-transactions, e.g.,data, smart cards, credit cards and exchange of business information by means ofonline transactions. Today, vendors of e-commerce systems have relied solely onsecure transaction protocols such as SSL, while ignoring the security of server andclient software. This article, Secure Business Application Logic for e-commerceSystems, discusses a key weak link in e-commerce systems: the business applicationlogic. Although the security issues of the front-end and back-end software systemsin e-commerce application warrant equal attention, but this research focuses onthe Security of Middle Tier of e-commerce server that implements the businessapplication logic and traditionally, e-commerce sites implemented the middle tierof software on the web server using CGI. We also present strategies for securebusiness application logic: good design and engineering, secure configuration,defensive programming and secure wrappers for server-side software.ª 2004 Elsevier Ltd. All rights reserved.

Introduction

A risk constitutes something negative or bad.Business people, however, need to think of risksas mere opportunities, the reason being that, inmost business environment, the number or size ofthe risks taken usually is equal to the number orsize of the advantages to be gained. The reverse is

E-mail address: nabifaisal@yahoo.com

0167-4048/$ - see front matter ª 2004 Elsevier Ltd. All rights resedoi:10.1016/j.cose.2004.08.008

also true. Namely, the number or size of the riskstaken usually also equals the losses potentially tobe sustained. It is, therefore, important always totake calculated risks and to be aware of all possibleconsequences (Labuschagne and Eloff, 2000).

The advent of the electronic commerce usheredin a new period pervaded by a sense of boundlessexcitement and opportunities. Although it tooksome time, but now most organisations havealready involved conducting electronic commerceas that world wide e-Commerce Market has

rved.

Secure business application logic for e-commerce systems 209

exceeded $46 billion in consumer transactions bythe year 2001 which became main focus of organi-sation involving into e-commerce (Ernst and Young,1998).

‘‘Electronic Commerce’’, also referred to as ‘‘e-commerce’’, has revolutionised the modern-daybusiness world. Thanks to its concomitant tech-nologies, new business opportunities have beencreated. This results in the survival or downfall ofmany organisations on the global economic playingfield, depending on whether they choose to seizeor fail to avail themselves of these opportunities.The new opportunities, however, come with theirown set of problems. The major concern cited bymost decision-makers when it comes to e-com-merce, is ‘‘Security, Privacy and Client Trust’’. Forthis reason, subscribers still feel uncomfortableabout the idea of trading on the Internet (Fore-sight, 1998).

To them, the possible risks to be incurred justifythe potential rewards. Unfortunately, their fearsare not unfounded because of trust, privacy andsecurity threats to all e-commerce transactions.Basically, e-commerce is concerned with doingbusiness using electronic technologies. It can in-volve the transaction of data, transaction of pay-ments or marketing information, and valueaddition to existing products or databases. E-commerce can involve the exchange of credit cardnumbers that represents purchases by a consumerfrom a retailer (Lawrence and Corbett, 2000).

Credit card is one of the primary means ofelectronic payment on the Internet. Althougha large number of users reported that they hadtheir credit card stolen, there is still a lot ofconsumer confidence in the use of credit card.Again, this trust should not be betrayed andarrangements should be made to assure thatconsumer confidence remains strong in credit cardspecially for those who are reluctant (Kalakota andWhinston, 1996).

According to the survey report by Bank ofEngland on 15-10-2002, this year the credit cardtheft worth was four hundred and eleven millionpounds (fraud of credit cards), which was a 50%increase compared to the previous year in the UK(Survey Report by Bank of England, 2002).

Another case reported in 2003 where the num-ber of user of Barclay Bank suffered while con-ducting online credit card transaction this timewas the case of during the transaction client toserver side, actually it was the case of ‘‘Web CopyCat Trick’’. This technique is the cause of mis-configuration server side components that pro-vided path way to intruder to play a techniquewhich is known as ‘‘Web Copy Cat Trick’’ and

organisation (Barclay Bank) suffered heavy losesdue to that, they had to advise their customers notto use online services until problem is resolved.

Another cyber crime case reported by MSNBCnews report: the issue of international credit cardthievery and fraud burst into the public conscious-ness in January 2004 with news of a heist ofthousands of credit cards from the CD UniverseWeb site, allegedly by a teenage hacker fromRussia. It continued to make headlines with newsthat Amazon.com had uncovered a Russia-basedplot to defraud it and other e-merchants out ofmore than $70,000 worth of merchandise usingstolen credit-card information.

Stephen Orfei, vice president for electroniccommerce and emerging technology at Master-Card, said that the Internet accounts for between2 and 2.5 percent of total credit card transactions.Using the lower figure and applying it to the bankassociation’s total fraud losses of $526 million in1998 yields a loss to online fraud of slightly morethan $10.5 million.

Visa USA reported $487 million in fraudulentcharges last year, which assuming a 2 percent ratewould be approximately $9.75 million.

American Express and Discover Financial Serv-ices do not publicly report fraud rates and declinedto comment on the subject of Internet credit cardfraud except to say that they aggressively attemptto comb.

Since e-commerce fraud rates are one-thirdhigher than overall fraud rates, according to Visa’sfigures for 1999 (9 cents per $100 on the Net vs. 6cents per $100 overall), that $20 million figure forVisa and MasterCard alone is most likely on the lowside. The federal government’s main mechanismfor tracking economic crimes is the TreasuryDepartment’s Financial Crimes Enforcement Net-work, known as FinCen, which collects reports on17 types of ‘‘suspicious activities’’ from U.S. banksand other institutions, the agency received about120,000 reports, of which 4900 e or about 4percent e reflected possible credit card fraud.Increasing ratio of e-commerce fraud rates is realconcern.

Concerns of e-commerce

Any business that is still in business, conducts‘‘commerce’’. Commerce is the exchange ofmoney for goods or services between companies(B2B) or end consumers (B2C). ‘‘E-commerce’’ isdoing commerce using electronic technology suchas intranets, extranets and the Internet, which

210 F. Nabi

provides with a new means of obtaining usefulinformation and purchasing products and servicesbetween companies and end consumers. Althoughthis form of e-commerce has undergone rapidgrowth, particularly through the use of the Inter-net, business and consumer fears and concernsabout the risks, both have inhibited its growth realand perceived, of doing business electronically(Kamthan, 1999).

From the time a business installs a web server orhires space on a commercial web server from anISP, there is a potential for business systems in theorganisation to be exposed to breaches of securityand confidentiality across the entire Internet(Lawrence and Corbett, 2000).

Any link to the Internet exposes the business totampering, or Internet graffiti, where data can beexposed with meaningless scribble, pictures orelectronic junk in the same way that graffiti artistscrawls on walls. Link to the Internet also exposesthe business to the theft of data. Database can bevery easily captured wholly and transferred forother uses such as industrial espionage (Sielgel,1996).

The TCP/IP protocol developed to run theInternet was not designed with security in mind.This protocol, the basic system running Internetcommunications, is vulnerable to interceptions(Hunt, 1998).

Any movement of data from a browser toa server or back is vulnerable to eavesdropping(Chaffy, 2000). Website security is about keepingstrangers out, but at the same time allowingcontrolled access to the network (Lawrence andCorbett, 2000).

Therefore, due to all these reasons, newerschemes for security, such as Secure Socket Layer(SSL), have been introduced. This is a low-levelencryption scheme used to encrypt e-commercecommunications and for consumers to use theircredit card numbers in transactions on a secureWWW form and transmit the form over the Inter-net without the risk of a cracker obtaining thecredit-card information in higher-level protocolssuch as SHTTP, NNTP, and FTP.

The SSL protocol can authenticate server (i.e.,verify server’s identity) encrypting data in transitbetween the server and client accessing the server(Ahuja, 1997).

Basically, cryptography is based on encryption,which use the authentication and digital signaturetechniques based on Cryptographic Methods. En-cryption is the transformation of data into a formunreadable by anyone without a secret key. Itspurpose is to ensure privacy by keeping the in-formation hidden from anyone for whom it is not

intended, even those who can see the encryptiondata. There are two types of cryptographic sys-tems: (1) symmetric system, where a single keyserves both as the encryption and decryption; (2)asymmetric system, where each person gets a pairof keys called the public and private key. Eachperson’s public key is published, while the privatekey is kept secret. The need for the sender andreceiver to share secret information is eliminated.All communications involve only public keys, andno private key is ever transmitted or shared.Furthermore, public and private key cryptographycan be used for authentication using CryptographicEnvelop Technology (which is developed in JavaArchive) technique (Lawrence and Corbett, 2000).This session key is used to encrypt the HTTPtransaction (Furche and Wrightson, 1996).

Nevertheless, the advancement of the securityfield has proved that vendors of e-commercesystems cannot solely rely on secure transactionprotocols, such as SSL e an encryption protocolpromoted as proof of 100% security by e-commercevendors. Lost in the hype are the real security risksof e-commerce and these attributes make up onlya small part of security, privacy and client trust ofe-commerce risks.

In what follows, we will discuss further aboutthe advancement on security, privacy and clienttrust of e-commerce risks, making secure businessapplication logic for e-commerce security, privacyand client trust in which we will describe aboute-commerce security more than cryptography andthe idea of secure business application logic fore-commerce.

Further advancements in the field

E-commerce security; more thancryptography

As the market for e-commerce continues to heatup significantly, most stakeholders in the marketare quick to declare that the system is secure.Encryption protocols such as SSL are promoted asproof of security by e-commerce vendors. Lost inthe hype are the real security risks of e-commerce.Although encryption of data during transactionsprovides crucial confidentiality, integrity, and au-thentication, these attributes make up only a smallportion of security that must be ensured fore-commerce security. Businesses engaging ine-commerce incur higher risk of attacks, higherrisk of severe losses, and a higher loss-to-incidentratio than simply put up web pages. In fact, due to

Secure business application logic for e-commerce systems 211

the complex nature of business, e-businesses aremuch more vulnerable than simple websites due tothe greater complexity of the software necessaryto support e-commerce transactions (Garfinkel andStafford, 1997; Gosh, 1998).

The software that executes on either end of thetransaction e sever-side or client-side software eposes real threats to the security, privacy andclient trust of all e-commerce transactions. Twofamiliar adages play an important role in under-standing how to secure e-commerce systems: (1)a chain is only as strong as its weakest link; and (2)in the presence of obstacles, the path of leastresistance is always the path of choice (Ghosh,2000). Encryption protocols generally provide thestrongest perceived security in all the componentsinvolved in e-commerce transaction (Garfinkel andStafford, 1997).

However, in e-commerce as in other real-worldsystems, the security of the system is only asstrong as its weakest component. On the whole,the security of server-side systems is much weakerthan the security provided by secure data trans-action protocols such as SSL, example of this claimrefers to the above mentioned cases of securitybreach and the case study of Barclay Bank Web sitetargeted that is the case of Copy Cat Trick which isconducted through the server-side misconfigura-tion of softwares, cause of vulnerability/compro-mising server-side security is clearly proof of thisclaim. Considering these two adages together inthe context of e-commerce security, privacy andclient trust, it becomes clear that maliciousperpetrators will rarely attempt to break encryp-tion codes when they can much more easily breakinto a system, and enjoy a much higher return viathis simpler approach (Ghosh, 2000).

This article addresses the topic of securingserver-side software used in e-commerce applica-tions. Today, most e-commerce server applicationsare implemented in n-tier architecture as shown inFig. 1.

This architecture usually consists of a front-endweb server, a business application layer, a back-end database, ERP systems, and legacy software.In practice, many of the security issues ine-commerce sites are specific to the way in whichthese components are configured

A weak link: business application logic

Although the security issues of the front-end andback-end software systems in e-commerceapplications warrant equal attention, this articlefocuses on the security of the middle tier of

e-commerce servers that implements the businessapplication logic. The business application logicrepresents the functions or services that a partic-ular e-commerce site provides. As a result, a givensite may often employ custom-developed logic. Asthe demand for e-commerce services grows, thesophistication of the business application logicgrows accordingly. The end result is a complexcustom software system that, if flawed, can resultin a complete security compromise of the site(Ghosh, 2000).

Traditionally, e-commerce sites implement themiddle tier of software on web servers using theCommon Gateway Interface (CGI). CGI scripts areprograms that run on the web server machine asseparate processes from the web server software.The web server invokes these general-purposeprograms in response to user requests. The CGIscripts’ main function is to process user input andperforms some services (such as retrieving datafrom a database, or dynamically creating a webpage) for the user. Because CGI scripts processuntrusted user input, the security risks associatedwith the CGI (and other forms of middle-tier soft-ware)areextremely high.Manyattacks againstweb-based systems exploit CGI scripts (Gundavaram,1996).

Expecting the unexpected

While developers can write CGI scripts in anygeneral-purpose programming language, they mostoften write such scripts in Perl, C, Tcl, or Python.The basic rule of thumb when designing CGI scriptsis to expect the unexpected. Or more appropri-ately, expect the malicious. While developers havecontrol over the content of CGI scripts, they haveno control over what users will send to the CGIscripts. Also, do not overlook attacks against CGIscripts that exist on the server as part of thedistribution, but are not even used as part of thee-commerce application. Some CGI scripts in-cluded as part of the web server distribution havewell-known flaws that can be exploited to obtainunauthorised access to the server. Even if devel-opers do not use the default CGI scripts as part ofthe web server pages, anyone else can use them bysimply knowing the script names (Stein, 1998).

More recently, component-based software (CBS)has made inroads in e-commerce applications. Theidea of using CBS is to develop, purchase, andreuse industrial-strength software in order torapidly prototype business application logic. Oneof the more popular component frameworks fore-commerce applications is Enterprise Java Beans

212 F. Nabi

Figure 1 Secure business application logic model for e-commerce systems security.

(EJB), which supports component-based Java.Other component models include the CommonObject Request Broker Architecture (CORBA), anopen standard developed by the Object Manage-ment Group (OMG), and Microsoft’s Common Ob-ject Model (COM) and Distributed COM (DCOM).The component frameworks are the ‘‘glue’’ thatenables software components to provide servicessuch as business application logic and use standardinfrastructure services such as naming, persis-tence, introspection, and event-handling, whilehiding the details of the implementation by usingwell-defined interfaces (Gosh, 1998).

Fig. 1 shows typical n-tier architecture fora component-based e-commerce application. Theweb browser client can display web pages in HTML,execute mobile code such as Java applets or webscripts, and capture business-specific semanticsusing XML. The web server provides web services inaddition to other Internet services such as e-mailand File Transfer Protocol (FTP). The businessapplication logic is coded in software componentsthat can be custom-developed or purchased off-the-shelf. The application servers provide theinfrastructural services for particular componentmodels such as EJB, CORBA, COM, and DCOM. Theyalso provide an interface for the business applica-tion logic to back-end services such as database

management, enterprise resource planning (ERP),and legacy software system services.

Component-based software forbusiness-to-business applications

In addition to supporting traditional CGI functions,component-based software is expected to enabledistributed business-to-business applications overthe Internet. The component-based software par-adigm also supports good software engineering(see ‘‘Designing for Security’’ section). The UnifiedModelling Language (UML) supports object-oriented analysis and design for component-basedframeworks. In addition, as the market for com-ponent-based software heats up, many standardbusiness application logic components will beavailable for purchase off the shelf.

The security risks of component-basedsoftware

Although component-based software providesnumerous benefits, it poses security hazards sim-ilar to CGI scripts. Component-based softwareenables software development in general-purpose

Secure business application logic for e-commerce systems 213

programming languages such as Java, C, andCCC. As such, these components execute withall the rights and privileges of server processes.Like CGI, they process untrusted user input.However, because component-based software canbe used to build sophisticated large-scale applica-tions, errors are unarguably more likely withcomponent-based software than with simple CGIscripts. Regardless of the implementation e CGI orapplication servers e the security risks of server-side software are high, and therefore server-sidesoftware must be carefully designed and imple-mented using the techniques covered in thefollowing sections (Stein, 1998).

Designing for security

As with all software development, good design andengineering practices are important for softwarequality. This point is particularly important fordevelopment of security-critical software such ase-commerce applications. Rather than thinking ofsecurity as an add-on feature to software systems,security should be designed into the system fromthe earliest stages of requirements gatheringthrough development, testing, integration, anddeployment. The goal of design for security is tobreak the penetrate-and-patch mindset that per-vades commercial software security today, andreplace it with a process for finding and removingsecurity-related bugs prior to software release.Finding and fixing bugs in software after releasecosts orders of magnitude more than correctingthem early during the software development life-cycle (Gosh, 1998).

One unfortunate consequence of the hugepressure to reduce time to market for e-commerceservices is that good software engineering practi-ces are dropped (or more often never started).As described in section ‘‘A key weak link: busi-ness application logic’’, the demand fore-commerce applications is driving the complexityof business application logic. Developing softwaresuch as a typical desktop application for one userat a time differs significantly from developing ane-commerce application that needs to handle tensof thousands of concurrent requests. Today’se-commerce applications need to not only handlemany simultaneous users, but also deal withmalicious threats. As a result, developers mustemploy good software engineering practices todevelop robust and secure business applicationlogic. Several key activities mark good softwareengineering practices:

� Gathering and formally specifying require-ments

� Developing normal and pathological usagescenarios

� Object-oriented analysis and design� Adopting good coding practices� Unit testing and integration� Release engineering� Third-party validation and verification

Requirements’ gathering has traditionally focusedon users’ needs for the application under de-velopment. In gathering requirements for security-critical applications, developers must equallyfocus on what the user should be allowed to doand should not be allowed to do. A plan formeeting functional requirements is typically cap-tured in specifications for the application. How-ever, specifications for e-commerce applicationsneed to specify not only which functional behav-iour is expected from the application, but alsowhich behaviour is not desired.

Therefore, to develop a specification of securebehaviour, the project team must develop a secu-rity policy for the e-commerce application (and itsusers). Developing specifications is often fraughtwith anxiety over formality. While formal nota-tions can be useful for reducing ambiguity, if theyare so daunting that they discourage the develop-ment of specifications, then they can have theopposite effect on software quality. Rememberthat the ultimate goal of software specification isto promote understanding of intended systembehaviour, so any specification is better than none.A specification of undesired behaviour is not onlyuseful for preventing security design flaws, but canalso be used for security-oriented testing (Gosh,1998).

Configuring the CGI

One of themost commone yet easily preventableesecurity hazards is misconfiguration of software.CGI scripts, too, must be correctly configured forsecurity. One feature supported by many webservers is the ability for individuals throughout anorganisation to write CGI scripts and have themexecuted from their own directories. Althoughuseful for ‘‘sniffing’’ personal web pages, suchscripts can introduce system security hazards. Ine-commerce applications, the web server should beconfigured to prevent CGI scripts from executinganywhere but a single CGI directory controlled bythe system administrator. The script-aliased CGImode for web servers ensures that CGI scripts will

214 F. Nabi

execute only from an explicitly named directory inthe server configuration file. In addition, the CGIscript path is not named in the URL to the CGI.Rather, the server ‘‘aliases’’ the explicit path to theCGI scripts to a name of choice such as ‘‘cgi-bin’’.Thus, running the server in script-aliased CGI modeprevents rogue CGI scripts from executing, and alsohides the explicit path to the CGI scripts (Pre-BuiltCGI Scripts).

Configure the CGI script directories correctlyusing operating system access controls. For in-stance, if CGI scripts are written in a compiledlanguage (such as C), the script sources should beexcluded from the document root of the webserver, so that they cannot be accessed via theweb. They should be accessible to the systemadministrator or web content development grouponly, and inaccessible to everyone else in theorganisation. If the script sources fall into thehands of malicious perpetrators, the source codecan be inspected for flaws, making the perpetra-tors’ job even easier. Access to the CGI executablesdirectory, frequently called the cgi-bin, should alsobe properly controlled. Only the web server andadministrator need access to this directory. Liberalaccess permissions to the CGI executables direc-tory let malicious insiders place their own scriptson the e-business site. Also, be sure to prohibitaccess to interpreters from the web server. Forexample, system administrators may be tempted toinclude the Perl interpreter in CGI script directo-ries. However, doing so provides direct web accessto interactively execute Perl commands e anextremely dangerous configuration.

Finally, account for every CGI program on theserver in terms of its purpose, origin, and mod-ifications. Remove CGI scripts that do not servea business function. View with suspicion andcarefully screen CGI scripts that are distributedwith web servers, downloaded from the Internet,or purchased from third parties. These steps willeliminate most of the potentially dangerous CGIscripts. Once a stable set of CGI programs has beenestablished, make a digital hash of the executableprograms (using MD5) to enable future integritychecks (Christiansen and Torkington, 1998).

Defensive programming

Simply configuring the system securely is notenough to ensure security. Even after the CGIscripts are properly locked down, flaws in thedesign and implementation of the CGI scripts canbe exploited to leverage full system compromise.A good starting place for writing secure CGI scripts

is to use safe language features. For instance,although interpreted languages such as Perl aregreat for rapidly prototyping software, they alsoprovide powerful constructs for executing systemcommands that perpetrators can easily exploit.Perl commands such as eval (), system (), back-quotes (‘), pipes, and exec () can potentiallyresult in system commands being executed onthe web server at the discretion of an unknownand untrusted remote user. Use these commandswith extreme caution when processing user input.

Although the same types of system commandscan be used in compiled languages such as C, theyare not as easily constructed or misused as systemcommands in interpreted languages such as Perl,Python, or Tcl. However, C provides its ownhazards due to its lack of advanced memorymanagement. For instance, the most commonand notorious security-related bug for C programsis the buffer overflow. This condition occurs whenthe memory allocated to a variable is less than theamount being written into it. Regardless of thelanguage used for implementing the businessapplication logic, the Cardinal’s rule in develop-ment is never to trust the user input.

Sanitising user input

Fortunately, defensive programming can add se-curity where powerful language constructs mightotherwise fall short. A key defensive strategy is tosanity-check (and sanitise) all program input. Forinstance, if a social security number is requested,be sure that the input is numeric and that no morethan nine characters are read. Also be sure tosanitise input of special Meta escape characters.Characters such as the backtick (‘) allow input tobe executed as commands to the interpreter.

Unescape special characters, or if possible,accept only legitimate characters. Do not assumethat the length of the input is fixed. Even if thelength of the input field is limited in a form, theuser is not constrained to using the form to send inuser input. When parsing user input, read only thelength of data necessary for the input and ensurethat adequate memory is allocated for the amountof input to be read (Ghosh, 2000).

Using environment variables

A common oversight in CGI script development isthe use of environment variables. The user can setcertain environment variables. Sanitise or sanity-check environment variables from HTTP clientsbefore using them. Use other system environment

Secure business application logic for e-commerce systems 215

variables with caution. Specify explicit pathsrather than rely on system environment variablesfor accessing programs and files. An insider canfool a CGI script that depends on an environmentvariable to execute a rogue program instead of theintended program. Also, do not use hidden fields informs in order to hide information. Though hiddenfields may not display in the browser, they areeasily discerned by inspecting the HTML source.

Leveraging existing safety features

In addition to these defensive programming tech-niques, some languages provide safety featuresthat should be leveraged when possible. For in-stance, Perl 5 contains a ‘‘taint’’ module forpreventing user-supplied input from being used insystem commands. When Perl tainting is enabled,any variable derived from user input (such ascommand-line arguments and environment varia-bles) is considered tainted (or untrusted). Thus,when a tainted variable is used in a systemcommand, such as modifying the file system orspawning a shell, the Perl runtime interpreterprevents the command from executing.

Similarly, Tcl has a safe language interpreterthat can prevent untrusted input from compromis-ing system security and integrity. When usingapplication servers for implementing business ap-plication logic, prefer using strongly typed lan-guages such as Java rather than C or CCC. Java’stype safety and advanced memory managementcan eliminate typical programmer errors in walkingthrough memory that often lead to security break-downs. Furthermore, Java 2 provides fine-grainedaccess control for Java programs to preventunauthorised access to system resources.

In summary, always expect the unexpectedfrom user input. Employ defensive programmingtechniques such as sanitising input regardless ofthe language used. If you develop in an interpretedlanguage, then use the safe language-interpreterfeatures such as Perl tainting and Safe-Tcl. Whendeveloping business application logic from compo-nents, use a type-safe language such as Javarather than languages such as C and CCC, whichgive free reign to the programmer to use memoryobjects in any context.

Wrapping the business application logic

The defensive programming techniques describedin the previous section can significantly helpto write secure server-side software. Even so,perfection is largely unattainable in software

development. To improve the security of thebusiness application logic, consider using one ofseveral existing technologies that can ‘‘wrap’’server-side software in order to limit potentialdamage from flawed software exploited for mali-cious gain.

One of the most commonly employed ap-proaches on UNIX-based systems is to use thechroot () command to effectively cordon off thefile system visible to a program. The chroot ()

function changes the effective root of the filesystem for a given process to a designated newroot. For server-side software, define the new rootas the smallest partition of the file system neces-sary for the programs to access. When a process isrun in a chroot () environment, it is effectivelyrunning in a jail cell to prevent it from causingdamage to other portions of the system. While thechroot () environment is useful for preventingauxiliary damage to the rest of the system, it isimportant to remember that the chroot () envi-ronment must contain the portion of the file systemnecessary for the program to perform its function.

If the business application logic needs to com-municate with critical system resources such asback-end databases, then these resources need tobe included within the chroot () environment. Inthis case, the chroot () environment will notprotect databases or other included resourcesfrom misbehaving software, but will protect theintegrity of other system resources outside thechroot () environment. Alternative commercialtechnologies for ‘‘sandboxing’’ executing pro-cesses are available on the Windows platform.

Another technique for UNIX-based systems pro-vides some protection by running CGI scripts withuser permissions. The program CGIWrap is de-signed for systems that allow internal users towrite and post their own CGI scripts. Althoughallowing users to post their own CGI scripts is notadvisable for e-commerce applications, if it isa requirement, then CGIWrap can be useful forlimiting the privilege of the executing CGI processto that of the user. The technique assumes thatpermissions of users are properly configured on thesystem such that no user is allowed access to otherusers’ files or to critical system files and programs.

In many systems, the web server is configured torun all CGI scripts under a single account’s priv-ileges. Usually an account is created for thispurpose, such as www or nobody. However, insystems where internal users are allowed to posttheir own CGI scripts, it is not advisable to allowa user’s script to access files owned by other users’or other web server files. CGIWrap enforces thepolicy that users’ CGI scripts can only access files

216 F. Nabi

owned by the script’s owner. Again, before leavingthe discussion of CGIWrap, it is important toreiterate that it is generally not advisable to allowusers to post their own CGI scripts to an e-commerce site.

A more attractive alternative to CGIWrap is theSBOX tool written by Stein (1998). Like CGIWrap,SBOX is designed for multi-user websites whereusers are allowed to post their own CGI scripts.However, in addition to limiting the privilege ofCGI scripts to their owner’s files, SBOX can alsoplace limits on executing CGI processes on the useof system resources such as CPU cycles, memory,and disk. This feature provides an effective way tothwart denial-of-service attacks from maliciousCGI scripts, or poorly written CGI scripts that endup consuming system resources to the detriment ofthe other e-commerce services. SBOX also allowsCGI scripts to be run in a chroot () directory.Thus, SBOX provides wrapping capability of pro-grams that not only limits the file system usingchroot (), but also ensures that the CGI scriptscannot infringe on other users’ programs and willnot deny service to other executing processes.

It is important to stress again; however, that e-commerce applications should not be deployed ina general-purpose environment that allows multi-ple users to upload their CGI scripts. But if CGIuploading does need to be supported, tools such asSBOX and CGIWrap can reduce the likelihood ofcatastrophic security breaches.

Conclusion

E-commerce security, privacy and client trustissues should always be dealt with when surfingon the web or using the Internet for businesspurposes.

E-commerce encompasses all aspects of usingthe Internet for business or personal use. Now,more than ever, a great deal of business isperformed in one-way or another over the Inter-net. For some, it is simply ease of communication;for others, having the ability to research topics,products, or even people make the Internet anabsolute necessity for business.

Businesses have begun exploiting the Internetfor commercial transactions. Recognizing the dan-gers in sending confidential information over aninherently insecure media, a number of securedata transport protocols have emerged. At mini-mum, these protocols encrypt sensitive informa-tion such as credit card numbers to preventunauthorised people from capturing the data.Some protocols even facilitate payment for mer-chants through banking institutions.

Even with the strong security provided in thetransport of data, e-commerce security still re-mains elusive. In practice, most security violationsoccur through other avenues than breaking ciphertext. Using encryption on the Internet is theequivalent of arranging an armoured car to delivercredit-card information from someone living ina cardboard box to someone living on a park bench.The point is that usually we infer security fromencryption when we are so vulnerable otherwise.

Therefore, keeping in view of strategy of de-veloping secure business application logic for e-commerce sites (server-side security and privacy)can secure from breaching by securing server-sidesoftware, because security is as strong as itsweakest link. This is why common sense is thebest tool to make your side secure from hacking/breaching system.

Common sense is the appropriate tool that canbe used to establish your security policy. Elaboratesecurity schemes and mechanisms are impressiveand they do have their own reasons, but yet thereis little point in investing money and time on anelaborate implementation scheme if the simplecontrols are forgotten.

References

Ahuja V. E-commerce on Internet. London: Academic Press Ltd;1997.

Chaffy D. Business information systems; technology, develop-ment and management in the e-business; 2000. ISBN:027365540X.

Christiansen Tom, Torkington Nathan. Perl cookbook: O’Reilly &Associates; 1998. [chapter 19: CGI programming].

Ernst, Young. Internet shopping e an Ernst & Young specialreport; 1998 [Section 2].

Foresight. E-commerce sets new rules, Systems RelationshipsMarketing, on behalf of Datatec Ltd, 1998 November;1(3).

Furche A, Wrightson G. Asystematic overview of electronicpayment system. Heidelberg, FDR: dpunkt, Verlag, Furdigtiale Technology Gmbh; 1996.

Garfinkel Simson, Stafford Gene. Web security and commerce:O’Reilly Publishing; 1997.

Gundavaram Shishir. CGI programming on the World Wide Web:O’Reilly & Associates; 1996.

Ghosh Anup K. director of security research at softwaretechnologies. Security and privacy in e-commerce. JohnWiley & Sons; 2000.

Gosh Anup K. E-commerce security: weak links, best defences:John Wiley & Sons; 1998. ISBN: 0-471-19223-6.

Hunt Craig. TCP/IP for Unix administrators. 2nd ed. O’Reilly;1998. ISBN: 1-56592-322-7.

Kalakota Ravi, Whinston Patrick. Frontiers of electroniccommerce: Addison-Wesley; 1996.

Kamthan Pankaj. A matter of trust. Journal of E-Commerce onthe WWW Sunday 25th April 1999.

Labuschagne L, Eloff JHP. E-commerce: the information-security challenges journal. Information Management &

Secure business application logic for e-commerce systems 217

Computer Security 2000;8(3):154e7 ISBN: 0968-5227. MCBUniversity Press.

Lawrence Elaine, Corbett Briam. E-commerce and Internetdigital models for business. 2nd ed. Australia: John Wiley &Sons; 2000. ISBN: 0 471673.

Pre-Built CGI Scripts e Security Issues When Installing andCustomizing Pre-Built Web Scripts, Selena Sol, WDVL.com.

Sielgel C. Internet security for business. New York: John Wiley &Sons, Inc; 1996.

Stein Lincoin. Web security step-by-step reference guide.Addison Wesley; 1998.

Survey report by Bank of England on 15-OCT-2002, BBC LondonReport.

Faisal Nabi, Pakistani Scientist in the field of Computer ScienceSecurity, was born in 1978 in Karachi. He had his initial education

from Aisha Bawany school and college education from GovtAllama Iqbal. He then joined Karachi University for graduation,post-grad level. He then went to UK for higher education, joinedMSc e-commerce/e-business at University of Luton. He special-ized in information/e-commerce security. Specialities: cryptog-raphy, stegnography, virtual disk design with blue fishencryption technique, designing invincible security architec-ture. Started research as R&D researcher at the University ofLuton without any support by the University and otherassistance. Research conducted on self-finance suffered allresearch expenditures. In April 2004, he was appointed asResearcher at Deveraux & Deloitte Research Centre, UK. I wantto say special thanks to Dr. Carsten Maple Department ofComputing and Information Systems, University of Lutonwho always encouraged me time to time, he is a top classResearcher.