How to Detect section about api-security HOT 10 CLOSED

This question also came up recently when @inonshk and myself introduced the Top 10 at OWASP Global AppSec DC. This should definitely be addressed.

from api-security.

We need to decide if we are going to write a paragraph at the end of every Top-10 item, or create a summary of this at the end of the document.
It can also be in the form of a convenient table. Example:

Thoughts?

from api-security.

Hi,

I think key point is that CISOs and other managers are not sure about differences in web app security detective/preventive controls and API ones. First thing is to highlight this, Whats applicable to both and whats not. From there, what are solutions to cover same topic on API side: dynamic code analysis is not convenient in app2app scenario. What about also insisting on 'continuous scanning/testing' by a red team or équivalent. What I noted in my company API strategy is a misunderstanding of api vs web and why things like WAF are not enough. Just a few evening thoughts @ appsec amsterdam. Happy tl discuss live tomorrow if people are present.

from api-security.

Hi all,

Personally I like the idea of both the table and the how to detect section. The table could possible help non technical individuals in finding out what team can assist them where as the how to detect section would help starting engineers like myself on finding the issues. I would be happy to assist in creating these sections.

from api-security.

Hi @LauraRosePorter

I would be happy to assist in creating these sections.

You can review the initial draft: source, PDF.
Go through all top 10 weaknesses and check whether there's something missing in the "How to Detect" paragraphs.

Cheers,
Paulo A. Silva

from api-security.

Hi @tuxnam

Hi,

I think key point is that CISOs and other managers are not sure about differences in web app security detective/preventive controls and API ones. First thing is to highlight this, Whats applicable to both and whats not. From there, what are solutions to cover same topic on API side: dynamic code analysis is not convenient in app2app scenario. What about also insisting on 'continuous scanning/testing' by a red team or équivalent. What I noted in my company API strategy is a misunderstanding of api vs web and why things like WAF are not enough. Just a few evening thoughts @ appsec amsterdam. Happy tl discuss live tomorrow if people are present.

This could be a "What's Next for CISOs and Managers" section. What do you think?
Would you like to draft it? We would love to review/accept your PR.

Cheers,
Paulo A. Silva

from api-security.

from api-security.

Hi @tuxnam,
Thanks for your comments.
I would like to address them but I'll need your help.

Generic remark(s)

1.

A lot of scenarios/mitigations are assuming the organisation controls the API endpoint, the back-end application (if different) and the client.

Can you please point the Top 10 weaknesses where this happens?

The only assumption we should do regarding the organization is that it controls the API Server, nothing else. I agree that the "back-end application" can be other than the API Server and we should be careful about it.

2.

You can find/review it on feature/how-to-detect branch: we're waiting a few more comments before merging it into develop for later release.

Broken Object Level Authorization

in How to prevent: Point 2: session object in a stateless world is a bit confusing.

You're right, this recommendation doesn't make sense for APIs.
It was removed (check develop branch) and it will be released soon.

Broken authentication

To give you some context, the first draft of this issue addressed mostly client authentication issues such as key management. Although this problem is very common, we realized that it's not an API issue but, instead, a Client issue.

On the other hand User Authentication problems are very common in APIs: the 4th most common weakness on collected data. Because of this, we re-factored this section to address User Authentication instead.

OAuth is not authentication, and certainly not API keys: true and written
all over the web, always good to remind readers: the key missing
information is always: what is API authentication then? Not sure relevant
for this paper but people get confused by reading this.

Any suggestions?

On how to prevent:
How do you implement MFA on APIs? It's (most of the time) application to
application flow. Same for captcha.

Based on given context, does the MFA recommendation make more sense?

Maybe we should discuss whether to rename this weakness "Broken User Authentication" (@inonshk, @ErezYalon).

I'd also add to prevent: ensure all API endpoints require authentication (I
have seen API calls where you could simply remove the bearer token, and get
a response)

What do you think about something like "Verify/test responses from endpoints requiring authentication, when no authentication token is provided."?

Sensitive data exposure

We don't have a "Sensitive Data Exposure" weakness but "Excessive Data Exposure" one ;)

I see your point, but we need to discuss whether it fits Excessive Data Exposure weakness (@inonshk, @ErezYalon).

Rate limiting

Docker is a good suggestion, an API gateway (which can help raise the bar
in most of the Top 10's) is another one.
Rate limit, if not granular enough, can also allow to DoS other users by
targeting the endpoint in a specific way.

Docker was referred as an easy way to accomplish resources limiting since it isn't as "easy" as rate limiting.

Rate Limiting can be implemented in several different ways/places (e.g., middleware, API Gateways, WAF, Firewall, ...): should we refer specifically API Gateways and nothing else or leave the recommendation as generic as possible?

Injection/Mass Assignment/ Rate Limiting

Can you please verify whether PR #23 matches your expectation?

Cheers,
Paulo A. Silva

from api-security.

from api-security.

After some messages we got, followed by internal discussions, it was decided not to include the How to Detect section in the inaugural version of the API Security Top 10.
Even just by mentioning detection technologies we felt that we might fall into unwanted "vendor wars" that would not be acceptable under OWASPs vendor neutrality, and might also divert the attention from the actual goal of this document: raising awareness to the rising importance of API Security.
This section may be considered again in future versions, or in the API Security cheatsheet.

from api-security.