Business Logic vulnerabilities via CSRF


Eugene Dokukin aka MustLive
Cross-Site Request Forgery (CSRF) vulnerabilities can be used for different nasty things, but the most dangerous one is stealing of money from users’ accounts. Which I’ll tell you about in this article.
Among vulnerabilities found in web applications there are logical vulnerabilities such as Business Logic flaws. Which allows an attacker to manipulate financial data in web applications, such as the ones used for online-banking, EPS and other e-commerce sites.
There are two types of Business Logic flaws: server-side and client-side. First one allows the user of the site to manipulate the site’s functionality to increase his finances, second one allows an external attacker to manipulate the site’s functionality to increase his finances, by decreasing finances of the user of the site. And I have found both types of such vulnerabilities many times since 2005.
Taking into account that Business Logic flaws are logical vulnerabilities, then they belong to the class Abuse of Functionality (WASC-42) [1]. It is the server-side type. The attack occurs at special using of functionality of the site, which was not expected by its developers.
But besides server-side Business Logic vulnerabilities, there are also client-side ones. Which belong to the class Cross-Site Request Forgery (WASC-09) [2]. The essence of such attack comes from conducting a CSRF-attack on the user with the purpose of manipulation of his finances (and functionality of the site being used exactly as it was intended by its developers). And the second type of these vulnerabilities is more widespread then the first one.
Example of Business Logic CSRF.
Example of such vulnerability, which I happened to meet many times at different e-commerce sites, it’s manipulation with withdrawing of money to electronic wallets. (i.e. abusing occurs of the functionality for withdrawing of money from a user’s account.)
With the existence of CSRF vulnerabilities at the site, the scenario of the attack will be the next:
1. Conduct CSRF-attack on the user, to change his wallet (e.g. WebMoney, PayPal, etc.) to attacker’s wallet.
2. Conduct second CSRF-attack on the user to initiate withdrawing of money (to wallet specified in the account).
Usually two steps of the attack (two requests) are required, because process of changing the wallet and withdrawal of money is divided into separate functionalities. But if at a vulnerable site these two operations are joined into one functionality, then it’s possible to send one request - for withdrawal of money to a specified wallet.
In two steps scenario the attack will be the next:
1. Send request to change the wallet:
http://e-commerce/user?wallet=attackerwallet
2. Send request to withdraw money:
http://e-commerce/user_money?withdraw=1
In one step scenario the attack will be the next:
1. Send request to change the wallet and withdraw money:
http://e-commerce/user?wallet=attackerwallet&withdraw=1
For these tasks it’s also possible to use XSS vulnerabilities. Including the existence of protection against CSRF attacks at the site, it’s possible to bypass this protection via XSS. But if the owners of the web sites sometimes protect them from XSS, then they protect them from CSRF much more rarely. So a CSRF attack will be enough for withdrawal of money from an user’s account.
Creating of CSRF-exploits.
For creation of CSRF-exploits, my tool CSRF Generator [3] can be used. It supports one-request and multi-request CSRF-attacks, GET and POST types of requests and timing for multi-request attacks. In case of GET requests the CSRF-attacks can be conducted by many html tags, particularly img and form tags, and in case of POST requests the CSRF-attacks can be conducted only by form tag. It concerns pure-html methods, besides those there are also methods with use of JavaScript to send requests (XHR for on-site requests and Cross-Site XHR for cross-site requests), which also can be used for CSRF-attacks.
For the above-mentioned one step and two steps scenarios the exploit code will be the next. These examples of CSRF-exploits were created with my CSRF Generator, which can be used for creating PoCs and exploits during security researches and security audits.
For one step scenario:
1. GET method with using of img tag:
<img src="http://e-commerce/user?wallet=attackerwallet&withdraw=1" width="0" height="0">
2. GET method with using of form tag:
<body onLoad="document.hack.submit()">
<form name="hack" action="http://e-commerce/user" method="get">
<input type="hidden" name="wallet" value="attackerwallet">
<input type="hidden" name="withdraw" value="1">
</form>
</body>