Summer Madness 2010 updates

John Kee · at Monday, January 29, 2024

Although REST has been a dominant choice for API design for the last decade, there is still little dedicated security research on the subject of REST APIs. The popularity of REST contrasts with a surprisingly small number of systematic approaches to REST security analysis. This contrast is also reflected in the low availability of analysis tools and best security practices that services may use to check if their API is secure.

In this blog series, we try to find reasons for this situation and what we can do about it. In particular, we will investigate why general REST security assessments seem more complicated than other API architectures. We will likewise discuss how we may still find systematic approaches for REST API analysis despite REST's challenges. Furthermore, we will present REST-Attacker, a novel analysis tool designed for automated REST API security testing. In this context, we will examine some of the practical tests provided by REST-Attacker and explore the test results for a small selection of real-world API implementations.

Author

Christoph Heine

Overview

Understanding the Problem with REST

When evaluating network components and software security, we often rely on specifications for how things should work. For example, central authorities like the IETF standardize many popular web technologies such as HTTP, TLS or DNS. API architectures and designs can also be standardized. Examples of these technologies are SOAP and the more recent GraphQL language specification. Standardization of web standards usually influences their security. Drafting may involve a public review process before publication. This process can identify security flaws or allow the formulation of official implementation and usage best practices. Best practices are great for security research as a specification presents clear guidelines on how an implementation should behave and why.

The situation for REST is slightly different. First of all, REST is not a standard in the sense that there is no technical specification for its implementation. Instead, REST is an architecture style which is more comparable to a collection of paradigms (client-server architecture, statelessness, cacheability, uniform interface, layering, and code-on-demand). Notably, REST has no strict dependency on other web technologies. It only defines how developers should use components but not what components they should use. This paradigm makes REST very flexible as developers are not limited to any particular protocol, library, or data structure.

Furthermore, no central authority could define rules or implementation guidelines. Roy Fielding created the original definition of REST as a design template for the HTTP/1.1 standard in 2000. It is the closest document resembling a standard. However, the document merely explains the REST paradigms and does not focus on security implications.

The flexibility of the REST architecture is probably one of the primary reasons why security research can be challenging. If every implementation is potentially different, how are we supposed to create common best practices, let alone test them consistently across hundreds of APIs? Fortunately for us, not every API tries to reinvent the wheel entirely. In practice, there are a lot of similarities between implementations that may be used to our advantage.

Generalizing REST Security

The most glaring similarity between REST API implementations is that most, if not all, are based on HTTP. If you have worked with REST APIs before, this statement might sound like stating the obvious. However, remember that REST technically does not require a specific protocol. Assuming that every REST API uses HTTP, we can use it as a starting point for a generalization of REST API security. Knowing that we mainly deal with HTTP is also advantageous because HTTP - unlike REST - is standardized. Although HTTP is still complex, it gives us a general idea of what we can expect.

Another observation is that REST API implementations reuse several standardized components in HTTP for API communication. Control parameters and actions in an API request are mapped to components in a generic HTTP request. For example, a resource that an API request operates on, is specified via the HTTP URL. Actions or operations on the said resource are identified and mapped to HTTP methods defined by the HTTP standard, usually GET, POST, DELETE, PUT, and PATCH. API operations retain their intended action from HTTP, i.e., GET retrieves a resource, DELETE removes a resource, and so on. In REST API documentation, we can often find a description of available API endpoints using HTTP "language":

Since the URL and the HTTP method are sufficient to build a basic HTTP request, we can potentially create an API requests if we know a list of REST endpoints. In practice, the construction of such requests can be more complicated because the API may have additional parameter requirements for their requests, e.g., query, header, or body content. Another problem is finding valid IDs of resources can be difficult. Interestingly, we can infer each endpoint's action based on the HTTP method, even without any context-specific knowledge about the API.

We can also find components taken from the HTTP standard in the API response. The requested operation's success or failure is usually indicated using HTTP status codes. They retain their meaning when used in REST APIs. For example, a 200 status code indicates success, while a 401 status code signifies missing authorization (in the preceding API request). This behavior again can be inferred without knowing the exact purpose of the API.

Another factor that influences REST's complexity is its statelessness paradigm. Essentially, statelessness requires that the server does not keep a session between individual requests. As a result, every client request must be self-contained, so multi-message operations are out of the picture. It also effectively limits interaction with the API to two HTTP messages: client request and server response. Not only does this make API communication easier to comprehend, but it also makes testing more manageable since we don't have to worry as much about side effects or keeping track of an operations state.

Implementing access control mechanisms can be more complicated, but we can still find general similarities. While REST does not require any particular authentication or authorization methods, the variety of approaches found in practice is small. REST API implementations usually implement a selection of these methods:

HTTP Basic Authentication (user authentication)
API keys (client authentication)
OAuth2 (authorization)

Two of these methods, OAuth2 and HTTP Basic Authentication, are standardized, while API keys are relatively simple to handle. Therefore, we can generalize access control to some degree. However, access control can be one of the trickier parts of API communication as there may be a lot of API-specific configurations. For example, OAuth2 authorization allows the API to define multiple access levels that may be required to access different resources or operations. How access control data is delivered in the HTTP message may also depend on the API, e.g., by requiring encoding of credentials or passing them in a specified location of the HTTP message (e.g. header, query, or body).

Finding a Systematic Approach for REST API Analysis

So far, we've only discussed theoretical approaches scatching a generic REST API analysis. For implementing an automated analysis tool, we need to adopt the hints that we used for our theoretical API analyses to the tool. For example, the tool would need to know which API endpoints exist to create API requests on its own.

The OpenAPI specification is a popular REST API description format that can be used for such purpose. An OpenAPI file contains a machine-readable definition (as JSON or YAML) of an API's interface. Basic descriptions include the definition of the API endpoints, but can optionally contain much more content and other types of useful information. For example, an endpoint definition may include a list of required parameters for requests, possible response codes and content schemas of API responses. The OpenAPI can even describe security requirements that define what types of access control methods are used.

{     "openapi": "3.1.0",     "info": {         "title": "Example API",         "version": "1.0"     },     "servers": [         {             "url": "http://api.example.com"         }     ],     "paths": {         "/user/info": {             "get": {                 "description": "Returns information about a user.",                 "parameters": [                     {                     "name": "id",                     "in": "query",                     "description": "User ID",                     "required": true                     }                 ],                 "responses": {                     "200": {                         "description": "User information.",                         "content": {                             "application/json": {                                 "schema": {                                     "type": "object",                                     "items": {                                         "$ref": "#/components/schemas/user_info"                                     }                                 }                             }                         }                     }                 }             }         }     },     "security": [         {             "api_key": []         }     ] }

As you can see from the example above, OpenAPI files allow tools to both understand the API and use the available information to create valid API requests. Furthermore, the definition can give insight into the expected behavior of the API, e.g., by checking the response definitions. These properties make the OpenAPI format another standard on which we can rely. Essentially, a tool that can parse and understand OpenAPI can understand any generic API. With the help of OpenAPI, tools can create and execute tests for APIs automatically. Of course, the ability of tools to derive tests still depends on how much information an OpenAPI file provides. However, wherever possible, automation can potentially eliminate a lot of manual work in the testing process.

Conclusion

When we consider the similarities between REST APIs and OpenAPI descriptions, we can see that there is potential for analyzing REST security with tools. Our next blog post discusses how such an implementation would look like. We will discuss REST-Attacker, our tool for analyzing REST APIs.

Acknowledgement

The REST-Attacker project was developed as part of a master's thesis at the Chair of Network & Data Security of the Ruhr University Bochum. I would like to thank my supervisors Louis Jannett, Christian Mainka, Vladislav Mladenov, and Jörg Schwenk for their continued support during the development and review of the project.

Cyber cell and IT cell these are the department in our india which provide cybersecurity and looks into the matters related to cyber crimes to stop the crime because in this digitilization world cyber crime increasing day by day so our government of india also takes the immediate action to prevent the cybercrimes with the help of these departments and also arrest the victim and file a complain against him/her with the help of cyberlaw in our constitution.

query log data from multiple sources
enrich the data with Threat Intelligence, geolocations and Azure resource data
extract Indicators of Activity (IoA) from logs and unpack encoded data
perform sophisticated analysis such as anomalous session detection and time series decomposition
visualize data using interactive timelines, process trees and multi-dimensional Morph Charts

It also includes some time-saving notebook tools such as widgets to set query time boundaries, select and display items from lists, and configure the notebook environment.

The msticpy package was initially developed to support Jupyter Notebooks authoring for Azure Sentinel. While Azure Sentinel is still a big focus of our work, we are extending the data query/acquisition components to pull log data from other sources (currently Splunk, Microsoft Defender for Endpoint and Microsoft Graph are supported but we are actively working on support for data from other SIEM platforms). Most of the components can also be used with data from any source. Pandas DataFrames are used as the ubiquitous input and output format of almost all components. There is also a data provider to make it easy to and process data from local CSV files and pickled DataFrames.

The package addresses three central needs for security investigators and hunters:

Acquiring and enriching data
Analyzing data
Visualizing data

We welcome feedback, bug reports, suggestions for new features and contributions.

Installing

For core install:

pip install msticpy

If you are using MSTICPy with Azure Sentinel you should install with the "azsentinel" extra package:

pip install msticpy[azsentinel]

or for the latest dev build

pip install git+https://github.com/microsoft/msticpy

Documentation

Full documentation is at ReadTheDocs

Sample notebooks for many of the modules are in the docs/notebooks folder and accompanying notebooks.

You can also browse through the sample notebooks referenced at the end of this document to see some of the functionality used in context. You can play with some of the package functions in this interactive demo on mybinder.org.

Log Data Acquisition

QueryProvider is an extensible query library targeting Azure Sentinel/Log Analytics, Splunk, OData and other log data sources. It also has special support for Mordor data sets and using local data.

Built-in parameterized queries allow complex queries to be run from a single function call. Add your own queries using a simple YAML schema.

Data Queries Notebook

Data Enrichment

Threat Intelligence providers

The TILookup class can lookup IoCs across multiple TI providers. built-in providers include AlienVault OTX, IBM XForce, VirusTotal and Azure Sentinel.

The input can be a single IoC observable or a pandas DataFrame containing multiple observables. Depending on the provider, you may require an account and an API key. Some providers also enforce throttling (especially for free tiers), which might affect performing bulk lookups.

TIProviders and TILookup Usage Notebook

GeoLocation Data

The GeoIP lookup classes allow you to match the geo-locations of IP addresses using either:

GeoLiteLookup - Maxmind Geolite (see https://www.maxmind.com)
IPStackLookup - IPStack (see https://ipstack.com)

GeoIP Lookup and GeoIP Notebook

Azure Resource Data, Storage and Azure Sentinel API

The AzureData module contains functionality for enriching data regarding Azure host details with additional host details exposed via the Azure API. The AzureSentinel module allows you to query incidents, retrieve detector and hunting queries. AzureBlogStorage lets you read and write data from blob storage.

Azure Resource APIs, Azure Sentinel APIs, Azure Storage

Security Analysis

This subpackage contains several modules helpful for working on security investigations and hunting:

Anomalous Sequence Detection

Detect unusual sequences of events in your Office, Active Directory or other log data. You can extract sessions (e.g. activity initiated by the same account) and identify and visualize unusual sequences of activity. For example, detecting an attacker setting a mail forwarding rule on someone's mailbox.

Anomalous Sessions and Anomalous Sequence Notebook

Time Series Analysis

Time series analysis allows you to identify unusual patterns in your log data taking into account normal seasonal variations (e.g. the regular ebb and flow of events over hours of the day, days of the week, etc.). Using both analysis and visualization highlights unusual traffic flows or event activity for any data set.

Time Series

Visualization

Event Timelines

Display any log events on an interactive timeline. Using the Bokeh Visualization Library the timeline control enables you to visualize one or more event streams, interactively zoom into specific time slots and view event details for plotted events.

Timeline and Timeline Notebook

Process Trees

The process tree functionality has two main components:

Process Tree creation - taking a process creation log from a host and building the parent-child relationships between processes in the data set.
Process Tree visualization - this takes the processed output displays an interactive process tree using Bokeh plots.

There are a set of utility functions to extract individual and partial trees from the processed data set.

Process Tree and Process Tree Notebook

Data Manipulation and Utility functions

Pivot Functions

Lets you use MSTICPy functionality in an "entity-centric" way. All functions, queries and lookups that relate to a particular entity type (e.g. Host, IpAddress, Url) are collected together as methods of that entity class. So, if you want to do things with an IP address, just load the IpAddress entity and browse its methods.

Pivot Functions and Pivot Functions Notebook

base64unpack

Base64 and archive (gz, zip, tar) extractor. It will try to identify any base64 encoded strings and try decode them. If the result looks like one of the supported archive types it will unpack the contents. The results of each decode/unpack are rechecked for further base64 content and up to a specified depth.

Base64 Decoding and Base64Unpack Notebook

iocextract

Uses regular expressions to look for Indicator of Compromise (IoC) patterns - IP Addresses, URLs, DNS domains, Hashes, file paths. Input can be a single string or a pandas dataframe.

IoC Extraction and IoCExtract Notebook

eventcluster (experimental)

This module is intended to be used to summarize large numbers of events into clusters of different patterns. High volume repeating events can often make it difficult to see unique and interesting items.

This is an unsupervised learning module implemented using SciKit Learn DBScan.

Event Clustering and Event Clustering Notebook

auditdextract

Module to load and decode Linux audit logs. It collapses messages sharing the same message ID into single events, decodes hex-encoded data fields and performs some event-specific formatting and normalization (e.g. for process start events it will re-assemble the process command line arguments into a single string).

syslog_utils

Module to support an investigation of a Linux host with only syslog logging enabled. This includes functions for collating host data, clustering logon events and detecting user sessions containing suspicious activity.

cmd_line

A module to support he detection of known malicious command line activity or suspicious patterns of command line activity.

domain_utils

A module to support investigation of domain names and URLs with functions to validate a domain name and screenshot a URL.

Notebook widgets

These are built from the Jupyter ipywidgets collection and group common functionality useful in InfoSec tasks such as list pickers, query time boundary settings and event display into an easy-to-use format.

More Notebooks on Azure Sentinel Notebooks GitHub

Azure Sentinel Notebooks

Example notebooks:

View directly on GitHub or copy and paste the link into nbviewer.org

Notebook examples with saved data

See the following notebooks for more examples of the use of this package in practice:

Windows Alert Investigation in GitHub or NbViewer
Office 365 Exploration in GitHub or NbViewer
Cross-Network Hunting in GitHubor NbViewer

Supported Platforms and Packages

msticpy is OS-independent
Requires Python 3.6 or later
See requirements.txt for more details and version requirements.

Contributing

For (brief) developer guidelines, see this wiki article Contributor Guidelines

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

Download Msticpy

Summer Madness 2010 updates

Automating REST Security Part 1: Challenges

Author

Overview

Understanding the Problem with REST

Generalizing REST Security

Finding a Systematic Approach for REST API Analysis

Conclusion

Further Reading

Acknowledgement

Related articles

WHO IS ETHICAL HACKER

What Is Cybersecurity And Thier types?Which Skills Required To Become A Top Cybersecurity Expert ?

Read more

Msticpy - Microsoft Threat Intelligence Security Tools

Related word

Remember...

Blog Archive

Contributors