Some days back, when I was going through the record breaking statistics of Facebook and its social networking platform’s REST APIs, I found phrases like “People on Facebook install 20 million applications every day. More than 2.5 million websites have integrated with Facebook”. It really shows the incredible power of REST APIs and probably it is just a start. Apart from Facebook, the list of API provider applications providing REST APIs is increasing day by day, some of these applications include LinkedIn, Google, Bing, Delicious, GroupOn, Paypal, Twitter, Salesforce and so on. The number of 3rd party applications built on top of REST APIs is also drastically increasing. Probably, we are going to see atleast thousands of 3rd party applications in the near future, built on top of REST APIs, creating a true mesh of applications never seen before.
However, everything comes with a cost and here the cost can be loss of your privacy, social and professional relationships, money and confidential data. As a result, it is extremely important to know and remediate various security risks involved with REST APIs and 3rd party applications. In this post, we will discuss some of the major security risks involved from the perspective of end users. In the end, we will demonstrate a real life scenario of privacy breach of a victim user.
There are two main scenarios to access API provider application by a user.
Scenario 1:
You access your API provider application directly over the
HTTP layer with proper security mechanisms provided by the application.
Figure 1: Scenario 1 where a user accesses API provider application directly
Scenario 2
You access your API provider application’s features via a 3rd party application on your browser. 3rd party application is responsible for making REST API based calls to API Provider App to implement necessary features. Authentication and authorization is provided by upcoming standard called OAuth.
Figure 2: Scenario 2 where a user accesses API provider functionality via a 3rd party application.
Threats
Following table shows how a 3rd party application can put a user under various security risks even if API Provider Application is secure from major security flaws. As shown, XSS/CSRF/Broken Authentication puts a user under the same risk as that of 3rd party application. On the other hand, Injection / Broken Authorization puts you under different risks depending upon exact functionality of 3rd party application.
| Scenario 1 | Scenario 2 | ||
| Risk / Security vulnerability | API Provider App | 3rd Party Application | API Provider App |
| Injection | No | Yes | Scenario Based |
| Cross -Site Scripting (XSS) | No | Yes | Yes |
| Broken Authentication | No | Yes | Yes |
| Cross-Site Request Forgery (CSRF) | No | Yes | Yes |
| Broken Authorization | No | Yes | Scenario Based |
Table 1: OWASP Top 5 Risks and comparison of how an insecure 3rd party application can make API Provider App insecure.
An illustration
Consider the following scenario where a popular social / professional networking site like LinkedIn or Facebook is an API Provider Application and there are 3rd party applications that provide functionality to make REST APIs calls to them. Say LinkedIn is secure from CSRF vulnerability, however there is CSRF vulnerability in 3rd Party application and as a result, we will show, it is possible to trick a victim user, say, to add an attacker as a contact in LinkedIn’s professional network.
In summary, attack sequences are described as following. Figure 3 demonstrate the attack sequences diagrammatically.
Figure 3: Flow depicting how an attacker exploits CSRF flaw in a 3rd party application.
Step 1: Attacker creates a blog with title called “REST API for dummies”. Attacker shares the blog post with the victim user.
The blog recommends 3rd Party application to try REST API calls. 3rd Party application is integrated with LinkedIn using OAuth protocol. OAuth authenticates and authorizes every 3rd party application before it can make any REST API call. Attacker creates a JavaScript exploit embedded in the blog post. The exploit utilizes CSRF vulnerability in the 3rd Party application to send a friend request to the attacker on behalf of the victim user, without victim user’s real intention and knowledge.
Figure 4: An example blog created by attacker, embedding a JavaScript exploit.
Step 2: Victim user follows the blog and open 3rd Party application in a new tab of web browser. Victim user selects OAuth option to authenticate and authorize 3rd Party application to make REST A
PI calls to LinkedIn.
Figure 5: 3rd Party application asks for a permission to get access to victim user’s LinkedIn Account
Step 3: The JavaScript exploit, embedded in the blog post, makes a HTTP Post request to 3rd Party on behalf of the victim user. As a result of CSRF vulnerability in 3rd Party application, HTTP POST will trigger logic at the backend server of 3rd Party to create a REST API call to LinkedIn. In the current example, exploit will send a fake friend request from victim user to the attacker. However, as a generic case, it is possible to post a comment, read the mailbox or perform any other action supported by LinkedIn REST APIs.
Step 4: A friend request email will be sent to attacker. Attacker can easily accept the invitation and add victim user as a friend in LinkedIn’s professional network.
Figure 6: An illustration of successful exploitation. Invitation mail sent to attacker on the behalf of victim user’s LinkedIn Account.
Conclusion
Application Mesh ups and REST APIs bring new dimensions to web application security. Security challenges of REST APIs need to be discussed, formalized and remediated.
In the next few blogs, I will explore some of the following topics:
- REST API and Next Generation Threats: Part 2
- REST API and Security Remediation from perspective of API providers, 3rd party applications and end users.
- REST APIs and role of Web Application Penetration Testing.
Please feel free to provide your valuable comments, questions and suggestions and stay tuned.
{ 5 comments… read them below or add one }
Hi, Mr Chauhan
I thinked your article very interesting. However, I didn´t see how a web application not vulnerable to CSRF, whether by captcha, whether by token, can be vulnerable when a 3rd party vulnerable intermediates the communication. Could you clarify this for me?
Thanks
Hi,
Nice article, especially the attack scenario as described. This definitely can be a threat however I think there are too many dependencies on the user for this attack to be successful. Even if all parameters are met and the attack is actually successful, is it viable to call it a bug or even a weakness in the API provider? Clearly you will be exploiting a bug in the 3rd party application as described in the scenario.
Theoretically you can consider this as a threat perhaps including the API provider however practically it is very difficult to consider it even as a weakness in the API provider given the way web and HTTP protocol is modeled.
Almost all the API providers does actually ask the user to “knowingly” give access to a 3rd party application that they trust. You can always build your own web app and entice the user to give it onetime API access to their gmail account pretending to do some statistic or eye candy stuff while in reality you can silently read the user’s mail regularly for a long time if access is granted. As an analogy it is like sending a malicious executable to an user and expecting him to run it on his system. Obviously most users won’t be running an executable due to “awareness” however again due to “lack of awareness” about the web I guess many of the users will actually allow an API access.
So my point is as technology develops it also becomes more complex and there is always a human factor which have to decide how to and how not to use technology. Usability enhancements will most probably always bring security issues but there is always an acceptable risk
@Abhisek. First of all, thanks a lot for providing valuable comments. I totally agree with some of the points mentioned in your comments and here are my answers:
“ .. difficult to consider it even as a weakness in the API provider ..“. I agree with your point, however
API provider should be more concerned about end user security and as a result there is need of auditing and security testing of all 3rd party application integration with them.
End user should be made aware of the involved risk in providing access to even trusted 3rd party application to their account on LinkedIn or Facebook or Gmail.
I am also asking a question such as “Can there be some improvement in REST API architecture?” to mitigate such risks similar to having anti-automation protection or CSRF protection. However, I also do not know the answer yet?
“You can always build your own web app and entice the user to give it onetime API …. “. I agree with this point and infact this is another major risk. However, I also want to stress upon the fact that even trusted 3rd party application can put end users at high risk, if 3rd party applications are vulnerable to XSS or CSRF.
I hope, I answered your questions.
Hello Mr Maros,
The answer of your questions is hidden in the illustration / example shown in the blog.
Please refer to Fig. 3 in the blog and follow the sequence of attacking steps. Attack sequence #4 is possible because 3rd party application is vulnerable to CSRF security flaw. As a result, once the victim user provides 3rd party application access to his/her LinkedIn account, malicious javascript, hidden in the blog, sent a crafted HTTP post request to 3rd party application resulting into successful attack sequence #5. The attack is also possible if 3rd party application is vulnerable to Cross Site Scripting vulnerability.
I hope, I answered your question. Please feel free to revert back with comments and “Aha” moments.
Regards
That is super information! Thanks for sharing! I’m going to Tweet about your blog.