INTRODUCTION
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.
Consumer privacy is becoming the most publicized security issue replacing theft and fraud as top concerns in e-commerce. The DDOS attacks demonstrated that business sites did not maintain adequate security protection and intrusion detection measures. Some of the sites did not detect the compromise, which occurred months before the DDOS attacks. The hackers who penetrated these sites had the ability to deliver a data integrity attack on the compromised business for the same amount of time. Businesses were spared simply because the hackers chose not to attack them in that manner. No customer will want to use a business that distributes sensitive customer data such as credit card information, SSN information or credit limits without the knowledge or permission of the customer.
User and system administrator awareness is becoming more important in the effort to counter e-commerce attacks. Consumers are slowly becoming aware of some security features such as encrypted web transactions, privacy statements by companies, etc. Internet service providers are becoming more responsive to complaints about Internet abuse originating from their sites.
E-commerce security needs to be addressed not only at the business site with its servers/network, but also on the client side, which includes direct connected home computers. It is this group of computers that are the most vulnerable to attack because the level of user security training or awareness is not high at all.
Today rapidly increasing using online transaction on online payment systems.the attacks for such systems is increasing more than that. Most of these attacks have utilized vulnerabilities that have been published in reusable third-party components utilized by websites, such as shopping cart software and poor design of such websites. Other factor is user awareness of security vulnerabilities.
Today there many types of attacks for e-commerce applications. such ass SQL injection, denial of service attacks, Cross-site Scripting (XSS) attack ant etc.
- SQL Injection - this will use sql quarries to get information, update or damage the system.attacker's queries are executed by the back-end database.SQL injection techniques differ depending on the type of database being used.
- Price Manipulation - This is almost completely unique to online shopping carts and payment gateways.attacker can get and change the hidden information while transaction.
- Buffer overflows - Sending in a large number of bytes to web applications can damage and get important information while the application is generating the errors.
- Cross-site scripting XSS - 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.
- Remote command execution - When 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.
Vulnerabilities
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. It is found that there are 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.
Let’s look at the common security vulnerabilities that have been discovered in E-Commerce sites.
Using denial of service attacks
The denial of service attack is one of the best examples of impacting site availability. It involves getting the server to perform a large number of mundane tasks, exceeding the capacity of the server to cope with any other task. For example, if everyone in a large meeting asks you your name all at once, and every time you answer, they ask you again. You have experienced a personal denial of service attack.
Distributed DoS is a type of attack used on popular sites, such as Yahoo!®. In this type of attack, the hacker infects computers on the Internet via a virus or other means. The infected computer becomes slaves to the hacker. The hacker controls them at a predetermined time to bombard the target server with useless, but intensive resource consuming requests. This attack not only causes the target site to experience problems, but also the entire Internet as the number of packets is routed via many different paths to the target.
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 privileges and has the 'xp_cmdshell' extended procedure, which allows execution of operating system commands.
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.
Achilles web proxy
The final payable price (currency=Rs&amount=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 may go completely unnoticed, or may be discovered too late. Repeated attacks of this nature could potentially cripple the viability of the online merchant.
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.
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 $DocumentRoot.
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=<script>alert("OK")<script>. In this case, when the victim clicks on this link, a message box with the text "OK" will open up on his system.
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 meta-characters, 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 meta-characters such as |;& were not rejected by the software. However, directory traversal was not possible in this software.
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.
Conclusion
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.