Modernizing Authentication — What It Takes to Transform Secure Access
By Aleksey Abramovich, A1QA
The use of credit and debit cards is a main concern in e-commerce application security. The breach of card details can result in major damage to any company, but there are many mechanisms that can be implemented to ensure bank card security and protect users' money from hackers.
E-commerce is rising, with many buyers preferring to purchase goods at the click of a mouse or swipe of their screen. The growth rate has surpassed the conventional security measures set in place to control online commerce and prevent consumer data fraud. Usually, every new e-commerce innovation is accompanied with a new security risk. So it's not a surprise that card holders, card issuer banks and sellers of products are concerned about the security of payment cards that are used to pay for goods and services online.
A strong and robust application storing users' payment details is the responsibility of the whole team. Product owner, product manager, developers, testers and designers must be aware of the mechanisms and best practices aimed at making a more robust and safe e-commerce app and stipulate their incorporation.
Implementing E-commerce Security Mechanisms
First, to make any application storing users' payment details safer, e-commerce being no exception, there should be proper mechanisms for authentication and authorization. They will make it possible to distinguish between the website visitors' rights and personal data. The mechanisms are the main attacking vectors and should be as safe as possible because if breached, they will provide access to users' sessions.
Development teams should apply proper security measures to build a secure e-commerce product that will employ customers' debit/credit cards.
One measure is to validate all data input by users. This will help avoid all kinds of injections to the application code. It's also important to implement control over the application and web server configuration to avoid frequent mistakes related to misuse of SSL/TLS protocols. Attackers may benefit from the protocol mistakes and pick up payment data the user inputs to the application.
The second largest vulnerabilities are located on different levels of system composition of the web applications, such as web server, third-party libraries and database servers.
Sometimes development teams are confined to a particular version of these components and can't update them due to incompatibility with the previous version. As a result, a developer can't update the current third-party library version if it has revealed any vulnerability. The developer has to fix it on his own, which is a time-consuming process; the application may be hacked while being fixed.
The Password Problem
Another serious problem is the use of standard/weak passwords to protect the administrator panels.
Password policy making is a challenging process. Passwords should be easy to remember and difficult to spot. These requirements contradict one another, and developers have to compromise. The best way around this is to follow the accepted policies, for example the PCI-DSS standard, which requires a minimum password length of seven characters containing both numbers and letters.
The good news is that business owners and application management teams have some evident and easy steps to take if they've found card details have been breached.
What to Do about a Broken E-commerce App
The first step is for the software developer to inform the payment card owner of the breach as promptly as possible. This should allow the cardholder to block their card in time. Secondly, the application owners should check all users with administrator access rights and change all passwords in the application.
Then the app safety should be investigated to detect all bottlenecks that might have been used by attackers. Possible attack vectors should be outlined, and then it's necessary to eliminate all the detected vulnerabilities and draft measures to prevent the same scenario from repeating in the future.
In this context, it can't go without mentioning phishing, which is a popular form of fraud. The attacker tries to learn login credentials by masquerading as a trusted entity or person in email or other communication channels or tries to acquire confidential information by directing a user to a fake page that looks legitimate.
It's no secret that it is very difficult to combat phishing completely. The most effective cornerstone technique to reduce phishing risks is to educate users who are often the first and the last lines of defense, and therefore any workable solution must include them.
For example, the secure application should have a policy and usage notice informing the user of the application's behavior. Any user should be informed that you won't ask him or her to provide personal information directly by email, for example. More important, all information should be provided in easy terms and attract users' attention when they surf your website or application.
Security Testing within the SDLC
While there are many approaches to running security testing, one common method verifies the application source code (white-box testing), while another often used approach performs an external review (black-box testing).
The first method takes more time, but helps to reveal numerous vulnerabilities and hidden errors that cannot be found otherwise. However, black-box testing offers the advantage of detecting within the shortest time the crucial vulnerabilities and contradictions that can be used by the attackers. It's advisable to perform black-box testing after any new functionality has been implemented.
There is also a third approach, which is a combination of the two mentioned above. It is called application security. It helps prevent the emergence of vulnerabilities in all stages of the project.
This all leads one to question software development and testing integration: should it be one process or two parallel ones? Within the context of this article, it is vital to implement security testing throughout the software development life cycle so that the revealed vulnerabilities can be properly addressed in a timely manner.
Unfortunately, in many organizations testing is often conducted as an afterthought at the end of the development cycle and the cost of the defect elimination increases. The National Institute of Standards and Technology estimates the cost to be 30 times higher when the code is revisited and changed to fix security vulnerabilities after the development is completed.
Integrate security within the SDLC up front, with no regard to the project scope and functionality. Of course, the share of information security may vary for every project. Small products will need less security, and consequently it will be less costly to implement.
E-commerce Security Best Practices
Finally, there are many industry standards, guidelines and best practices focused on securing e-commerce applications and its accompanying environment that should be taken into account. They foresee strategies to enhance web application security.
The most relevant for any web projects are WASC and OWASP, specifying vulnerabilities classification and recommendations for development teams.
Complying with the in-field policies, as well as with the company's internal guides, will make payments via your application safer and raise your consumers' trust. And this is ultimately what it's all about.
Aleksey Abramovich is a senior QA manager at A1QA, an independent software testing and quality assurance company, where he is responsible for project management and coordination, staff recruiting and teaching, and QA team work optimization. He is also a coordinator for the Security Testing Center of Excellence. During his eight years with A1QA, he and his team have executed countless projects for well-known companies to deliver safe and secure IT products. Aleksey enjoys sharing his knowledge and experience speaking at industry events and writing articles on security and penetration testing trends and methodologies.