Andre, I am a big fan of yours with the way you explain the things in
neat way.Being a moderator/owner of some of large lists of my profession
for close to 8 years now I rarely had this kind of patience to write so
much and so neat.
BTW For the time being, I would prefer to keep this thread on hold
though point d is something I can experiment with.
Give me sometime to think about to redesign this piece of code.
On 6/15/2012 3:53 AM, André Warnier wrote:
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
