Need some help/opinions about preventing new HTML viruses

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.
Who is Participating?
qwaleteeConnect With a Mentor Commented:
They may be refering to HTML that exploits bugs in IE's security model.  This usually takes one of four forms:

1) cross-site scripting attacks, where the HTML can gain access to a site that you have access to and resides in a different fram or browser window.  Example: a page loads two frames, one visible and one not visible. The visible frame shows your bank's login page.  The invisble frame monitors the banking frame to see if it can find something that looks like your account number.

2) IE sandbox holes.  These do things like trying to access the hard disk and upload your files to a hidden web site.

3) IE/Windows integration holes -- try to get IE to load machine executable code when it shouldn't.

4) tracking bugs of various types that may use either a simple cookie, or a combination of techniques above

All of these are generally not e-Mail issues.  They are browser issues.  What the PTB may be afraid of is that they have a proxy that filters for "bad IE content," and virus scanners taht find bad e-Mail attachments... but they are afraid that HTML e-Mail may be a third category, because the HTML is never processed by the proxy (comes as e-Mail element), and teh virus scanners may not work on HTML elements that don't look like executable code attachments.  I think they are being paranoid, because the e-Mail virus scanners are supposed to include any virus type, even if it is embedded in HTML e-Mail.  Perhaps they think #1 and #4 aren't considered "viruses" per se.  Contact SYmantec, and have them issue a clarifying statement.
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.
JadeComputerGalAuthor Commented:
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.