http://www.cafesoft.com/products/cams/tomcat-security.html
if you are asking how to overcome Man-in-the-middle fraudulent manipulation
based on basic authentication?
and or Man-in-the middle fraudulent manipulation based on Form-based
authentication which uses j_username
and j_password
and posts back to j_security_check using cleartext?
i would suggest implementation authentication using either Message-Digest or
HTTPS
Message-Digest processes passwords with a Digest algorithm such as SHA, MD2, or
MD5.. the receiving entity must agree on the digested contents for
authentication to occur
HTTPS or HTTP on a SSL connection usually implemented with a known key stored
in a keystore where access is controlled by CA (certificate authority)
presentation of a certificate..
a good explanation of how Tomcat implements SSL details are available at
http://www.mbaworld.com/docs/ssl-howto.html
commercial vendors such as Verisign
have implemented CA servers which validate the requesting entity and the
requestor to ensure both are indeed who they say they are.. client
authenticating to CA authority is a new feature but prevents spoofed clients
from order-execution and/or using spoofed credentials to effect fraudulent
transactions..I would strongly suggest you enable authentication capability in
both directions if using SSL
https://www.verisign.com/support/roots.html
security elements defined and configured by Tomcat:
Deployment descriptor
<security-constraint> elements define
the permissions and
rules for the protected Tomcat resources and
include the following
XML elements:
web-resource-collection - A set
of URL patterns
and HTTP methods that describe a set of resources
to be
protected. All requests that contain a URL pattern matched
in a web
resource collection are subject to the constraint. auth-constraint - A set of
security
roles (one or
more) to which a user must belong to be granted
access to
resources matched by the web resource collections (e.g. admin/manager)
user-data-constraint - Describes
integrity and
confidentiality requirements for the transport layer
of the client
server.
an example of XSD which describes user-data-constraintType would be
<xsd:complexType name="user-data-constraintType">
<xsd:annotation>
<xsd:documentation>
The user-data-constraintType is used to indicate how
data communicated between the client and container should be
protected.
Used in: security-constraint
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="description"
type="j2ee:descriptionType"
minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="transport-guarantee"
type="j2ee:transport-guaranteeType"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:ID"/>
</xsd:complexType>
namespace j2ee is assigned xmlns:j2ee="http://java.sun.com/xml/ns/j2ee";
where transport=guaranteeType can be NONE,INTEGRAL or CONFIDENTIAL
the latter 2 types imply use of SSL
Man in the middle fraud is a concern to all and one which should be dealt with
the most secure and reliable algorithm
available
anyone else?
Martin Gainty
______________________________________________
Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung/Note de
déni et de confidentialité
This message is confidential. If you should not be the intended receiver, then
we ask politely to report. Each unauthorized forwarding or manufacturing of a
copy is inadmissible. This message serves only for the exchange of information
and has no legal binding effect. Due to the easy manipulation of emails we
cannot take responsibility over the the contents.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> From: chuck.caldar...@unisys.com
> To: users@tomcat.apache.org
> Date: Wed, 13 May 2009 07:16:50 -0500
> Subject: RE: Form Based Authentication creates user session before it is
> authenticated?
>
> > From: umeshkavade [mailto:umeshkav...@yahoo.co.in]
> > Subject: Re: Form Based Authentication creates user session before it
> > is authenticated?
> >
> > P.S: BTW, is Tomcat planning to resolve this vulnerability in near
> > future?
>
> I'll bite: what "vulnerability" are you referring to?
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
_________________________________________________________________
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009
