on 30-Dec-2015 10:16
Let’s say we have a web application with a form field that permits the upload of arbitrary files. It would appear to the user similar to the below:
Aside from photos, the application may permit users to upload Word documents, Excel spreadsheets, PDF’s, and so forth.
This can cause many false positives when the web application is protected by ASM, because the uploaded files may:
It is therefore necessary to inform ASM that a particular parameter on a form field is one that contains a file upload so that checking for attack signatures and metacharacters can be disabled.
Simply, because we do not want to introduce unnecessary exposure into the security policy. Just because a particular signature causes a false positive on the file upload transaction does not mean it should do elsewhere on the web application. At the time of writing, ASM permits attack signatures to be selectively disabled on parameters, but not URLs.
Use a HTTP inspection tool such as Fiddler, Burp or Developer Tools to determine the name of the upload parameter and URL. In this case, we are uploading a JPG file named DSCF8205.JPG; the parameter used to transfer the file is called ‘filename1’. The URL is /foo.cfm.
NOTE: This can also be obtained from the ASM request log; however these do sometimes get truncated making it impossible to determine the parameter name if it occurs more than 5KB into the request.
Assuming the upload is specific to a given URL, create that URL in the ASM policy.
Next, create a parameter with the name we discovered earlier, and ensure it is set to type ‘File Upload’.
The above procedure should work for most cases, and arbitrary file uploads (except executables) should be allowed. However, there are some cases where additional configuration is required.
Attack signatures have a defined scope, as seen below:
This information can be found in ASM under “Attack Signatures List”. As an example, search for ‘Path Traversal’ attack types and expand signature id’s 200007006 and 200007000:
A signature with a ‘Request’ scope does not pay any attention to parameter extraction – it just performs a bitwise comparison of the signature to the entire request as a big flat hex blob. So to prevent this signature from being triggered, we can (a) disable it, (b) use an iRule to disable it on these specific requests.
Before we can use iRules on an ASM policy, we need to switch on the ‘Trigger ASM iRule Events’ setting on the main policy configuration page. Further information can be found at: https://techdocs.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-11-5-0/27.h....
The below is an iRule that will prevent a request meeting the following characteristics from raising an ASM violation:
when ASM_REQUEST_VIOLATION { if {([HTTP::method] equals "POST") and ([string tolower [HTTP::path]] ends_with "/foo.cfm") and ([string tolower [HTTP::header "Content-Type"]] contains "multipart/form-data") } { if {([lindex [ASM::violation_data] 0] contains "VIOLATION_ATTACK_SIGNATURE_DETECTED") and ([ASM::violation details] contains "sig_data.sig_id 200007000") } { ASM::unblock } } }
What if you’re getting a lot of false positives and just want to disable attack signatures with Request scope?
when ASM_REQUEST_VIOLATION { if {([HTTP::method] equals "POST") and ([string tolower [HTTP::path]] ends_with "/foo.cfm") and ([string tolower [HTTP::header "Content-Type"]] contains "multipart/form-data") } { if {([lindex [ASM::violation_data] 0] contains "VIOLATION_ATTACK_SIGNATURE_DETECTED") and ([ASM::violation details] contains "context request") } { ASM::unblock } } }
False positives might also be generated by large file uploads exceeding the system-defined maximum size. This value is 10MB by default and can be configured. See https://support.f5.com/csp/article/K7935 for more information.
However, this is a system-wide variable, and it may not be desirable to change this globally, nor may it be desirable to disable the violation. Again, we can use an iRule to disable this violation on the file upload:
when ASM_REQUEST_VIOLATION { if {([HTTP::method] equals "POST") and ([string tolower [HTTP::path]] ends_with "/foo.cfm") and ([string tolower [HTTP::header "Content-Type"]] contains "multipart/form-data") } { if {([lindex [ASM::violation_data] 0] contains "VIOLATION_REQUEST_TOO_LONG") } { ASM::unblock } } }
I've been using your iRule a bit, but we realized there is one problem with it. Imagine, there is a request which violates like 15 different violations(so it is a real attack). And now with your iRule, if one of the violations would be attack signature in context request, it would be unblocked. I've found a way how to improve the iRule. It reads the violation details, and if it finds other violation than VIOL_ATTACK_SIGNATURE in other context than request, it will keep blocking the request.
when ASM_REQUEST_VIOLATION {
log local0. "ASM Violation: [HTTP::method], [string tolower [HTTP::path]], [ASM::violation names] ; [ASM::violation details] "
if {([HTTP::method] equals "POST") and ([class match [string tolower [HTTP::path]] equals upload-paths]) and ([string tolower [HTTP::header "Content-Type"]] contains "multipart/form-data") } {
set details [ASM::violation details]
set i 0
set only_attack_context_request 1
foreach {viol} $details {
if { [lindex ${viol} 0] equals "viol_name" } {
log local0. "ASM 01 $viol; [lindex ${details} [expr {$i+1}]]"
if { ($viol ne "viol_name VIOL_ATTACK_SIGNATURE" ) or ([lindex ${details} [expr {$i+1}]] ne "context request") } {
set only_attack_context_request 0
}
}
set i [expr {$i+1}]
}
if {$only_attack_context_request == 1 } {
ASM::unblock
log local0. "ASM unblocked [HTTP::method], [string tolower [HTTP::path]], [ASM::violation details] "
}
}
}
, You can set up a third-party integrated anti-virus service on the ASM and have these files be checked for virus/malware by having the ASM send it to an external ICAP server:
K70941653: Configuring BIG-IP ASM antivirus protection