Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4FDA6456.5010904@ice-sa.com>
Date: Fri, 15 Jun 2012 00:23:18 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: URL Rewriting
References: <4FD80726.5050408@poonam.org> <4FD85463.1060608@ice-sa.com>
 <4FD8D80A.4040704@poonam.org>
In-Reply-To: <4FD8D80A.4040704@poonam.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kiran Badi wrote:
> Please inline for my answers Andre.
> 
> Kiran,
>>
>> Why does that "id=17" visible in the URL bother you ?
>> Is it because of some security aspect ? (that the user could change 
>> it, and get something else than what they should be getting ?)
> Thanks for reminding this aspect.I was not checking for empty resultset 
> in my code.Fixed that one now.:)
>>
>> 1) If that is the case, then the basic logic of your application is 
>> flawed.  If this is information that really needs to be sent by the 
>> browser to the server, then the browser must have that information. 
>> And if that information originally comes from the server and is sent 
>> to the browser, then there is /nothing/ that you can do to block some 
>> user from playing around with it, before sending it back to the server.
>> If you do not want the user to be able to play around with some 
>> information, then don't send it to him in the first place. O
> Ok let me share the way I wrote this piece,
> 
> href="<%=request.getContextPath()%>/getmyservice.do?id=${myid}"> , this 
> is link basically where I append the id(id comes from DB) send this to 
> the servlet and it the pulls the records from db for corresponding id 
> and then sends it back again to JSP for display.But I am not able to 
> figure out as why I not getting the url of jsp something like
> 
> http://localhost:8080/ourstory/myiddata.jsp
> 
> .So thought that let me try to rewrite the url in case if its possible.
>>
>> 2) if the browser /must/ send some information to the server as part 
>> of the URL, then there is /nothing/ that can be done on the server 
>> side, to stop the browser showing this information in the URL bar.
>>
>> To illustrate this :
>> - imagine that the server sends a page to the browser, and this page 
>> contains a link like :
>> <a 
>> href="http://localhost:8080/mysite/getmyservice.do?id=my-very-secret-information">click 
>> here</a>
>>
>> Then the user, just by moving his mouse above "click here", sees the 
>> content of that link at the bottom of his screen, in the status bar, 
>> right ?
>> And the user can right-click on "click here", and choose "copy link 
>> location".
>> And then the user can open another browser window, and paste this URL 
>> in the URL bar.
>> And then the user can modify this link before hitting the return 
>> button, so that the link now looks like
>> http://localhost:8080/mysite/getmyservice.do?id=some-other-information
>> right ?
>> And all this happens in the browser, /before/ the server even sees 
>> this browser request.
>> So what could the server do ?
> This is interesting information,how about sending the info as POST 
> rather than Get.Not sure if I can convert clicking of the link from get 
> from post.but I will try.But again the place where I am displaying the 
> generating the links, is not within form, they just hyperlinks with id 
> appended to it.
> 
> Now I know both get/post can be broken if one wants it,thats all 
> together is different case,but for now I need tidy and clean url with no 
> id appended to it.
> 
> Does my requirement makes sense ?
> 

Since you ask it that way, the answer would be no.

Step 1 : the browser contacts the server via a request with some URL (doesn't really mater 
which one at this stage, but in this first step there is no "id" yet).

Step 2 : the server does something with that request, and returns some response to the 
browser.  In this response, somewhere, the "id" to use in step 3 must be mentioned, or 
some other way to retrieve the id.

Step 3 : the browser sends another request to the server, in which this "id" parameter 
must be included (or some other way for the server to retrieve the correct id).

Step 4 : the server receives this second request, retrieves the id, and does something 
useful with it.

Now, at step 3, if the browser must include this "id" value in the request, it must 
include it somewhere.  This "somewhere" can be :

a) in the URL of a hyperlink.  In that case, the user will see the id parameter in the 
hyperlink, and in the browser URL bar when the user clicks the hyperlink.

b) in the body of the request. In this case, the user would not see the id parameter in 
the URL at step 3.  But it also means that the request in step 3 must be a POST request.
That is typically done with a
<form method="POST" action="/the/url/to/which/this/is/posted">
...
<input type="hidden" name="id" value="my-id-value" />
...
</form>

You cannot do that with a simple hyperlink. Clicking a hyperlink sends a GET request, not 
a POST request. And GET requests do not have a body.
It also means that the server, at step 2, must compose and send this html page to the 
browser, with the <form> in it, and the hidden "id" parameter.
It also means that the user can, after step 2, do a "view page source", and see the hidden 
"id" value.  The user can also save this page to a disk file, edit it to change the hidden 
value, then recall this file in the browser, and press the submit button.

c) at step 2, the server could send the "id" parameter inside an encrypted cookie. At step 
3, the browser would send this cookie back to the server.  The application on the server 
then needs to retrieve this cookie (at step 4), decode it, and retrieve the "id" value 
from it.
The user could still, after step 2, play tricks with the cookie and change the "id" value, 
but it would be a lot more difficult (he would have to decrypt the cookie, extract and 
replace the id value, re-encrypt the cookie properly, and arrange to send it back to the 
server), at step 3.
If the encryption is well done, the server would detect that the value of "id" has been 
modified.

d) the server never sends the "id" value to the browser, thus preventing the user to play 
tricks with it.  To achieve this, at step 2 the server would create a session, and store 
the id value in that session (on the server side). Then still at step 2 it would send back 
to the browser a pointer to this session (for example, a JSESSIONID cookie). At step 3 the 
browser would send back this session pointer to the server, the server would retrieve the 
session, including the saved "id" value.

e) there may be more esoteric ways of having the browser send back the id to the server, 
involving javascript functions on the browser side. But for that, the browser has to 
receive the id from the server at some point.  And that always means that it is insecure, 
because no matter which way this is done, once the browser has it, the user can always 
find a way to play with it.  The browser is under the full control of the user (and what 
looks to the server as a browser, may not even be a browser at all. Think of wget for 
example).

(d) is the most secure method, and it is also the easiest to implement, because Tomcat 
already has all the mechanisms in place to create and store and retrieve sessions data. 
And it can work with a simple hyperlink.
(c) is as secure as the cookie encryption/decryption method is secure.  It can also work 
with a simple hyperlink. But it is a lot more complicated to set up.
(a) is what you do not want
(b) is moderately complex, and not secure

To be complete, I should add that there exists a method (e), which (at step 2) involves 
creating a pair of quantum-entangled photons on the server side, and sending one of them 
to the browser. The browser would send back this photon to the server at step 3 (without 
having looked at it), and the server would then match it up with its twin, to retrieve the 
appropriate id.  This requires a special extension to websockets, thus at least Tomcat 7.
Unfortunately, the details of this method are still classified and OT on this list.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org