You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org> on 2005/03/12 21:46:54 UTC
[jira] Created: (TAPESTRY-281) asset service has security flaw
asset service has security flaw
-------------------------------
Key: TAPESTRY-281
URL: http://issues.apache.org/jira/browse/TAPESTRY-281
Project: Tapestry
Type: Bug
Components: Framework
Versions: 3.0.2
Environment: Tomcat 5, JDK 1.4
Reporter: Howard M. Lewis Ship
The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
* View the web.xml file:
http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
* View the tapestry.application file:
http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
* View a raw JSP file:
http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
* Download a few class files that are part of the application:
http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Updated: (TAPESTRY-281) asset service has security flaw
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-281?page=history ]
Howard M. Lewis Ship updated TAPESTRY-281:
------------------------------------------
Assign To: Howard M. Lewis Ship
Version: 3.1
(was: 3.0.2)
Fix Version: 3.1
> asset service has security flaw
> -------------------------------
>
> Key: TAPESTRY-281
> URL: http://issues.apache.org/jira/browse/TAPESTRY-281
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 3.1
> Environment: Tomcat 5, JDK 1.4
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Fix For: 3.1
>
> The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
> The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
> Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
> * View the web.xml file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
> * View the tapestry.application file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
> * View a raw JSP file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
> * Download a few class files that are part of the application:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-281) asset service has security flaw
Posted by David Taylor <Da...@cox.net>.
I fully agree with your assessment and think it is more than adequate
for this application. Given the length of an MD5 hash it would take
quite some time to try all possible hash values for a given asset. While
purists might object on the basis that a brute force attack is possible,
the risk is reasonably small unless your server is much faster than mine :)
The problem I face is that MD5 has the reputation of being a "broken"
hash. While it can be argued at a technical level that this is an
appropriate use of MD5, it is very difficult to convince someone less
technical. Speaking from experience, it is no fun sitting across the
table from Visa and government security auditors and trying to explain
how MD5 is broken except when used in your application. The unfortunate
reality is that the people that make the decisions just don't understand
the details and want a "sure thing". These are the same people that
subscribe to the idea that "nobody is ever fired for choosing IBM".
Maybe I should find some less paranoid customers...
Howard Lewis Ship wrote:
>So, you're an evil hacker and you want to suck out a Java .class file
>using the asset service.
>
>So you say, "MD5 is broken", all I have to do is a) figure out the
>name of the class and b) generate a correct MD5 digest for it.
>
>Maybe they can pick out the class name from a stack trace.
>
>That leaves (b). If you don't know the content, or even the length,
>of the file, how would you go about creating the MD5 digest for it?
>Short of iterating through the possible values for a few billion
>years?
>
>Those cases where people have "cracked" MD5 ... they usually started
>with a lot more, such as a partial password, or a public key, and used
>that, along with a lot of other data, to get at the encoded data (the
>private key).
>
>In fact, MD5 is probably overkill for the Tapestry asset service use
>case, a simple CRC32 checksum would probably be more than sufficient.
>
>
>On Tue, 15 Mar 2005 18:06:38 -0500, David Taylor <Da...@cox.net> wrote:
>
>
>>Great, I was planning on backporting the changes this week. I was also
>>considering adding the feature of limiting the hash to the first few KB
>>of the file to avoid the performance hit when dealing with large assets.
>>One of the applications I have in the works currently serves up
>>thousands of high-res JPEG and large PDF files using dynamically created
>>assets.
>>
>>I do have one question -- are your updates a straight port of the
>>original MD5-only version or did you allow for other hash algorithms?
>>While MD5 is probably more than adequate for this use, security minded
>>businesses are afraid of MD5 because it has demonstrated collisions and
>>is considered "broken". For these clients I am planning on using SHA-256
>>since it is not yet considered to be an "evil" algorithm. If not, I
>>would be happy to help add support for other algorithms.
>>
>>Thanks for your timely contribution.
>>
>>David
>>
>>matthew c. mead wrote:
>>
>>
>>
>>>I have "backported" this to a cvs checkout of 3.0.2. It isn't
>>>perfect, but it meets my needs and is probably a good start.
>>>
>>>Is anyone interested in it?
>>>
>>>Is there a maintainer for 3.0.2/3.0.3?
>>>
>>>
>>>
>>>-matt
>>>
>>>Howard M. Lewis Ship (JIRA) wrote:
>>>
>>>
>>>
>>>> [ http://issues.apache.org/jira/browse/TAPESTRY-281?page=history ]
>>>> Howard M. Lewis Ship resolved TAPESTRY-281:
>>>>-------------------------------------------
>>>>
>>>> Resolution: Fixed
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>asset service has security flaw
>>>>>-------------------------------
>>>>>
>>>>> Key: TAPESTRY-281
>>>>> URL: http://issues.apache.org/jira/browse/TAPESTRY-281
>>>>> Project: Tapestry
>>>>> Type: Bug
>>>>> Components: Framework
>>>>> Versions: 3.1
>>>>>Environment: Tomcat 5, JDK 1.4
>>>>> Reporter: Howard M. Lewis Ship
>>>>> Assignee: Howard M. Lewis Ship
>>>>> Fix For: 3.1
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>The asset service can be used to view files that should not be
>>>>>visible. This could expose important resources, including database
>>>>>passwords and connection information.
>>>>>The asset service appears to expose any file relative to the
>>>>>classpath, and you can even use the ".." operator to go backwards,
>>>>>down into WEB-INF in general.
>>>>>Here are some examples. They were tested on a demo application
>>>>>which is often available on the web, but they've been "cleaned," so
>>>>>they don't point to a real server anymore:
>>>>>* View the web.xml file:
>>>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
>>>>>
>>>>>* View the tapestry.application file:
>>>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
>>>>>
>>>>>* View a raw JSP file:
>>>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
>>>>>
>>>>>* Download a few class files that are part of the application:
>>>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>>>>>
>>>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-281) asset service has security flaw
Posted by Paul Ferraro <pm...@columbia.edu>.
Howard Lewis Ship wrote:
>So, you're an evil hacker and you want to suck out a Java .class file
>using the asset service.
>
>So you say, "MD5 is broken", all I have to do is a) figure out the
>name of the class and b) generate a correct MD5 digest for it.
>
>Maybe they can pick out the class name from a stack trace.
>
>That leaves (b). If you don't know the content, or even the length,
>of the file, how would you go about creating the MD5 digest for it?
>Short of iterating through the possible values for a few billion
>years?
>
>Those cases where people have "cracked" MD5 ... they usually started
>with a lot more, such as a partial password, or a public key, and used
>that, along with a lot of other data, to get at the encoded data (the
>private key).
>
>In fact, MD5 is probably overkill for the Tapestry asset service use
>case, a simple CRC32 checksum would probably be more than sufficient.
>
>
>
... and checksums are about an order of magnitude faster to compute!
I realize that the discovery about the "broken"-ness of various digest
algorithms unveiled at the recent CRYPTO 2004 that raised such a stir
really doesn't amount to much in reality. Instead of taking a few
billion years to find a hash collision, it might take half the time
(i.e. a /couple/ of billion years).
My only point was only that given how convenient it is to specify digest
algorithms, it seemed only natural to allow it to be configurable.
However, to avoid maxing out url size, some of the newer algorithms
(e.g. SHA-512) will probably necessitate using base 64 encoding rather
than hex encoding.
Paul
>On Tue, 15 Mar 2005 18:06:38 -0500, David Taylor <Da...@cox.net> wrote:
>
>
>>Great, I was planning on backporting the changes this week. I was also
>>considering adding the feature of limiting the hash to the first few KB
>>of the file to avoid the performance hit when dealing with large assets.
>>One of the applications I have in the works currently serves up
>>thousands of high-res JPEG and large PDF files using dynamically created
>>assets.
>>
>>I do have one question -- are your updates a straight port of the
>>original MD5-only version or did you allow for other hash algorithms?
>>While MD5 is probably more than adequate for this use, security minded
>>businesses are afraid of MD5 because it has demonstrated collisions and
>>is considered "broken". For these clients I am planning on using SHA-256
>>since it is not yet considered to be an "evil" algorithm. If not, I
>>would be happy to help add support for other algorithms.
>>
>>Thanks for your timely contribution.
>>
>>David
>>
>>matthew c. mead wrote:
>>
>>
>>
>>>I have "backported" this to a cvs checkout of 3.0.2. It isn't
>>>perfect, but it meets my needs and is probably a good start.
>>>
>>>Is anyone interested in it?
>>>
>>>Is there a maintainer for 3.0.2/3.0.3?
>>>
>>>
>>>
>>>-matt
>>>
>>>Howard M. Lewis Ship (JIRA) wrote:
>>>
>>>
>>>
>>>> [ http://issues.apache.org/jira/browse/TAPESTRY-281?page=history ]
>>>> Howard M. Lewis Ship resolved TAPESTRY-281:
>>>>-------------------------------------------
>>>>
>>>> Resolution: Fixed
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>asset service has security flaw
>>>>>-------------------------------
>>>>>
>>>>> Key: TAPESTRY-281
>>>>> URL: http://issues.apache.org/jira/browse/TAPESTRY-281
>>>>> Project: Tapestry
>>>>> Type: Bug
>>>>> Components: Framework
>>>>> Versions: 3.1
>>>>>Environment: Tomcat 5, JDK 1.4
>>>>> Reporter: Howard M. Lewis Ship
>>>>> Assignee: Howard M. Lewis Ship
>>>>> Fix For: 3.1
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>The asset service can be used to view files that should not be
>>>>>visible. This could expose important resources, including database
>>>>>passwords and connection information.
>>>>>The asset service appears to expose any file relative to the
>>>>>classpath, and you can even use the ".." operator to go backwards,
>>>>>down into WEB-INF in general.
>>>>>Here are some examples. They were tested on a demo application
>>>>>which is often available on the web, but they've been "cleaned," so
>>>>>they don't point to a real server anymore:
>>>>>* View the web.xml file:
>>>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
>>>>>
>>>>>* View the tapestry.application file:
>>>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
>>>>>
>>>>>* View a raw JSP file:
>>>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
>>>>>
>>>>>* Download a few class files that are part of the application:
>>>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>>>>>
>>>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-281) asset service has security flaw
Posted by Howard Lewis Ship <hl...@gmail.com>.
So, you're an evil hacker and you want to suck out a Java .class file
using the asset service.
So you say, "MD5 is broken", all I have to do is a) figure out the
name of the class and b) generate a correct MD5 digest for it.
Maybe they can pick out the class name from a stack trace.
That leaves (b). If you don't know the content, or even the length,
of the file, how would you go about creating the MD5 digest for it?
Short of iterating through the possible values for a few billion
years?
Those cases where people have "cracked" MD5 ... they usually started
with a lot more, such as a partial password, or a public key, and used
that, along with a lot of other data, to get at the encoded data (the
private key).
In fact, MD5 is probably overkill for the Tapestry asset service use
case, a simple CRC32 checksum would probably be more than sufficient.
On Tue, 15 Mar 2005 18:06:38 -0500, David Taylor <Da...@cox.net> wrote:
> Great, I was planning on backporting the changes this week. I was also
> considering adding the feature of limiting the hash to the first few KB
> of the file to avoid the performance hit when dealing with large assets.
> One of the applications I have in the works currently serves up
> thousands of high-res JPEG and large PDF files using dynamically created
> assets.
>
> I do have one question -- are your updates a straight port of the
> original MD5-only version or did you allow for other hash algorithms?
> While MD5 is probably more than adequate for this use, security minded
> businesses are afraid of MD5 because it has demonstrated collisions and
> is considered "broken". For these clients I am planning on using SHA-256
> since it is not yet considered to be an "evil" algorithm. If not, I
> would be happy to help add support for other algorithms.
>
> Thanks for your timely contribution.
>
> David
>
> matthew c. mead wrote:
>
> > I have "backported" this to a cvs checkout of 3.0.2. It isn't
> > perfect, but it meets my needs and is probably a good start.
> >
> > Is anyone interested in it?
> >
> > Is there a maintainer for 3.0.2/3.0.3?
> >
> >
> >
> > -matt
> >
> > Howard M. Lewis Ship (JIRA) wrote:
> >
> >> [ http://issues.apache.org/jira/browse/TAPESTRY-281?page=history ]
> >> Howard M. Lewis Ship resolved TAPESTRY-281:
> >> -------------------------------------------
> >>
> >> Resolution: Fixed
> >>
> >>
> >>
> >>> asset service has security flaw
> >>> -------------------------------
> >>>
> >>> Key: TAPESTRY-281
> >>> URL: http://issues.apache.org/jira/browse/TAPESTRY-281
> >>> Project: Tapestry
> >>> Type: Bug
> >>> Components: Framework
> >>> Versions: 3.1
> >>> Environment: Tomcat 5, JDK 1.4
> >>> Reporter: Howard M. Lewis Ship
> >>> Assignee: Howard M. Lewis Ship
> >>> Fix For: 3.1
> >>>
> >>
> >>
> >>
> >>
> >>> The asset service can be used to view files that should not be
> >>> visible. This could expose important resources, including database
> >>> passwords and connection information.
> >>> The asset service appears to expose any file relative to the
> >>> classpath, and you can even use the ".." operator to go backwards,
> >>> down into WEB-INF in general.
> >>> Here are some examples. They were tested on a demo application
> >>> which is often available on the web, but they've been "cleaned," so
> >>> they don't point to a real server anymore:
> >>> * View the web.xml file:
> >>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
> >>>
> >>> * View the tapestry.application file:
> >>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
> >>>
> >>> * View a raw JSP file:
> >>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
> >>>
> >>> * Download a few class files that are part of the application:
> >>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
> >>>
> >>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> 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
Re: [jira] Resolved: (TAPESTRY-281) asset service has security flaw
Posted by "matthew c. mead" <m-...@goof.com>.
The patch is inline as part of this message.
Of particular note, I don't like these things:
I was not totally kosher in introducing a new message into
Tapestry.properties
It appears the asset service is used in generating the exception page?
If this code fails in any way, the exception page cannot be presented.
Hence, if someone tries to reach an asset via the old-style asset
service url (ie with no hash), the will get a container exception page,
rather than tapestry's defined exception page.
Lack of configurability on digest algorithm - this is easy to fix.
I couldn't find a callback hook to tie into in Tapestry 3.0.2 that
allows the asset service to clear its digest cache upon restart of
tapestry. This was something Howard did with his code for 3.1.
I ended up making use of the URLConnection to pass to the Digest
Provider - Howard used a String for the path, but I'm not sure of the
most expedient way of getting something servlet context based to the
Digest provider so it can open an input stream. Howard used dependency
injection to handle this in 3.1, but 3.0.2 does not have Hivemind
integrated.
Let me know if you clean this up more, I'd be interested in seeing it.
-matt
----- assetsecurityfix.patch -----
diff -ur --new-file --exclude examples --exclude build.properties
--exclude downloads --exclude .build --exclude *CVS* --exclude *~
--exclude *.jar
jakarta-tapestry-3.0.2/framework/src/org/apache/tapestry/TapestryStrings.properties
jakarta-tapestry/framework/src/org/apache/tapestry/TapestryStrings.properties
---
jakarta-tapestry-3.0.2/framework/src/org/apache/tapestry/TapestryStrings.properties
Tue Mar 30 13:45:25 2004
+++
jakarta-tapestry/framework/src/org/apache/tapestry/TapestryStrings.properties
Tue Mar 15 16:21:20 2005
@@ -93,6 +93,7 @@
AssetService.exception-report-title=Failure to export asset {0}.
ExternalAsset.resource-missing=Could not access external asset {0}.
+asset-digest-mismatch=Digest for access to asset {0} mismatched
previously calculated digest.
# org.apache.tapestry.bean
diff -ur --new-file --exclude examples --exclude build.properties
--exclude downloads --exclude .build --exclude *CVS* --exclude *~
--exclude *.jar
jakarta-tapestry-3.0.2/framework/src/org/apache/tapestry/asset/AssetService.java
jakarta-tapestry/framework/src/org/apache/tapestry/asset/AssetService.java
---
jakarta-tapestry-3.0.2/framework/src/org/apache/tapestry/asset/AssetService.java
Thu Feb 19 12:38:09 2004
+++
jakarta-tapestry/framework/src/org/apache/tapestry/asset/AssetService.java
Tue Mar 15 16:41:22 2005
@@ -75,6 +75,8 @@
private static final int BUFFER_SIZE = 10240;
+ private ResourceDigestSource _digestSource = new
ResourceDigestSourceImpl();
+
/**
* Builds a {@link ILink} for a {@link PrivateAsset}.
*
@@ -87,11 +89,27 @@
{
if (Tapestry.size(parameters) != 1)
throw new ApplicationRuntimeException(
- Tapestry.format("service-single-parameter",
Tapestry.ASSET_SERVICE));
+ Tapestry.format("service-incorrect-parameter-count",
new Object[] {Tapestry.ASSET_SERVICE, new Integer(1)}));
// Service is stateless
- return constructLink(cycle, Tapestry.ASSET_SERVICE, null,
parameters, false);
+ String resourcePath = (String) parameters[1];
+ URL resourceURL =
cycle.getEngine().getResourceResolver().getResource(resourcePath);
+
+ if (resourceURL == null)
+ throw new ApplicationRuntimeException(
+ Tapestry.format("missing-resource", resourcePath));
+
+ URLConnection resourceConnection = null;
+ try {
+ resourceConnection = resourceURL.openConnection();
+ } catch (IOException e) {
+ throw new ApplicationRuntimeException("MCM TODO - couldn't open
URLConnection to " + resourcePath);
+ }
+
+ String digest = _digestSource.getDigestForResource(resourceConnection);
+
+ return constructLink(cycle, Tapestry.ASSET_SERVICE, null, new
Object[] {parameters[0], digest}, false);
}
public String getName()
@@ -133,11 +151,12 @@
{
Object[] parameters = getParameters(cycle);
- if (Tapestry.size(parameters) != 1)
+ if (Tapestry.size(parameters) != 2)
throw new ApplicationRuntimeException(
- Tapestry.format("service-single-parameter",
Tapestry.ASSET_SERVICE));
+ Tapestry.format("service-incorrect-parameter-count",
new Object[] {Tapestry.ASSET_SERVICE, new Integer(2)}));
String resourcePath = (String) parameters[0];
+ String digest = (String) parameters[1];
URL resourceURL =
cycle.getEngine().getResourceResolver().getResource(resourcePath);
@@ -147,9 +166,13 @@
URLConnection resourceConnection = resourceURL.openConnection();
+ if
(!_digestSource.getDigestForResource(resourceConnection).equals(digest))
+ throw new
ApplicationRuntimeException(Tapestry.format("asset-digest-mismatch",
Tapestry.ASSET_SERVICE));
+
ServletContext servletContext =
cycle.getRequestContext().getServlet().getServletContext();
- writeAssetContent(engine, cycle, output, resourcePath,
resourceConnection, servletContext);
+ resourceConnection = resourceURL.openConnection();
+ writeAssetContent(engine, cycle, output, resourcePath,
resourceConnection, servletContext);
}
/** @since 2.2 **/
@@ -209,4 +232,8 @@
engine.reportException(title, ex);
}
}
-}
\ No newline at end of file
+ public void setDigestSource(ResourceDigestSource md5Source)
+ {
+ _digestSource = md5Source;
+ }
+}
diff -ur --new-file --exclude examples --exclude build.properties
--exclude downloads --exclude .build --exclude *CVS* --exclude *~
--exclude *.jar
jakarta-tapestry-3.0.2/framework/src/org/apache/tapestry/asset/ResourceDigestSource.java
jakarta-tapestry/framework/src/org/apache/tapestry/asset/ResourceDigestSource.java
---
jakarta-tapestry-3.0.2/framework/src/org/apache/tapestry/asset/ResourceDigestSource.java
Wed Dec 31 19:00:00 1969
+++
jakarta-tapestry/framework/src/org/apache/tapestry/asset/ResourceDigestSource.java
Tue Mar 15 15:58:43 2005
@@ -0,0 +1,41 @@
+// Copyright 2005 The Apache Software Foundation
+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+
+package org.apache.tapestry.asset;
+
+import java.net.URLConnection;
+
+/**
+ * Calculates the digest value, as a string, for a particular classpath
resource. This is primarily
+ * used by the {@link org.apache.tapestry.asset.AssetService}to
authenticate requests (you are not
+ * allowed access to a resource unless you can provide the correct
digest value).
+ *
+ * @author Howard M. Lewis Ship
+ * @since 3.1
+ */
+public interface ResourceDigestSource
+{
+ /**
+ * Calculates the DIGEST checksum for a classpath resource. Because
this is expensive, the value
+ * may be cached.
+ *
+ * @param resourcePath
+ * the classpath resource, which should start with a
leading slash.
+ * @return A string representation of the digest for the provided
resource path.
+ * @throws ApplicationRuntimeException
+ * if the resource does not exist, or there is an error
calculating the checksum.
+ */
+
+ public String getDigestForResource(URLConnection resourceConnection);
+}
diff -ur --new-file --exclude examples --exclude build.properties
--exclude downloads --exclude .build --exclude *CVS* --exclude *~
--exclude *.jar
jakarta-tapestry-3.0.2/framework/src/org/apache/tapestry/asset/ResourceDigestSourceImpl.java
jakarta-tapestry/framework/src/org/apache/tapestry/asset/ResourceDigestSourceImpl.java
---
jakarta-tapestry-3.0.2/framework/src/org/apache/tapestry/asset/ResourceDigestSourceImpl.java
Wed Dec 31 19:00:00 1969
+++
jakarta-tapestry/framework/src/org/apache/tapestry/asset/ResourceDigestSourceImpl.java
Tue Mar 15 16:36:54 2005
@@ -0,0 +1,120 @@
+// Copyright 2005 The Apache Software Foundation
+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+
+package org.apache.tapestry.asset;
+
+import java.io.BufferedInputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.net.URL;
+import java.net.URLConnection;
+import java.security.MessageDigest;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.commons.codec.binary.Hex;
+
+import org.apache.tapestry.Tapestry;
+import org.apache.tapestry.ApplicationRuntimeException;
+
+/**
+ * Implementation of {@link
org.apache.tapestry.asset.ResourceDigestSource} that calculates an
+ * DIGEST checksum digest and converts it to a string of hex digits.
+ *
+ * @author Howard M. Lewis Ship
+ * @since 3.1
+ */
+public class ResourceDigestSourceImpl implements ResourceDigestSource
+{
+ private static final int BUFFER_SIZE = 5000;
+
+ /**
+ * Map keyed on resource path of DIGEST checksum (as a string).
+ */
+
+ private final Map _cache = new HashMap();
+
+ public synchronized String getDigestForResource(URLConnection
resourceConnection)
+ {
+ String result = (String) _cache.get(resourceConnection.getURL());
+
+ if (result == null)
+ {
+ result = computeMD5(resourceConnection);
+ _cache.put(resourceConnection.getURL(), result);
+ }
+
+ return result;
+ }
+
+ private String computeMD5(URLConnection resourceConnection)
+ {
+ URL url = resourceConnection.getURL();
+
+ if (url == null)
+ throw new
ApplicationRuntimeException(Tapestry.format("missing-resource",
resourceConnection.getURL()));
+
+ InputStream stream = null;
+
+ try
+ {
+ MessageDigest digest = MessageDigest.getInstance("MD5");
+
+ stream = resourceConnection.getInputStream();
+
+ digestStream(digest, stream);
+
+ stream.close();
+ stream = null;
+
+ byte[] bytes = digest.digest();
+ char[] encoded = Hex.encodeHex(bytes);
+
+ return new String(encoded);
+ }
+ catch (IOException ex)
+ {
+ throw new
ApplicationRuntimeException(Tapestry.format("missing-resource",
resourceConnection.getURL()));
+ }
+ catch (Exception ex)
+ {
+ throw new ApplicationRuntimeException(ex);
+ }
+ finally
+ {
+ try {
+ if (stream != null) {
+ stream.close();
+ }
+ } catch (IOException ioe) {
+ // ignore
+ }
+ }
+ }
+
+ private void digestStream(MessageDigest digest, InputStream stream)
throws IOException
+ {
+ byte[] buffer = new byte[BUFFER_SIZE];
+
+ while (true)
+ {
+ int length = stream.read(buffer);
+
+ if (length < 0)
+ return;
+
+ digest.update(buffer, 0, length);
+ }
+ }
+}
----- end assetsecurityfix.patch -----
David Taylor wrote:
> Great, I was planning on backporting the changes this week. I was also
> considering adding the feature of limiting the hash to the first few
> KB of the file to avoid the performance hit when dealing with large
> assets. One of the applications I have in the works currently serves
> up thousands of high-res JPEG and large PDF files using dynamically
> created assets.
>
> I do have one question -- are your updates a straight port of the
> original MD5-only version or did you allow for other hash algorithms?
> While MD5 is probably more than adequate for this use, security minded
> businesses are afraid of MD5 because it has demonstrated collisions
> and is considered "broken". For these clients I am planning on using
> SHA-256 since it is not yet considered to be an "evil" algorithm. If
> not, I would be happy to help add support for other algorithms.
>
> Thanks for your timely contribution.
>
> David
>
> matthew c. mead wrote:
>
>> I have "backported" this to a cvs checkout of 3.0.2. It isn't
>> perfect, but it meets my needs and is probably a good start.
>>
>> Is anyone interested in it?
>>
>> Is there a maintainer for 3.0.2/3.0.3?
>>
>>
>>
>> -matt
>>
>> Howard M. Lewis Ship (JIRA) wrote:
>>
>>> [ http://issues.apache.org/jira/browse/TAPESTRY-281?page=history ]
>>> Howard M. Lewis Ship resolved TAPESTRY-281:
>>> -------------------------------------------
>>>
>>> Resolution: Fixed
>>>
>>>
>>>
>>>> asset service has security flaw
>>>> -------------------------------
>>>>
>>>> Key: TAPESTRY-281
>>>> URL: http://issues.apache.org/jira/browse/TAPESTRY-281
>>>> Project: Tapestry
>>>> Type: Bug
>>>> Components: Framework
>>>> Versions: 3.1
>>>> Environment: Tomcat 5, JDK 1.4
>>>> Reporter: Howard M. Lewis Ship
>>>> Assignee: Howard M. Lewis Ship
>>>> Fix For: 3.1
>>>>
>>>
>>>
>>>
>>>
>>>
>>>> The asset service can be used to view files that should not be
>>>> visible. This could expose important resources, including database
>>>> passwords and connection information.
>>>> The asset service appears to expose any file relative to the
>>>> classpath, and you can even use the ".." operator to go backwards,
>>>> down into WEB-INF in general.
>>>> Here are some examples. They were tested on a demo application
>>>> which is often available on the web, but they've been "cleaned," so
>>>> they don't point to a real server anymore:
>>>> * View the web.xml file:
>>>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
>>>>
>>>> * View the tapestry.application file:
>>>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
>>>>
>>>> * View a raw JSP file:
>>>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
>>>>
>>>> * Download a few class files that are part of the application:
>>>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>>>>
>>>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
--
matthew c. mead
http://www.goof.com/
Re: [jira] Resolved: (TAPESTRY-281) asset service has security flaw
Posted by David Taylor <Da...@cox.net>.
Great, I was planning on backporting the changes this week. I was also
considering adding the feature of limiting the hash to the first few KB
of the file to avoid the performance hit when dealing with large assets.
One of the applications I have in the works currently serves up
thousands of high-res JPEG and large PDF files using dynamically created
assets.
I do have one question -- are your updates a straight port of the
original MD5-only version or did you allow for other hash algorithms?
While MD5 is probably more than adequate for this use, security minded
businesses are afraid of MD5 because it has demonstrated collisions and
is considered "broken". For these clients I am planning on using SHA-256
since it is not yet considered to be an "evil" algorithm. If not, I
would be happy to help add support for other algorithms.
Thanks for your timely contribution.
David
matthew c. mead wrote:
> I have "backported" this to a cvs checkout of 3.0.2. It isn't
> perfect, but it meets my needs and is probably a good start.
>
> Is anyone interested in it?
>
> Is there a maintainer for 3.0.2/3.0.3?
>
>
>
> -matt
>
> Howard M. Lewis Ship (JIRA) wrote:
>
>> [ http://issues.apache.org/jira/browse/TAPESTRY-281?page=history ]
>> Howard M. Lewis Ship resolved TAPESTRY-281:
>> -------------------------------------------
>>
>> Resolution: Fixed
>>
>>
>>
>>> asset service has security flaw
>>> -------------------------------
>>>
>>> Key: TAPESTRY-281
>>> URL: http://issues.apache.org/jira/browse/TAPESTRY-281
>>> Project: Tapestry
>>> Type: Bug
>>> Components: Framework
>>> Versions: 3.1
>>> Environment: Tomcat 5, JDK 1.4
>>> Reporter: Howard M. Lewis Ship
>>> Assignee: Howard M. Lewis Ship
>>> Fix For: 3.1
>>>
>>
>>
>>
>>
>>> The asset service can be used to view files that should not be
>>> visible. This could expose important resources, including database
>>> passwords and connection information.
>>> The asset service appears to expose any file relative to the
>>> classpath, and you can even use the ".." operator to go backwards,
>>> down into WEB-INF in general.
>>> Here are some examples. They were tested on a demo application
>>> which is often available on the web, but they've been "cleaned," so
>>> they don't point to a real server anymore:
>>> * View the web.xml file:
>>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
>>>
>>> * View the tapestry.application file:
>>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
>>>
>>> * View a raw JSP file:
>>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
>>>
>>> * Download a few class files that are part of the application:
>>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>>>
>>> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>>>
>>>
>>
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-281) asset service has security flaw
Posted by "matthew c. mead" <m-...@goof.com>.
I have "backported" this to a cvs checkout of 3.0.2. It isn't perfect,
but it meets my needs and is probably a good start.
Is anyone interested in it?
Is there a maintainer for 3.0.2/3.0.3?
-matt
Howard M. Lewis Ship (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/TAPESTRY-281?page=history ]
>
>Howard M. Lewis Ship resolved TAPESTRY-281:
>-------------------------------------------
>
> Resolution: Fixed
>
>
>
>>asset service has security flaw
>>-------------------------------
>>
>> Key: TAPESTRY-281
>> URL: http://issues.apache.org/jira/browse/TAPESTRY-281
>> Project: Tapestry
>> Type: Bug
>> Components: Framework
>> Versions: 3.1
>> Environment: Tomcat 5, JDK 1.4
>> Reporter: Howard M. Lewis Ship
>> Assignee: Howard M. Lewis Ship
>> Fix For: 3.1
>>
>>
>
>
>
>>The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
>>The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
>>Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
>>* View the web.xml file:
>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
>>* View the tapestry.application file:
>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
>>* View a raw JSP file:
>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
>>* Download a few class files that are part of the application:
>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>>
>>
>
>
>
--
matthew c. mead
http://www.goof.com/
[jira] Resolved: (TAPESTRY-281) asset service has security flaw
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-281?page=history ]
Howard M. Lewis Ship resolved TAPESTRY-281:
-------------------------------------------
Resolution: Fixed
> asset service has security flaw
> -------------------------------
>
> Key: TAPESTRY-281
> URL: http://issues.apache.org/jira/browse/TAPESTRY-281
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 3.1
> Environment: Tomcat 5, JDK 1.4
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Fix For: 3.1
>
> The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
> The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
> Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
> * View the web.xml file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
> * View the tapestry.application file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
> * View a raw JSP file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
> * Download a few class files that are part of the application:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org