We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now


Need some help/opinions about preventing new HTML viruses

Medium Priority
Last Modified: 2013-12-18
There is some concern in my company about the risk of the new HTML viruses and what we might be able to do to prevent them. Not so much around the known ones, but more around as new ones are identified, or preventing any malicious HTML code. The known ones are covered as the AV vendors release the dats.

I've done some experimenting and can't come up with a workable solution. In some places (it's a global company) there is proxy authentication required with every access to port 80, so the messages come through with image placeholders if there is an IMG SRC tag, and it prompts for authentication. That is tolerable, because people can go to the site for the images if they like, and the message is still very legible. However, that seems to be blocking only those images, not the embedded HTML.

I've also tried setting my person doc to Prefers Notes Rich Text. That seems to be stripping out all the HTML when it does the MIME to CD conversion, but the messages are an awful mess, to the point that a lot of end users wouldn't be able to find what they were looking for in them. I'm not sure that is a good solution.

I'm looking for some suggestions about how to prevent malicious HTML, but also some opinions about the trade-off. I'm thinking the risk is low at this point for several reasons. The first is there doesn't seem to be any more risk than with any other virus, while we're waiting for the AV vendors to release a new dat. The second is that the HTML viruses that have been identified so far use ports that we don't have open anyway, so even if they are run in the preview pane they can't get to their web site to download anything. Also, if there are new ones that use common ports that we have open, such as 80, the user would still have to sign in if all the proxies were set up for additional authentication. (Some authenticate at the OS login).

The remaining issue is malicious HTML code embedded in the message that runs on its own without going to a web site to get a file to do something destructive to the machine. But then most of the PCs in the environment are XP or 2K and are locked down, so for those, what any virus or HTML can do if it runs while an end user is logged in is limited. We do still have a few business units that have 98, but those are in the process of being brought inline with the rest of the domain.

Is there any middle of the road solution that will prevent malicious HTML without garbling the useful HTML messages?

Many thanks in advance.
Watch Question

Bozzie4IT Architect

Don't use Internet Explorer as the default web browser :-)

It's difficult, because you want somehow to be able to tell which messages are 'useful' and which are 'not useful' .... That sounds like a job for an anti-spam engine.

 You could use Notes as the default browser, and de-activate for all users in user preferences all javascript, active x and java.  This also means you won't be able to use that in your applications, so probably not  realistic for you (or use <your browser> and lock down the browser).  

For now, I don't think there is a reason to particulary fear the embedded HTML virusses (the kind that don't connect).  Depend on your antivirus vendor, or try to find a good anti-spam engine that is able to detect these.  Kspam is a free 1 for Notes, but Trend Micro also has a solution ....



If you want to keep nice html formatting features and not to be affected by virus.. go for the anti-virus software which works with domino (like symantec NAV, Trend Mircor, Mcafee)


Technically, that's SAV, not NAV, when it runs on the Domino data.  NAV is the end-user retail OS-level AV from Symantec.

Look, HTML viruses are not really different from any other virus, except for the particulars of the delivery mechanism.  On top of that, they are harder to create -- a regular executable virus relies on getting executed by the user, with the exception of those few that exploit IE holes to get autoexecuted.  Again, the HTML viruses are similar to the latter.  So, the risk is actually slightly smaller than with other viruses.

As I see it, you either rely on your AV vendor, or you don't.  I don't, which is why I encourage multiple vendors running concurrently (e.g., Trend as the edge appliance, Symantec on the DMZ, Sophoros on user mail servers, McAfee on the desktop).  But I'm just a little paranoid.


Thanks to everyone for the comments. We're having a conference call about this soon, and everyone seems to be leaning toward stripping the HTML with MIME to CD conversion, but I keep thinking that's overkill and we're losing more than we're gaining, at least at this point.

Qwaletee, thanks very much. I'm paranoid too but I'm trying not to be too paranoid here and have everybody end up with garbled HTML. We're using Symantec in the DMZ, SAV on some mail servers and GroupShield on others (long story, don't ask), and McAfee on the desktops. Like I said in the initial post, I told them that we're at no more risk than with any other virus while we're waiting for the vendors to release dats. But they're also wanting to know about "other malicious HTML" that isn't actually a virus. Nobody has really clarified what that means, but I think they're talking about spam that takes you to a site or something. Most of our spam is filtered by another system, so not much gets through. Even if it did, and all it was doing was trying to take you to their site, we could get around that by making all the proxies require separate authentication like some do now. So, if that were the case, do we really have any exposure to speak of, or enough to make it worth screwing up the HTML mails that people need to get?

Many thanks again
Unlock this solution with a free trial preview.
(No credit card required)
Get Preview
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a free trial preview!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.