Open Close

REST APIs and Next Generation Threats: Part 1

FacebookGoogle+LinkedInDiggEmailRedditStumbleUponPinterestDeliciousShare/Save

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.

(Read More:  Infographics- SAST vs DAST: What should you choose?)

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.

Free Research Report:  How secure are the Security Products?

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.

(Read More:  9 Questions to ask your Application Security Testing Vendor!)

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, 3rd 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.

(Read More:  Web Application Scanner: How should you benchmark?)

 

Advertisement:

 

Leave a comment

All fields marked (*) are required