CSRF Attack For Banking Apps

Cross-site request forgery vulnerability is currently ranked Number 8 on the OWASP Top 10 vulnerabilities chart and is a very common application-layer vulnerability to exploit. It’s also known as a one-click attack, Session Riding and abbreviated as CSRF (sometimes pronounced sea-surf) or XSRF.

WHAT IS CSRF

CSRF allows the malicious attacker to use an active session of the victim and make a target system perform actions on behalf of victim without his prior knowledge , at least until the unauthorized transaction has been committed.

It’s a type of malicious exploit of application whereby unauthorized commands are transmitted from a user to the trusted website. CSRF incidents are hard to detect as they are disguised into normal user requests.

Key Concepts of Cross-Site Request Forgery

As mentioned above, CSRF occurs when a malicious web site, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted application which is currently authenticated by user.

As explained in above diagram first the victim logs in to application, which initiates the session between victim computer and application server and creates a unique ID for victim. He is then free to interact with the server and perform data modifying tasks.

The hacker uses social engineering techniques such as unsolicited emails with HTML content, malware planted on popular WebPages, etc. and make the victim click on malicious URLs which contains legal commands for the targeted application.

Once victim clicks on the malicious URL , victim’s browser generates unauthorized requests using the same session ID acquired earlier. Application assumes the request or commands are coming from the Victim(User) and performs them. This way attacker inherits the identity and privileges of the victim to perform an undesired function on behalf of victim.

Therefore if the user is currently authenticated to the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.

Objectives of CSRF attacks
⦁ Transfer money from bank
⦁ To add or delete content from a application.
⦁ Changing user’s password.
⦁ Add items to a user’s shopping basket.
⦁ Changing the delivery address of an order.

CSRF attack in banking applications

The victim enters his banking application (www.xyzbank.com) and initiates a session.

He is given a unique session token by bank application and the interaction with the server is launched.

The malicious attacker creates a URL with a CSRF payload with the intent of stealing $1000 from the victim’s bank account. This malicious URL is pushed to the victim via email.

When user click on that URL, it executes CSRF payload and sends the request to xyzbank.com, while riding the session the victim is already logged on to. The stolen $1000 is transferred from user account to the hacker account.

How to prevent CSRF attacks?
It is expected from application developers to make a habit of taking the following security measures:

Session time out – Making sure the session times out after a short period of time, it reduces the time-frame that the victim has to perform the attack.

Unique CSRF tokens – The most common method to prevent CSRF attacks is to append unpredictable challenge tokens .The user should get a random CSRF token every time he logs into the application. In all subsequent requests, this token should be passed and validated in the server. This effectively disable the malicious URLs as they cannot be authenticated by the server, which checks for the unique CSRF tokens.

Tokens per request – The aforementioned CSRF tokens are usually given out per session, but can be given out for each request separately for ensuring that the request is valid and not coming from a source other than the user.

Example –
Since the tokens has been defined, the attacker not able to know what is the token of the slave, because every loading of the page the token will change to other random number\string.

A detailed manual penetration testing is also recommended to be performed periodically. For more info, refer to https://www.valencynetworks.com/penetration-testing-services/website-security-penetration-testing.html