4

I’m still in the planning stage so this may not be fully fleshed out, but I’m working on a SaaS project. Part of which allows users (customers of my SaaS) to configure my API to watch for events and respond in a preconfigured way. One response is for my API (built in PHP) to kick off a POST HTTP request to a URL provided during setup, with given parameters. It is intended that user will point these requests to their own server or other internal system and then be able to listen for these requests and integrate it with their own internal email/tracking/payment systems.

However, I’m a bit worried about giving these users free reign over who they get my server to POSTs requests too. Assuming I sanitize the URL input and any parameters, and throttle the number of requests it can send out, is there any potential malicious use cases stemming from a user triggering POSTs from my API?

Anders
  • 64,406
  • 24
  • 178
  • 215
DasBeasto
  • 1,796
  • 2
  • 14
  • 14

2 Answers2

1

I would worry about giving users an arbitrary endpoint configuration.

It might be an idea to validate the domain ahead of time.

Example: goodguy.com signs up, send an email to admin@goodguy.com to perform the domain validation, or have them set up a txt DNS record you can query to validate there ownership of the domain.

All the other measures are a must as well, rate limiting, sanitisation etc but you really should validate the user has the right to be sending automated requests to the domain.

is there any potential malicious use cases stemming from a user triggering POSTs from my API?

A couple of the top of my head:

  • Very slow brute force attack, rate limiting would not catch this
  • Multiple account sign up, DOS attack, i.e 1000 fake users sign up and all fire a complex post request somewhere
  • Using your service as a mask for malicious requests, i.e I send a bunch of malicious payloads from a server I control while simultaneously spamming the same target from your server, this puts your server IP in the victims logs along with me
TrickyDupes
  • 2,809
  • 1
  • 13
  • 27
1

Yes, this is dangerous. You are opening yourself up to Server Side Request Forgery (SSRF).

If you give your users the ability to send POST requests to arbitrary URI:s from within your network they can reach things they are not supposed to reach. What happends if you have some sort of sensitive HTTP server running on your network, and someone uses this to send requests to it? Depending on how much control they have over the contents of the request it migth be more or less problematic, but in general it is not a good idea.

So how do you mitigate against it? You could try to filter the URI:s, but this is much harder than it seems, and I am not sure I would rely on it. See this for a discussion about some of the challanges. Another approach is to simply proxy the request through a server outside your own network.

Anders
  • 64,406
  • 24
  • 178
  • 215
  • Ah this is a very good point I hadn't thought of. I'm not sure off the top of my head what on my server would be sensative/vulnerable to this but it's best to avoid it. I suppose one possibility is if they just pointed it back to the API/trigger itself and caused an infinite loop of sorts. – DasBeasto Oct 17 '17 at 12:22