Re: Web Mail Vulnerabilities

[Devdas Bhagat <dvb () users sourceforge net>]

On 15/10/02 16:01 -0400, Link, Jennifer wrote:
> We are looking at provided mail access via internet connection (home,
> internet cafe, library etc.) and I'm trying to research what vulnerabilities
> exist for such access.  Any websites, books or personal experience you could
> provide would be VERY VERY helpful.  I'm just getting started so all
> tid-bits are welcome!!
> From the address, I will assume that this is related to military
systems.
To begin with:
Connecting to the internet introduces threats (or at least a new route
of access to your systems). Attackers can break into your http
server/mail server and use that as a stepping stone into the rest of the
network.

Data on the internet is essentially unprotected (no authentication, and
no encryption by default). This implies that any net access to security
related material is vulnerable to sniffing on intermediate
routers/networks, which you do not control.

You are introducing an additional service to the world, so there may be
holes in that service (your http daemon and the webmail client itself).
Webmail clients are vulnerable to a number of attacks, including but not
limited to session hijacking, password exposure, cross site
scripting, holes in the scripting language itself....

Again, access is from unsecured systems, which may be compromised. You
could have usernames and passwords compromised on those systems.

googling for webmail security would be a good start.



My personal security procedures would probably include:

Use a physically separate network for web access. This should be
dissconnected from the secure network.

Use secure and patched products only (defend against attacks on
publically available services).

Since network security is a concern, use ipsec, or at least https.

Additionally, use SMTPS (or the STARTTLS ESMTP extension) to protect
(E)SMTP sessions.
Use gpg/pgp/ S/MIME to encrypt email.

As far as the webmail client goes, I personally don't trust PHP based
clients right now because there have been too many vulnerabilities (not
the language, just the coders). You could probably develop an inhouse
client in a week or two.

Email may contain spam, HTML, viruses... I would suggest something like
demime to strip everything except plain text from the email. This is the
safest way to deal with MIME (get rid of it).

Hope this helps a bit.

Devdas Bhagat