Creating a very spammable endpoint with Oracle APEX Restful Services
I'm helping an organisation that has a very simple (and very static) corporate website. They were interested in adding a contact form, and wanted the data to be sent to their APEX-managed database.
Building an entire back-end service for this purpose seemed like too much work, so I decided to give APEX's RESTful Services a try:
RESTful Services enable the creation of a set of standards-based API’s on top of database objects available for a workspace. Without connecting directly to the underlying data source these API’s allow external systems to interact securely with the data by querying, inserting, updating or deleting.
I started by creating a new CONTACT_REQUEST table:
Then, on the "Restful Data Services" page (under SQL Workshop), I created a new ORDS (Oracle REST Data Services) Module called forms:
Note that I've added the website's domain to the "Origins Allowed" field to allow the website to access the response from this cross-origin request.
Under this new module, I created a Template called contact:
Finally, I created a Handler for this template:
The most important part of the handler configuration is the PL/SQL block. I used the script shown below to insert the data received in the request into the CONTACT_REQUEST table, and define a status variable with value 201, which is the success status code:
In order for the status code to be returned, I also needed to add the X-APEX-STATUS-CODE header configuration at the bottom of the page:
In just a couple of minutes, I had my new endpoint:
And as you can see the data is added to the new database, as expected:
This looks very spammable
It is.
From what I could find, APEX doesn't support rate limiting, so there's not much else I can do to prevent someone from finding this endpoint and spamming it for fun.
Since the client is communicating directly with APEX, I can't think of any alternative way to throttle requests.
Finally, if you've been paying attention I've been obscuring the sub-directory that APEX assigned for my organisation, which was based on the "schema" that I set at the start of this process.
This means that a simple Google Dork may allow you to enumerate all endpoints of this type, and most likely find many that don't enforce authorisation, either on purpose (which is the case here), or by mistake.
In fact, the oracle.txt SecList already has some popular name-patterns.
Have fun 😉