Security Basics for Financial Applications
WHITE PAPER
SECURITY BASICS FOR FINANCIAL APPLICATIONS
Abstract Security is the principal requirement for online financial applications. Data privacy, customer trust, and long-term growth all depend on how secure a financial application is. As these applications are accessed from various devices and through numerous channels, financial organizations strive hard to implement a foolproof security system. In this white paper, we will discuss the core security measures that can be considered while building financial applications. We will start with core design concepts for financial applications, move on to the different security techniques and best practices, and finally, provide a basic security design for financial applications. The financial applications referred in this white paper include web applications, financial portals, and other finance domain-related online applications. Financial applications
Finance applications include applications applications face a host of threats such as the required information aggregation as performing financial transactions such as identity theft, session hijacking, password well. They are integrated with core banking online banking portals, online insurance hacking etc. which has long term impact systems or finance enterprise applications, applications and such for which security is on revenue and user trust. to provide domain-specific features. a prime concern. Most of the e-commerce Additionally, they also offer a wide range of Online financial applications provide a and retail applications invariably deal personalization and customization features variety of features, such as dashboard with payment transactions and hence that enable finance organizations to launch views, reports, personalized customer security would be an important feature of personalized campaigns and features for pages, and for particular financial domains, these applications as well. Online finance targeted segments.
Core security concerns of financial applications
The key security aspects in financial authorization, data encryption, transport- permission models, data privacy and applications include secure authentication, level security, role-based access and robust integrity, and security extensions.
Key security vulnerabilities and ways to tackle them
Based on our experience in financial Man-in-the-middle attacks and details to initiate a financial transaction. applications, we have created a list of the session hijacking An effective way to prevent this attack is common security challenges, the details of to use a security token with each request In this kind of attack, the hacker may that is validated on the server-side. We will security vulnerabilities, and the effective intercept traffic between the requestor learn more about this technique and its measures to address them: and the finance portal. The first step in implementation in the following pages. Multiple sessions preventing such an attack is to use a secure transport layer, such as HTTPS, for Injection attacks Financial applications usually do not allow all secure interactions. The rule applies for The attacker can use SQL injection multiple sessions due to security and data- finance services as well. In addition to this, techniques to gain information access. The integrity concerns. Using a combination of we must encrypt secured data (such as user vulnerability can be exploited by appending the following approaches should restrict information, finance information) during SQL keywords and comments (such as these multiple sessions: transit, and decrypt before rendering to appending ‘1=1’ to the query string). the client. • Create session filters to intercept every In order to effectively mitigate this, we user request, and use a database- Request spoofing and cross-site need to: driven table to check the multiple request forgery (CSRF) session information, in order to restrict Validate all user input on the client as In such a vulnerability, the attacker may • the user sessions based on the session well as the server-side and maintain a send a forged request to the server. data blacklist of characters for this validation The attacker can gain access to request • Restricting the user sessions at the parameters using techniques such as • Encode or remove HTML and SQL- server side: Server modules (such as snooping, and can then construct an reserved characters core banking modules) keep track of attack-script to make the portal believe Use prepared statements instead user that the request is coming from a genuine • of direct SQL commands in the source. For instance, if the attacker obtains Combining these two approaches allows a application. Use object-relational the session ID or is able to intercept the truly single session-based implementation. mapping (ORM) tools, such as request, he / she can use the session Hibernate,for database interactions
External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited Key security features of online finance applications
Besides core security features such as Nonrepudiation occurs based on the Endpoint security refers to protecting the authentication, authorization, single- following two criteria– The user is the endpoint device to comply with anti- sign-on, session management, account legitimate identity that sent the content/ malware and virus protection to prevent, management, financial application should performed the transaction;the content/ detect, and remediate any malicious also deal with other security such as follows: transaction details are not modified in programming on the system. This helps the middle, as data integrity is ensured in restricting any malicious program that Federated identity and access through a hashing algorithm. might be tracking keystrokes to obtain management sensitive information. Crypto libraries The identity and access management Virtual keyboards help in reducing the risk Crypto libraries are the cryptographic can be federated across the domain, and of key loggers logging keystrokes, as the libraries used in Internet standards to share the same identity store and access clicks happen only on the virtual keyboard provide encryption algorithms. manager for all user groups. This strategy to input the data. This also makes it more works best in subsidiaries and acquired The functionality includes key generation difficult for malware programs to track the entities. algorithms, key exchange agreements, and clicks and obtain the input data. However, there is a possibility that the malware Strong nonrepudiation using DS public-key cryptographic standards. For finance applications, it is recommended to can take screenshots upon each click and Nonrepudiation means that a party cannot use a salted password-hashing algorithm hence, the endpoint should be secure and deny the authenticity of their signature as discussed below. updated with respect to anti-malware upon the sending of a message. programs as well. Endpoint security – Anti-malware / In the digital world, nonrepudiation can virtual keyboards. be achieved through digital signatures.
Financial application key design considerations
Listed below are some of the key design • Adoption of services-oriented iteratively to ensure that the aspects that need to be kept in mind while architecture for integration – An ESB desired performance service-level developing finance applications. These middleware can be used to handle agreement (SLA) is met complex and multiple services and are additional design factors along with Scalability can be achieved by enable service-oriented integration security. using the appropriate infrastructure between different banking systems and hardware • Open standards-based technology Leveraging open-source technologies and integrations – This includes using wherever applicable Incorporation of a governance standards related to HTML, CSS, and model to proactively check the Continuous build and integration accessibility to name a few • heartbeat of the systems to ensure approach for execution –Tools such as system availability and uptime • Layered architecture using MVC Jenkins Continuous Integration can be pattern – This provides a clear layer- used to maintain build quality • Reusability and automation: Reusing wise separation of components the existing components and Performance, availability, and with each layer handling a distinct • frameworks will profoundly impact scalability –Performance should responsibility. MVC enables loose developer productivity, faster time- be thought through, right from coupling, separation of concerns, and to-market, and significantly increase the component design to the flexibility to change the components in the overall quality. Based on the given performance testing stage. In addition each layer independently business requirements, the following to performance-based design, other components are marked for reuse, • Modular and extensible component performance optimization techniques partially/completely: design –Each of the solution can be adopted, including: components will be designed such that High Level architecture of finance it can be reused for future needs The solution will also be tested applications
External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited A high level overview of a sample finance web application is shown below:
Support, Management Client Application Content Information, Widgets Widgets Governance, Presentation Common & Layer Server Security Presentation Content Services Publishing Services Users & Roles REST
Authentication Business Process Rules Processes Process Layer Orchestration
Authorization
Single Sign On Service Mediation Adaptors Transformation Validation Routing (ESB)
Con guration
Logging Business Service Business Services Service Aggregation Layer
Caching
Exception Integration Data Access Components Service Gateways Handling Layer
User Store Database Data File System Services Services 1 Services 2 Services 3 Sources
A typical, n-tier MVC architecture here. Presentation layer consists of financial be used for service mediation and to for finance applications has various widgets, portlet, reports, and handle handle concerns such as routing, protocol components, with MVC architecture other presentation concerns. Business transformation, validation etc. Business providing separation of concerns for the layer processes business logic, rules and layer exposes various business services and various layers. Service-oriented integration business processes. Typically a message integration layer integrates with necessary is the de-facto standard for integration oriented middleware such as ESB would enterprise interfaces.
The different security aspects of financial applications
After having discussed core security Here, we provide comprehensive coverage security issues. Let us start by looking at concerns, let us deep-dive into the other of security techniques and proven core security features required in a typical security aspects of financial applications. methodologies to effectively address financial application:
External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited Authentication
Authentication is all about allowing a enough for a typical banking or financial authentication mechanism should not stop user to login based on a username and application? at validating the user credentials. So what credentials. However, would that be In banking applications, the primary else would be required?
Password policy
Let us go with an encryption algorithm to encrypted value. Thus, it is easy to maintain What is the solution now? encrypt and store the password. SHA, MD5 a lookup table of all possible combination Salted Password Hashing are some of the encryption algorithms of passwords. In some cases, if not most, that generate an encrypted password of the user’s password will be one of a Salted password hashing algorithms– these the user and store them in the database. dictionary word. Hackers can thus create a algorithms, such as the BCrypt Password We all agree that it will never be possible lookup table for each dictionary word with Encoder, generate different encryption to decrypt the encrypted password from a mapping encrypted password. If they values for the same password input. How these secure encryption algorithms, but gain access to the encrypted password, is it possible? For every password, the hackers will not try the obvious. Would they can easily crack the password using algorithm generates a random ‘salt’ that is they? They would try to identify any this lookup table. inserted to the original password before loopholes in these secure encryption it is encrypted. Thus, different encryption Although this vulnerability can be limited algorithms and exploit them instead. The values are generated for the same to a certain extent, by introducing stronger authentication mechanism should thus password input, and lookup tables can password policies that restrict the use of be foolproof against brute force attacks. If never be created for such algorithms. The direct dictionary words. Hackers have gone you wonder what brute force attack is, it salt is embedded along with the encrypted a step further already– they have begun to is a trial-and-error method used by hacker value, and only the algorithms themselves suffix, prefix, or insert the possible special application programs to decode encrypted can gain access to the salt, and validate the characters, numeric values, as well as the data such as passwords. supplied password. And these can never be appropriate casing around it. They are thus decrypted. For the same password input, these able to create the lookup table regardless. encryption algorithms generate the same
Request identification Banking applications need to go that one- request is allowed, and another Request ID • Sophisticated attacks like CSRF (Cross step extra – they should also authenticate is generated and sent to the portal client, Site Request Forgery) can also be each request and authenticate the request which also stores the new unique identifier prevented using Request IDs even after post-login. This will prevent any in server cache or persistence storage. Once again, browser refresh is not session hijack. Now how is this achieved? This process repeats for every request, • possible, and a user cannot resubmit enhancing the security measures at each Immediately after validating user the same request, as the valid unique step. credentials, a unique identifier (let us call identifier cannot be supplied to the it a Request ID) can be generated and • Session hijacking is not possible as server for validating the request mapped to the customer ID in the server every request needs to have the Simultaneous sessions can be cache or persistence storage. The same Request ID,which the server expects • prevented in the same way, as the new value would be returned to the portal from the portal client session cannot provide the Request client, which would be appended to this The refresh, back, and forward ID the server expects – thus, no new Request ID for the subsequent requests. • navigation within the history is not session can be established. If security The request filter would then validate possible on browsers as the session is highly critical, both simultaneous the Request ID sent by client, against the is destroyed when a valid unique session can be destroyed, prompting unique identifier stored in the server cache identifier cannot be supplied to the users to authenticate themselves again or persistence storage. If they match the server for validating the request
External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited A sample secure user-registration and user-authentication flow is shown in the following diagram: