Hi, This is a general question for F5 11.2.0 version software around where we go about enabling the Cross Site scripting. Is this being done via the CSRF Protection mechanism. Are we able to enable it on a transparent basis and run for a while to detect attack and then enable blocking ?
Hello Moinul, cross-site scripting (XSS) protection is done by the attack signatures in ASM which detect known character sequences and patterns in the XSS class of attacks. Cross site request forgery (CSRF) is a separate mechanism that relies on an ASM token. If you are testing your system, and XSS attacks are not being blocked, there are a few reasons. One is that the security policy is in transparent mode. In transparent mode, all requests pass, but you can check the "Learn" and "Alarm" flags on the blocking settings screen to ensure you are alerted on specific violations. Another reason is that your attack signatures, or one specific signature, are in staging. Staging gives you time to determine if a triggered attack signature is a false positive before enforcing it (removing it from staging). Another reason is that if an attack signature was triggered on a parameter, and the parameter is in staging, the request still will not be blocked. Make any sense?
Please review sol 5903
The version you are running on is almost out of its last support milestone, EOTS, End of Technical Support. Also ASM is still using http classes and is vastly improved in the newer versions.
Cross site scripting protection is handled with the attack signatures. You can place the policy into blocking mode and then place the attack signatures into alert only mode, or place the entire policy into transparent.
You will have to make sure that whatever URI, filename, and parameters are learned and enforced if you are tightening the policy.
I had the same problem like question above. My websites still enable to be attack using XSS, especially using alert() parameter.
-My security policy has been blocking
-My attack signature staging has been disabled
-My alert() signature also has been enable
-I got some propose parameter policy from Manual Traffic Learning that associate with XSS attack. I already accept it, an parameter has been add to the Security > App Security > Parameter, and no staging for this parameter.
-OS version 11.3.0
-Attack signature v10.2.0, last update 18-01-2011
I know that my attack signature has been very-very old and need to be update, but XSS is a common attack so i think this signature should can be able to block the attack. Anybody can help me about this problem? Does it because the old attack signature? And is there any concern that I had to know if I want to update my signature, in case my signature has been very long time not updated?
Thanks before for the help
Some additional things to check
1. Attack signatures assigned to security policy are set to Block
2. Check that the parameter you accepted is not the policy is NOT set to "ignore value"
3. Check that there are no overridden (disabled) XSS signatures for the parameter
From what you are describing it looks like you have accepted "alert()" as a parameter in your policy? this means you have whitelisted it - this could be an issue you are experiencing... Please check if it is there by mistake.
A) Please check your staging from the Enforcement-Readiness Summary (used to be called Staging-Tighenting SUmmary in older versions) - Make sure your URLS/parameters are enforced.
B) Make sure that XSS Signatre set is assigned to the policy and is in Blocking mode
C) Navigate to a URL which should be blocked, but not blocking: e.g. /myurl/somefile.php?name=alert('xss')
Find this URL in your event log and inspect it for any raised violations - this should give a clue why it is not blocking.
Hope this helps,
Attack signatures assigned to security policy are set to Block --> All attack signature has been set to block, also for alert()
Check that the parameter you accepted is not the policy is NOT set to "ignore value" --> All the parameter were I accept from Manual Traffic Learning. I only make sure that this parameter are not in staging mode. On mannual traffic learning, it say that all this parameter were depend on XSS attack signature CDATA. And I'm a little bit confuse with this Parameter list concept on ASM, if I make parameter like picture above, is it mean that all those parameter will be blocked or will be whitelisted and allowed on traffic? I think it will be blocked, won't it?
Check that there are no overridden (disabled) XSS signatures for the parameter --> Can you please give me an example what configuration that might be overriden? I had check actually, but I will recheck like your suggestion if in case I missed it
http://example.com/example.aspx?%0064ee0'>(script)alert("test")(%2fscript)2df6e=1 ---> I change the <> character before and after script word with ().
I had face a problem like this before where my security policy can't block XSS attack using alert() parameter. I solve that by using Data Guard and using Custom Patterns, and write alert() on Custom Patterns form. I found this solution from https://devcentral.f5.com/questions/asm-xss-protection. But I dont think that this a really good solution where XSS attack parameter is so many and not only alert()
Thanks before for your help...
If as you say the request URL in question was not logged on the Event Log (with Log All Requests) then it is NOT GOING THROUGH ASM and is not protected by an ASM policy!
Do you have any iRules/LTM polcies/HTTP Class profile which might route this URL away from ASM?
I had two BIG-IP box, one LTM box, and one ASM box. Data flow of my application was come from LTM box to ASM box, ASM do inspection, and send back to LTM box.
I had no iRules/LTM policies/HTTP Class that redirect data traffic and make it not going through ASM. The only iRules I used on LTM box is for redirecting traffic from http to https.
If there is any iRules/LTM policies/HTTP Class that redirect traffic, so all url request should be not logged on ASM, and ASM can't do manual traffic learning. But on my case, ASM logged all traffic except this XSS alert() request.