search

OWASP / API-Security

OWASP API Security Project
https://owasp.org/www-project-api-security/
Other
2.07k stars 377 forks source link

Lack of injection in 2023 API10 #86

Closed cyn8 closed 1 year ago

cyn8 commented 1 year ago

Hi team,

I have noticed whilst going through the new API10 guidelines that there is no dedicated page for injection-based attacks. I realise going into 2023, pure injection-based are becoming less common, but I believe it should still be prevalent enough to test for these issues?

Is it intended for the 2023RC that the injection category is removed?

planetlevel commented 1 year ago

Take a look at the issues starting with https://github.com/OWASP/API-Security/issues/77. The team excluded injection because they think it's not specific to APIs. It doesn't matter that recent reports have shown it to be the largest attack vector on APIs. The philosophy is that this T10 should only include things that are uniquely risks to APIs. I think this is wrong and will mislead teams to ignore critical problems like injection on APIs.

ynvb commented 1 year ago

@planetlevel - to further strengthen your point: If this list is supposed to include only attacks unique to APIs, why is there a new "SSRF" category in this list? This is clearly not an exclusive attack on APIs - but it is very relevant (which is why I believe it found its way into the list).

Also, Injections were not excluded - they are part of API-10 - however, I agree it is not very clear to understand that reading trough the categories description.

cyn8 commented 1 year ago

@ynvb

Also, Injections were not excluded - they are part of API-10 - however, I agree it is not very clear to understand that reading trough the categories description.

Could you link me where injections are included in the 2023 API10? I can't seem to find them.

securitylevelup commented 1 year ago

After a GitHub search in the repo, I see two mentions of 'Injection' now in API10 with two additional links. This is definitely not enough focus on API Injection attacks, especially with the threat of GraphQL Injection attacks looming ahead.

https://github.com/OWASP/API-Security/blob/c56e753eb08e28c6c6d4d756bb3038bcc0ca804a/2023/en/src/0xaa-unsafe-consumption-of-apis.md

llegaz commented 1 year ago

I think Remote Execution is not mentioned either. IMO, that points well the lack on the injection topic and the threats that are overlooked here.

tebbers commented 1 year ago

@planetlevel - to further strengthen your point: If this list is supposed to include only attacks unique to APIs, why is there a new "SSRF" category in this list? This is clearly not an exclusive attack on APIs - but it is very relevant (which is why I believe it found its way into the list).

Also, Injections were not excluded - they are part of API-10 - however, I agree it is not very clear to understand that reading trough the categories description.

And isn't an SSRF just one TYPE of Injection? Why leave the others out and just name that one...Seems odd to not have all of the injection types in one place.

planetlevel commented 1 year ago

SSRF is a top-level item in main OWASP T10 (as opposed to being included in the Injection category). I expect that someday it will be subsumed into the injection category. But this decision was made based on an absolutely massive data collection effort and months of data science by a highly qualified team. Personally, I support having SSRF as a top-level category for APIs... but that's because I have a ton of data about how prevalent this vulnerability is for APIs and how often it is attacked in production.

tebbers commented 1 year ago

SSRF is a top-level item in main OWASP T10 (as opposed to being included in the Injection category). I expect that someday it will be subsumed into the injection category. But this decision was made based on an absolutely massive data collection effort and months of data science by a highly qualified team. Personally, I support having SSRF as a top-level category for APIs... but that's because I have a ton of data about how prevalent this vulnerability is for APIs and how often it is attacked in production.

Is that data public that we can all look at? @planetlevel

planetlevel commented 1 year ago

I offered to share data with the project leads, but never heard anything back.

d0znpp commented 1 year ago

I shared this, but no feedback. According to what we see in CVE and bug bounties, Injections are API1:

Hi guys!

I finally did that! The classification and data source is available here: https://drive.google.com/drive/folders/1IyygtOohhCWlA-mbHUw9w-xgv0dXn7v3?usp=share_link

That's all the CVEs, HackerOne, and more than ten other sources. Mapped to CWEs.

ErezYalon commented 1 year ago

Hi team,

I have noticed whilst going through the new API10 guidelines that there is no dedicated page for injection-based attacks. I realise going into 2023, pure injection-based are becoming less common, but I believe it should still be prevalent enough to test for these issues?

Is it intended for the 2023RC that the injection category is removed?

Hi @cyn8, Yes, the general Injection category was removed. The OWASP API Security Top 10 is an awareness document that expands the general OWASP Security Top 10. Being an expansion, we tried to cover categories unique to APIs, categories that have different consequences/mitigations/mechanisms in APIs, or categories that have a particular interest in an API-centric application. Injections are indeed prevalent. But they exist in every application regardless of whether it uses APIs.

ErezYalon commented 1 year ago

I shared this, but no feedback. According to what we see in CVE and bug bounties, Injections are API1:

Hi guys!

I finally did that! The classification and data source is available here: https://drive.google.com/drive/folders/1IyygtOohhCWlA-mbHUw9w-xgv0dXn7v3?usp=share_link

That's all the CVEs, HackerOne, and more than ten other sources. Mapped to CWEs.

Thanks, @d0znpp, for the effort, but you sent the data after the call-for-data was closed and not in the requested format.

LaurentCB commented 1 year ago

The OWASP API Security Top 10 is an awareness document that expands the general OWASP Security Top 10. Being an expansion, we tried to cover categories unique to APIs, categories that have different consequences/mitigations/mechanisms in APIs, or categories that have a particular interest in an API-centric application.

A first page disclaimer (with this explanation written bold and an url link to the main OWASP Security top 10) as it has already be mentioned would be really nice for newcomers in order to understand the purpose of the project.

Because this project (as pointed out several times now) is REALLY perturbing especially for those accustomed to the main Top 10 for years.

Regards, L.

planetlevel commented 1 year ago

I disagree with the "expands main T10" philosophy. But if that is the plan, then I suggest you delete these categories which are duplicated from main OWASP T10:

If you're planning to stick with some that duplicate the OWASP T10, then I suggest the first one you ought to duplicate is Injection.

ErezYalon commented 1 year ago

A first page disclaimer (with this explanation written bold and an url link to the main OWASP Security top 10) as it has already be mentioned would be really nice for newcomers in order to understand the purpose of the project.

@LaurentCB, we agree. While the RC is just the bare-boned Top 10 list, the final list will be published with a clear introduction (and disclaimer) about the purpose and meaning of the project.

...I suggest you delete these categories which are duplicated from main OWASP T10:

  • 0xa2-broken-authentication
  • 0xa6-server-side-request-forgery
  • 0xa7-security-misconfiguration

@planetlevel, while these categories are not unique to APIs, they do have different consequences/mitigations/mechanisms in APIs.

planetlevel commented 1 year ago

And "injection" doesn't?

All of the main T10 are important for APIs and yet they all need some interpretation for APIs.

This document should capture the T10 risks to APIs. Period.

I don't believe that API developers will read the main T10 and then read the API T10 as an extension.

And API risks like unsafe libraries, injection, weak crypto, and others from the main T10 must be there.

d0znpp commented 1 year ago

I guess we have to agree that the main criteria of this work were to make it look different from OWASP's Web Top 10. That’s why we have Injections renamed and moved down. There is no other reason, and many prove, that Injections are Top-1, including CVE, bug-bounty reports, and data breach analysis, by both amount and risk score.

And in fact, the classic OWASP Top 10 now represents API risk priorities much better than OWASP API Top 10. Which is valid, if we agree that WebApps are in fact just legacy API, a subset of a broader APIs definition.

ErezYalon commented 1 year ago

Thanks, @planetlevel, your opinion was noted.

@d0znpp, API10 is not a renamed Injection category. It is about the false trust feeling that developers have when recining data via responses and not directly from a user. If you missed it, others will as well, so thanks for pointing out it is not clear enough. We will consider re-wording.

wenz commented 1 year ago

SSRF is a top-level item in main OWASP T10 (as opposed to being included in the Injection category). I expect that someday it will be subsumed into the injection category. But this decision was made based on an absolutely massive data collection effort and months of data science by a highly qualified team.

In all fairness, SSRF came from the community survey and would not have made it onto the list based on the data alone ("the data shows a relatively low incidence rate"). I'm guessing it will be eventually moved, but not into Injection, but rather into Broken Access Control (where also CSRF is).