"How to Detect" section

[Paulo Silva]

Dear All,
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` [1] branch you'll find a new "How to Detect"
section on each Top 10 weakness.

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

[1]: https://github.com/OWASP/API-Security/blob/feature/how-to-detect/2019/en/dist/owasp-api-security-top-10.pdf
[2]: https://github.com/OWASP/API-Security/issues/21

Cheers,
Paulo Silva

OWASP API Security Project - Project Main Maintainer
OWASP Go Secure Coding Practices Guide - Project Co-Leader

[abid khan]

Very valid point Paulo u highlighted) but im sharing my view that the people who respond on how to detect must know what is API nd how it works, probably the most contributed people on TOP 10 API risk should be the right to respond "How to Detect" else contributor will ask to change the title first before responding how to detect, just an assumption. now lets see how we can contribute on subject concern.

Regards:

ABID

[abid khan]

paulo, can i directly posted the test method "how to detect" with exploit scenario over here rather than going into the github repo etc.?

Regards:

ABID

On Thursday, September 19, 2019 at 9:33:18 PM UTC+5, Paulo Silva wrote:

[Paulo Silva]

Hi Abid,

Contributions are strongly encouraged to be done in GitHub so that we can track them and their authors.

If you're not used to git, you can use GitHub's WebUI which allows you to edit source markdown files inside your browser.

For now, let's move forward in this thread and later on I'll move myself the outcome to the repo.

Please note that "How to Detect" should be a brief paragraph pointing available technology to detect the weakness. Attack scenarios have there own section.

Cheers,

--
You received this message because you are subscribed to the Google Groups "API Security Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-security-pro...@owasp.org.
To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/368a6984-2913-46f5-8db1-94471e91d816%40owasp.org.

[Erez Yalon]

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?

[Isabelle Mauny]

Hi Erez and all,

With the fast evolution of the product market, I would point to “features” rather than giving product categories. 

For example, A1 can be addressed by :

 - Filtering data based on a whitelist model 

 - Use ABAC or RBAC

Then users can map those features to product, solutions on the market, or by coding best practices. It will also help make that list last in time, even if the tools categories change, new categories appear, etc.

In terms of where, a table at end of doc could work, like a cheat sheet, so you have a clear global view on what to do in order to address all vulnerabilities. 

Cheers,

Isabelle.

___________________________________________________________

Isabelle Mauny - Chief Product Officer and Founder - 42Crunch

-- 
You received this message because you are subscribed to the Google Groups "API Security Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-security-pro...@owasp.org.

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/715bd813-e489-4565-9e74-499c8a107ab4%40owasp.org.

[Girish Jorapurkar]

Why not both? Reasoning.. for those who are referring to a specific issue, they get the complete "picture" for the issue on that page.... for those who want to take a holistic approach and see/verify their security controls (process-wise or technical), they will benefit from the summary page.

(By the way, a huge thank you for this effort of creating, sharing and inviting the participation!)

--

[abid khan]

Dear All, please find attached effective detection against A1 and A5, please feel free to discuss the detection process which is briefly described in attached document along with A1 nd A5 issues screen shots.

Regards:

ABID KHAN

On Thursday, September 19, 2019 at 9:33:18 PM UTC+5, Paulo Silva wrote:

[Paulo Silva]

On Friday, September 20, 2019 at 5:13:31 PM UTC+1, Isabelle Mauny wrote:

Hi Erez and all,

With the fast evolution of the product market, I would point to “features” rather than giving product categories. 

For example, A1 can be addressed by :

 - Filtering data based on a whitelist model 

 - Use ABAC or RBAC

Data filtering, ABAC and RBAC belong to "How to Prevent" section.

The "How to Detect" should provide answer to different question: "my teams are developing an API: what tools should I provide to them so that we can avoid/early detect security issues?"

Then users can map those features to product, solutions on the market, or by coding best practices. It will also help make that list last in time, even if the tools categories change, new categories appear, etc.

Industry is used to "Magic Quadrants".

I think using "product families" (e.g., RASP, DAST, SAST, ...) will work.

 

To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

[Paulo Silva]

On Friday, September 20, 2019 at 10:57:13 PM UTC+1, Girish Jorapurkar wrote:

Why not both? Reasoning.. for those who are referring to a specific issue, they get the complete "picture" for the issue on that page.... for those who want to take a holistic approach and see/verify their security controls (process-wise or technical), they will benefit from the summary page.

I like the idea of having both: +1

 

To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

[Paulo Silva]

Hi Abid,

Thanks for your contribution.

In the API Top 10 we can't go as far as you went in your document.

As I said in my first email, we're looking for either a short paragraph on each top 10 entry, or a global table as suggested by Erez.

Can you please build on top of my suggestions:

* GitHub `feature/how-to-detect` branch [1]
* A1:2019 Broken Object Level Authorization "How to Detect" example [2]

As far as I understand it you suggest Pentesting as a mean to detect A1 and A5.

We agree on that and Pentesting is already on our draft [2], [3].

[1]: https://github.com/OWASP/API-Security/tree/feature/how-to-detect

[2]: https://github.com/OWASP/API-Security/blob/feature/how-to-detect/2019/en/src/0xa1-broken-object-level-authorization.md#how-to-detect

[3]: https://github.com/OWASP/API-Security/blob/feature/how-to-detect/2019/en/src/0xa5-broken-function-level-authorization.md#how-to-detect

Cheers,

[ABID KHAN]

Sure i understand what exactly you want i will build-up a short (multiple paragraph) against most of the API top 10, like how would i know that im vulnerable? Right?

 

or how can i detect at the very earlier stage of API development.? is that what you mean?

 

as far as the Pentesting mean to detect A1 and A5 was concern it was comprehensive and one of the aggressive approach to detect all API top 10, (mentioned in my document" actually i went to the given draft [1][2] but i did not find such technical stuff in those draft which could be used to "detect All API top 10" it was just about the approach to follow "how to detect" like it says "code review or by pentest you can detect, but how to detect technically was not there, so the point im trying to highlighting is there must be a document or something like which tell the world how pentester can detect, i guess that would be really helpful for tester  that how and what kind of tricks/techniques is possible to use in order to detect such vulnerabilities.

Regards:

ABID

 

[Paulo Silva]

Abid,
To try to avoid duplicate work, please carefully read suggested "How
to Detect" drafts:

* https://github.com/OWASP/API-Security/blob/feature/how-to-detect/2019/en/src/0xa1-broken-object-level-authorization.md#how-to-detect
* https://github.com/OWASP/API-Security/blob/feature/how-to-detect/2019/en/src/0xa2-broken-authentication.md#how-to-detect
* https://github.com/OWASP/API-Security/blob/feature/how-to-detect/2019/en/src/0xa3-excessive-data-exposure.md#how-to-detect
* https://github.com/OWASP/API-Security/blob/feature/how-to-detect/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md#how-to-detect
* https://github.com/OWASP/API-Security/blob/feature/how-to-detect/2019/en/src/0xa5-broken-function-level-authorization.md#how-to-detect
* https://github.com/OWASP/API-Security/blob/feature/how-to-detect/2019/en/src/0xa6-mass-assignment.md#how-to-detect
* https://github.com/OWASP/API-Security/blob/feature/how-to-detect/2019/en/src/0xa7-security-misconfiguration.md#how-to-detect
* https://github.com/OWASP/API-Security/blob/feature/how-to-detect/2019/en/src/0xa8-injection.md#how-to-detect
* https://github.com/OWASP/API-Security/blob/feature/how-to-detect/2019/en/src/0xa9-improper-assets-management.md#how-to-detect
* https://github.com/OWASP/API-Security/blob/feature/how-to-detect/2019/en/src/0xaa-insufficient-logging-monitoring.md#how-to-detect

Then, if you have suggestions to change them, please send your comments here.

Cheers,

> --
> You received this message because you are subscribed to the Google Groups "API Security Project" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-pro...@owasp.org.
> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/dae3dde5-1fc2-4003-80ad-57395a400316%40owasp.org.



--

[ABID KHAN]

i guess the pentest should be included as mandatory to detect broken-authentication issue,

 

as most of the API service use authentication credentials (at backend) before allowing user to access to the API just to ensure user authenticity, and that credentials itself has passed in unsecure way, example in headers or it has some broken cryptographic weakness which might be the easiest target for an attacker to bypass the service authentication using manual pentest and gain direct access to the API services.

Plz note: automated tool might not disclosed such broken authentication credentials in an API as it has no direct interface where tool itself can authorized (using credentials) to detect such weakness, it is only possible when application itself has authentication module like web app, but yes tool can be used against rest of the vulnerabilities associated with “broken-authentication”, like brute force etc,

 

Please allow me (just to prove my concept) to share some screen-shot of A2 shown how it is possible to detect A2 using Pentest approach, it also shows how it is easiest for an attacker to gain access to the API services.

Regards:

ABID KHAN

> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

[Andreas Happe]

Hi,

great talk at AppSec btw.

I just checked the howto detect bola/broken-authentication sections. Into how much depth do you want to go? For example for Broken Authorization I would like something like "given an service endpoint xyz/invoices/update, get valid credentials for two users (assume JWT or Cookie-based session) and then perform curl against valid authorization, curl without authentication data, curl with wrong authorization data.

It would be great if we could show a screenshot of burp with a configured authentication/authorization check plugin, but that is to vendor specific for me. Is there something like this for OWASP ZAP?

What do you think? If that's okay I can prepare an example

cheers, Andreas

> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

[ABID KHAN]

i had the same confusion but later i came to know that the approach (how to detect)  is only requirement instead of going into depth,  for example which approach does tester need to counter API top 10 (Pentest,code review or tool). hope it clarify all.

Regards:

ABID KHAN

[Yoav Spector]

Hi all.

I have a question. The focus I see is on the development stage. Pen testing and data-driven methods are able to detect some of these issues, but only after development (i.e. in production).

Is the difference between "How to detect" and "How to prevent" is time-based (dev. phase vs production phase) or action-based (How to know and alert vs how to safely block)?

Regards,

Yoav

> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-pro...@owasp.org.

> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/dae3dde5-1fc2-4003-80ad-57395a400316%40owasp.org.



--
Paulo Silva

OWASP API Security Project - Project Main Maintainer
OWASP Go Secure Coding Practices Guide - Project Co-Leader

--

You received this message because you are subscribed to the Google Groups "API Security Project" group.

To unsubscribe from this group and stop receiving emails from it, send an email to api-security-pro...@owasp.org.
To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/304b3851-3b35-4093-a455-434be2c9afe4%40owasp.org.

[Ozioma Aghamba]

Hi Yoav,

I think that the unique implementation of APIs as opposed to software applications in general makes it such that detection mostly occurs post-development. 

Think of it like this: You're trying to connect 2 cities together (Web resource to web client or mobile app) through a road (API). Until you build the road, you don't know what people (malicious vs non-malicious users) will be accessing it, how or whether it may be abused by transporting illegal/contraband goods until the road is built, complaints are made and it becomes news. One way to combat this would be to install security checkpoints after the road has been built (because this can't be done before it is built). However, if this had been considered before construction, the road would have been built at entry points (where security checks will be carried out). 

APIs are mostly built like the road in this case, but, by making security considerations early on, most of these issues can be detected before release to the public.

Forgive the shabby analogy but I hope you get the idea.

Thanks,

Ozioma

> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/dae3dde5-1fc2-4003-80ad-57395a400316%40owasp.org.



--
Paulo Silva

OWASP API Security Project - Project Main Maintainer
OWASP Go Secure Coding Practices Guide - Project Co-Leader

--
You received this message because you are subscribed to the Google Groups "API Security Project" group.

To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

[Keith Casey]

To make the analogy a little more relatable, maybe flip it to a tollroad and the reasoning still works.

I think the underlying problem that we have is that people *aren't* generally planning for those tollbooths. It's not out of negligence but it's from lack of perspective.

Before that road is built, people travel between the two cities via indirect means (scraping?). It's painful and takes a while but it generally works. As more people do it, the indirect paths become more direct and form into consistent patterns. The path through the fields becomes a dirt road becomes gravel becomes paved.

Too often no one said "hey, we should set up/plan a tollbooth to track traffic and control the flow" and now you have a major highway which people depend on and changing the flow is painful at best.

I may have to use this analogy elsewhere. Well done. :)

keith

To unsubscribe from this group and stop receiving emails from it, send an email to api-security-pro...@owasp.org.

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/9b4ce2d4-0280-4566-8ad7-a08037811809%40owasp.org.

-- 

D. Keith Casey, Jr.

http://CaseySoftware.com/

Check out my book "A Practical Approach to API Design"

available now: http://bit.ly/restfulapis

and the API Developer Newsletter: http://bit.ly/apiWeekly

[Yoav Spector]

Hi.

Thanks for the replies.

I agree that detection occurs mainly post-development, if it happens at all. I think this should also be reflected in the "How to detect" section, as not all readers are familiar with all existing detection methods.

> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-pro...@owasp.org.

> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/dae3dde5-1fc2-4003-80ad-57395a400316%40owasp.org.

--

Paulo Silva

OWASP API Security Project - Project Main Maintainer

OWASP Go Secure Coding Practices Guide - Project Co-Leader

--

You received this message because you are subscribed to the Google Groups "API Security Project" group.

To unsubscribe from this group and stop receiving emails from it, send an email to api-security-pro...@owasp.org.

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/304b3851-3b35-4093-a455-434be2c9afe4%40owasp.org.

--

You received this message because you are subscribed to the Google Groups "API Security Project" group.

To unsubscribe from this group and stop receiving emails from it, send an email to api-security-pro...@owasp.org.

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/9b4ce2d4-0280-4566-8ad7-a08037811809%40owasp.org.

-- 

D. Keith Casey, Jr.

http://CaseySoftware.com/

Check out my book "A Practical Approach to API Design"

available now: http://bit.ly/restfulapis

and the API Developer Newsletter: http://bit.ly/apiWeekly

--
You received this message because you are subscribed to the Google Groups "API Security Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-security-pro...@owasp.org.

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/402f8beb-6f67-4b35-b091-19184fda7a88%40www.fastmail.com.

[Paulo Silva]

Fortunately, OWASP Top 10 series are not only read by developers but also by
some other security practitioners like CISOs.

The "How to Detect" section should cover the required best
practices/tasks/tools to detect security issues during development, testing,
and production stages.

For instance, both *code review* and *pen testing* allow early detection of
authentication issues. The former during development (e.g., authentication
middleware missing for some route) the latter *after the implementation cycle*
(e.g. bypass identification).
With that in mind, managers will be able to promote code review among
development teams and do whatever necessary to guarantee pen testings to
happen as earlier as possible either creating an internal security team or
outsourcing it (both take a considerable amount of time).

I would like to make it clear that when *pen testing* is suggested in the
"How to Detect" draft, we're suggesting it as part of development cycles. As
soon as the development team finishes the authentication mechanism, in the
next development cycle, while the development team is working on other
features, the security team should spend its time testing/breaking the
authentication.
I believe this approach has better results than starting the pen testing only
when the API is ready to be released from an implementation perspective. The
"What's Next for DevSecOps" explores this idea.

That being said, we're looking for:

* a very concise paragraph for each top 10 weakness;
* (maybe) a "What's Next for CISOs?" section [1] with a summary table [2] and
other relevant hints.

[1]: https://github.com/OWASP/API-Security/issues/21#issuecomment-535677677
[2]: https://github.com/OWASP/API-Security/issues/21#issuecomment-533607481

Cheers,

> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/CALrqrPYasFXhEUSCg4yJYROjK07TuKKtGkMQKTGvzbPoaq2MzQ%40mail.gmail.com.

[ABID KHAN]

i totally agree with you "Paulo Silva" 

actually my highlighted approach in "how to detect" Draft section against A2 was about use Pentest approach to detect A2 at the earlier stage instead of using tool, where the draft says "tool" and "code review" only.

because as i highlighted in my above statements (just to prove my concept)  that tool never give you the A2 detection if we talk about API security testing (detail response is already given above) however it covered the rest of vuln associated with A2 such as brute force etc, but it wouldn't go to detect A2 as mentioned in above define methods in my response, therefor i would like to request everyone in this group go and read my response against A2 (first read DRAT how to detect against A2) and then feel free to response for further clarity if anyone require.

Regards:

ABID KHAN

>> > To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

>> > To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/dae3dde5-1fc2-4003-80ad-57395a400316%40owasp.org.
>>
>>
>>
>> --
>> Paulo Silva
>>
>> OWASP API Security Project - Project Main Maintainer
>> OWASP Go Secure Coding Practices Guide - Project Co-Leader
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "API Security Project" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

>> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/304b3851-3b35-4093-a455-434be2c9afe4%40owasp.org.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "API Security Project" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

>> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/9b4ce2d4-0280-4566-8ad7-a08037811809%40owasp.org.
>>
>>
>> --
>> D. Keith Casey, Jr.
>> http://CaseySoftware.com/
>>
>> Check out my book "A Practical Approach to API Design"
>> available now: http://bit.ly/restfulapis
>> and the API Developer Newsletter: http://bit.ly/apiWeekly
>>
>> --
>> You received this message because you are subscribed to the Google Groups "API Security Project" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

>> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/402f8beb-6f67-4b35-b091-19184fda7a88%40www.fastmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "API Security Project" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

[Erez Yalon]

Dear All,

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.

Best,

Erez

>> > To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

>> > To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/dae3dde5-1fc2-4003-80ad-57395a400316%40owasp.org.
>>
>>
>>
>> --
>> Paulo Silva
>>
>> OWASP API Security Project - Project Main Maintainer
>> OWASP Go Secure Coding Practices Guide - Project Co-Leader
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "API Security Project" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

>> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/304b3851-3b35-4093-a455-434be2c9afe4%40owasp.org.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "API Security Project" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

>> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/9b4ce2d4-0280-4566-8ad7-a08037811809%40owasp.org.
>>
>>
>> --
>> D. Keith Casey, Jr.
>> http://CaseySoftware.com/
>>
>> Check out my book "A Practical Approach to API Design"
>> available now: http://bit.ly/restfulapis
>> and the API Developer Newsletter: http://bit.ly/apiWeekly
>>
>> --
>> You received this message because you are subscribed to the Google Groups "API Security Project" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

>> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/402f8beb-6f67-4b35-b091-19184fda7a88%40www.fastmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "API Security Project" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.