Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Clear all filters
Answers

F5 is not blocking Cross Site Script attack

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 ?

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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?

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Please review sol 5903 https://support.f5.com/kb/en-us/solutions/public/5000/900/sol5903.html

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Dear All,

I had the same problem like question above. My websites still enable to be attack using XSS, especially using alert() parameter.

For information:

-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

Shaggy

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Mr Shaggy,

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.

Also:

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, Sam

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Dear Scott,

  1. Attack signatures assigned to security policy are set to Block --> All attack signature has been set to block, also for alert() Image Text

  2. 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?

  3. 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

Dear Sam,

  1. 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. --> I had enforce all staging results
  2. Make sure that XSS Signature set is assigned to the policy and is in Blocking mode --> alert() signature has been block, like a previous picture
  3. Navigate to a URL which should be blocked, but not blocking: e.g. /myurl/somefile.php?name=alert('xss') --> Well Sam, this also a weird thing on my problem, because the request URL was not logged on the Event Log. I had try to search the request URL by filtering output on event log, on URL request form filter, using "alert" word, but I can't found this request URL on Event Log list. For your information event log profile has been set to log "All Request". The request URL that was used to do XSS attack testing is seem like this:

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...

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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?

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Dear Sam,

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.

Thanks..

0