url rewriting supported?

[Simon Kitching-5]

Hi,

This email from 2006 says that "url rewriting" (ie having sessions
without cookies) is not supported by JSPWiki. Is this still true for
later releases?
   http://www.nabble.com/URL-Rewriting-to6040752.html#a6042004

Thanks,
Simon

[Andrew Jaquith-2]

Putting the session ID in the URL (which is I think what you are  
asking about) is a fairly severe security risk. Cloning the session  
becomes trivial if the URL is obtained.

I know that in certain locales (Germany, for example), it is believed  
that cookies represent an invasion of privacy. But, perversely,  
banning cookies actually decreases the overall level security for  
webapps because the session ID is now exposed in the URL. For this  
reason, the practice of adding session IDs to webapp URLs has always  
been discouraged by best-practice organizations such as OWASP.

Janne's comment from 2006, I expect, still holds. We would encourage  
anyone who wishes to eliminate cookies -- in spite of best-practice  
advice from the security community -- to write their own patches. But  
it is extremely unlikely that JSPWiki will ever incorporate a "no  
cookie" (URL rewriting) feature.

Andrew

On Jun 18, 2008, at 10:20 AM, Simon Kitching wrote:

> Hi,
>
> This email from 2006 says that "url rewriting" (ie having sessions
> without cookies) is not supported by JSPWiki. Is this still true for
> later releases?
>   http://www.nabble.com/URL-Rewriting-to6040752.html#a6042004
>
> Thanks,
> Simon
>

[Simon Kitching-5]

Hi Andrew,

Many thanks for the quick answer.

Yes I did mean encoding the session id in the url
("http://host/foo.jsp;jsessionid=123?page=Main").

We want to disable cookies in our dev environment so that we can log
into the same app multiple times from the same browser; this makes
testing some things a lot easier. Firefox shares cookies between windows
unless you go to a lot of effort (setting up separate profiles). Note
that in the setup here, there is a large existing webapp with an
embedded jspwiki engine to serve the help pages; disabling a dev/test
feature in order to support the (small) help engine feature hasn't been
terribly popular.

I'm working on enabling this in JSPWiki anyway, but won't bother
submitting the patches here.

By the way, I don't see cookies as a lot more secure. The cookie text is
also sent in plain text in both the request and response bodies. There
aren't many cases where someone can intercept the url but not the
cookies. But thanks for the reference to OWASP; I'll have a look at what
they say about that.

Regards,
Simon

Andrew Jaquith schrieb:

> Putting the session ID in the URL (which is I think what you are
> asking about) is a fairly severe security risk. Cloning the session
> becomes trivial if the URL is obtained.
>
> I know that in certain locales (Germany, for example), it is believed
> that cookies represent an invasion of privacy. But, perversely,
> banning cookies actually decreases the overall level security for
> webapps because the session ID is now exposed in the URL. For this
> reason, the practice of adding session IDs to webapp URLs has always
> been discouraged by best-practice organizations such as OWASP.
>
> Janne's comment from 2006, I expect, still holds. We would encourage
> anyone who wishes to eliminate cookies -- in spite of best-practice
> advice from the security community -- to write their own patches. But
> it is extremely unlikely that JSPWiki will ever incorporate a "no
> cookie" (URL rewriting) feature.
>
> Andrew
>
> On Jun 18, 2008, at 10:20 AM, Simon Kitching wrote:
>
>> Hi,
>>
>> This email from 2006 says that "url rewriting" (ie having sessions
>> without cookies) is not supported by JSPWiki. Is this still true for
>> later releases?
>>   http://www.nabble.com/URL-Rewriting-to6040752.html#a6042004
>>
>> Thanks,
>> Simon
>>
>

[Andrew Jaquith-2]

Simon,

That makes sense. I can see why cookies aren't the best option in your  
case.

As a work-around, have you considered using Prism? It won't be as  
clean as tabbed browsing, but you will at least get the session  
isolation you need.

Andrew

On Jun 18, 2008, at 12:22 PM, Simon Kitching <sk@...> wrote:

> Hi Andrew,
>
> Many thanks for the quick answer.
>
> Yes I did mean encoding the session id in the url
> ("http://host/foo.jsp;jsessionid=123?page=Main").
>
> We want to disable cookies in our dev environment so that we can log
> into the same app multiple times from the same browser; this makes
> testing some things a lot easier. Firefox shares cookies between  
> windows
> unless you go to a lot of effort (setting up separate profiles). Note
> that in the setup here, there is a large existing webapp with an
> embedded jspwiki engine to serve the help pages; disabling a dev/test
> feature in order to support the (small) help engine feature hasn't  
> been
> terribly popular.
>
> I'm working on enabling this in JSPWiki anyway, but won't bother
> submitting the patches here.
>
> By the way, I don't see cookies as a lot more secure. The cookie  
> text is
> also sent in plain text in both the request and response bodies. There
> aren't many cases where someone can intercept the url but not the
> cookies. But thanks for the reference to OWASP; I'll have a look at  
> what
> they say about that.
>
> Regards,
> Simon
>
> Andrew Jaquith schrieb:
>> Putting the session ID in the URL (which is I think what you are
>> asking about) is a fairly severe security risk. Cloning the session
>> becomes trivial if the URL is obtained.
>>
>> I know that in certain locales (Germany, for example), it is believed
>> that cookies represent an invasion of privacy. But, perversely,
>> banning cookies actually decreases the overall level security for
>> webapps because the session ID is now exposed in the URL. For this
>> reason, the practice of adding session IDs to webapp URLs has always
>> been discouraged by best-practice organizations such as OWASP.
>>
>> Janne's comment from 2006, I expect, still holds. We would encourage
>> anyone who wishes to eliminate cookies -- in spite of best-practice
>> advice from the security community -- to write their own patches. But
>> it is extremely unlikely that JSPWiki will ever incorporate a "no
>> cookie" (URL rewriting) feature.
>>
>> Andrew
>>
>> On Jun 18, 2008, at 10:20 AM, Simon Kitching wrote:
>>
>>> Hi,
>>>
>>> This email from 2006 says that "url rewriting" (ie having sessions
>>> without cookies) is not supported by JSPWiki. Is this still true for
>>> later releases?
>>>  http://www.nabble.com/URL-Rewriting-to6040752.html#a6042004
>>>
>>> Thanks,
>>> Simon
>>>
>>
>

[Olaf Kock]

Simon Kitching schrieb:
> By the way, I don't see cookies as a lot more secure. The cookie text is
> also sent in plain text in both the request and response bodies. There
> aren't many cases where someone can intercept the url but not the
> cookies. But thanks for the reference to OWASP; I'll have a look at what
> they say about that.

Hi,

I do get your point with the dev environment and logging in multiple
times. However, even though http transfer is the same for urls and
cookies the url may be transferred for referred images and links to
other sites as the referrer, e.g. the url of a page that a link was
clicked on.

This is hard to get around correctly and the reason for this setup to be
so unpopular securitywise.

Cheers,
Olaf

[Simon Kitching-5]

Olaf Kock schrieb:

> Simon Kitching schrieb:
>  
>> By the way, I don't see cookies as a lot more secure. The cookie text is
>> also sent in plain text in both the request and response bodies. There
>> aren't many cases where someone can intercept the url but not the
>> cookies. But thanks for the reference to OWASP; I'll have a look at what
>> they say about that.
>>    
>
> Hi,
>
> I do get your point with the dev environment and logging in multiple
> times. However, even though http transfer is the same for urls and
> cookies the url may be transferred for referred images and links to
> other sites as the referrer, e.g. the url of a page that a link was
> clicked on.
>
> This is hard to get around correctly and the reason for this setup to be
> so unpopular securitywise.
>  

That's a good point for a general-purpose wiki tool. Thanks for pointing
that out.

It's not quite so relevant for the specific use we are making of
JspWiki, and not at all an issue for development/testing. But I agree
that *most* people won't be using jspwiki the way we do.

Just for the record (in case someone else wants to do this), enabling
"url rewriting" support seems to be fairly easy. I have:
* added a servlet filter which stores the HttpServletResponse in a
thread-local
* implemented a custom URLConstructor (subclassing
DefaultURLConstructor) which overrides the makeURL method to fetch the
HttpServletResponse from that thread-local and invoke encodeURL on it.
Note that this method is also called during jspwiki startup, so a null
HttpServletResponse needs to be ignored.

I'm not sure if this approach will fix 100% of the urls that JspWiki
generates, but it is certainly enough to get things generally working in
our test environment (so far).

Regards,
Simon

[Janne Jalkanen]

>
> Just for the record (in case someone else wants to do this), enabling
> "url rewriting" support seems to be fairly easy. I have:
> * added a servlet filter which stores the HttpServletResponse in a
> thread-local
> * implemented a custom URLConstructor (subclassing
> DefaultURLConstructor) which overrides the makeURL method to fetch the
> HttpServletResponse from that thread-local and invoke encodeURL on it.
> Note that this method is also called during jspwiki startup, so a null
> HttpServletResponse needs to be ignored.
>
> I'm not sure if this approach will fix 100% of the urls that JspWiki
> generates, but it is certainly enough to get things generally  
> working in
> our test environment (so far).

This sounds fairly functional.  Can't see offhand what could possibly  
break.

/Janne

[Andrew Jaquith-2]

Simon --

I've been gently tweaking Janne from time to time about externalizing  
the URL constructors in a similar manner to what you describe,  
although the use I had in mind wasn't related to session IDs.

Something like http://tuckey.org/urlrewrite/ would do nicely, and  
would certainly allow us to implement custom URL schemes without  
having JSPWiki needing to be aware of how the URLs were made. The  
trade-off, as always, is memory and some performance.

For 3.0, this might happen, or might not.

Andrew

On Jun 19, 2008, at 3:41 AM, Simon Kitching wrote:

> Olaf Kock schrieb:
>> Simon Kitching schrieb:
>>
>>> By the way, I don't see cookies as a lot more secure. The cookie  
>>> text is
>>> also sent in plain text in both the request and response bodies.  
>>> There
>>> aren't many cases where someone can intercept the url but not the
>>> cookies. But thanks for the reference to OWASP; I'll have a look  
>>> at what
>>> they say about that.
>>>
>>
>> Hi,
>>
>> I do get your point with the dev environment and logging in multiple
>> times. However, even though http transfer is the same for urls and
>> cookies the url may be transferred for referred images and links to
>> other sites as the referrer, e.g. the url of a page that a link was
>> clicked on.
>>
>> This is hard to get around correctly and the reason for this setup  
>> to be
>> so unpopular securitywise.
>>
> That's a good point for a general-purpose wiki tool. Thanks for  
> pointing
> that out.
>
> It's not quite so relevant for the specific use we are making of
> JspWiki, and not at all an issue for development/testing. But I agree
> that *most* people won't be using jspwiki the way we do.
>
> Just for the record (in case someone else wants to do this), enabling
> "url rewriting" support seems to be fairly easy. I have:
> * added a servlet filter which stores the HttpServletResponse in a
> thread-local
> * implemented a custom URLConstructor (subclassing
> DefaultURLConstructor) which overrides the makeURL method to fetch the
> HttpServletResponse from that thread-local and invoke encodeURL on it.
> Note that this method is also called during jspwiki startup, so a null
> HttpServletResponse needs to be ignored.
>
> I'm not sure if this approach will fix 100% of the urls that JspWiki
> generates, but it is certainly enough to get things generally  
> working in
> our test environment (so far).
>
> Regards,
> Simon
>

[Janne Jalkanen]

On Jun 19, 2008, at 22:39 , Andrew Jaquith wrote:

> Simon --
>
> I've been gently tweaking Janne from time to time about  
> externalizing the URL constructors in a similar manner to what you  
> describe, although the use I had in mind wasn't related to session  
> IDs.

I'm still opposed to the idea because of the context loss involved.  
URL rewriting *after* the HTML translation is done means that e.g.  
preformatted areas would also get all of their URLs rewritten.

Though I have to admit that the current URLConstructors are kind of  
messy, so rewriting them to be clearer might be a better solution.

(Yes, it's also possible to write something like <a href="XXX-MAGIC/
Wiki.jsp"> and then rewrite those magic markers, BUT this means that  
the output from the MarkupTranslator would no longer be functional,  
which will make the life of the embedders more complicated.  I would  
much rather go through a bit of extra complexity in our code to make  
sure the developers don't have to worry about some hidden magic  
effects which are caused by complex interaction of thingamalingies  
which you "just have to know".  We've got enough of those already ;-)

/Janne