ASM- Null in multi-part parameter value- Clarification

Do you have the download* parameter identified as a file upload type parameter? Is there a learning suggestions for that violation?

I can't find any such parameter:

And this issue is not only with download* parameter, I can see many :

And many more.....

Will this help?

I can't see any image. Do you have learning suggestions for parameters and/or parameter-based violations?

Please find the missing images:

It's pretty clear that the filename is being considered as a parameter name, instead of 'name' and 'filename', which are the actual parameter names.

I wonder if ASM is misidentifying the parameters and values because the parameters aren't separated by an ampersand '&' character (the presence of name-value pairs separated by an ampersand is used to automatically identify form data by ASM)?

You could try adding 'name' and 'filename' as parameters in your policy, then allow the null (or space) character as an acceptable metacharacter in the parameter value.

Are you familiar enough with this application that you can identify the real parameter names and file type extensions? That would help a lot in resolving the parameter-based violations (your illustration indicates more violations, not all of which are related to parameters.) It can be tedious to add the parameters one by one. If you change the learning scheme of your policy to "Always" you will soon see a list of parameters detected in traffic. This can help isolate problems related to parameters (you have 370 suggestions related to illegal parameter length in your example) from file types that might share the same name. Another option is to modify the attributes of the wildcard parameter (indicated by an asterisk: *) to allow a greater byte length than is currently specified--but not so permissive that you create buffer overflow or other DoS scenarios.

To clarify--change the learning scheme for parameters to Always...until your policy has learned them all.

I see this one pretty regularly. Unfortunately I haven't found a way to cleanly handle it on ASM and technically it's a problem with the application, so I don't expect a solution from F5.

In multipart/form-data POST requests, the value of the "name" directive of the Content-Disposition header is the parameter name. If the web application needs the actual file name, there's the "filename" directive for that (see for example https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition )

However, as I mentioned, I've come accross several instances where the file name was also used for the "name" directive. ASM is parsing this correctly, resulting in completely unpredictable parameter names, because they now actually depend on what the end user uploaded.

You can try talking to the developers of the web application and get them to change the form. Or you can implement a very broad wildcard parameter (e.g. a "*" on the path of the form with parameter type file upload) which of course would also cover all kinds of other parameters and reduce the protection level. Or if it's just the "null in multipart" violation, disable that one globally.

If anyone else is aware of an easier or more secure solution, I would also like to hear it.