Security in Public API’s – How [Updated 2019]

Far too often we will download an API (Application Programming Interface) from Programmable Web, or download an SDK like the Facebook SDK and not worry about any of the security issues that might come from bad or improper coding practices that are embedded within the API. Often any static code analysis of any of these API's will show that there are flaws in the implementation of the API that increases the attack surface and risk for a company using those API's. Part of any security program for any company that is using public API's should be a complete review of the API and how it can be exploited due to bad or improper coding practices on the part of the person who built the API.

Most programmers and many security engineers who do static code analysis know that sample code is often not recommended for production use. This has been a standard rule of thumb since the Microsoft Safety stand down, and multiple hacking attacks that exploited sample code that was left as part of the IIS installation on thousands of web servers worldwide.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

What we rarely hear about though are the risks associated with using publicly available API's through any source. While the biggest repository of public API's is out at Programmable Web, almost every company that offers an API also offers an SDK (Software Development Kit) with examples of how to do particular functions. Unfortunately this is the same as "sample code", and you never know the quality of the samples or the risks or potential effects that those samples might have on your own code set. Flaws in API programs allows a hacker or malicious individual to understand the way that the server logic works, and allow the hacker time to work out an effective way of subverting the API to do something that the developer did not intend to have happen. Testing public API's or API's that come as part of specific SDK's for Web 2.0 applications needs to be part of any companies security and testing evaluation program. While it is common for companies who write code to do QA testing, many companies that tie into public API's do not do QA testing on the API to ensure that it was written correctly, and can be used safely.

One way to at least test Dot Net assemblies is to use FX Cop, which is a dot net static code analysis tool from Microsoft. You can download it as part of the programming SDK for Dot Net, and it is highly recommended that both programmers and security engineers who evaluate code for security do at least learn to use this tool.

As an example of using static code analysis to discover programmatic flaws, we will look at the Facebook Dot Net SDK that can be downloaded from http://facebooksdk.codeplex.com/releases/view/72008. This SDK has a lot of great sample code in it for static analysis so that programmers and security engineers can start looking at the way static code analysis works, and some fairly common issues with public API's or "sample code" that comes with many SDK's.

This is a fairly recent SDK at the time of writing (October 2011). These SDK's are updated often with new content or new capabilities, so if you are doing this, then you will want to make sure you download the latest SDK and run a static code analysis against the API's you will be using or any assembly in the package if you are simply doing this to learn something interesting or learning how to do static code analysis. Once you have downloaded the Microsoft SDK including the latest Dot Net Framework, you will have FXCop Installed. In this case we are using FXCop 10.0.0, although this program is frequently updated as well.

You want to right click on MyFXCopProject to add targets, or be able to bring in any DLL you care to review for security as part of your static code analysis. For this example we will bring in the MOQ.DLL file from the Facebook SDK, using version 3.5 of the DLL.

FacebookCSharpSDKSourcepackagesMoq.4.0.10827libNET35Moq.dll

Click on Analyze and FXCop will go through the DLL looking for common programming issues. FXCop relies on a database of coding styles and coding best practices to do the analysis. In many cases this is a good tool to discover core issues, but it would also be worth it to use other static code analysis tools as well if the code analysis indicates that there are many flaws that might be missed. Using this tool though is a good indication of how well the programmer who wrote the API followed coding best practices, or understood how the program used to write the code has changed or segments have been deprecated over time.

Once the analysis is completed, FXCop will provide a graded idea of what flaws or errors it encountered in the dot net object (in this case a DLL), and what the flaws are about.

There are many different ways that FXCop rates the severity of particular aspects of the code, and then gives them a certainty level, or how likely this error really exists in the program.

You can quickly sort to the highest level issues with the code set and then review each individual aspect of the issues. If you do not have a programming background, it would be good to work with a programmer so that the company can individually triage the flaws according to the way that the programmers work, or use this to submit bug reports if your company uses an internal bug tracking and reporting mechanism. In any case, any critical flaw is something that should be reviewed by a professional programmer, who is familiar with the code and the company to help triage programmatic errors that will be reported with this tool.

This is the sorted view, a non-breaking fix means that the compiler will throw a warning, while a breaking issue might halt or influence the compilation of the program. Because we are working with a DLL, it compiled, but might leave a hook for a hacker to access the call, and cause the program to error out and provide debug information that should not be provided to anyone but programmers.

Because we have a breaking issue noticed by FXCop, we will look at that first to see what the issue is, and if it is fixable, or worth testing further, or sending to the bug tracking system used by a company. Again, working with a programmer on this is always a good idea of the security engineer has not done static code analysis or is not a programmer.

What this is saying to the person is that this is a critical error, with a 33% chance of probability that this is a critical error. It labels it as breaking, but we know the program compiled. FXCop is looking for a security attribute in serialization information (could be a security token, or something that is passed to the call independently of the DLL). Odds are highly likely that a serialized security token is passed to this call from another DLL or from a web form such as login, or other information. The static analysis should look for what data is passed to this call in other sections of the code to make sure that at least some security token is passed in the serialized information. The error also points to that same conclusion, that there is a token somewhere that is being passed to this object.

Add the following security attribute to 'AbstractInvocation.GetObjectData(SerializationInfo, StreamingContext)' in order to match a LinkDemand on base method 'ISerializable.GetObjectData(SerializationInfo, StreamingContext)': [SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.SerializationFormatter)].

This is something that while breaking requires further code analysis of the entire process so that the dependency can be resolved. Either a token is passed from LinkDemand or it is not, if not then this should be submitted as a bug to the programmer that is using the API.

Some errors are simple error catching. There should always be a robust error catching function, but this is often overlooked in the case of errors from the program. Error code catching is a fundamental part of programming, but also one of those easily ignored or overlooked sections when programming code. Uncaught errors can lead to information being released to a user or to a hacker that could give the hacker or user more information about how the web server was configured, or how the web service actually functions in relationship to the data that is being presented to it.

Modify 'AttributeDisassembler.Disassemble(Attribute)' to catch a more specific exception than 'Exception' or rethrow the exception.

Sometimes writing error catching code can be extraordinarily dull to write, but good error catching code can keep the hacker or even the casual user from encountering fail over issues that expose critical or important internal web server configurations or data that could lead to a very good hack that exposes databases or the web server itself. This is the kind of errors that hackers specifically are looking for so that they can better understand the server logic behind it, and how the API works with the server data. While being a public API is not a bad thing, with source code that a static analysis can be run opens the door to finding attack surfaces. Any code as a public API, the ability of hackers or malicious individuals knowing this information about the public API and its configuration opens the door to more interesting hacks, or more interesting data leakage from the system than the owners might have intended. In some cases might lead to the ability to write a worm or virus that specifically targets the exploit(s) found during static code analysis.

Reviewing each API that is used by a company should be part of any information security process. API's introduce risk that is similar to using sample code that is included with specific program sets. While API's are very useful when building mashups or consuming data in new ways, if the API is not programmed properly or leaves specific data types open that could cause an error, then the user of the API could be in danger of risking information through data leakage. API's are part of the Web 2.0 eco-system, and as such do increase the hacking foot print of multiple systems that rely on those API's. Security and Business units need to understand how the API was written, what security implications it has, and how best to manage those risks.

Understanding the hidden calls within the API's allows us to understand the running logic of the Web 2.0 application. While Javascript using XHR (XML HTTP Requests), and firebug is one way of understanding the logic of the Web 2.0 application, also understanding the static code analysis of the Web 2.0 API or any API makes it much easier to understand the attack surface that is available, as well as providing the ability to mockup code and practice effective attacks before they go mainstream and end up on the internet much like the last two internet worms that affected MySpace and Twitter early on in the Web 2.0 world.

Much like any other source of public code, the ability for a hacker or malicious individual to download the code is not restricted. Hackers performing static code analysis and then mocking up on a web server the attacks they want to perform is one way of perfecting the hack so that company or social connections can be exploited later on. Reverse engineering API's is a common hacker process to determine how easy it would be to attack any part of the Web 2.0 surface to gain additional information, steal personal information, or otherwise infiltrate computer systems using those API's.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

While the functionality of an API is fixed to what the service provider intends on giving to people using the API, the use of improperly secured or programmed API's makes hacking Web 2.0 much more interesting, and much more plausible as many people are going to use those same API's, making one hack effective across a broad range of users.