This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
An Implementation of Secure Banking SystemAbstract- Online Banking is an indispensable factor in everyday life and users’ trust remains with the reputation of the bank. Thus it’s the need of the bank to ensure the customers that it is fully secure against all the various current and new security attacks which are emerging every day. Our implementation of Secure Banking System (I.R.A Bank) comprises of various standard functionalities of the bank along with additional emphasis on the security features. This paper would be benefitted by the contemporary programmers and research scholars focusing in web security.
Index Terms—secure banking, SSL, SQL Injection, Phishing, PKI, User management, Session Management, XSS attacks.
A secure banking system implementation comprises of the usual day-to-day online activities of the bank with more emphasis on the security features. It should provide an extra layer of security for the transactions, bill payment and other features for the end user. There has to be a secure way to access the system logs, transaction details and user management for the bank administrators. Thus, the project’s need was to develop a secure banking system with some transaction functionalities for the external users and management functionalities for the administrators, coupled with security features.
Our implementation of a Secure Banking system (SBS) is I.R.A Bank where we have various banking functionalities like credit and debit funds, transfer the funds among two individuals, Merchant bill payment and so on, with added security features to be discussed in the later part of the paper. Various banking features and the security features were tested by us and underwent a round of rigorous peer testing. Thus we will be addressing the features implemented and the lessons learnt by us in the following sections of the paper. We used Spring MVC, Hibernate ORM, and MySQL as database for this project.
This paper is arranged in the following format. Section 2 discusses the overview of the project and the various functionalities implemented. Section 3 discusses the list of various security features implemented in the project. Section 4 addresses the lessons learnt during various stages of this project followed by the conclusion and acknowledgements.
II. Overview of the project
The basic need of this project is that user should be able to access this Banking system from any place and any device. Thus the project was hosted in ASU’s VLAB cloud environment and thus end users are able to access our I.R.A bank through a particular URL over internet (HTTPS).
A. Project Overview
The project is divided into two major divisions a) Services offered to the External Users b) Services offered to the Internal Users. External Users include the merchant and regular user whereas Internal Users include the bank employee and the admin user. New User registration module access is given for the external users (Regular user and Merchant).
In the User Account management, we developed the following features for a regular user. User can view his/her account details, perform credit and debit funds operation, transfer funds to other user’s accounts, can edit his personal information, can change some of the transaction details and authorize the bank employees to view his review transactional details. The regular user can raise any issue to the admin and can track the raised issues from a link “My issues”.
- Some of the operations performed by User.
Merchant User can submit the bill payment of the user, to the bank after the proper authorization from the regular users. This is achieved securely with the help of 2-way Public Key Infrastructure (PKI) authentication of both the user and merchant which voids the Man In The Middle (MITM) attack. PKI will be explained more in the security section of this paper.
The Internal user (bank employee) in our project has the following functionalities. Bank employee can view, edit and approve the transactions upon the necessary authorizations from regular users and merchants. The admin user can view the user’s general information like First name , last name but his confidential information can be viewed only after his/her consent and authorization of Government agency. Admin can approve for critical transactions in our project, when the transaction exceeds a particular amount (5000 USD). Admin user can edit, delete the basic information of the users.
- Home page dashboard for an administrator.
B. Banking Functionalities implemented
1) Debit and Credit Funds:
External Users, both regular user and merchant were provided with Debit/Credit link to perform their credit/debit transactions.
2) Transfer Funds:
External Users, both regular user and merchant were provided with Transfer Funds link to transfer funds from their account to other user’s account. If the transaction is less than 5000 USD, there are no approvals needed. If the transaction exceeds the above mentioned limit, then it is a critical transaction and requires the approval from an internal user and PKI is involved. User has to provide the account details of the other user and the amount to be transferred along with his PKI which will be digitally verified by the bank using his public key.
3) Bill pay:
PKI is implemented for this feature. An interface was provided to merchant who initiates a bill pay request to the user. Secondly, user signs that request with his private key and the merchant uses his private key to identify himself to the bank. An UI was given to the bank which checks both the user and merchant details and approves/rejects that bill pay transaction. This way MITM can be prevented and the critical transactions occur in a secure environment.
4) Technical Account Access:
Internal users (admin and bank employees) were provided an interface to access the account details of the external users only after their authorization. If the details to be viewed is Personal information (PII) then Government agency authorization was also mandatory.
5) Transactional Account Access:
Internal users (admin and bank employees) were provided with an interface to access the transactions details of the external users only after their authorization.
C. My Contributions
To get more expertise in web programming for the large scale projects of this kind, I took the responsibility of designing the base project. Right from designing the class diagram and database design I went on creating the initial base application of our I.R.A Bank application. This included setting up of spring xml files and defining a general structure of the project. I had setup hibernate interactions for the base project which would be referred by teammates in the later stages of the project. I have developed spring security for the project which helps in the role based authentication for the application and it prevents access to unauthorized users. I had created a global exception handling mechanism which catches any unforeseen exceptions and errors during the runtime and thereby not exposing the confidential information of the project to the attackers. I had created the user registration mechanism with client and server side validations with the necessary business logic and database interactions. I created the admin functionalities like edit, delete and view user account information and accessing the system logs. I worked with my team mates in other parts of the project like OTP and PKI and got involved in various phases of testing.
III. Implemented security features
A. Preventing SQL injections
SQL injection is a common attack pattern where the attacker tries to get sensitive information from the system by injecting the forms with SQL queries/query parameters. Usually the dynamic SQL queries are the victim of SQL injections.If the attacker passes the serverside whitelist validations then they can get hold of the data if SQL injection is not prevented. One way of preventing SQL injection is to use parameterized queries. As given in the Section 2, we have used Hibernate ORM which uses parameterized queries. The idea is to avoid using the user input query string directly while creating dynamic SQL query statements.
B. Preventing Phishing attack:
Phishing is a major security concern in modern-day websites. The attacker might send a malicious email to the user and the user clicks on the link given in the email which redirects the user to attacker's fraudulent website and the personal details from the user are requested. This is how the attacker gets the confidential user information. We have prevented phishing attack in our Secure banking system by using a SiteKey, which is a way of gaining the trust of user by mutual authentication.
- SiteKey shown to the user for mutual authentication is one of the ways to prevent phishing.
C. Implementation of PKI:
PKI was implemented in two modules of the project.1) when there is a critical transaction of more than 5000 USD, then the user has to identify himself by signing the request with the private key received during registration. The Bank will verify the user using his public key and will approve the transaction. 2) When the merchant initiate a bill pay request to the user, user signs the request with his private key and the merchant uses his private key to identify himself to the bank. Bank checks both the user and merchant and approves the bill pay transaction. This way MITM can be prevented and the critical transactions occur in a secure environment.
D. Prevent exposing of confidential information:
When there are some unforeseen errors in the application, it doesn’t expose the code details or any other confidential information. It redirects itself to a global exception page designed by us. This was tested vigorously by peer testers for various type of errors and in all cases the expected behavior was exhibited.
E. Prevention of brute force attack:
We have limited the number of login attempts to five in our application. When the attacker tries to get hold of the user’s account illegally, the attacker gets blocked after five wrong attempts. The real user can request for a change in password after answering two security questions and entering the secret code received in the OTP mail. This process considerably reduces the brute force attack and the dictionary attack by the attackers.
F. Prevention of XSS attack:
G. Forgot password with OTP:
We have implemented “Forgot password” feature with various layers of security. The first level is to answer two security questions set by the real user. Here we have allowed the user to set his own questions to prevent privilege escalation and weak password recovery mechanism for forgotten password as given in . The second layer of security is to enter the OTP code received in the mail. It expires in 5 minutes and virtual keyboard is used here to prevent keylogging attack.
H. Role based authentication:
We have role based authentication implemented in our project. Each user is assigned a role and they can view the pages only which they are authorized to. This is done using Spring security and the unauthorized users will be redirected an “Access Denied” page.
I. Prevention of session hijacking:
We have implemented a session timeout of five minutes, and the session automatically becomes inactive after five minutes of inactivity.
J. URL pattern manipulation:
The major security concern in modern day websites is URL pattern manipulation, i.e. the attackers can guess the URL of the other modules of the project which they are not authorized to view and make severe damage to the system. This is prevented in our project by using Spring Security to have role based authentication mechanism. The malicious unauthorized users cannot view or change the contents of the page where they don’t have an access.
K. Prevent keylogging:
We have used virtual keyboard in important modules like forgot password (OTP) where the user is enforced to enter the OTP code received in the mail only through virtual keyboard to prevent keylogging attack.
IV. Lessons Learnt
A. Never trust the user’s input:
Not trusting the user’s input is the primary secure software design principle learnt during the course of this project. We assumed that all the inputs entered by the user using forms are malicious and “defense in depth” strategy was applied and strong while list validation was performed in all the web forms.
B. Use Serverside validation:
C. Enforce password strength:
We missed out this important security feature of enforcing an effective password strength. But in the future implementation we have planned to enforce a strong password strength validation with minimum 8 characters length, one capital letter, one number and one special character. This will reduce make brute force attack and dictionary attack more difficult.
D. Fail Securely:
During the course of the project, we as a team learnt one of the secure software design principle “Fail Securely”. It is expected that during some unexpected and unforeseen circumstances the software fails but it should be handled properly that the confidential information like code snippets, database table details/structure, and subroutines name should not be exposed. We have implemented a global exception page, which routes the user to “Oops! Something went wrong. Please try again” page.
E. Teamwork and version control software handling:
For huge projects of this kind, proper usage of version control system is mandatory. We used git for version control and initially during the first phase of development, we had problems in merging and conflicts due to frequent changes. We got used to it and understood the concepts as we progressed in other phases of the project.
As discussed in the Section II, we have implemented various banking functionalities for all types of users. As given in Section III, the most common security lapses in modern day websites are prevented in our project and their necessary explanations were provided. In Section 1V the lessons learnt by us were provided, which should be taken seriously by anyone who wishes to design and develop a secure banking system. This is applicable to us as well, for future enhancements and implementations.