This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Failing PCI Scans because of outdated jQuery in User Portal - Is there a fix?

We are failing our PCI compliance scans on every XG firewall we have that has the user portal enabled.  Our PCI compliance scanning company is telling us this:

 

Description:  "jQuery is vulnerable to Cross-site Scripting (XSS) attacks when a cross-domain Asynchronous JavaScript and Extensible Markup Language (AJAX) Request is performed without the dataType option, causing text/javascript responses to be executed.  This finding indicates that either the root domain url, sub-domain url, or an imported/sourced version of jQuery is below jQuery version 3.0. All three scenarios allow an attacker to execute cross site scripting attacks on the root domain."

Evidence: jQuery appears to be '2.1.3' and needs to be at '3.0.0' or higher

 

This is ONLY happening on the port used by the User Portal.  To verify this we changed the port to another number, had a host rescanned, and the vulnerability was found on that new port.

 

Is there anything I can do to get this fixed or do I have to wait for Sophos to update the jQuery version they are using?  Is there a bug report place I can put this if that's the case or who do I contact?

 



This thread was automatically locked due to age.
  •  of course spinning up a new VM is going to work, because it's not dragging around legacy configuration from successive upgrades since  installed his XG with whatever version it came with.

    There seems to be a common misconception that client systems like  are broken. They aren't. Their state is merely different from a clean install due to all those state changes made during each version upgrade.

    What's really needed is a full configuration export that allows for full configuration import to be performed from a clean install, which would help prevent artefacts from affecting configuration, make fault repeatability achievable (ideally) and enable fault analysis to be conducted on a non-production system.

    Until that's in place all these XGs are essentially sacred cow pets, rather than the cattle they should be. 

  • The real issue I see is on each firmware upgrade its going back to a non-secure configuration which to me means that's the default config within the firmware.  If it defaulted to what posted that would be great but it doesn't and has never done so.  It also should be noted that when I contacted support, again almost two years ago, they were aware of the issue and gave me the instructions on changing it manually.  So it's not like this isn't a known issue.

  • I believe what you are saying but how come that I don't see this? So it can't be a default config as it should be the same here then.

    I'd say there is more to this than only a default config. Maybe different configs in the firmware based upon some prerequisites?

  • We are talking about the WAF? 

    AllanD can you show us, which TLS Version you select in GUI?

  • TLS v1.2:

     

     

    I believe what you are saying but how come that I don't see this? So it can't be a default config as it should be the same here then.

    I'd say there is more to this than only a default config. Maybe different configs in the firmware based upon some prerequisites?

     

    I don't know.  But I can tell you, with two of my firewalls starting around 16.01 and the third starting around 17.00, and all the firmware upgrades in between, I've had to manually make this change around 30 times.  The httpd file gets reset every time to that old insecure version.

     

    FYI - We are way off topic from the original jQuery issue but this is definitely another issue that needs to be fixed.  I wonder how many other people have the same problem but just don't know since they arn't subject to PCI compliance scans and are assuming their firewall "just works".

  • FYI:

    I just did the Qualsys SSL check with our XG210 and 17.5 GA:

     

    TLS seems to be ok

     

    But some weak cipher suites are enabled

     

    Overall rating is T but would be A if trust issues are ignored.

    I did not change anything in config files etc.

     

    Regards, Jelle

     

    I saw the same results when I tested my XG135.  Haven't tested my XG210 yet, but I may later.

  • AllanD, Michael Dunn was doing some digging, and pointed out to me that there's two different httpd.conf files on the shell:

    /_conf/httpd/conf/httpd.conf

    and 

    /usr/apache/conf/httpd.conf

    I was referencing the first one, but I suspect you're referencing the second one, as I see similar lines you're mentioning in the second file. 

    The first one is used by webadmin, the user portal, and other system services, and I've tested numerous systems, and can confirm the same scan results Bill Roland reports, across my estate of firewalls. The second one is related to WAF, but I'm not certain how exactly it is used - if it's still used at all. For example, it always says it will allow TLS 1.0 & 1.1, but I can change that setting in webadmin, under "Webserver Protection > General", then test against https://www.ssllabs.com/ssltest/ and clearly see that TLS 1.0 and 1.1 are allowed or blocked, on any WAF listening ports, according to the webadmin setting. So while I can verify what you're seeing on the shell, I can't confirm the external behavior results you're reporting.

    Ignoring the .conf file contents for the moment, I want to make sure I'm really looking at the same thing that is actually failing for you. Can you give a bit more info on the audit failures you're getting? what ports are involved, etc..?

  • AlanT said:

    I want to make sure I'm really looking at the same thing that is actually failing for you. Can you give a bit more info on the audit failures you're getting? what ports are involved, etc..?

    I think everything is documented pretty well already in this post:  https://community.sophos.com/products/xg-firewall/f/firewall-and-policies/109122/failing-pci-scans-because-of-outdated-jquery-in-user-portal---is-there-a-fix/391199#391199

    When the default /usr/apache/conf/httpd.conf is used, which again gets reset with each firmware update, I fail on TLS 1.0 being supported along with 3DES issues.  When the file is edited to remove TLS1, 1.1, and 3DES I no longer fail on those items.  The port these vulnerabilities are found on are 443 which are all pointing to internal web servers so I believe you are correct when you say this is a issue with WAF.  My user portal is on 4443, web admin on 4444 (internal only).  As for:

    AlanT said:

    I'm not certain how exactly it is used - if it's still used at all.

    Based on the evidence in the above post it definitely is being used.  Otherwise making a change to it wouldn't be changing what is detected. 

     

    As a side note I don't know what changing the TLS version under Protection -> Web Server -> General Settings does.  It doesn't seem to have any effect on either config file.  I would think it should affect both but as a test I changed mine to TLS v1.0 and apply. I waited a couple minutes then checked both files under SSLProtocol.  The /usr/apache/conf/httpd.conf file still defaulted to "SSLProtocol all -SSLv2 -SSLv3" and the /_conf/httpd/conf/httpd.conf file still defaulted to "SSLProtocol -all +TLSv1.2".  So not sure what that actually does if anything.

  • I second all of  comments.  I'm in the exact same boat to pass PCI.  My XG was pre-loaded with ver 17 when I received it.  After every firmware update I have to perform the same changes to the httpd files. 

     

    PCI compliance did eventually accept my dispute regarding the Jquery issue. 

  • Ok, I think we're getting somewhere. At least we've pinned down the problem area, and we should be able to get to the bottom of this a little easier now. The file I was originally referencing is used for most everything other than WAF. We can ignore that in your case. The file you are changing shouldn't matter, but apparently does. 

    Can you (AllanD and JonathanP) post the sanitized contents of /cfs/waf/reverseproxy.conf? 

    Also, are you able to run an nmap scan (nmap -sV --script ssl-enum-ciphers -p 443 [ip or hostname]) and share the output of that? 

    Lastly, can you verify that 'cat /usr/apache/conf/httpd.conf |grep Include' returns a line 'Include /cfs/waf/reverseproxy.conf'?

     

    I've dug into this enough to know that changing the cipher settings in /usr/apache/conf/httpd.conf shouldn't matter. WAF should always use the cipher settings from reverseproxy.conf, and we need to understand why it seems different in your case. Hopefully the above info will pin it down a little closer.