Apigee API proxy - block all requests that include file upload

 

Hi,

We are using Apigee X and we require our API proxies to block all requests that include file uploads.

Currently, as a temporary solution, we have implemented a JavaScript code to parse the request header's content-type and payload content. We look for a boundary with the key "filename" to identify requests with file uploads. If such a boundary is found, we block the request.

However, we have concerns regarding the stability of the parsing process to handle all possible requests. Are there any experiences related to this issue that anyone can share with us?

Thank you.

Solved Solved
1 5 318
1 ACCEPTED SOLUTION

I suppose if you wanted to do that, you would need to parse the multi-part form request, and examine the content-type of each of the individual parts. And then reject if any of them are non-text format.  

The problem is, you cannot do this kind of check in JavaScript, because as we know, the JS callout in Apigee tries to coerce the message payload into a string, and that means the JS callout will not be able to reliably scan for each message part in a multipart form, if some of the parts are binary streams. 

There is an open-source callout for Apigee that parses multipart forms. It doesn't do exactly what you want, but it's close. It can parse multipart forms with binary data.  If you know Java, what you could do is start with that callout, and modify it so that it does not parse the payload, but merely scans it.  And it should reject the payload if the content-type header on any of the parts is non-text. To indicate that the message includes a non-text part, the callout could either set a context variable with true/false, or throw an exception, which means the apiproxy flow would go into "fault" flow.  That would be up to you. 

 

View solution in original post

5 REPLIES 5

I agree that trying to use a JavaScript callout for this parsing is probably not a good idea. A multipart form payload is not always a string (obviously), but the JavaScript callout is not good dealing with non-string payloads.

Is there a way to generalize the pattern?  Rather that looking for filename= in the Content-Disposition of a form payload, can you just reject any payload with Content-type `multipart/form-data` ?  APIs generally don't use multipart/form-data anyway.  If you can reject all multipart forms, then it's a simple Condition in your preflow:

  <Step>
    <Name>RF-Invalid-Content-Type</Name>
    <Condition>request.header.content-type = "multipart/form-data"</Condition>
  </Step>

 

Hi dchiesa1,

Thank you for your suggestion.

We have considered rejecting any payload with Content-type `multipart/form-data`. However, we cannot rule out the possibilities of APIs using multipart/form-data for text only.

Do we have any way to easily identify if a request includes a binary file?

I suppose if you wanted to do that, you would need to parse the multi-part form request, and examine the content-type of each of the individual parts. And then reject if any of them are non-text format.  

The problem is, you cannot do this kind of check in JavaScript, because as we know, the JS callout in Apigee tries to coerce the message payload into a string, and that means the JS callout will not be able to reliably scan for each message part in a multipart form, if some of the parts are binary streams. 

There is an open-source callout for Apigee that parses multipart forms. It doesn't do exactly what you want, but it's close. It can parse multipart forms with binary data.  If you know Java, what you could do is start with that callout, and modify it so that it does not parse the payload, but merely scans it.  And it should reject the payload if the content-type header on any of the parts is non-text. To indicate that the message includes a non-text part, the callout could either set a context variable with true/false, or throw an exception, which means the apiproxy flow would go into "fault" flow.  That would be up to you. 

 

"Apigee-Java-MultipartForm-V2" does help a lot. However, I see a comment under MultipartFormParserV2 - "There is a limit of 5MB for the size of the uploaded files in the multipart form. If you have an upl..." How can we control the limit of the size of the uploaded files? In our case, the file size could be very large.

I think that comment in the readme is out of date. Based on a quick review I don't see any enforced or practical limit in the size of the part.  Even so, it seems to me that should not matter to you. If you're using that callout as a starting point, you'd probably modify it so that it does not preserve the streams for the individual parts. You just want to know the size. So even if there were a limit, you'd remove it when you modify the callout to do what you want, which is scan the form for size.  

Am I right?