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 providerapplications 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 3^rd party applications built on top of REST APIs is also drastically increasing. Probably, we are going to see atleast thousands of 3^rd 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 3^rd 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.

(Read more:  5 easy ways to build your personal brand !)

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 3^rd party application on your browser. 3^rd 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.

(Read more:  Top 5 Big Data Vulnerability Classes)

Threats

Following table shows how a 3^rd 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 3^rd party application. On the other hand, Injection / Broken Authorization puts  you under different risks depending upon exact functionality of 3^rd party application.

Table 1: OWASP Top 5 Risks and comparison of how an  insecure 3rd party application can make API Provider App insecure.

(Watch more : Checklist: How to choose between different types of Application Security Testing Technologies?)

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 3^rd 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 3^rd 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:

1. REST API and Next Generation Threats: Part 2
2. REST API and Security Remediation from perspective of API providers, 3^rd party applications and end users.
3. REST APIs and role of Web Application Penetration Testing.

Please feel free to provide your valuable comments, questions and suggestions and stay tuned.

--BY JITENDRA.CHAUHAN

More:  Want to be an author? Nominations open for co-authors of CISO Handbook