Attack-driven Testing of Payment Management Systems for Credit Cards
As credit cards being a status symbol are being used by almost everyone, managing their payments has become an increasingly complex area. Credit card payment management system is the most common banking application, so the need for having a foolproof secure system is of prime importance. Software testing engineers are building comprehensive threat profiles and test plans by proactively putting themselves in the shoes of smart attackers.
The objective of deploying such an attack-driven testing is that security holes in these sensitive applications can be plugged to the best possible extent before an attacker can find them. Of course there is no end to the imagination of evil minds, yet the testers have to stay constantly alert on the new potholes.
An overview of credit card payment management systems:
Credit card payment management systems are used by banks to track the payments and follow up on past due payments. These applications automate a lot of the work in managing card payments and reduce the manual interventions required for ensuring payments.
There are many ways the bank receives payment for a
credit card:
1) Cheques deposited by customers at ATMs and bank branches;
2) Online transfers from Internet banks;
3) Cash payments at the counter at the bank branches;Where the funds are received as cheques or cash, data-entry operators enter the details to the credit card payments application. Where online fund transfers are used, messages are exchanged electronically between the receiving system and the credit card payment system.
The credit card payment management application keeps track of all the payments of the customers � monthly payments, premiums, late fees, interest, etc. It calculates the monthly charges, generates the credit card statements to be mailed to customers, and sends instructions for scheduling the dispatch. This is the application that calculates the minimum amount to be paid in the month and the due dates.
These days payment management applications handle hundreds of different credit card products for the bank – each having diversified facilities and charges. The monthly credit card statement should reflect these accurately. Banks regularly create new products to serve new market requirements, and the payment application has to be flexible enough to keep pace with these innovations.
The application also has important monitoring functions like – when a customer has defaulted on payments repeatedly, it can alert the bank to the event. Different types of alerts can be configured to detect high-risk customers or abnormal behavior.
Administrative users have the privilege to maintain master records for products and create new users. Data-entry operators have privileges to add new transactions. The help desk can query the application for the status and details of payments. External applications interface with the application to provide details of online payments.
The newer-generation credit card payment management systems are generally web-based. Web services interfaces enable these applications to receive payment details from other systems.
Creation of Threat profiles:
Threat profiles are also of two types: like generic profiles, and the specific threat profiles. The easiest method to visualize the threats to the security of the application is the combination of the generic threats and the other threats that are more specifically applicable to the credit card payment management application.
A) Generic threat’s profile:
1) The attacker violates the dual approval or maker-checker system.
2) The attacker violates the data integrity in the software application.
3) The attacker bypasses the system used for authentication.
4) The attacker mischievously captures the passwords of some other users.
5) The attacker shuts down the software application.
6) The attacker hijacks the working session of some other user.
7) The local attacker mischievously captures sensitive data out of the user�s PC.
8) The attacker takes full or partial access of the server machine.
9) The attacker bypasses the audit trails.
B) Threat profiles applicable to credit card management system:
1) A data-entry operator is able to approve a payment without actually being made.
2) The attacker is able to change the due date of payment for a credit card.
3) The attacker is able to change the amount of transaction made on the payment from a user�s credit card.
4) The attacker is able to manipulate the credit card service charges & premiums of the users.
5) The attacker is able to manipulate the interest rates on different types of credit cards like platinum, gold & silver etc.
6) The attacker is able to modify the list of defaulters of credit cards.
7) The attacker is able to prevent the passing of informing about overdue payments to the customer.
8) A data-entry operator is able to steal the PIN numbers or CVV numbers from the database.
9) A data-entry operator is able to see the statements & other confidential reports related to the credit card.
10) The attacker is able to deactivate the entries without due authorization.
11) The attacker is able to change the schedule of statements being dispatched to the customer.
Check points in the test plan:
Intelligent software testing engineer following the approach of attack-driven testing uses following checkpoints in his/her test plan.
1) Can a data-entry operator approve a payment from the credit card without actually being made?
# Test if we are able to add a false credit card transaction using some parameter manipulation.
2) Can an attacker change the due date of a credit card payment?
# Test if we are able to change the payments due dates with the help of SQL injection.
# Test if we are able to change the payments due dates with the help of parameter manipulation.
3) Can an attacker change the amount of a transaction on a user’s credit card payment?
# Test if we are able to change the amount parameters with the help of parameter manipulation.
# Test if we can bypass the validations done at the browser.
# Test if we can clear the payments of credit card with the help of SQL injection.
4) Can an attacker manipulate the credit card premiums & service charges of users?
# Test if we can modify the rate of interest charged with the help of parameter manipulation.
# Test if we can modify the premiums of the users with the help of SQL injection.
5) Can an attacker manipulate the interest rates on regular, silver, gold and platinum credit cards?
# Test if we can modify the credit card with the help of parameter manipulation.
# Test if we can modify the cards interest rate by escalation of privilege with the help of parameter manipulation.
6) Can an attacker modify the list of credit card defaulters?
# Test if we can edit our list of defaulters or enhance the privileges with the help of SQL injection.
# Test if we can delete the name of the use from the defaulter list with the help of parameter manipulation.
# Test if we can access the privileged data without actually logging to the software application.
7) Can an attacker prevent the application from informing the customer about pending or overdue payments?
# Test if we can switch off some other person�s informing using e-mail features by enhancing privileges with the help of parameter manipulation.
# Test if we can modify the list of outstanding payments with the help of parameter manipulation.
# Test if we can trick the user into turning off information by e-mail with the help of CSRF attack.
8) Can a data-entry operator steal the credit card PINs and CVV numbers from the main database?
# Test if we can modify the SQL queries of database with the help of SQL injection.
# Test if we can transmit the credit card information in a plain text through wire.
# Test if we can capture the information on credit card by using the refresh feature of the browser, despite logging out by the user.
# Test if we can directly exploit the known vulnerabilities of the database.
9) Can a data-entry operator view the credit card statements & other confidential reports?
# Test if we can modify the requests to view the confidential reports with the help of parameter manipulation.
# Test if we can see the sensitive reports in the cache/history of the browser.
# Test if we can access the sensitive reports without actually logging to the software application.
10) Can an attacker deactivate the entries of others without authorization?
# Test if we can deactivate credit card entries of some other users with the help of parameter manipulation.
11) Can an attacker change the schedule of credit card statements being sent to the customer?
# Test if we can put off the subscription of some other user with the help of parameter manipulation.
# Test if a user can change the preferences of other users with the help of SQL injection.
Conclusion:
1) Although attack-driven testing is an excellent proactive approach of security testing, yet there remains a drawback of false sense of security.
2) Comprehensive checklists of attacks as described above must be kept up-to-date with new experiences. Such checklists are very valuable both to analysts defining requirements and to the software testing engineers.
3) All said and done, it remains a cat-and-mouse race between the attackers & the testers; wherein the evil minds usually dominate.
Many More Articles on Risk Analysis & Security Testing
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.