E-Commerce Security Workable Attacks Againest E-Commerce


Published on

E-Commerce Security Workable Attacks Againest E Commerce, Research by Abdollah Shirvani

Published in: Education, Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

E-Commerce Security Workable Attacks Againest E-Commerce

  1. 1. Workable attacks against E-commerce Author: Abdollah Shirvani Shirvani.86@Gmail.com 1st e-commerce security Conference-Ramiran.Co, Tehran, Iran, summer 2008 What is e-Commerce? E-Commerce refers to the exchange of goods and services over the Internet. All major retail brands have an online presence, and many brands have no associated bricks and mortar presence. However, e-Commerce also applies to business to business transactions, for example, between manufacturers and suppliers or distributors. In the online retail space, there are a number of models that retailers can adopt. Traditionally, the Web presence has been kept distinct from the bricks and mortar presence, so transactions were limited to buying online and delivering the goods or services. The online presence is also important for researching a product that a customer can purchase later in the store. Recently, there has been a trend towards multi-channel retail, allowing new models such as purchasing online and picking up in store. E-Commerce systems are also relevant for the services industry. For example, online banking and brokerage services allow customers to retrieve bank statements online, transfer funds, pay credit card bills, apply for and receive approval for a new mortgage, buy and sell securities, and get financial guidance and information. Security overview A secure system accomplishes its task with no unintended side effects. Using the analogy of a house to represent the system, you decide to carve out a piece of your front door to give your pets' easy access to the outdoors. However, the hole is too large, giving access to burglars. You have created an unintended implication and therefore, an insecure system. In the software industry, security has two different perspectives. In the software development community, it describes the security features of a system. Common security features are ensuring passwords that are at least six characters long and encryption of sensitive data. For software
  2. 2. consumers, it is protection against attacks rather than specific features of the system. Your house may have the latest alarm system and windows with bars, but if you leave your doors unlocked, despite the number of security features your system has, it is still insecure. Hence, security is not a number of features, but a system process. The weakest link in the chain determines the security of the system. In this article, we focus on possible attack scenarios in an e-Commerce system and provide preventive strategies, including security features that you can implement. Security has three main concepts: confidentiality, integrity, and availability. Confidentiality allows only authorized parties to read protected information. For example, if the postman reads your mail, this is a breach of your privacy. Integrity ensures data remains as is from the sender to the receiver. If someone added an extra bill to the envelope, which contained your credit card bill, he has violated the integrity of the mail. Availability ensures you have access and are authorized to resources. If the post office destroys your mail or the postman takes one year to deliver your mail, he has impacted the availability of your mail. The players In a typical e-Commerce experience, a shopper proceeds to a Web site to browse a catalog and make a purchase. This simple activity illustrates the four major players in e-Commerce security. One player is the shopper who uses his browser to locate the site. The site is usually operated by a merchant, also a player, whose business is to sell merchandise to make a profit. As the merchant business is selling goods and services, not building software, he usually purchases most of the software to run his site from third-party software vendors. The software vendor is the last of the three legitimate players. The attacker is the player whose goal is to exploit the other three players for illegitimate gains. Figure 2 illustrates the players in a shopping experience. Figure 2. The players The attacker can besiege the players and their resources with various damaging or benign schemes that result in system exploitation. Threats and vulnerabilities are classified under confidentiality, integrity, and availability. A threat is a possible attack against a system. It does not necessarily mean that the system is vulnerable to the attack. An attacker can threaten to throw eggs against your brick house, but it is harmless. Vulnerability is a weakness in the system, but it is not necessarily known by the attacker. For example, only you know that you have left your front door unlocked. Vulnerabilities exist at entry and exit points in the system. In
  3. 3. a house, the vulnerable points are the doors and windows. When the burglar threatens to break into your house and finds the vulnerability of the unlocked door, he is exploiting the assets in the house. Security features While security features do not guarantee a secure system, they are necessary to build a secure system. Security features have four categories:  Authentication: Verifies who you say you are. It enforces that you are the only one allowed to logon to your Internet banking account.  Authorization: Allows only you to manipulate your resources in specific ways. This prevents you from increasing the balance of your account or deleting a bill.  Encryption: Deals with information hiding. It ensures you cannot spy on others during Internet banking transactions.  Auditing: Keeps a record of operations. Merchants use auditing to prove that you bought specific merchandise. The criminal incentive Attacks against e-Commerce Web sites are so alarming; they follow right after violent crimes in the news. Practically every month, there is an announcement of an attack on a major Web site where sensitive information is obtained. Why is e-Commerce vulnerable? Is e-Commerce software more insecure compared to other software? Did the number of criminals in the world increase? The developers producing e-Commerce software are pulled from the same pool of developers as those who work on other software. In fact, this relatively new field is an attraction for top talent. Therefore, the quality of software being produced is relatively the same compared to other products. The criminal population did not undergo a sudden explosion, but the incentives of an e-Commerce exploit are a bargain compared to other illegal opportunities. Compared to robbing a bank, the tools necessary to perform an attack on the Internet is fairly cheap. The criminal only needs access to a computer and an Internet connection. On the other hand, a bank robbery may require firearms, a getaway car, and tools to crack a safe, but these may still not be enough. Hence, the low cost of entry to an e-Commerce site attracts the broader criminal population. The payoff of a successful attack is unimaginable. If you were to take a penny from every account at any one of the major banks, it easily amounts to several million dollars. The local bank robber optimistically expects a windfall in the tens of thousands of dollars. Bank branches do not keep a lot of cash on hand. The majority is represented in bits and bytes sitting on a hard disk or zipping through a network. While the local bank robber is restricted to the several branches in his region, his online counterpart can choose from the thousands of banks with an online operation. The online bank robber can rob a bank in another country, taking advantage of non-existent extradition rules between the country where the attack originated, and the country where the attack is destined. An attack on a bank branch requires careful planning and precautions to ensure that the criminal does not leave a trail. He ensures the getaway car is not easily identifiable after the robbery. He cannot leave fingerprints or have his face captured on the surveillance cameras. If he performs his actions on the Internet, he can easily make himself anonymous and the source of the attack untraceable.
  4. 4. The local bank robber obtains detailed building maps and city maps of his target. His online counterpart easily and freely finds information on hacking and cracking. He uses different sets of tools and techniques everyday to target an online bank. Points the attacker can target As mentioned, the vulnerability of a system exists at the entry and exit points within the system. Figure 3 shows an e-Commerce system with several points that the attacker can target:  Shopper  Shopper' computer  Network connection between shopper and Web site's server  Web site's server  Software vendor Figure 3. Points the attacker can target Common Security Vulnerabilities in E-commerce Systems The tremendous increase in online transactions has been accompanied by an equal rise in the number and type of attacks against the security of online payment systems. Some of these attacks have utilized vulnerabilities that have been published in reusable third-party components utilized by websites, such as shopping cart software. Other attacks have used vulnerabilities that are common in any web application, such as SQL injection or cross-site scripting. This article discusses these vulnerabilities with examples, either from the set of known vulnerabilities, or those discovered during the author's penetration testing assignments. The different types of vulnerabilities discussed here are SQL injection, cross-site scripting, information disclosure, path disclosure, price manipulation, and buffer overflows. Successful exploitation of these vulnerabilities can lead to a wide range of results. Information and path disclosure vulnerabilities will typically act as initial stages leading to further exploitation. SQL injection or price manipulation attacks could cripple the website, compromise confidentiality, and in worst cases cause the e-commerce business to shut down completely.
  5. 5. Wherever examples of such vulnerabilities are given in advisories published by Bugtraq, we have given the Bugtraq ID in square brackets. Details of the vulnerability may be viewed by navigating to http://www.securityfocus.com/bid/<bid_number>. 2. Vulnerabilities 2.1 Background There are a number of reasons why security vulnerabilities arise in shopping cart and online payment systems. The reasons are not exclusive to these systems, but their impact becomes much greater simply because of the wide exposure that an online website has, and because of the financial nature of the transactions. One of the main reasons for such vulnerabilities is the fact that web application developers are often not very well versed with secure programming techniques. As a result, security of the application is not necessarily one of the design goals. This is exacerbated by the rush to meet deadlines in the fast-moving e-commerce world. Even one day's delay in publishing a brand new feature on your website could allow a competitor to steal a march over you. We've typically found this in cases where e-commerce sites need to add functionality rapidly to deal with a sudden change in the business environment or simply to stay ahead of the competition. In such a scenario, the attitude is to get the functionality online; security can always be taken care of later. Another reason why security vulnerabilities appear is because of the inherent complexity in most online systems. Nowadays, users are placing very demanding requirements on their e-commerce providers, and this requires complex designs and programming logic. In a number of cases, we've found that e-commerce sites tout their 128-bit SSL certificates as proof that their sites are well secured. The gullibility of customers to believe in this has reduced over the past few years, but even now there are thousands of web sites displaying Verisign or Thawte certificate icons as proof of their security. The following sections look at common security vulnerabilities that have been discovered in shopping cart and online payment systems. 2.2 SQL Injection SQL injection refers to the insertion of SQL meta-characters in user input, such that the attacker's queries are executed by the back-end database. Typically, attackers will first determine if a site is vulnerable to such an attack by sending in the single-quote (') character. The results from an SQL injection attack on a vulnerable site may range from a detailed error message, which discloses the back-end technology being used, or allowing the attacker to access restricted areas of the site because he manipulated the query to an always-true Boolean value, or it may even allow the execution of operating system commands. SQL injection techniques differ depending on the type of database being used. For instance, SQL injection on an Oracle database is done primarily using the UNION keyword and is much more difficult than on the MS SQL Server, where multiple queries can be executed by separating them with the semi-colon. In its default configuration, MS SQL server runs with Local System
  6. 6. privileges and has the 'xp_cmdshell' extended procedure, which allows execution of operating system commands. The most publicized occurrences of this vulnerability were on the e-commerce sites of Guess.com and PetCo.com. A 20-year old programmer in Orange County, California, Jeremiah Jacks discovered that it was possible to ferret out highly sensitive data such as credit card numbers, transaction details, etc. from these and a number of other sites using specially crafted URLs containing SQL meta-characters. SQL injection vulnerabilities have also been discovered in shopping cart software such as the VP-ASP Shopping Cart, I Generic Free Shopping Cart, Web Merchant Services Storefront Shopping Cart, etc. Of these, the vulnerability in the Storefront Shopping Cart occurred in its login.asp page, and could potentially allow the attacker to execute malicious database queries, without needing to authenticate to the web site. 2.3 Price Manipulation This is a vulnerability that is almost completely unique to online shopping carts and payment gateways. In the most common occurrence of this vulnerability, the total payable price of the purchased goods is stored in a hidden HTML field of a dynamically generated web page. An attacker can use a web application proxy such as Achilles to simply modify the amount that is payable, when this information flows from the user's browser to the web server. Shown below is a snapshot of just such a vulnerability that was discovered in one of the author's penetration testing assignments. Figure 1: Achilles web proxy The final payable price (currency=Seamount=879.00) can be manipulated by the attacker to a value of his choice. This information is eventually sent to the payment gateway with whom the online merchant has partnered. If the volume of transactions is very high, the price manipulation
  7. 7. may go completely unnoticed, or may be discovered too late. Repeated attacks of this nature could potentially cripple the viability of the online merchant. Similar vulnerabilities have also been found in third-party software such as in the 3D3 ShopFactory Shopping Cart, where price and item-related information was stored in client-side cookies, which could easily be manipulated by an attacker. Similarly, Smart win Technology's CyberOffice Shopping Cart 2.0 could be attacked by downloading the order form locally, and resubmitting it to the target server with the hidden form fields modified to arbitrary values. 2.4 Buffer overflows Buffer overflow vulnerabilities are not very common in shopping cart or other web applications using Perl, PHP, ASP, etc. However, sending in a large number of bytes to web applications that are not geared to deal with them can have unexpected consequences. In one of the author's penetration testing assignments, it was possible to disclose the path of the PHP functions being used by sending in a very large value in the input fields. As the sanitized snapshot below shows, when 6000 or more bytes were fed into a particular field, the back-end PHP script was unable to process them and the error that was displayed revealed the location of these PHP functions. Figure 2: PHP timeout error Using this error information it was possible to access the restricted 'admin' folder. From the structure of the web site and the visible hyperlinks there would have been no way to determine that there existed the 'admin' directory within the 'func' sub-directory below the main $Document Root. Multiple buffer overflows were also discovered in the PDGSoft Shopping Cart, which potentially allowed the attacker to execute code of his choice by over-writing the saved return address. Error pages can serve as a valuable source for critical information. These errors can be induced in web applications that do not follow strict input validation principles. For instance, the
  8. 8. application may expect numeric values and would fail when alphabets or punctuation characters are supplied to it. This is exactly what has happened in the case below. Here, the e-commerce website used numbers for its various pages. Users would navigate using a link such as http://www.vulnerablesite.com/jsp/Navigate.jsp?pageid=123. By manipulating the URL and supplying the value 'AA' for the paged, the following error was induced: Figure 3: Discovering information through navigation errors If you observe carefully, the highlighted information reveals the Oracle Application Server version as Oracle 9iAS as well as certain third-party components being used by the web application, such as Orion Application Server. It also reveals the path where other (possibly vulnerable) .jsp scripts exist - /scripts/menu.jsp. 2.5 Cross-site scripting The Cross-site Scripting (XSS) attack is primarily targeted against the end user and leverages two factors: 1. The lack of input and output validation being done by the web application 2. The trust placed by the end-user in a URL that carries the vulnerable web site's name. The XSS attack requires a web form that takes in user input, processes it, and prints out the results on a web page, which also contains the user's original input. It is most commonly found in 'search' features, where the search logic will print out the results along with a line such as 'Results for <user_supplied_input>'. In this case, if the user input is printed out without being parsed, then an attacker can embed JavaScript by supplying it as part of the input. By crafting a URL, which contains this JavaScript, a victim can be social engineered into clicking on it, and the script executes on the victim's system. A typical XSS attack URL would look like this: http://www.vulnerablesite.com/cgi-bin/search.php?keywords=&lt;script>alert("OK")&lt;script>.
  9. 9. In this case, when the victim clicks on this link, a message box with the text "OK" will open up on his system. In most cases, the attacker would craft the URL in order to try and steal the user's cookie, which would probably contain the session ID and other sensitive information. The JavaScript could also be coded to redirect the user to the attacker's website where malicious code could be launched using ActiveX controls or by utilizing browser vulnerabilities such as those in Internet Explorer or Netscape Navigator. However, the JavaScript can also be used to redirect the user to a site that looks similar to the original web site and requests the user to enter sensitive information such as his authentication details for that web site, or his credit card number or social security number. A related attack is shown below: Figure 4: Phishing scam (Source: Article on Security Focus http://www.securityfocus.com/infocus/1745) In this case, the attacker has opened up two windows on the victim's system. The one in the background is the original Citibank web site, whereas the pop up window in front of it requests for the user's debit card number, PIN, and card expiration date. On hitting the submit button, this information is sent to the attacker's server. Called a 'phishing' attack , it was done by sending a
  10. 10. spoofed email that claimed to originate from Citibank and asked users to verify their details. The link in the spoofed email looked something like this http://www.citibank.com:ac=piUq3027qcHw003nfuJ2@sd96V.pIsEm.NeT/3/?3X6CMW2I2uP OVQW Most users would not be aware that as per HTTP rules, this link would actually go to sd96v.pisem.net (highlighted above), and not www.citibank.com Similar attacks can be carried out if the web application has scripts that redirect users to other parts of the site, or to other related sites. For instance, in one of our assignments, the web application had a script that was used to send the user to dynamically created parts of the web site: http://www.vulnerablesite.com/cgi-bin/redirect.php?url=some_dynamic_value Due to the lack of security awareness of the web developers, they did not realize that an attacker could craft a URL such as http://www.vulnerablesite.com/cgi-bin/redirect.php?url=www.attackersite.com and send it to a victim. This URL can be trivially obfuscated by hex-encoding the part that follows 'url=' or by converting the attacker's IP address into hexadecimal, octal or double-word values. For instance if the attacker's IP address is, the URL could be crafted as follows: http://www.vulnerablesite.com/cgi-bin/redirect.php?url=http://7934518627/. 2.6 Remote command execution The most devastating web application vulnerabilities occur when the CGI script allows an attacker to execute operating system commands due to inadequate input validation. This is most common with the use of the 'system' call in Perl and PHP scripts. Using a command separator and other shell metacharacters, it is possible for the attacker to execute commands with the privileges of the web server. For instance, Hassan Consulting's Shopping Cart allowed remote command execution, because shell metacharacters such as |; & were not rejected by the software. However, directory traversal was not possible in this software. In another case, Pacific Software's Carello Shopping Cart had a vulnerable DLL that allowed the execution of remote commands due to directory traversal attacks that could be carried out using a specially crafted URL. 2.7 Weak Authentication and Authorization Authentication mechanisms that do not prohibit multiple failed logins can be attacked using tools such as Brutus . Similarly, if the web site uses HTTP Basic Authentication or does not pass session IDs over SSL (Secure Sockets Layer), an attacker can sniff the traffic to discover user's authentication and/or authorization credentials. Since HTTP is a stateless protocol, web applications commonly maintain state using session IDs or transaction IDs stored in a cookie on the user's system. Thus this session ID becomes the only way that the web application can determine the online identity of the user. If the session ID is stolen (say through XSS), or it can be predicted, then an attacker can take over a genuine user's online identity vis-à-vis the vulnerable web site. Where the algorithm used to generate the session ID is weak, it is trivial to write a Perl script to enumerate through the possible session ID space and break the application's authentication and authorization schemes. This was illustrated in a paper by David Endler, "Brute-Force Exploitation of Web Application Session IDs", where he explains how session IDs of sites like www.123greetings.com,
  11. 11. www.register.com, and others could be trivially brute-forced. Similarly, in one such instance, we discovered that the order ID for the user's transactions was not generated randomly, and it was possible to access the orders placed by other users simply by writing a Perl script that enumerated all possible order IDs within a given range. The most pertinent point here is that although web application may have mechanisms to prevent a user from multiple password guessing attempts during authentication, they do not usually prevent a user from trying to brute- force sessions IDs by resubmitting the URLs as described in Endler's paper. 3. Countermeasures The most important point is to build security into the web application at the design stage itself. In fact, one of the key activities during the design phase should be a detailed risk assessment exercise. Here, the team must identify the key information assets that the web application will be dealing with. These could include configuration information, user transaction details, session IDs, credit card numbers, etc. Each of these information assets needs to be classified in terms of sensitivity. Depending upon the tentative architecture chosen, the developers along with security experts must analyze the threats, impact, vulnerabilities and threat probabilities for the system. Once these risks are listed out, system countermeasures must be designed and if necessary the architecture itself may be modified. Countermeasures should also include strict input validation routines, a 3-tier modular architecture, use of open-source cryptographic standards, and other secure coding practices. Some excellent resources on secure coding are David Wheeler's book "Security Linux Programming HOWTO", Michael Howard's "Writing Secure Code", and John Viega's "Secure Programming Cookbook for C and C++". The Open Web Application Security Project's Guide is also a highly useful document on web application security issues. 4. Conclusion The vulnerabilities discussed in this article are not necessarily exclusive to shopping carts or online payment systems. They could easily be present in other types of web applications as well. However, in the case of e-commerce systems, the vulnerabilities acquire a graver dimension due to the financial nature of transactions. What is at stake is not only a direct loss of revenues, but companies may face a serious loss to their reputations as well. In some cases, they may be faced with legal penalties for violating customer privacy or trust, as in the case of Guess.com and PetCo.com. It is of paramount importance for designers and developers of web applications to consider security as a primary design goal and to follow secure coding guidelines in order to provide the highest possible degree of assurance to their customers.
  12. 12. Ecommerce Security Issues 1-Customer Security: Basic Principles 2-Protecting Yourself Customer Security: Basic Principles Most ecommerce merchants leave the mechanics to their hosting company or IT staff, but it helps to understand the basic principles. Any system has to meet four requirements:  Privacy: information must be kept from unauthorized parties.  Integrity: message must not be altered or tampered with.  Authentication: sender and recipient must prove their identities to each other.  Non-repudiation: proof is needed that the message was indeed received. Privacy is handled by encryption. In PKI (public key infrastructure) a message is encrypted by a public key, and decrypted by a private key. The public key is widely distributed, but only the recipient has the private key. For authentication (proving the identity of the sender, since only the sender has the particular key) the encrypted message is encrypted again, but this time with a private key. Such procedures form the basis of RSA (used by banks and governments) and PGP (Pretty Good Privacy, used to encrypt emails). Unfortunately, PKI is not an efficient way of sending large amounts of information, and is often used only as a first step — to allow two parties to agree upon a key for symmetric secret key encryption. Here sender and recipient use keys that are generated for the particular message by a third body: a key distribution center. The keys are not identical, but each is shared with the key
  13. 13. distribution center, which allows the message to be read. Then the symmetric keys are encrypted in the RSA manner, and rules set under various protocols. Naturally, the private keys have to be kept secret, and most security lapses indeed arise here. : Digital Signatures and Certificates Digital signatures meet the need for authentication and integrity. To vastly simplify matters (as throughout this page), a plain text message is run through a hash function and so given a value: the message digest. This digest, the hash function and the plain text encrypted with the recipient's public key is sent to the recipient. The recipient decodes the message with their private key, and runs the message through the supplied hash function to that the message digest value remains unchanged (message has not been tampered with). Very often, the message is also timestamped by a third party agency, which provides non-repudiation. What about authentication? How does a customer know that the website receiving sensitive information is not set up by some other party posing as the e-merchant? They check the digital certificate. This is a digital document issued by the CA (certification authority: VeriSign, Thawte, etc.) that uniquely identifies the merchant. Digital certificates are sold for emails, e- merchants and web-servers. : Secure Socket Layers Information sent over the Internet commonly uses the set of rules called TCP/IP (Transmission Control Protocol / Internet Protocol). The information is broken into packets, numbered sequentially, and an error control attached. Individual packets are sent by different routes. TCP/IP reassembles them in order and resubmits any packet showing errors. SSL uses PKI and digital certificates to ensure privacy and authentication. The procedure is something like this: the client sends a message to the server, which replies with a digital certificate. Using PKI, server and client negotiate to create session keys, which are symmetrical secret keys specially created for that particular transmission. Once the session keys are agreed, communication continues with these session keys and the digital certificates. : PCI, SET, Firewalls and Kerberos Credit card details can be safely sent with SSL, but once stored on the server they are vulnerable to outsiders hacking into the server and accompanying network. A PCI (peripheral component interconnect: hardware) card is often added for protection, therefore, or another approach altogether is adopted: SET (Secure Electronic Transaction). Developed by Visa and Mastercard, SET uses PKI for privacy, and digital certificates to authenticate the three parties: merchant, customer and bank. More importantly, sensitive information is not seen by the merchant, and is not kept on the merchant's server. Firewalls (software or hardware) protect a server, a network and an individual PC from attack by viruses and hackers. Equally important is protection from malice or carelessness within the
  14. 14. system, and many companies use the Kerberos protocol, which uses symmetric secret key cryptography to restrict access to authorized employees. Transactions Sensitive information has to be protected through at least three transactions:  credit card details supplied by the customer, either to the merchant or payment gateway. Handled by the server's SSL and the merchant/server's digital certificates.  credit card details passed to the bank for processing. Handled by the complex security measures of the payment gateway.  order and customer details supplied to the merchant, either directly or from the payment gateway/credit card processing company. Handled by SSL, server security, digital certificates (and payment gateway sometimes). Practical Consequences 1. The merchant is always responsible for security of the Internet-connected PC where customer details are handled. Virus protection and a firewall are the minimum requirement. To be absolutely safe, store sensitive information and customer details on zip-disks, a physically separate PC or with a commercial file storage service. Always keep multiple back-ups of essential information, and ensure they are stored safely off-site. 2. Where customers order by email, information should be encrypted with PGP or similar software. Or payment should be made by specially encrypted checks and ordering software. 3. Where credit cards are taken online and processed later, it's the merchant's responsibility to check the security of the hosting company's webserver. Use a reputable company and demand detailed replies to your queries. 4. Where credit cards are taken online and processed in real time, four situations arise: 1. You use a service bureau. Sensitive information is handled entirely by the service bureau, which is responsible for its security. Other customer and order details are your responsibility as in 3. above. 2. You possess an ecommerce merchant account but use the digital certificate supplied by the hosting company. A cheap option acceptable for smallish transactions with SMEs. Check out the hosting company, and the terms and conditions applying to the digital certificate. 3. You possess an ecommerce merchant account and obtain your own digital certificate (costing some hundreds of dollars). Check out the hosting company, and enter into a dialogue with the certification authority: they will certainly probe your credentials. 4. You possess a merchant account, and run the business from your own server. You need trained IT staff to maintain all aspects of security — firewalls, Kerberos, SSL, and a digital certificate for the server (costing thousands or tens of thousands of dollars).
  15. 15. Security is a vexing, costly and complicated business, but a single lapse can be expensive in lost funds, records and reputation. Don't wait for disaster to strike, but stay proactive, employing a security expert where necessary. Protecting Yourself Here we provide some practical suggestions for keeping data safe, and not infringing the rules or law relating to tax, search engines and other traders. Office Security The following are obvious but can be overlooked:  use hard-to-guess passwords, restrict access to them, and don't leave them in desk drawers or on PCs.  ensure backups are made regularly, in sequence, and are intelligently labeled.  check backups regularly, i.e. ensure that restores from backups are sound.*  keep paper copies, and in a safe place.  store copies of all essential information, preferable encrypted and off-site in: o zips disks, CDs, removable hard-disks, etc. o online storage facilities.* Protection from Viruses Do the following:  consider using alternative browser(s).  get the appropriate virus protection software, and keep it up to date.*  install a decent firewall.*  set passwords properly on networks ( IT manager's job). Protection from Spyware Many computers are infected by spyware of some sort. Most are 'harmless', but an increasing number pass into viruses that will steal and transmit confidential information, even memorizing the keystrokes of passwords. You need to:  avoid keeping confidential information on any machine connected to the Internet.*  run spyware removal software.*  encrypt confidential information.*  consider purchasing a special guide to spyware.  visit security sites for information on the latest threats 
  16. 16. Protection from Hackers Hackers break into computer systems, sometimes to prove themselves, sometimes with malicious intent. You need to:  install a firewall.*  ensure sensitive information is encrypted.*  maintain proper security (restrict access with passwords) in the office. Protection from Fraud You don't have to accept every order, or not immediately. Escrow services are widely available. Trade associations and other institutions provide useful information and support. Payment service providers have levels of security. Your own order page can ask for further details, and its country drop-down list be amended to exclude the worst offenders.* Affiliate businesses need to be especially careful, and in these ways:  prevent competitors stealing their affiliate links by using inexpensive software for the purpose.*  prevent bogus clicks-throughs by competitors who do not purchase: aim to bankrupt you with the pay-per-click search engines.  impression fraud by competitors aiming to lower your click-through rates and so disqualify your ads with Google. The last two scams are often outsourced to low-wage outlets and/or employ special software. You'll need to track your clicks with special click auditing software (sometimes included in bid management software), or ensure that the company that runs your pay-per-click campaigns does so. Web servers Webserver security is highly technical, as you'll appreciate by reading the articles listed on the resources page. Obvious things to check or ask about:  the financial standing of the hosting company, and how long they have been in business.*  guaranteed uptime*  security protocols to cope with denial-of-service and hacker attacks.*  regularity of backups: does it include user logs, product databases, order tracking logs, server-side scripts, etc.?*  whois database (www.whois.net) to ensure that you and not the hosting company remain the administrative and technical contact for your domain and — most critically — the registrant of the domain.*  backup: ring them at 3 a.m. Sunday morning if they claim 24/7 telephone support.*
  17. 17.  complaints procedure: you don't want your site dumped because of an unwarranted complaint from a competitor.*  other sites being hosted with them (ask for webmasters to contact). Also check: association with spam or porn sites won't help your business.*  the business address of the server (whois). Find the path to the server with a tracing program: with a reseller you'll find some other ISP's server.*  visit forums to see what webmasters really think about hosting companies.*  scrutinize the contract (and employ a business lawyer to check copyright, complaints, fees and service renewal / discontinuation matters).* And:  host alternative company domains with another company: you can then switch painlessly if the first goes out of business or suffers a prolonged denial of service.*  check your webmaster is implementing proper routines, including the updating of passwords regularly.* Webpage Content You are responsible for the content of your webpages, which means ensuring:  nothing is libelous or could be construed so.*  material does not infringe copyright.*  links don't damage the interests of sites linked to (deep-linking may).*  pages don't fall foul of search engine and directory requirements.* America is a litigious society. Play safe, and even consider cloaking techniques to prevent information being extracted from pages and made the basis of frivolous lawsuits. (But only use cloaking if you know what you're doing: search engines will drop a site if they suspect the device is being used improperly.) Customer Data You are always responsible for customer information: an onerous task if it includes credit card and/or bank details. Use secure web forms that automatically transfer and store customer information safely on a third-party secure site.* Encrypt it.* Keep it off Internet-connected machines.* Make several copies and store safely off-site.* Seventy percent of companies that lose their customer data go out of business within the year. Legal Matters Your company is bound by the laws and regulations of the state or country in which you are incorporated. Check that you understand the basics, and have experts to consult if and when needed. Be especially careful of material that could offend the authorities or religious groups
  18. 18. abroad, be considered inflammatory, or supportive of outlawed or terrorist groups — i.e. keep your social and political aspirations for another site and another name. References: 1. SQL injection and Oracle, Pete Finnigan http://www.securityfocus.com/infocus/1644 2. Advanced SQL injection, Chris Anley http://www.nextgenss.com/papers/advanced_sql_injection.pdf 3. News article on SQL Injection vulnerability at Guess.com http://www.securityfocus.com/news/346 4. Jeremiah Jacks at work again, this time at PetCo.com http://www.securityfocus.com/news/7581 5. Achilles can be downloaded from http://achilles.mavensecurity.com/ 6. CERT Advisory Malicious HTML HTML Tags Embedded in Client Web Requests http://www.cert.org/advisories/CA-2000-02.html 7. Definition of 'phishing' http://www.webopedia.com/TERM/p/phishing.html 8. Brutus can be downloaded from http://www.hoobie.net/brutus/ 9. Brute-Force Exploitation of Web Application Session IDs, David Endler http://www.idefense.com/application/poi/researchreports/display 10. Secure Programming for Linux and Unix HOWTO, David Wheeler, http://www.dwheeler.com/secure-programs/ 11. OWASP Guide http://www.owasp.org/