Forum Discussion

Albert_252822's avatar
Albert_252822
Icon for Nimbostratus rankNimbostratus
Apr 20, 2016

Adding parameters to a vulnerability

Hi all,

 

What do you think is the best method to add different parameters to a known vulnerability.

 

The scenario is that my vulnerability scanner detects an SQL Injection on the paramter "user" (http://site.com/login.php?user=joe) and I import that result scan to the ASM. On the other hand, I know that the parameter "id" also is vulnerable to SQLi (http://site.com/login.php?id=2) but it wasn't detected by the vulnerability scanner. How could I add the parameter "id" to be protected against SQLi in the same policy?

 

Thanks in advance.

 

4 Replies

  • Hi mortoj, Thanks a lot, that's right what I was looking for! I have one more question about that, what would be the difference if I choosed "Integer" in the "Data Type" tab instead of modifying the "Attacks Signature" tab?. The parameter "id" would be protected against any Attack Signature? Because selecting that Data Type, the "Attack Signatures" tab isn't showed...
  • That's a good question. I haven't configured a parameter using Data type but I took a look. It appears that when Data type - Integer is chosen, the only value(s) that can be entered for this type of parameter (using data-type -> Intger) are whole numbers. I do not believe Attack Signatures are checked against this type of parameter with the Data Type -> Integer selected. My best guess is that there are no attack signature patterns that consist of strictly and only whole numbers. My reference is ASM Configuration Guide 10.2. (Start on page 10 - 14 Configuring parameter characteristics for user-input parameters.....Integer is on page 10 - 18) https://support.f5.com/content/kb/en-us/products/big-ip_asm/manuals/product/config_guide_asm_10_2_0/_jcr_content/pdfAttach/download/file.res/asm_config_guide_10_2.pdf ----Hope this helps----
  • Hi mortoj, you are right. Attack signatures are not checked when the parameter type is defined because parameter values which don't match with the defined type aren't even evaluated, the request is rejected before that. I've tested it and it works in this way. The big question is what type of configuration is better to apply when you know your parameter has to be an integer value and also you know it's vulnerable to a specific vulnerability. My guess is that is better to define the "Data Type" so this parameter will be "protected" against more vulnerabilities...
  • One way would be: First verify you have the SQLi name in the Attack Signature Set you have configured for your security policy. If it's in your Signature Set then Application Security -> Parameters -> Parameter List -> Create (Create Parameter named "id") After entering the parameter criteria, there are three 'tabs' "Data Type" "Value Meta Characters" "Attack Signatures" Go into the "Attack Signatures" tab. You should see a box to the right that says "Global Security Policy Settings" with a list of Attack Signatures from your Signature Set. Below that box is a search box. Type in a portion of your SQLi name. If you find it, move it over to the left using the << Set the state to "Disable" - This will manually disable the chosen Attack Signature for the specific parameter.

     

    This is one way to manually do what you're asking.