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.

Security & Privacy in the App Economy

Published Originally on Apigee

As enterprises adjust to the new reality of business having moved beyond their core and legacy systems of record – to millions of mobile devices and social networks at the edge of the enterprise, to new distribution channels in the shape of apps which are often built by third party or partner developers – the question of end user privacy becomes increasingly important. As the app economy matures, it’s participants will have to quickly move from self governance to establishing standards or even regulation to address end-user privacy expectations.

Who is responsible for security and privacy when dealing with applications and APIs?

In the era of the browser, privacy questions were handled expressly between the website operator and the end user. The end user consented to using the products and services exposed through the website and had the right to agree to the policies set forth by the web site operator.

In the app economy, the value chain changes forcing a change in how privacy and privacy policy need to be managed and crafted. The question of privacy will quickly rise higher in the minds of end users as the app economy matures.

Who is ultimately responsible for privacy and policy in the app economy?

End users? API providers? App developers?
The answer is all of the above!

End Users

Privacy is really the control that a user has on their definition in an environment that they are familiar with and understand how it functions. The world of apps is a new environment that end users are only becoming familiar with and privacy best practices from the browser world can be found severely lacking in this new environment. Users will demand similar rights as they do in the online/browser world, including:

• Understand and view the information being collected about them

• The ability to choose what information can be collected and for what purposes it can be used beyond the immediate product or service

• The ability to contest the accuracy of information collected about them

• Understand the security of processes and systems used to store and process their private data

Enterprises

Through the ability of APIs and apps to reach new markets and end users across the globe, the enterprises might find themselves operating in completely new markets and geographic regions and therefore find themselves bound to the privacy regulations in several parts of the world. This means that enterprises will have to increasingly deal with different privacy rules and regulations for the same services and products. New products and technologies are required to operate in this new environment.

App Developers

The app developer who might not have been thinking about their end-user privacy expectations will very soon have to worry about how and what end user information they collect, store, process, and share. Preparing for success requires developers to be cognizant of privacy and security issues and utilize best practices while building their apps.

Developers should collect only the data required to offer the best experience to end users. They should not store user data without users’ permission. User data should be obfuscated or encrypted if possible, and so on.

As apps become popular, as usage increases and becomes more personalized, these requirements and considerations can be ominous and a distraction for developers. They too will need a new set of tools and technologies to help them deal with privacy expectations, consent, and data management solutions.

Conclusion

A whole host of factors including the advent of big data technologies, publicly available information sources optimized for consumption, sophisticated behavioral analysis for personalization, and the advent of recommendation and predictive products and services, end users will become more concerned about their privacy. They will demand a single point of contact and tools to understand their privacy considerations and control their information and its usage.

Is the app economy ready for this challenge?

Here are some steps that can be taken to get ahead of the problem.

Developers:

• Understand and provide to your end users privacy policies and data handling procedures for all services that your app uses

• Choose APIs (and services) for your app that are highly reputed and offer best-in-class privacy handling and mitigation procedures

• Enable end users to connect with services directly regarding their policy questions

• Utilize cloud-based data storage providers that are privacy and security certified

Enterprises:

• Consider the entire value chain from a security perspective – from API to developer to app to end user

• Build capability to distinguish between good and malicious apps that use your APIs

• Detect malicious apps and take steps to block such apps and notify end users of these apps and help them deal with any privacy outages

• Enable end users of apps that use your APIs to understand your data collecting and privacy policies