tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: PATCH: fix for asset service (branch-3-0 2005-03-16)
Date Mon, 21 Mar 2005 15:00:24 GMT
Another solution is to change the asset service to reject all incoming
requests if externalization of assets is enabled.  In this scenario,
assets are copies out of JAR files onto the file system (mapped to a
web folder).  Currently, the asset service continues to execute.  By
disabling it, you close the gap ... and have an effective whitelist
because files are extenalized when a URL referencing them is generated
(as part of a page render).

However, this has some issues in a  cluster, unless the file system /
web folder is shared or shadowed between servers in the cluster.

On Mon, 21 Mar 2005 15:56:34 +0100, David White <dw11610@onemail.at> wrote:
> On Mon, 2005-03-21 at 09:11 -0500, Howard Lewis Ship wrote:
> > >  All a CHF can do is confirm that the content that has
> > been hashed is almost certainly identical with another piece of content
> > that produced the same digest.
> >
> > Exactly.  And that's all that's necessary.  That's a near perfect
> > credential because it is non-trivial (i.e., virtually impossible) to
> > generate the digest without the file.
> An UNIX box may be considered well and truly compromised if an attacker
> gets access to the hashed passwords in /etc/shadow or /etc/passwd. The
> same applies for the SAM in Windows. Why, if the CHF is truly one-way?
> Because the bad guy can e.g. use a dictionary and end-user stupidity to
> dramatically reduce the search space.
> You ignored my argument about using the asset service to scan for
> vulnerable Java classes or other resources. For an attacker, finding out
> that a resource in www.someserver.com/TapestryAppContext is identical to
> a resource that has been acquired by other means is useful information.
> This attack is isomorphic to a dictionary attack on a password hash.
> > The digest is long enough that
> > you aren't going to guess it (not in the lifespan of the universe). As
> > far as I understand it, this is exactly the kind of thing CHF are for.
> >
> No, a CHF is most commonly used to ensure integrity of a message, thus
> the name "message digest". The use of a CHF in an authentication routine
> is deprecated when better mechanisms (e.g. Kerebos, smart cards,
> challenge-response with asymmetric crypto, et. al.) are available. These
> mechanisms may well use CHFs, but a CHF alone is *not* such a mechanism.
> > You can overide the asset service in both 3.0 and 3.1 to fit your
> > needs ... but all our energies are better spent elsewhere.
> >
> The patch I sent serves the needs of the project I am working on. I
> would be willing to contribute a further patch to handle clustered
> environments. I also see value in supporting the use of a message digest
> to verify content assets provided by untrusted sources.
> Cordially,
> David WHITE
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

View raw message