OpenAPI Security Exploits

In the past two days, yet another OpenApi exploit was found that elevates privileges on python. Why is this significant?

Only because I have been talking about these issues as early as 2013 and as late as July 27th when I submitted this as an OpenApi exploit to Github (see below):

In the last 3 years, the number of exploits for OpenAPI has continued to climb without people fixing the issues. The issues affect every underlying implementation but OpenApi continues to push itself as a solution:

This issue affects ALL implementations of OpenAPI due to the fact that it cannot synchronize the state on the fly (due to using an archaic API pattern).

What is Synchronization: OpenAPI Users Don’t Know

OpenAPI users don’t even understand basic principles like ‘shared state’ and when talking to them about ‘synchronized state’ they get confused and do not understand:

For developers who don’t understand the backend, they think duplicate ‘doc generation’ is ‘synchronization’ and a duplicate file is the same as synchronized state without even understanding what synchronization is.

If I wanted to synchronize between two databases, one database copies over the state between to the other LIVE so that they are always in SYNC; It does not create a duplicate file wherein those systems could get out of sync. It duplicates its state continuously on the fly so that the distributed systems always stay in SYNC.

How To Fix Issue: Abstraction of Communication Layer

To fix this issue, you have to abstract the communication logic from the controller so that it can be shared like in this video where I show how to dynamically reload the state:

The OpenAPI exploit only exists due to the fact that the OpenAPI file is a duplicate/unsynchronized file of the actual state in the application and as such, will at times be out of synch with the endpoints and security. This leads to wide open holes for exploitation in the OpenApi spec.