This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Top 10 2017-A10-Underprotected APIs"
(OWASP Top 10-2017 RC1: A10-Underprotected APIs) |
m (editorial changes (deleted some empty lines)) |
||
| Line 16: | Line 16: | ||
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}> | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}> | ||
<!--- Threat Agents: --->Consider anyone with the ability to send requests to your APIs. Client software is easily reversed and communications are easily intercepted, so obscurity is no defense for APIs. | <!--- Threat Agents: --->Consider anyone with the ability to send requests to your APIs. Client software is easily reversed and communications are easily intercepted, so obscurity is no defense for APIs. | ||
| − | |||
</td> | </td> | ||
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}> | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}> | ||
<!--- Attack Vectors --->Attackers can reverse engineer APIs by examining client code, or simply monitoring communications. Some API vulnerabilities can be automatically discovered, others only by experts. | <!--- Attack Vectors --->Attackers can reverse engineer APIs by examining client code, or simply monitoring communications. Some API vulnerabilities can be automatically discovered, others only by experts. | ||
| − | |||
</td> | </td> | ||
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}> | <td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}> | ||
<!--- Security Weakness --->Modern web applications and APIs are increasingly composed of rich clients (browser, mobile, desktop) that connect to backend APIs (XML, JSON, RPC, GWT, custom). APIs (microservices, services, endpoints) can be vulnerable to the full range of attacks. Unfortunately, dynamic and sometimes even static tools don’t work well on APIs, and they can be difficult to analyze manually, so these vulnerabilities are often undiscovered. | <!--- Security Weakness --->Modern web applications and APIs are increasingly composed of rich clients (browser, mobile, desktop) that connect to backend APIs (XML, JSON, RPC, GWT, custom). APIs (microservices, services, endpoints) can be vulnerable to the full range of attacks. Unfortunately, dynamic and sometimes even static tools don’t work well on APIs, and they can be difficult to analyze manually, so these vulnerabilities are often undiscovered. | ||
| − | |||
</td> | </td> | ||
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}> | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}> | ||
<!--- Technical Impacts --->The full range of negative outcomes is possible, including data theft, corruption, and destruction; unauthorized access to the entire application; and complete host takeover. | <!--- Technical Impacts --->The full range of negative outcomes is possible, including data theft, corruption, and destruction; unauthorized access to the entire application; and complete host takeover. | ||
| − | |||
</td> | </td> | ||
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}> | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate|year=2017}}> | ||
<!--- Business Impacts --->Consider the impact of an API attack on the business. Does the API access critical data or functions? Many APIs are mission critical, so also consider the impact of denial of service attacks. | <!--- Business Impacts --->Consider the impact of an API attack on the business. Does the API access critical data or functions? Many APIs are mission critical, so also consider the impact of denial of service attacks. | ||
| − | |||
| − | |||
</td> | </td> | ||
{{Top_10_2010:SummaryTableEndTemplate|year=2017}} | {{Top_10_2010:SummaryTableEndTemplate|year=2017}} | ||
Revision as of 23:15, 21 April 2017
| ← A9-Using Components with Known Vulnerabilities | What's Next for Developers → |
| Threat Agents / Attack Vectors | Security Weakness | Impacts | |||
|---|---|---|---|---|---|
| App Specific | Exploitability AVERAGE |
Prevalence COMMON |
Detectability DIFFICULT |
Impact MODERATE |
Business ? |
|
Consider anyone with the ability to send requests to your APIs. Client software is easily reversed and communications are easily intercepted, so obscurity is no defense for APIs. |
Attackers can reverse engineer APIs by examining client code, or simply monitoring communications. Some API vulnerabilities can be automatically discovered, others only by experts. |
Modern web applications and APIs are increasingly composed of rich clients (browser, mobile, desktop) that connect to backend APIs (XML, JSON, RPC, GWT, custom). APIs (microservices, services, endpoints) can be vulnerable to the full range of attacks. Unfortunately, dynamic and sometimes even static tools don’t work well on APIs, and they can be difficult to analyze manually, so these vulnerabilities are often undiscovered. |
The full range of negative outcomes is possible, including data theft, corruption, and destruction; unauthorized access to the entire application; and complete host takeover. |
Consider the impact of an API attack on the business. Does the API access critical data or functions? Many APIs are mission critical, so also consider the impact of denial of service attacks. |
|
|
Am I Vulnerable To 'Insufficient Logging&Monitoring'?
Testing your APIs for vulnerabilities should be similar to testing the rest of your application for vulnerabilities. All the different types of injection, authentication, access control, encryption, configuration, and other issues can exist in APIs just as in a traditional application. However, because APIs are designed for use by programs (not humans) they frequently lack a UI and also use complex protocols and complex data structures. These factors can make security testing difficult. The use of widely-used formats can help, such as Swagger (OpenAPI), REST, JSON, and XML. Some frameworks like GWT and some RPC implementations use custom formats. Some applications and APIs create their own protocol and data formats, like WebSockets. The breadth and complexity of APIs make it difficult to automate effective security testing, possibly leading to a false sense of security. Ultimately, knowing if your APIs are secure means carefully choosing a strategy to test all defenses that matter. |
How Do I Prevent 'Insufficient Logging&Monitoring'?
The key to protecting APIs is to ensure that you fully understand the threat model and what defenses you have:
Be sure your security analysis and testing covers all your APIs and your tools can discover and analyze them all effectively. |
|
Example Attack Scenarios
Scenario #1: Imagine a mobile banking app that connects to an XML API at the bank for account information and performing transactions. The attacker reverse engineers the app and discovers that the user account number is passed as part of the authentication request to the server along with the username and password. The attacker sends legitimate credentials, but another user’s account number, gaining full access to the other user’s account. Scenario #2 Imagine a public API offered by an Internet startup for automatically sending text messages. The API accepts JSON messages that contain a “transactionid” field. The API parses out this “transactionid” value as a string and concatenates it into a SQL query, without escaping or parameterizing it. As you can see the API is just as susceptible to SQL injection as any other type of application. In either of these cases, the vendor may not provide a web UI to use these services, making security testing more difficult. |
References
OWASP External |
| ← A9-Using Components with Known Vulnerabilities | What's Next for Developers → |
