parameter
18 TopicsASM blocked request contains & (ampersand) symbol in parameter value
ASM thinks that in a parameter value the "&" and space is the beginning of a new parameter and thus blocks on AMF body context for a command execution signature and does not check the built parameter. Should it be recommended to the developers that they encode their "&" throughout their request to not confuse the ASM or just have them not use that charater in their input fields? example:&BuiltParameter=Chocolate&0x20MSG0x20Solved583Views0likes2CommentsASM/WAF policy - Parameter value type was determined to be "XML value" but really it is "HTML"
Hi, hoping someone can help with this issue. F5 WAF suggested that the parameter "text" should be "XML value". I agreed and and I'm using the default XML content profile. However the actual value looks like HTML code to me, which is not an option anywhere AFAIK. Mostly there are no issues, except for some special situations likethis particular request that contains "(" and ")" characters in the value. As a result I'm getting an error: XML Buffer ( Description Malformed document Illegal data between tags Context Parameter Location Form Data Parameter Level Global Parameter Name text Parameter Value *************** The request looks very similar to the one below: POST /aaa/bbb HTTP/1.1 Host: aaa.bbb.org Connection: keep-alive Content-Length: 00000 sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="101", "Google Chrome";v="101" Accept: */* Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest sec-ch-ua-mobile: ?0 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.54 Safari/537.36 sec-ch-ua-platform: "Windows" Origin: https://aaa.bbb.org Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: https://aaa.bbb.org Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9 Cookie: ************ X-Forwarded-For: 1.1.1.1 text=<b>aaa+aa.+11111+aa+aaaaaaa+111+1111+</b>(<a+href="https://www.ccc.org/ddd/111/ppp.pdf">aaaa11.222</a>+-+oooooooooo)+(eeeeeeeee+jjjjjjjjjj+1,+2222) &input_format=full_html&token=xxxxxxxxxxxx Is there any way to tweak the XML content profile to make this work, or should I switch the parameter to user-input/alphanumericand add the HTML meta characters as allowed?1.3KViews0likes1CommentiRule for ignoring request if it includes a specific parameter value
We currently have an iRule that is examining cookies to block or allow the request. We would also like to add a section that looks for a parameter's value. The parameter needs to equal "true" for it to pass. Below is a sample url and what we currently have as the iRule but it doesn't seem to be working: https://www.site.com/path/location?xyz=abc&value=true&zzz=aaa if { [HTTP::uri] starts_with "/path/" } { if { ![HTTP::query] contains "value=true" } { blocking action } else { ignoring action } } } Is there something we are missing or need to change for this to work? Thank you!406Views0likes1Commentirule to match on 2nd parameter name and value
I want to capture on the 2nd parameter name and value. If memid=x then send to this node. However, the irule is only matching the tokenid portion. But I can only get it to match on tokenId (the first parameter). Here is the test URI: http://test.domain.org/HBNetRD/App/Signon/SSOInit?tokenId=r43DRErQu0CpO_smc2kEfSzGEn6w&memid=1 ` Could I be hitting this bug. I am on 12.1.2: [https://devcentral.f5.com/questions/uri-query-question-20954](https://devcentral.f5.com/questions/uri-query-question-20954) `when HTTP_REQUEST { switch [string tolower [HTTP::query] { "memid=1" { node 1.1.1.1] } "memid=2" { node 2.2.2.2] } "memid=3" { node 3.3.3.3] } "memid=4" { node 4.4.4.4] } "memid=5" { node 5.5.5.5] } default { pool p80_pool } } log local0. "Sending HTTP path [HTTP::query] to node [LB::server addr]" } curl -I http://10.1.10.20/?token=123&memid=5 Jun 28 10:40:28 F51_v12 info tmm1[12424]: Rule /Common/MEMBER_TO_OLB : Sending HTTP query /?token=123 to node /Common/p80_pool 0 It will match on this: ?token=123memid=1 not this: ?token=123&memid=1265Views0likes1CommentASM - regex in Parameter Name
Hi, I'm looking for a possibility to implement a dynamic parameter, that contains a string that may vary as parameter name itself. It's something like this: <soap:Envelope xmlns...> <abcd:Envelope xmlns...> <fghjkl:Envelope xmlns...> I thought of creating a Wildcard Parameter like this: <[a-zA-Z0-9]{2,15}:Envelope* so it matches an alphanumeric, 2-15 chars long string. Unfortunately it seems that you can't use any quantifiers in the parameter name (at least according to this thread from 11 years ago: https://devcentral.f5.com/s/question/0D51T00006i7VCi/regex-in-parameter-name ) Does anyone know if there is any solution to this problem by now? Or if there is a possibility to do this in a syntax that is supported? (the 2-15 is not mandatory, could be more or less chars too) Otherwise I'm afraid that I really have to follow the suggestion from this thread and add 14 different parameters, one for each length :( Thanks in advance!924Views0likes3CommentsF5 ASM learning new parameters while being in blocking mode.
Hi, I have my ASM protecting many web applications. The problem is that some of the applications/websites, don´t have that much traffic, but some of the websites have a lot of Forms etc. Since the traffic is not to much, it didn´t learned all of the parameters of the website while it was on transparent mode, and even some of the parameters learned don´t have all the meta characters allowed. Question 1: If i disable the value meta character on the parameter itself, does it still block attacks like XSS, SQLi etc? Question 2: Is there a way to have my policies in block mode, but do not block new parameters that are added by developers as an example, and then accessed by users? Question 3: Do you guys keep the Wildcard * parameter in blocking state or leave it in staging ? Question 4: When policy is in automatic, i detected that if a parameter in the website that should allow alpha-numeric values, if it gets a lot of hits by users that just post numeric values ( lets say username) the policy change the parameter data type to integer itself, and after that if some user as a username that have letters in it, will get blocked. What is the better way to get over this. Manual (extensive work checking all the policies every day) or automatic ( some things stop working after some time so have to correct it mannually), or is there and alternative in the Learning and blocking settings that allow to loosen the policy keeping it secure and manageable?1.1KViews0likes1CommentBlocking a request if the URL meets two parameter requirements?
I have a API request that has two parameters that can easily be tampered. The problem is that there are legitimate requests that will match the numbers if I only have a parameter rule on one of the values and not the other. So I need a way to have the equivalent of a "AND" statement saying if VariableA=x and VariableB=y to block the request. But if VA=x and VB= to not block anything. Is this a possibility in the standard settings for ASM parameters or will this require some type of iRule. Thank you!306Views0likes1CommentASM Attack signatures on URL/parameter
Hi, I am trying to figure out violation logging when both URL and parameter is involved. Tested on 13.1.0.8 Request: Post to URL: /post1 Parameter in form (request body): parameter1 Policy in Transparent Parameters on URL level Encoded XSS string in parameter1 Depending on staging setting results are like that: URL staging: Disabled Parameter staging: Enabled Request reported in Event log: Status: Legal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected And second setting: URL staging: Enabled Parameter staging: Disabled Request reported in Event log: Status: Illegal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected Above suggest that violation detection is only performed on parameters. Still it is a bit misleading that for first staging setup violation is detected in exactly the same way as for second but request is reported as Legal. Now Attack signature settings changed (both URL and parameter with staging disabled) Check attack signatures on this URL: Disabled Check attack signatures on this parameter: Enabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value And second setting: Check attack signatures on this URL: Enabled Check attack signatures on this parameter: Disabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value From previous test it looked like only parameter signatures cause request to be reported as Illegal, but from above it seems that Attack signatures has to be checked on both URL and parameter to trigger Attack signature detected. Results are quite confusing here. I would expect results like that: No matter if staging is disabled both request should be listed as Illegal If only parameter Attack signatures are causing request to be Illegal then disabling Attack signatures on URL should still trigger Attack signatures violation. How Event Log entry for request with: Status: Legal Violation rating: 4 should be interpreted in compare to one where status is Illegal? Piotr606Views0likes1CommentASM Attack signatures on URL/parameter
Hi, I am trying to figure out violation logging when both URL and parameter is involved. Tested on 13.1.0.8 Request: Post to URL: /post1 Parameter in form (request body): parameter1 Policy in Transparent Parameters on URL level Encoded XSS string in parameter1 Depending on staging setting results are like that: URL staging: Disabled Parameter staging: Enabled Request reported in Event log: Status: Legal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected And second setting: URL staging: Enabled Parameter staging: Disabled Request reported in Event log: Status: Illegal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected Above suggest that violation detection is only performed on parameters. Still it is a bit misleading that for first staging setup violation is detected in exactly the same way as for second but request is reported as Legal. Now Attack signature settings changed (both URL and parameter with staging disabled) Check attack signatures on this URL: Disabled Check attack signatures on this parameter: Enabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value And second setting: Check attack signatures on this URL: Enabled Check attack signatures on this parameter: Disabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value From previous test it looked like only parameter signatures cause request to be reported as Illegal, but from above it seems that Attack signatures has to be checked on both URL and parameter to trigger Attack signature detected. Results are quite confusing here. I would expect results like that: No matter if staging is disabled both request should be listed as Illegal If only parameter Attack signatures are causing request to be Illegal then disabling Attack signatures on URL should still trigger Attack signatures violation. How Event Log entry for request with: Status: Legal Violation rating: 4 should be interpreted in compare to one where status is Illegal? Piotr347Views0likes0Commentsdefine exactly number of parameters for a specific URL
Dear All, Environment: BIG-IP 13.1.0.5 For a specific URL I defined a flow based parameter check. All these parameter are mandatory. Totally I have 4 and when I go to Security ›› Application Security : URLs : Flows List ›› Flow Properties I see there are 4 mandatory parameters defined. All these checks are working fine but if I add a fifth parameter testing in my browser such a request is not blocked. I didn't find a way to define that this URL has to have exactly 4 parameters and not more. Is there a way ? Kind regards Hans272Views0likes1Comment