Protecting users, apps, and APIs from abuse

Published Originally on Apigee

Abusers or spammers are the bad guys looking to make money by getting unsuspecting end users or consumers of online services to interact with malicious content or spam that leads to one or more of the following scenarios:

• Eyeballs on spam content that lead to clicks and purchases.
• Gathering users’ private information through keyloggers (or other spyware) on the user’s machine or device which is then sold to the highest bidder.
• Phishing for users’ private information such as SSN, credit card #, or passwords and selling those to the highest bidder.
• Installing malicious software on users’ machines or devices, which in turn steals more of their information or uses their bandwidth or storage for carrying our further attacks.

Any workflow that creates or consumes content, shares or reshares content, sends or receives communications can be vulnerable to attack.

Online attacks almost always contain a “payload” that either delivers the attack or leads the user to another location where the attack is completed. Any time a piece of content is created or consumed or a communication is sent or received, there is an inherent “payload” that is delivered. In the wrong hands, this payload can be malicious.

Blogs can be spammed with comments which contain spam or malware, or which employ phishing techniques that redirect users to other malicious locations on the Internet.

In the same way, users can receive emails that contain spam or malware or other phishing techniques. Users can be redirected to malicious sites in their browser. Users’ machines can be attacked and malware (such as adware, spyware, key loggers and viruses) installed which can scrape users’ private information and send it to the abusers.

Thinking about apps and APIs as assets

Apps like APIs can be considered “assets” that can be used to carry out attacks against end users.

APIs (and especially free APIs) provide services that eventually reach other users. Even if an API has a usage cost associated with it, if the return on investment for an abuser for planning and carrying out an attack is higher than the cost of using the API (at scale), even paid APIs can be abused.

Both developers and enterprises have apps that are highly monetizable if abused. App-based attacks fall into the following general categories:

Malicious apps: These apps are written with the sole goal of abusing unsuspecting users who download and install them. With the increasing use of single sign on services and integration of social networks with apps through social network platforms, a user’s social network can be used to propagate these attacks.

Well-intentioned apps with vulnerabilities: These apps are not written to be malicious but have vulnerabilities either in their code (e.g. the apps’s functionality can be scripted or controlled through hooks provided by the app) or in their business logic (e.g. no throttling of calls from a single user to the back-end system). An abuser can exploit these vulnerabilities to carry out attacks on enterprise APIs or on the end users of the apps.

Well intentioned apps exploited by a malicious user: In this case, an abuser can use some legitimate capability offered by the app as a foundation to carry out attacks that propagate through the end user’s social network and spread through further usage.

Protecting your assets

You don’t want your APIs or apps used for abuse. It is crucial for both developers and enterprises to protect their “assets”. If an end user develops a perception that a certain app or service is “dangerous”, usage declines, growth can be reversed, and revenue and profit suffer.

Remember that abusers are most often out there to make money and if the cost to carry out an attack is less than the value derived from the attack, it will continue to be a sound business investment for the abusers.

Some things that developers can do to protect their apps and end users (and their friends)

• Monitor usage of your app and its impact on the users. Build and maintain a proxy for user reputation and models of good and bad behavior in the content of the app.
• Enable end users to report suspicious behavior of the app or of other users of the app.
• Work with the enterprise or API provider to ensure that your app is not creating suspicious loads on the API.

Some things that enterprises can do to protect their APIs

• Build traffic monitoring solutions and models to rate traffic as safe or abusive.
• Ensure that any content or communication created or shared through the API is free of malicious payloads.
• Invest in mechanisms to report and notify suspicious user and app behavior to the app developers.
• Build reputation systems for users, content and IP addresses to be able to quickly classify traffic, users and apps as good or bad OR desirable or undesirable.

Next time we’ll look at some of the ways to push back against attackers, including use of quotas, throttling, and so on.