Automating REST Security Part 1: Challenges

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

• Automating REST Security Part 1: Challenges
• Automating REST Security Part 2: Tool-based Analysis with REST-Attacker
• Automating REST Security Part 3: Practical Tests for Real-World APIs 

 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.

Further Reading

The feasibility of tool-based REST analysis has also been discussed in scientific papers. If you want to know more about the topic, you can start here:

• Atlidakis et al., Checking Security Properties of Cloud Service REST APIs (DOI Link)
• Lo et al., On the Need for a General REST-Security Framework (DOI Link)
• Nguyen et al., On the Security Expressiveness of REST-Based API Definition Languages (DOI Link)

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.

Related articles

1. Best Hacking Tools 2020
2. Hacking Tools 2019
3. Hacker Tools Github
4. Hack Tools
5. Hacker
6. Pentest Tools
7. Hacker Tools Free Download
8. Game Hacking
9. Hacker Tools Apk
10. Pentest Tools For Android
11. Nsa Hacker Tools
12. World No 1 Hacker Software
13. Tools Used For Hacking
14. Pentest Tools For Mac
15. Hackers Toolbox
16. Pentest Reporting Tools
17. Pentest Tools For Mac
18. Pentest Tools Port Scanner
19. Hacking Tools For Pc
20. Pentest Tools Download
21. Best Pentesting Tools 2018
22. Hacking Tools For Beginners
23. Hacking Tools 2020
24. Hacker Tools Linux
25. Hacking Tools Free Download
26. Hacker Tools For Ios
27. Pentest Tools Subdomain
28. Pentest Tools Website Vulnerability
29. Hacking Tools Windows 10
30. Usb Pentest Tools
31. Pentest Tools Find Subdomains
32. Pentest Tools Subdomain
33. Pentest Tools Github
34. Hacker Tools Free Download
35. Hack Tools
36. Pentest Tools Review
37. How To Install Pentest Tools In Ubuntu
38. Hacker Tools Github
39. Physical Pentest Tools
40. Pentest Tools Apk
41. New Hack Tools
42. Hacking Tools Windows
43. Hacks And Tools
44. Hack Rom Tools
45. New Hack Tools
46. Pentest Tools Url Fuzzer
47. Usb Pentest Tools
48. Hacking Tools Hardware
49. Hacks And Tools
50. Hacker Hardware Tools
51. Hacker Tools Windows
52. Hacking Tools For Kali Linux
53. Hacks And Tools
54. Hacking App
55. Hack Tools For Windows
56. Hacking Tools Usb
57. Hack Tool Apk
58. Best Hacking Tools 2020
59. Tools 4 Hack
60. Hack Tools For Mac
61. Hack Tools For Mac
62. Hack Website Online Tool
63. Hacking Tools 2020
64. Hack Tools For Pc
65. Best Hacking Tools 2019
66. Pentest Tools Open Source
67. Hack Tools For Ubuntu
68. Pentest Tools List
69. Hack Tools Mac
70. Hacking Tools For Windows 7
71. Hacker Tools Linux
72. Hacker Tools Apk Download
73. Pentest Recon Tools
74. How To Install Pentest Tools In Ubuntu
75. Pentest Tools Review
76. Hacking Tools For Windows
77. Hack Tools 2019
78. Termux Hacking Tools 2019
79. Android Hack Tools Github
80. Pentest Tools For Mac
81. Hacker Search Tools
82. Hacking Tools For Windows
83. Hacker Tools List
84. Physical Pentest Tools
85. Hack And Tools
86. Hacker Tools For Ios
87. Hacker Tools
88. Bluetooth Hacking Tools Kali
89. Physical Pentest Tools
90. Hacking Tools Mac
91. Beginner Hacker Tools
92. Nsa Hack Tools Download
93. Pentest Tools Bluekeep
94. Tools For Hacker
95. Hacks And Tools
96. Hacker Tools For Pc
97. Hacking Tools For Kali Linux
98. Pentest Automation Tools
99. Hack Tool Apk No Root
100. Hacking Tools Online
101. Hack Rom Tools
102. Hacking Tools Github
103. Hack App
104. Usb Pentest Tools
105. Hacker Tools 2020
106. Computer Hacker
107. Hacker Tools List
108. Hacker Tools Free Download
109. Hacks And Tools
110. Hacks And Tools
111. Pentest Tools
112. Github Hacking Tools
113. Hacking Tools For Windows
114. Nsa Hack Tools Download
115. Hacker Tools Windows
116. Pentest Tools Open Source
117. Hacker Tools For Windows
118. Ethical Hacker Tools
119. New Hack Tools
120. Hacker Tools 2020
121. What Are Hacking Tools
122. Hacker Tools For Ios
123. Beginner Hacker Tools
124. What Is Hacking Tools
125. Hacking Tools For Windows
126. Hacker Tools Github
127. Pentest Tools Tcp Port Scanner
128. Hack Tools Mac
129. Hack Website Online Tool
130. Best Hacking Tools 2020
131. Hack Tools For Mac
132. Hack Tools For Games
133. Hacker Tools 2019
134. Hacker Tool Kit
135. Black Hat Hacker Tools
136. Hacking Tools Free Download
137. Hacker Tools For Mac
138. Hacking Tools Pc
139. Hacker Techniques Tools And Incident Handling
140. Game Hacking
141. Pentest Tools Open Source
142. Hacker Tools
143. Pentest Tools Subdomain
144. Pentest Automation Tools
145. What Is Hacking Tools
146. Hacker Tools Linux
147. Hacking Tools Windows 10
148. Pentest Tools Linux
149. Game Hacking
150. Beginner Hacker Tools
151. Easy Hack Tools
152. What Is Hacking Tools
153. How To Make Hacking Tools
154. Hacker Techniques Tools And Incident Handling
155. Nsa Hack Tools