Antivirus blocking site

[RBarnes]

This problem just started happening about a month ago. For an
unknown reason, “some”, not all of our users are having issues with our website,
the application just hangs up for the most part,  for 10 to 15, so they say, and then the app
starts working.  The only common thing we’ve
found among them to resolve this issue is to disable their antivirus, or add an
exception to our URL. After doing that, all seems to work as expected.

We are using the latest version of controls 2014.1.225.40
 
We have disabled the antivirus on the clients with AVG,Trends and Kaspersky.  It also doesn’t
seem to be specific to a given browser, IE, Chrome, FireFox, etc.

We have not had this happen locally, just with remote customers.

Any help in trying to chase this down would be greatly appreciated.

Roger

[Marin Bratanov]

Hi Roger,

Some time ago we had an antivirus program cause false positives with one of our scripts. Perhaps the case is similar again. Thus, it is very likely that the next definitions update from the AV vendor will fix the issue.

Another thing you can look into is whether some add-on or plugin in the browsers is causing this. For example, plugins like GreaseMonkey can add scripts to any page opened in the browser, which may be causing the AV to "wonder" what to do with it.

If there are any additional details about the problem, this could help in tracking it down - e.g., is there an error message, does the AV log show blocked or potential threats?

You can also try toggling the CDN - if it is being used, try disabling it so the resources for the page come from the same server, and vice versa. I realise this is a big change to ask for on a production site, but you can test it out on a small page first, if possible.


Regards,
Marin Bratanov
Telerik

[RBarnes]

As mentioned in my original post, we can't duplicate this in-house and it's becoming more and more of an issue, which is very, very difficult to correct or even determine the issue when we can't duplicate it.  We have however gotten access to some customers box, and disabled AVG, site works fine.  Checked for updates of AVG, non found, all was up to date, re-enabled AVG, site was no longer accessible.  We have not checked for Plugins in their browser, but this doesn't seem to be browser specific, same user, same box has the same exact issue with three different browsers, so unless they have the same plugins in all three browsers, that's kind of a long shot, I think, I could be wrong.

As far as CDN, we are not using CDN.

[Marin Bratanov]

Hello Roger,

I understand your frustration with cases that you cannot reproduce or test. They are, indeed, very difficult to resolve when you cannot reproduce them.

On each point from your reply:

- AV software may take some time before new definitions are shipped. If the issue has started manifesting recently it is likely that they will take at least a week. I would advise contacting the respective vendors for assistance, more information and probably an update that you can advise your users for.

- since all browsers on the machine have the same behavior it is, indeed, unlikely that a plugin is causing the problem. It may be, however, a firewall, not the antivirus core itself, so you can look into that too. Perhaps adding the site to whitelisted domains can help. Also, if the site is running under HTTPS it is possible that the AV takes time in validating the certificate and while doing so it may intentionally be blocking the browser.

- CDN - what I was suggesting was to, in this case, enable it on a rather small/unimportant page and try to access that page, just to see if it makes a difference. Perhaps the webresource requests for all the scripts and skins are causing the slowdown for some reason (e.g., they are compressed, so you can look into that setting on the IIS) or the AV has general issues with webresources.

At this point I believe that the best course of action would be to contact the AV vendor(s) for assistance, because we have not had such reports about our public facing sites, so if the issue were related to them, we would have received word of it.

Regards,
Marin Bratanov
Telerik

[RBarnes]

I was able to reproduce the slow loading pages last night with a remote wireless connection, it was taking about 8 minutes to initially load the app.  After the initial load consecutive connections where fine.  So I cleared my browser cache, re-tested, 8 minutes again. The same results where experienced with IE and Chrome.  I enabled CDN, cleared browser cache, and the load time was nearly instant.  Cleared Browser cache re-tested 15 more times, each test was fine, no load time issues.  I then turned CDN off, re-tested, back to 8 minute initial load times.  So I turned CDN back on, and left it on.  So far no reported issues from any users.  I also have a test version of the app setup on the same server, so I turned off EnableScriptCombine, and the load times on this test version where fine, prior to that, they were also 8 minute initial load times.

Most of the users where reporting 8-10 minute initial load times, which are inline with my findings.

Rather than saying it's fixed, I'd really like to know why, and get a real fix.  I shouldn't be seeing that big of a difference with load times with Combining scripts.  I also tested the production site with turning off CombineScripts and it seemed to be fine with it off as well.  But I left CDN enabled, which doesn't combine scripts and also removes some of our traffic from our webserver.

What's the next step?

Thank your for your efforts and suggestions.

Roger

[Marin Bratanov]

Hello Roger,

With this new information, it would seem that the AV is having issues with parsing such large webresource files. The script combination feature causes all scripts on the page to be appended into a single webresource request, and so it may become rather large (even a couple of MB).

Thus, to summarize the differences in both cases:

• with script combination you get only one, very large request that contains megabytes of obfuscated (and possibly compressed) scripts. The AV program, most likely, takes time to evaluate its content before letting the browser parse and execute them.
• without combination each script file comes with a separate request so the AV software is most likely faster with evaluating each of them.
• when the browser cache is not cleared, this request is cached on the hard disk of the client machine, so it is likely that the AV has already scanned it and does not evaluate it again, which is why it works after the first time it loads.
• the CDN also causes scripts to arrive at smaller chunks and allows for even better caching of their contents which is a combination between the two previous points.

This leads me to believe that the issues lies with the way the webresource requests are being scanned when they come from the server and not from the browser cache. Thus, I would still advise that you contact the respective vendors for assistance with this case. Perhaps heuristic search or some other setting in the programs causes them to add additional checks which cause the slowdown.

If you can monitor the actual network traffic, it is likely to confirm this - if the requests are fully returned from the Internet quickly, but the slowdown is afterwards, then the issue is definitely with the way the AV checks them. Since the browser is not responsive during this time you may need to use network sniffing tools like WireShark or other proxies like Fiddler to see this.

You can perform yet another test - save the request for the combined scripts and put it in a simple JS file, then add this file to a page. It is likely to cause the same slowdown. Of course, this cannot be guaranteed, because there will be no calls to the scripts inside, while in a real page the MS AJAX library would try to initialize first, then objects based on it (like our controls) will be instantiated, so there is quite a lot of logic being executed.

Regards,

Marin Bratanov
Telerik