Cirrostratus
CirrostratusSetting the parameter type "File Upload" limits the range of checks that are performed on the parameter value. The primary usage is obviously file uploads, because for example a PDF file or Excel sheet is pretty much a binary blob with some text sprinkled in between and applying meta character checks to see if it includes a quote, a dollar sign, a null byte or some nonprintable character somewhere doesn't make a lot of sense.
In version 14 (maybe also 13?) you can select to still check attack signatures on File Upload parameters - which for real file uploads may not be very useful, but for your scenario should be a good idea. (note: never tested if this actually works)
Setting the checksum parameter to file upload will open you up to some risk of attacks specifically on that parameter, because checks on the parameter will be limited.
If you find this more concerning than globally allowing null bytes, then disabling the "null in request" violation would be the way to go.
There may be another option that is not mentioned in the KB: An iRule to selectively unblock the request if this violation occurs specifically on that parameter. But that would require some engineering and I don't know if it even actually works.
CirrostratusI see that for "File Upload" Option there is no Attack Signature Option I can select. Images attached.
CirrostratusThis is a feature of version 14 and later. See https://support.f5.com/csp/article/K79544554
"Note: Prior to BIG-IP ASM 14.0.0, you can configure attack signatures for parameters of Alpha-Numeric data type. Starting in BIG-IP ASM 14.0.0, you can configure attack signatures for parameters of File Upload data type, in addition to parameters of Alpha-Numeric data type."
CirrostratusOnly for Alpha-Numeric it shows Attack Signature tab. Image attached
CirrostratusCan you explain little bit more on this
"If you find this more concerning than globally allowing null bytes, then disabling the "null in request" violation would be the way to go."
CirrostratusI can't give you a clear right or wrong answer on this.
When you disable the "null in request" violation, it will be disabled for the entire policy. If your application is vulnerable to null byte attacks anywhere, then you lost a relevant protection for that. Likely not the only protection, as one of the other violations may be able to catch it. So is this an acceptable risk? Probably yes, but I can't make that call without knowing your application and your security requirements or general policy setup.
If you set the parameter to type File Upload, this will only affect this specific parameter and not the rest of your policy. But if your application happens to be vulnerable to any kind of injection attack exactly on that parameter, then ASM would likely not be able to prevent it anymore (unless you run v14 and have attack signatures enabled on the parameter). Again, if this is likely, or if the risk is acceptable, is something you alone can decide.
CirrostratusThanks as of now for your reply. I am still trying to dig into it.
I am trying to understand refer to this K7931 and when we see "Null in Request" in our Event Log does this fall into below 2 criteria ?
Configuring the parameter with the NULL to use User-input value as the Parameter Value Type
Configuring the parameter with the NULL to use Ignore value as the Parameter Value Type