Proposal for top 10: Inadvertently Encouraging Vulnerabilities in External Systems

[Joshua Maddux]

I’d like to propose an item in the top 10 relating to defensive programming across API boundaries, and the idea that the architecture of an API affects the risk level of applications that consume it.

This is something that would feel out of place in the broader web appsec top 10, but really becomes a concern when talking about APIs.  It’s especially important for those that are consumed by a large amount of external applications, as opposed to just an SPA and/or mobile app.  The main motivation for this is the content of the talk I gave at defcon and blackhat this year:

https://www.defcon.org/html/defcon-27/dc-27-speakers.html#Maddux

https://www.blackhat.com/us-19/briefings/schedule/index.html#api-induced-ssrf-how-apple-pay-scattered-vulnerabilities-across-the-web-14462

I also noticed that it’s becoming a theme for trainings in API security.  I don’t know what the training content entails, but it would be interesting to get the trainer’s thoughts on this, since there’s a section here to “Create APIs that are easy to use securely and hard to use insecurely” which is exactly what I’m talking about: https://www.blackhat.com/eu-19/training/schedule/index.html#attacking-and-securing-apis-15133

For the issue I pointed out in Apple Pay Web, the core idea is that the API requires merchants to implement an endpoint that is the textbook SSRF case, unless merchants’ developers are aware of SSRF and do careful validation, which has some tricky edge cases.  It’s hopefully changing now that this has had some exposure at conferences. In the meantime it’s done a lot of damage, caused Apple some embarrassment, and earned me some bounties in sites that support Apple Pay.

A couple more examples:

• Webhooks - This is one of the most broadly applicable cases, since there are a lot of unauthenticated webhook receivers out there.  The majority of webhook senders simply provide an HMAC and hope that the consumer of the webhook will check it, but in practice this is overly optimistic.  A more defensive approach adopted by some webhooks such as Plaid, is to just provide a cryptographically unique ID and expect the receiver to make a separate HTTP request to fetch the event with that ID.  Another alternative is to still send the HMAC, but perform a couple of testing requests during registration to verify that the receiver does in fact verify the HMAC.

• SOQL - Salesforce has a REST API that takes in a sql-like string as a parameter, and it’s fairly popular.  Unfortunately, there’s no parametrization built into the API, so you get a lot of injection attacks in applications that consume this API.  Obviously it would be difficult for Salesforce to walk back this decision, but if they had audited and designed the API with the idea I'm proposing in mind, they could have included, and perhaps enforced parameterized queries from the start.  Importantly, this does not fall under A8/Injection against Salesforce’s API, since the injection doesn’t happen within Salesforce’s code. It manifests as passing the SOQL escaping burden to applications that consume the API: https://trailhead.salesforce.com/en/content/learn/modules/secdev_injection_vulnerabilities/secdev_inject_prevent_soql_injection 

• For some older precedent, a lot of past SAML stuff might fit under this category, since it’s similar in nature - there’s a single design detail that tends to manifest as a vulnerability across multiple implementations.

Some potential objections to including this in the top 10:

• “The API security top 10 draft is already pretty good.”  I agree! I think if anything, a couple of items might be consolidated, since it’s already a great list.  One possibility might be to roll together Object+Function level access control (A1/A5), while keeping it at the top of the list since it’s really important.  Or maybe one of the other items could be combined with A7.

• “There’s not enough precedent.”  This might be fair, and I’m not super familiar with the process for coming up with the top 10 lists.  In the meantime this category is becoming my bug hunting MO, so there’s definitely going to be more precedent as time goes on.

If there is some interest in this, I would be happy to write a draft for the appropriate section in the Top 10 PDF, as well as cheat sheet content and relevant code for crAPI.

[Paulo Silva]

Hi Joshua,
Thanks for your interest and for the detailed email.

We had the chance to discuss this topic in our last meeting and agreed that it
isn't a top 10 issue.

You can now get more details on how this OWASP API Security Top 10 was built,
reading the Methodology and Data section [1].

As you pointed out, "there's not enough precedent": only 2.58% of the analyzed
incidents were related to SSRF, pushing this weakness to the bottom. Then,
applying the Risk Methodology [2] it gets out of the Top 10.

We've got great feedback about the proposed Top 10 list which we believe
reflects the point where we are now in terms of API security weaknesses. Of
course when working on the next Top 10 version, this will be re-evaluated.

That being said, we agreed that this is something that should be part of a cheat
sheet and something that we definitely want to have on crAPI - Completely
Ridiculous API (check the roadmap [3]).

It would be awesome to have your contributions on this and other topics.

[1]: https://github.com/OWASP/API-Security/blob/develop/2019/en/src/0xd0-about-data.md
[2]: https://github.com/OWASP/API-Security/blob/develop/2019/en/src/0x10-api-security-risks.md
[3]: https://www.owasp.org/index.php/OWASP_API_Security_Project#tab=Road_Map

Thanks for sharing,

[Joshua Maddux]

Hi Paulo,

Thanks for the detailed response and for those links.  That makes sense - having data drive the top 10 is great, and of course that makes precedent a big factor.  I look forward to contributing to crAPI and cheatsheets - it sounds like they'll be really cool.

[Isabelle Mauny]

Dear all,

I taught an API security course yesterday and for that created material based on the Pixi API (which is part of the OWASP devSlop project).

Basically, I used the vulnerabilities in the API to illustrate each Top10 entry, plus some real life breaches. 

I believe that with limited changes, Pixi could really be the base for the crAPI for this project. 

Another thing for the project: as you mention, the entries are explained independently, but are tighly related. The document would benefit from explaining how the combination of several issues leads to a breach: for example, in Pixi,  bad security configuration leads me to find a JWT shared secret, I use that to forge JWTs, lack of JWTs content validation and it gets accepted without an issue, since IDs are guessable, I can login as another user and get their data. Through mass assignment, I can make myself an admin and get the list of all users. And finally, since we have a MongoDB noSQL injection vulnerability, it allows me to login into any account without knowing their passwords.

Looking forward to contribute any way we can!

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/5417798e-546a-4cdc-9aaf-840661ee21be%40owasp.org.

[Paulo Silva]

Hi Isabelle,

On Thu, Sep 12, 2019 at 8:48 AM Isabelle Mauny <isab...@42crunch.com> wrote:
>
> Dear all,
>
> I taught an API security course yesterday and for that created material based on the Pixi API (which is part of the OWASP devSlop project).

Great sharing!
Sometimes it is not an easy task to keep on track with all OWASP Projects.
Pixi project deserves a mention in the OWASP API Security Top 10 "What's Next
For Developers" section.

> Basically, I used the vulnerabilities in the API to illustrate each Top10 entry, plus some real life breaches.

What about your materials, are they available somewhere or can you share them?

> I believe that with limited changes, Pixi could really be the base for the crAPI for this project.

Definitely.

> Another thing for the project: as you mention, the entries are explained independently, but are tighly related. The document would benefit from explaining how the combination of several issues leads to a breach: for example, in Pixi, bad security configuration leads me to find a JWT shared secret, I use that to forge JWTs, lack of JWTs content validation and it gets accepted without an issue, since IDs are guessable, I can login as another user and get their data. Through mass assignment, I can make myself an admin and get the list of all users. And finally, since we have a MongoDB noSQL injection vulnerability, it allows me to login into any account without knowing their passwords.

How do you see this coming into API Security Top 10?

To be honest I like the Top 10 single page template: it makes it a lot
easier for
developers since it is very succinct. We went with a single sheet per weakness
(front and back) so that we could have more detailed attack scenarios (btw, the
attack scenarios are based on public incidents).

We plan to add to each weakness a "How to Detect" section.
What do you think about a "How to Escalate" section with a list of related Top
10 weakness with a short description on how they can be combined to escalated
the issue?

>
> Looking forward to contribute any way we can!

Would you like to open an issue on GitHub [1] so that we can work on it?

I was thinking that, maybe, you could also open a Pull Request with a proposal
for the A7:2019 Security Misconfiguration since you already have a very good
starting point.

[1]: https://github.com/OWASP/API-Security/issues

Cheers,

> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/B30AE813-D1C9-4830-BD69-3E1750D73B7E%4042crunch.com.



--
Paulo Silva

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

[Mordecai Kraushar]

Hi;

I will present next week at the PCI community meeting on securing cardholder data in the api economy.

In the prizo i will demo PIXI as well. (https://events.pcisecuritystandards.org/vancouver-2019/speakers/mordecai-kraushar/) 

Slides should be available soon after the conference.

mordecai

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

[erez....@owasp.org]

Hello Mordecai,

 

That sounds very interesting. I am looking forward to seeing your slides.

 

Best,

 

Erez Yalon

OWASP API Security Project Co-Leader

OWASP Go-SCP Project Co-Leader

(Coming Soon) OWASP Software Composition Security Project Leader

 

Email:    erez....@owasp.org

Mobile: +972505977720

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

[Isabelle Mauny]

Hi Paulo,

Will brand the presentation under Creative commons and share.

As for the PR, sure thing! Let me have a shot at that...

Obrigada;-) 

Isabelle.

[Isabelle Mauny]

Dear group,

As promised, here is the presentation :

https://www.dropbox.com/s/cg5v5rhh40iikrq/owasptop10bytheexample.pdf?dl=0

Please bear with me as this is still work in progress - Comments are obviously welcome!

Cheers,

Isabelle.

___________________________________________________________

Isabelle Mauny - Chief Product Officer and Co-Founder - 42Crunch

[Paulo Silva]

Hi Isabelle,
Great work. It really looks interesting.

Pixi looks the best tool available to practice API security. I'll add a
reference to it in the API Top 10.

Obrigado,

> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/6F1EBC28-74E0-488A-8EED-BAC4264E716A%4042crunch.com.

[erez....@owasp.org]

I agree, great work Isabelle!

Best,

Erez Yalon
OWASP API Security Project Co-Leader
OWASP Go-SCP Project Co-Leader
(Coming Soon) OWASP Software Composition Security Project Leader

Email: erez....@owasp.org
Mobile: +972505977720

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/CAN%3DxGgOBidYD6CfSsabBA-gUEDy6cuRQB3ejbr4PRSA%2BL%2Bxb-g%40mail.gmail.com.

[Dmitry Sotnikov]

Since Erez just mentioned crAPI in another thread - I remembered about this one. :)

So I looked at Pixi, and it looks like 8 out of 10 vulnerabilities are already there:

1. Broken Object Level Access Control (delete takes picture_id as param)
2. Broken Authentication (static API key in URL over http)
3. Excessive Data Exposure (get pictures, get user/info)
4. Lack of Resources & Rate Limiting (no rate limits, /pictures has no array size limit, /pictures/upload has no size limit)
5. Missing Function/Resource Level Access Control (Admin function access is checked by app web UI - APIs can be invoked directly w/o checks)
6. Mass Assignment (put /user/edit_info)
7. Security Misconfiguration (server.conf file accessible on the server and contain JWT secret)
8. Injection (MongoDB NoSQL injection in post /login)
9. Improper asset management - missing in Pixi
10. Insufficient logging - need to check: Pixi has logs and even some bad ones leaking tokens, but is there insufficient logging for any attack scenarios?

Since this is an OWASP and open source project, why re-invent the wheel? Sounds to be like we can be better off just contributing to the project and documenting the vulnerabilities from API Top 10 project perspective.

Dmitry

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/001201d56ef2%24a6b57af0%24f42070d0%24%40owasp.org.

--

Dmitry Sotnikov

VP, Cloud Platform
42 Crunch
Cell: +1.949.303.9653, Skype: DSotnikov, Twitter, LinkedIn

[erez....@owasp.org]

Hi Dmitry,

 

It makes a lot of sense that projects like JuiceShop, Pixi, and others, will cover API Security issues since API is the heart of every modern app.

While supporting and urging everyone who can to contribute to the above awesome projects, I believe there is an added value of having a specific project focused around API Security. This is not really re-inventing the wheel. Just making more wheels 😃

 

Best,

 

Erez Yalon

OWASP API Security Project Co-Leader

OWASP Go-SCP Project Co-Leader

(Coming Soon) OWASP Software Composition Security Project Leader

 

Email:    erez....@owasp.org

Mobile: +972505977720

[Dmitry Sotnikov]

OK, happy to contribute when the project starts.