You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Tony Collen <tc...@neuagency.com> on 2003/03/20 22:14:31 UTC
cocoon-view as possible security problem?
Browsing the livesites, on a whim I tried this URL:
http://dir.salon.com/?cocoon-view=content
and it worked! Obviously someone deploying Cocoon should be aware that
this view is "on" by default, and may reveal data in your page you might
not want. I have yet to see "bad" data get exposed, but there's always
the possibility.
Do we want the views turned off by default, and have a message in the
sitemap about enabling the views? Would it make more sense to have
thename of the "cocoon-view" parameter be able to be changed via
configuration? Say I wanted the parameter to be my-view instead of
cocoon-view. Security through obscurity?
Tony
Re: cocoon-view as possible security problem?
Posted by Geoff Howard <co...@leverageweb.com>.
At 08:24 AM 3/21/2003, you wrote:
>Geoff Howard wrote:
>
>>By the way, I think there are bigger security problems in cocoon...
>
>Like what? (not being arrogant or defensive, just curious... damn email
>communication sometimes coveys the wrong tone)
>
>Stefano.
You've probably seen my other email by now, but just wanted to clarify that
I probably should not have phrased that so bluntly. Still, I hope this
turns into a good conversation.
Some of the issues that have been causing me to think about this have more
to do with default configuration which makes that phrase way over
blown. I've been meaning to start a wiki/discussion about getting a list
of suggested modifications to the default config for live
sites. cocoon-reload, file upload params, possibly views, etc. are what I
think of off the cuff, but would love to hear what others with deeper
knowledge of more of the code think.
Geoff
Re: cocoon-view as possible security problem?
Posted by Geoff Howard <co...@leverageweb.com>.
At 01:52 PM 3/21/2003, you wrote:
>On Fri, 21 Mar 2003, Geoff Howard wrote:
>
> > >Is it? With in-memory upload you can get to OutOfMemory exceptions and
> > >potentially corrupt cocoon instance. With file uploads, you can create
> > >100Mb file systems which you can fill up but you won't disturb
> > >functionality of the server. I don't see how in-memory uploads are more
> > >secure; I see them as *less* secure.
> >
> > Well, in combination with the max-upload-size parameter (or whatever it's
> > called) I felt that better. If I can cause the request to ignore multipart
> > files bigger than xMB, that seems to mitigate the risk. But that's worth
> > some discussion. My worry with autosaving all files is 1) I can purposely
> > fill up your hard drive, given time. 2) Could a user more clever than I
> > create a POST request that would cause a file to be placed somewhere other
> > than the upload dir?
>
> >From my experience with PHP, here's how it works:
>
>You have a PHP script that a form posts a file to. During the execution
>of the script, you have access to an object which represents the uploaded
>file. The object also contains the name of the file on the client
>machine, the mime/type, the actual size of the file uploaded, and the
>temporary name of the file as it is stored on the server.
>
>The uploaded file only exists on the filesystem for the duration of the
>script, and if you want to actually save it, you need to move the temp
>file into a directory. As soon as the script is done executing, PHP
>automatically removes the temporary file. This seems to work out just
>fine, and I haven't seen any bad security problems with it so far.
>
>For further inspiration, check out [1]
>
>Tony
Yes, this is on my list of things I'd like to get to - there was a
discussion about it a month ago or so. That is also a step in the right
direction. Most of that is already in place for us, except notably
cleaning the file up on the way out. I worked up a patch to CocoonServlet
that did just that but someone had the good suggestion to modify the whole
process to store either the files themselves in Request attributes (not
back compatible unless you put them in the Request too) or the keys to the
FilePart objects in as Request attributes. Great idea that I'm hoping to
work on, but have been quite busy at a new job. (launching rockets,
according to SN ;) )
If anyone with more time wants to pursue that themselves, I'd gladly pass
on what I was working on (though not sure any code remains).
>[1] http://www.php.net/manual/en/features.file-upload.php
I'll check this out later.
Geoff
Temp Upload start (See also [RT] pipeline aspects)
Posted by Geoff Howard <co...@leverageweb.com>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Saturday, March 22, 2003 4:38 AM
> To: cocoon-dev@xml.apache.org
> Subject: [RT] pipeline aspects
>
>
> Geoff Howard wrote:
>
> > Obviously, if my
> > application doesn't use any uploads I should disable them in web.xml.
> > But right now, it's all or nothing: I either allow all users to upload
> > _on any page_ (if they create a form that posts to any url in cocoon's
> > space), or I totally disallow uploads. I've been thinking through
> > enabling configs for resource-based, or even authentication-based
> > restrictions for uploads. What would others think?
>
> I've been thinking about this for a while and I thought about waiting
> for 2.1 before sending these RT, but I just wanted to introduce them
> briefly before a quick-hack solution is implemented.
>
I printed the rest out to read carefully offline, but in the meantime I have
already started on the "quick-hack" you feared. ;) I'd love to see a real
solution like you propose post-2.1, but this could work for 2.1.
Actually, this doesn't get
at the restrictions I mentioned above, but to the temp-upload option Vadim
asked for volunteers on. I've attached a patch which includes the changes
below
to MultiPartParser and a quick change to upload.xsp. This is meant only to
give the general idea of what would make cleaning up uploads at the end of
service() more feasible.
If no one likes it, I don't want to put any more time in, but if this looks
OK, I can make the changes to CocoonServlet and work on a good way to
provide the configuration option. Unfortunately, as currently implemented,
autosave-uploads
is boolean and this would introduce a third state. Options to deal with
that are:
1) modify autosave-uploads from boolean to numeric/string or
2) add temp-uploads boolean.
I'm kind of leaning to 2, but totally open to suggestions.
See also:
http://marc.theaimsgroup.com/?t=104387868200007&r=1&w=2 and
http://marc.theaimsgroup.com/?t=103478709700005&r=1&w=2
Index:
src/java/org/apache/cocoon/components/request/multipart/MultipartParser.java
===================================================================
RCS file:
/home/cvspublic/cocoon-2.1/src/java/org/apache/cocoon/components/request/mul
tipart/MultipartParser.java,v
retrieving revision 1.1
diff -u -r1.1 MultipartParser.java
---
src/java/org/apache/cocoon/components/request/multipart/MultipartParser.java
9 Mar 2003 00:09:10 -0000 1.1
+++
src/java/org/apache/cocoon/components/request/multipart/MultipartParser.java
22 Mar 2003 15:23:43 -0000
@@ -59,6 +59,7 @@
import java.io.IOException;
import java.io.OutputStream;
import java.io.PushbackInputStream;
+import java.util.ArrayList;
import java.util.Hashtable;
import java.util.StringTokenizer;
import java.util.Vector;
@@ -99,6 +100,10 @@
/** Field characterEncoding */
private String characterEncoding;
+
+ /** Field UPLOAD_ATTRIBUTE - name of request attribute storing
+ * keys to uploaded files placed in the request */
+ private final static String UPLOAD_ATTRIBUTE = "cocoon-uploads";
/**
* Constructor, parses given request
*
@@ -136,7 +141,7 @@
new TokenStream(
new PushbackInputStream(
new
BufferedInputStream(request.getInputStream()),
- MAX_BOUNDARY_SIZE)),
getBoundary(request.getContentType()));
+ MAX_BOUNDARY_SIZE)),
getBoundary(request.getContentType()), request);
}
/**
@@ -148,7 +153,7 @@
* @throws IOException
* @throws MultipartException
*/
- private void parseMultiPart(TokenStream ts, String boundary)
+ private void parseMultiPart(TokenStream ts, String boundary,
HttpServletRequest request)
throws IOException, MultipartException {
ts.setBoundary(boundary.getBytes());
@@ -157,7 +162,7 @@
while (ts.getState() == TokenStream.STATE_NEXTPART) {
ts.nextPart();
- parsePart(ts);
+ parsePart(ts, request);
}
if (ts.getState() != TokenStream.STATE_ENDMULTIPART) { // sanity
check
@@ -173,7 +178,7 @@
* @throws IOException
* @throws MultipartException
*/
- private void parsePart(TokenStream ts)
+ private void parsePart(TokenStream ts, HttpServletRequest request)
throws IOException, MultipartException {
Hashtable headers = new Hashtable();
@@ -181,7 +186,7 @@
try {
if (headers.containsKey("filename")) {
if (!"".equals(headers.get("filename"))) {
- parseFilePart(ts, headers);
+ parseFilePart(ts, headers, request);
} else {
// IE6 sends an empty part with filename="" for
// empty upload fields. Just parse away the part
@@ -198,7 +203,7 @@
else if (((String)
headers.get("content-disposition")).toLowerCase()
.indexOf("multipart") > -1) {
parseMultiPart(new TokenStream(ts, MAX_BOUNDARY_SIZE),
- "--" + (String) headers.get("boundary"));
+ "--" + (String) headers.get("boundary"), request);
ts.read(); // read past boundary
} else {
throw new MultipartException("Unknown part type");
@@ -219,7 +224,7 @@
* @throws IOException
* @throws MultipartException
*/
- private void parseFilePart(TokenStream in, Hashtable headers)
+ private void parseFilePart(TokenStream in, Hashtable headers,
HttpServletRequest request)
throws IOException, MultipartException {
byte[] buf = new byte[FILE_BUFFER_SIZE];
@@ -241,6 +246,7 @@
if (file.exists()) {
if (!allowOverwrite) {
+ // FIXME: race condition if simultaneous threads upload
a file of the same name
if (silentlyRename) {
int c = 0;
@@ -272,6 +278,13 @@
} else {
put(headers.get("name"), new FilePartFile(headers, file));
}
+
+ ArrayList uploads =
(ArrayList)request.getAttribute(UPLOAD_ATTRIBUTE);;
+ if (uploads == null) {
+ uploads = new ArrayList();
+ }
+ uploads.add(headers.get("name"));
+ request.setAttribute(UPLOAD_ATTRIBUTE,uploads);
}
/**
[RT] pipeline aspects
Posted by Stefano Mazzocchi <st...@apache.org>.
Geoff Howard wrote:
> Obviously, if my
> application doesn't use any uploads I should disable them in web.xml.
> But right now, it's all or nothing: I either allow all users to upload
> _on any page_ (if they create a form that posts to any url in cocoon's
> space), or I totally disallow uploads. I've been thinking through
> enabling configs for resource-based, or even authentication-based
> restrictions for uploads. What would others think?
I've been thinking about this for a while and I thought about waiting
for 2.1 before sending these RT, but I just wanted to introduce them
briefly before a quick-hack solution is implemented.
In my continuous quest to see if our pipeline architecture is enough for
even the most complex web needs, I found out that it is not always the case.
After we release 2.1, I will introduce a discussion about "pipeline
aspects" in order to suggest a more elegant approach to:
- handling webdav
- handling uploading
- handling views
- handling proxying
- handling chunked encoding
In short, all those behaviors that require deep contact with the
internals of the HTTP stream both in reading and writing and,
potentialy, from all the pipeline components.
The way we designed the pipelines was mediated out of the servlet API
and the servlet API was designed exactly to prevent you from having to
know (or manage) the HTTP internals.
Since the approach was a very useful one (in short, clean IoC applied to
the HTTP paradigm), we designed the environment in that direction.
But we have one major difference between the servlet API: the API is
designed so that one or more web resource is associated to one (or,
using request dispaching, a procedural chain of) programmatic request
handlers (the servlets or the jsp pages).
Our model is entirely different and it's pretty rare (see readers) that
we have only one request-handling component that touches the request.
Cocoon aims at complete and clean SoC and started for publishing needs
(stateless, GET-driven). We achieved that with the sitemap. Then we
moved into webapps (stateful, GET/POST roundtrip driven). I think we
solved all possible issues with the flow.
The question I posed to myself was: now that we have both pipelines,
sitemaps and flows, are we able to handle the complexity of WebDAV in a
clean way?
The answer is, unfortunately, "no".
Don't get me wrong: you can write a cocoon-enabled webdav-app
(webdav-apps are webapps that use not only GET/POST but all the webdav
extension to the HTTP protocol!) even with 2.1 but it won't be so clean.
why?
well, unlike GET/POST actions which inherently assume a
resource-oriented granularity, there are other actions (and I consider
the cocoon view a special case of HTTP content negotiation) that require
'cross cutting' behavior across different resources.
I think the sitemap semantics is inherently great at describing concerns
that can be well separated (using matching, for example) but very poor
at describing crosscutting concerns.
Examples of crosscutting concerns are:
1) webdav enabled
2) restricted/protected
3) proxiable
4) viewable
5) upload handling
6) pipeline-wide global parameters
There is no single mechanism to handle all those.
Views have a special semantics. Upload handling is made *explicitly*
cross-cut across the entire domain space (and this is, rightly, a
potential vulnerable point, expecially if associated with resource
restriction).
The best example of crosscutting concern is Restriction/protection: this
is most elegantly done (currently) with wrapping a map:mount.
I wonder is this is, architecturally, the best approach.
In theory, it should be possible to define 'behavior modifiers' that
wrap pipelines and transparently provide different behaviors to them.
I see two possible approaches:
- external modification
- internal modification
external modification is done with wrapping a mount, like we do today
for restricting access to an entire sub-sitemap.
internal modification is done for views, but this required a special
semantics added to the sitemap and, in retrospect, it seems to me that
it was a mistake.
We can't use Actions or flow to modify pipeline behaviors unless we give
full access to the underlying object model, opening the gates for abuses.
We can't add the possibility for people to add their own sitemap
semantics, or we have the same abuse problem.
I see two possible solutions, depending on where we want to go:
1) create a 'wrapping' component
or
2) add the ability to add pluggable <map:pipeline> metadata without
exposing hooks for internal pipeline abuses.
Note that these are very random thoughts and I don't have a coherent
view of what we need and how we solve those issue. at the same time, I
think it's worth thinking at those pipeline-wide problems with little
aspect orientation in mind.
Stefano.
Re: cocoon-view as possible security problem?
Posted by Vadim Gritsenko <va...@verizon.net>.
Tony Collen wrote:
>On Fri, 21 Mar 2003, Geoff Howard wrote:
>
>
>
>>>Is it? With in-memory upload you can get to OutOfMemory exceptions and
>>>potentially corrupt cocoon instance. With file uploads, you can create
>>>100Mb file systems which you can fill up but you won't disturb
>>>functionality of the server. I don't see how in-memory uploads are more
>>>secure; I see them as *less* secure.
>>>
>>>
>>Well, in combination with the max-upload-size parameter (or whatever it's
>>called) I felt that better. If I can cause the request to ignore multipart
>>files bigger than xMB, that seems to mitigate the risk. But that's worth
>>some discussion. My worry with autosaving all files is 1) I can purposely
>>fill up your hard drive, given time. 2) Could a user more clever than I
>>create a POST request that would cause a file to be placed somewhere other
>>than the upload dir?
>>
>>
>
>
>
....
>The uploaded file only exists on the filesystem for the duration of the
>script, and if you want to actually save it, you need to move the temp
>file into a directory. As soon as the script is done executing, PHP
>automatically removes the temporary file. This seems to work out just
>fine, and I haven't seen any bad security problems with it so far.
>
...
Any takers to implement enhanced autosave-uploads parameter? Values
could be:
false or no - ignore uploads
memory - save in memory
temp - save onto disk, remove when processing is finished
true or disk - save onto disk, don't remove
Vadim
Re: cocoon-view as possible security problem?
Posted by Tony Collen <tc...@neuagency.com>.
On Fri, 21 Mar 2003, Geoff Howard wrote:
> >Is it? With in-memory upload you can get to OutOfMemory exceptions and
> >potentially corrupt cocoon instance. With file uploads, you can create
> >100Mb file systems which you can fill up but you won't disturb
> >functionality of the server. I don't see how in-memory uploads are more
> >secure; I see them as *less* secure.
>
> Well, in combination with the max-upload-size parameter (or whatever it's
> called) I felt that better. If I can cause the request to ignore multipart
> files bigger than xMB, that seems to mitigate the risk. But that's worth
> some discussion. My worry with autosaving all files is 1) I can purposely
> fill up your hard drive, given time. 2) Could a user more clever than I
> create a POST request that would cause a file to be placed somewhere other
> than the upload dir?
>From my experience with PHP, here's how it works:
You have a PHP script that a form posts a file to. During the execution
of the script, you have access to an object which represents the uploaded
file. The object also contains the name of the file on the client
machine, the mime/type, the actual size of the file uploaded, and the
temporary name of the file as it is stored on the server.
The uploaded file only exists on the filesystem for the duration of the
script, and if you want to actually save it, you need to move the temp
file into a directory. As soon as the script is done executing, PHP
automatically removes the temporary file. This seems to work out just
fine, and I haven't seen any bad security problems with it so far.
For further inspiration, check out [1]
Tony
[1] http://www.php.net/manual/en/features.file-upload.php
Re: cocoon-view as possible security problem?
Posted by Geoff Howard <co...@leverageweb.com>.
At 08:33 AM 3/21/2003, you wrote:
>Geoff Howard wrote:
>
>>>>By the way, I think there are bigger security problems in cocoon...
><snip/>
>
>>Also, is cocoon-reload still enabled by default? seems a wget in a loop
>>with ?cocoon-reload=true could put a site in a world of hurt... (by the
>>way, last time I checked Jetty/Cocoon cvs is barfing on that..)
>
>
>With jetty, try http://localhost:8888?cocoon-reload=true - without '/'
>symbol. Jetty is ... different ... from other engines.
>
>
>>I've worked on the multipart file uploads because I felt the original
>>status posed security/abuse issues. It's now at a better point but I
>>think there are still some issues I'm not (at an RF level) convinced are
>>OK. IIRC the default is now to allow "in-memory" uploads only which is a
>>step better.
>
>
>Is it? With in-memory upload you can get to OutOfMemory exceptions and
>potentially corrupt cocoon instance. With file uploads, you can create
>100Mb file systems which you can fill up but you won't disturb
>functionality of the server. I don't see how in-memory uploads are more
>secure; I see them as *less* secure.
Well, in combination with the max-upload-size parameter (or whatever it's
called) I felt that better. If I can cause the request to ignore multipart
files bigger than xMB, that seems to mitigate the risk. But that's worth
some discussion. My worry with autosaving all files is 1) I can purposely
fill up your hard drive, given time. 2) Could a user more clever than I
create a POST request that would cause a file to be placed somewhere other
than the upload dir?
>And, of course, best approach is no uploads at all :)
Well, you were probably half kidding/half serious. Obviously, if my
application doesn't use any uploads I should disable them in web.xml. But
right now, it's all or nothing: I either allow all users to upload _on any
page_ (if they create a form that posts to any url in cocoon's space), or I
totally disallow uploads. I've been thinking through enabling configs for
resource-based, or even authentication-based restrictions for
uploads. What would others think?
Geoff
Re: cocoon-view as possible security problem?
Posted by Vadim Gritsenko <va...@verizon.net>.
Geoff Howard wrote:
>>> By the way, I think there are bigger security problems in cocoon...
>>
<snip/>
> Also, is cocoon-reload still enabled by default? seems a wget in a
> loop with ?cocoon-reload=true could put a site in a world of hurt...
> (by the way, last time I checked Jetty/Cocoon cvs is barfing on that..)
With jetty, try http://localhost:8888?cocoon-reload=true - without '/'
symbol. Jetty is ... different ... from other engines.
> I've worked on the multipart file uploads because I felt the original
> status posed security/abuse issues. It's now at a better point but I
> think there are still some issues I'm not (at an RF level) convinced
> are OK. IIRC the default is now to allow "in-memory" uploads only
> which is a step better.
Is it? With in-memory upload you can get to OutOfMemory exceptions and
potentially corrupt cocoon instance. With file uploads, you can create
100Mb file systems which you can fill up but you won't disturb
functionality of the server. I don't see how in-memory uploads are more
secure; I see them as *less* secure.
And, of course, best approach is no uploads at all :)
<snip/>
> One I'd really like to look into is places where directory traversal
> could be successful, depending on your matchers.
That's might be real security issue.
Vadim
Re: cocoon-view as possible security problem?
Posted by Steven Noels <st...@outerthought.org>.
On 21/03/2003 13:57 Geoff Howard wrote:
> OK, gotta get back to work - I'm in the middle of a launch.
Be careful, rockets are nasty things these days.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: cocoon-view as possible security problem?
Posted by Vadim Gritsenko <va...@verizon.net>.
Steven Noels wrote:
> On 21/03/2003 13:57 Geoff Howard wrote:
>
>> Also, is cocoon-reload still enabled by default? seems a wget in a
>> loop with ?cocoon-reload=true could put a site in a world of hurt...
>> (by the way, last time I checked Jetty/Cocoon cvs is barfing on that..)
>
>
> ... and from the difference in speed between
> http://dir.salon.com/?cocoon-reload=true and http://dir.salon.com/, I
> assume this might be the case here.
Hm.. Is allow-reload-ip config parameter a thing worth to have? Or maybe
somebody has better suggestions?
Vadim
Re: cocoon-view as possible security problem?
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Steven Noels" <st...@outerthought.org> wrote:
> On 21/03/2003 13:57 Geoff Howard wrote:
>
>> Also, is cocoon-reload still enabled by default? seems a wget in a loop
>> with ?cocoon-reload=true could put a site in a world of hurt... (by the
>> way, last time I checked Jetty/Cocoon cvs is barfing on that..)
>
> ... and from the difference in speed between
> http://dir.salon.com/?cocoon-reload=true and http://dir.salon.com/, I
> assume this might be the case here.
Someone _should_ write to webmaster@dir.salon.com :-) I'm not sure they want
to have their content delivered in XML without the banner-ads or their site
reloaded by random folks :-)
Pier
Re: cocoon-view as possible security problem?
Posted by Steven Noels <st...@outerthought.org>.
On 21/03/2003 13:57 Geoff Howard wrote:
> Also, is cocoon-reload still enabled by default? seems a wget in a loop
> with ?cocoon-reload=true could put a site in a world of hurt... (by the
> way, last time I checked Jetty/Cocoon cvs is barfing on that..)
... and from the difference in speed between
http://dir.salon.com/?cocoon-reload=true and http://dir.salon.com/, I
assume this might be the case here.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: cocoon-view as possible security problem?
Posted by Geoff Howard <co...@leverageweb.com>.
At 07:39 AM 3/21/2003, you wrote:
>>By the way, I think there are bigger security problems in cocoon...
>
>Don't be shy and speak out loud :)
>What do have you in mind exactly?
>--
>Torsten
Sorry - wasn't being shy, just trying to be quick and didn't have time to
get fully into that fully right now (nor to fix what I mention ATM). For
starters though there's this:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14286 (SQL injection in
DatabaseAuthenicatorAction )
Also, is cocoon-reload still enabled by default? seems a wget in a loop
with ?cocoon-reload=true could put a site in a world of hurt... (by the
way, last time I checked Jetty/Cocoon cvs is barfing on that..)
I've worked on the multipart file uploads because I felt the original
status posed security/abuse issues. It's now at a better point but I think
there are still some issues I'm not (at an RF level) convinced are
OK. IIRC the default is now to allow "in-memory" uploads only which is a
step better.
I also should have said security "questions" at this stage, because I
haven't had time to really dig into the nagging questions I've had in some
areas. I'll do so and get back.
One I'd really like to look into is places where directory traversal could
be successful, depending on your matchers.
OK, gotta get back to work - I'm in the middle of a launch.
Geoff
Re: cocoon-view as possible security problem?
Posted by Torsten Curdt <tc...@dff.st>.
> By the way, I think there are bigger security problems in cocoon...
Don't be shy and speak out loud :)
What do have you in mind exactly?
--
Torsten
Re: cocoon-view as possible security problem?
Posted by Stefano Mazzocchi <st...@apache.org>.
Geoff Howard wrote:
> By the way, I think there are bigger security problems in cocoon...
Like what? (not being arrogant or defensive, just curious... damn email
communication sometimes coveys the wrong tone)
Stefano.
Re: cocoon-view as possible security problem?
Posted by Tony Collen <tc...@neuagency.com>.
On Fri, 21 Mar 2003, Geoff Howard wrote:
<multiple-snippage/>
> >>So, at the end, I would do:
> >>
> >>1) turn off views from the default sitemap. NOTE: this will turn off the
> >>ability to make static snapshots of your webapp from the cocoon CLI!
Well, this is obviously not good for us... so...
> >>2) write a pretty detailed comment in the default sitemap telling what
> >>views are, how they work briefly and what potential security issues do
> >>they make.
This is probably the best idea. I would *really* hope someone who is
deploying Cocoon in a production environment would at least be able to
read the sitemap in this spot :^)
> >>3) keep the view parameter name hardcoded as it is.
> >>
> >>Thoughts? anybody against this?
In retrospect, my idea for being able to change the parameters was not a
good idea... and it would add unneeded complexity to everything. #2 is
the best (and easiest) IMO.
Tony
Re: cocoon-view as possible security problem?
Posted by Tony Collen <tc...@neuagency.com>.
On Fri, 21 Mar 2003, Geoff Howard wrote:
<multiple-snippage/>
> >>So, at the end, I would do:
> >>
> >>1) turn off views from the default sitemap. NOTE: this will turn off the
> >>ability to make static snapshots of your webapp from the cocoon CLI!
Well, this is obviously not good for us... so...
> >>2) write a pretty detailed comment in the default sitemap telling what
> >>views are, how they work briefly and what potential security issues do
> >>they make.
This is probably the best idea. I would *really* hope someone who is
deploying Cocoon in a production environment would at least be able to
read the sitemap in this spot :^)
> >>3) keep the view parameter name hardcoded as it is.
> >>
> >>Thoughts? anybody against this?
In retrospect, my idea for being able to change the parameters was not a
good idea... and it would add unneeded complexity to everything. #2 is
the best (and easiest) IMO.
Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: cocoon-view as possible security problem?
Posted by Geoff Howard <co...@leverageweb.com>.
At 03:19 AM 3/21/2003, you wrote:
>Stefano Mazzocchi wrote:
>
>>Tony Collen wrote:
>>
>>>Browsing the livesites, on a whim I tried this URL:
>>>
>>>http://dir.salon.com/?cocoon-view=content
>>>
>>>and it worked! Obviously someone deploying Cocoon should be aware that
>>>this view is "on" by default, and may reveal data in your page you might
>>>not want. I have yet to see "bad" data get exposed, but there's always
>>>the possibility.
>>
>>
>>Well, the cocoon "view" was designed to be a standard way for external
>>crawlers or spiders to gather 'semantically meaningful' data from URLs
>>served by cocoon.
>>
>>yes, there is the possibility of bad data exposed.
>>
<snip/>
>>So, at the end, I would do:
>>
>>1) turn off views from the default sitemap. NOTE: this will turn off the
>>ability to make static snapshots of your webapp from the cocoon CLI!
>>
>>2) write a pretty detailed comment in the default sitemap telling what
>>views are, how they work briefly and what potential security issues do
>>they make.
>>
>>3) keep the view parameter name hardcoded as it is.
>>
>>Thoughts? anybody against this?
>
>
>What about simply adding an IP matcher in the view that would restrict
>access to the view to a reserved set of clients (localhost by default),
>and direct others to a nice page, or simply a 404 error ? This would leave
>the door open to local debugging and crawnling, and would firmly close it
>to remote "attacks".
I don't see any need for #1 because
- isn't it used by a lot of samples?
- it gives the impression that they are not meant to be public and normally
expose dangerous data (which they don't - probably)
If the warning is there, and information/ability is provided on
strategies to secure views (like Sylvain's good suggestion) that's enough IHMO.
By the way, I think there are bigger security problems in cocoon...
Geoff
Re: cocoon-view as possible security problem?
Posted by Geoff Howard <co...@leverageweb.com>.
At 03:19 AM 3/21/2003, you wrote:
>Stefano Mazzocchi wrote:
>
>>Tony Collen wrote:
>>
>>>Browsing the livesites, on a whim I tried this URL:
>>>
>>>http://dir.salon.com/?cocoon-view=content
>>>
>>>and it worked! Obviously someone deploying Cocoon should be aware that
>>>this view is "on" by default, and may reveal data in your page you might
>>>not want. I have yet to see "bad" data get exposed, but there's always
>>>the possibility.
>>
>>
>>Well, the cocoon "view" was designed to be a standard way for external
>>crawlers or spiders to gather 'semantically meaningful' data from URLs
>>served by cocoon.
>>
>>yes, there is the possibility of bad data exposed.
>>
<snip/>
>>So, at the end, I would do:
>>
>>1) turn off views from the default sitemap. NOTE: this will turn off the
>>ability to make static snapshots of your webapp from the cocoon CLI!
>>
>>2) write a pretty detailed comment in the default sitemap telling what
>>views are, how they work briefly and what potential security issues do
>>they make.
>>
>>3) keep the view parameter name hardcoded as it is.
>>
>>Thoughts? anybody against this?
>
>
>What about simply adding an IP matcher in the view that would restrict
>access to the view to a reserved set of clients (localhost by default),
>and direct others to a nice page, or simply a 404 error ? This would leave
>the door open to local debugging and crawnling, and would firmly close it
>to remote "attacks".
I don't see any need for #1 because
- isn't it used by a lot of samples?
- it gives the impression that they are not meant to be public and normally
expose dangerous data (which they don't - probably)
If the warning is there, and information/ability is provided on
strategies to secure views (like Sylvain's good suggestion) that's enough IHMO.
By the way, I think there are bigger security problems in cocoon...
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: cocoon-view as possible security problem?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
> Tony Collen wrote:
>
>> Browsing the livesites, on a whim I tried this URL:
>>
>> http://dir.salon.com/?cocoon-view=content
>>
>> and it worked! Obviously someone deploying Cocoon should be aware that
>> this view is "on" by default, and may reveal data in your page you might
>> not want. I have yet to see "bad" data get exposed, but there's always
>> the possibility.
>
>
> Well, the cocoon "view" was designed to be a standard way for external
> crawlers or spiders to gather 'semantically meaningful' data from URLs
> served by cocoon.
>
> yes, there is the possibility of bad data exposed.
>
>> Do we want the views turned off by default, and have a message in the
>> sitemap about enabling the views? Would it make more sense to have
>> thename of the "cocoon-view" parameter be able to be changed via
>> configuration? Say I wanted the parameter to be my-view instead of
>> cocoon-view. Security through obscurity?
>
>
> Ok, some thoughts:
>
> 1) security thru obscurity is bad habit and we should avoid this.
>
> 2) views do not cause a security problem for someone that *knows* what
> views are and why they are there
>
> 3) but I agree that not many do.
>
> 4) if we make that parameter configurable, the *WHOLE* point of having
> views disappears since crawlers don't have a way to tell how to ask
> for a specific view.
>
> NOTE: a crawler should be allowed to ask for a specific view setting
> an HTTP header in the request. The use of the 'cocoon-view' parameter
> is a hack. We are aware of this. It's a hack because no browser allows
> you to set the http headers directly, nor there is a portable way to
> do this via javascript. Since views are useful for debugging, we
> allowed this way of asking for views.
>
> So, at the end, I would do:
>
> 1) turn off views from the default sitemap. NOTE: this will turn off
> the ability to make static snapshots of your webapp from the cocoon CLI!
>
> 2) write a pretty detailed comment in the default sitemap telling what
> views are, how they work briefly and what potential security issues do
> they make.
>
> 3) keep the view parameter name hardcoded as it is.
>
> Thoughts? anybody against this?
What about simply adding an IP matcher in the view that would restrict
access to the view to a reserved set of clients (localhost by default),
and direct others to a nice page, or simply a 404 error ? This would
leave the door open to local debugging and crawnling, and would firmly
close it to remote "attacks".
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: cocoon-view as possible security problem?
Posted by Stefano Mazzocchi <st...@apache.org>.
Tony Collen wrote:
> Browsing the livesites, on a whim I tried this URL:
>
> http://dir.salon.com/?cocoon-view=content
>
> and it worked! Obviously someone deploying Cocoon should be aware that
> this view is "on" by default, and may reveal data in your page you might
> not want. I have yet to see "bad" data get exposed, but there's always
> the possibility.
Well, the cocoon "view" was designed to be a standard way for external
crawlers or spiders to gather 'semantically meaningful' data from URLs
served by cocoon.
yes, there is the possibility of bad data exposed.
> Do we want the views turned off by default, and have a message in the
> sitemap about enabling the views? Would it make more sense to have
> thename of the "cocoon-view" parameter be able to be changed via
> configuration? Say I wanted the parameter to be my-view instead of
> cocoon-view. Security through obscurity?
Ok, some thoughts:
1) security thru obscurity is bad habit and we should avoid this.
2) views do not cause a security problem for someone that *knows* what
views are and why they are there
3) but I agree that not many do.
4) if we make that parameter configurable, the *WHOLE* point of having
views disappears since crawlers don't have a way to tell how to ask for
a specific view.
NOTE: a crawler should be allowed to ask for a specific view setting an
HTTP header in the request. The use of the 'cocoon-view' parameter is a
hack. We are aware of this. It's a hack because no browser allows you to
set the http headers directly, nor there is a portable way to do this
via javascript. Since views are useful for debugging, we allowed this
way of asking for views.
So, at the end, I would do:
1) turn off views from the default sitemap. NOTE: this will turn off the
ability to make static snapshots of your webapp from the cocoon CLI!
2) write a pretty detailed comment in the default sitemap telling what
views are, how they work briefly and what potential security issues do
they make.
3) keep the view parameter name hardcoded as it is.
Thoughts? anybody against this?
Stefano.