How to Detect section

[PauloASilva]

We have received some comments and feedback from CISOs and other non-hands-on
managers about our, and other, top 10 guides. The main thing they are usually
missing is an action item for them, in the form of "how to detect".

In the feature/how-to-detect branch you'll find a new "How to Detect"
section on each Top 10 weakness.

We would like to have your comments and contributions to review and improve
them. Bear in mind that we SHOULD NOT mention any specific product, but only the
technology.

Cheers,
Paulo A. Silva

[ErezYalon]

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

[ErezYalon]

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:

	Code Review	DAST	IAST	WAF	SAST	Alien Technology
A1	X	X			X	X
A2	X	X	X	X		X
A3	X		X	X		X

Thoughts?

[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.

[LauraRosePorter]

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.

[PauloASilva]

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

[PauloASilva]

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

[tuxnam]

I like the idea of 'What's next for CISOs?', can be short, giving a few hints. Will think about it. I have a few questions/remarks on the full document, happy to discuss these: *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. Generally, organisation expose the APIs, client implementation is left to customer. A developer portal is available with OpenAPI specifications. This means that a lot of controls can't be applied client-side and we need a way to validate server-side (API gateway, WAF,.. etc.) 2. What about: how to detect? *Broken Object Level Authorization* in How to prevent: Point 2: session object in a stateless world is a bit confusing. *Broken authentication:* 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. Authentication *to *a OAuth endpoint gives you a valid OAuth token, which then is used as access control mechanism. Authentication is therefore a unique step, while the token then acts both to prove you authenticated and to take access control decision(s). On how to prevent: How do you implement MFA on APIs? It's (most of the time) application to application flow. Same for captcha. 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) *Sensitive data exposure* I'd add also another straightforward scenario: having sensitive data in URI. This leads to data being in server logs or other kind of caches. example: GET HTTPS://api.mybank.com/v1/creditcard/{partial-credit-card-number}/transactions *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. *For injection and mass assignment or even rate limiting:* I would also add content-inspection of JSON/XML payloads. It can be abused either to DoS, either to try to leak info or even perform mass assignment. From what we observed in our own scenarios, there was a clear lack of JSON schema inspection or content validation, leading to either errors in the API endpoint (with 'only' error message in the best scenario) or injection temptatives. This could, in extreme cases, even lead to Remote Code Execution.

…

--- Just a few thoughts. Very good and useful material! thanks to all who contributed. BRs,

On Thu, Sep 26, 2019 at 1:04 PM PauloASilva ***@***.***> wrote: Hi @tuxnam <https://github.com/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 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21?email_source=notifications&email_token=AEMGMW32LUHGWK5WPHPXRCLQLSJM7A5CNFSM4IYNMWU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7VF7FQ#issuecomment-535453590>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEMGMW3EYYZR4CVJVUB4ULDQLSJM7ANCNFSM4IYNMWUQ> .

-- Benats Guillaume.

[PauloASilva]

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

[tuxnam]

Hi, Thanks for your detailed comments. I'll try to go through latest develop branch again this week taking your comments into account and see if anymore feedback. I'll also start thinking about the whats next for CISOs part and maybe draft something. Guillaume (aka tuxnam)

…

On Mon, 7 Oct 2019, 20:11 PauloASilva, ***@***.***> wrote: Hi @tuxnam <https://github.com/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 <https://github.com/OWASP/API-Security/tree/feature/how-to-detect>: 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 <https://github.com/OWASP/API-Security/blob/develop/2019/en/src/0xa1-broken-object-level-authorization.md>) 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" ***@***.*** <https://github.com/inonshk>, @ErezYalon <https://github.com/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 ***@***.*** <https://github.com/inonshk>, @ErezYalon <https://github.com/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 <#23> matches your expectation? Cheers, Paulo A. Silva — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21?email_source=notifications&email_token=AEMGMWYKFNHK4EPH2Q5JTILQNN3VDA5CNFSM4IYNMWU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEARJIGA#issuecomment-539137048>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEMGMW6IHKN5EO3TAWKGLN3QNN3VDANCNFSM4IYNMWUQ> .

[ErezYalon]

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.