Forums Register Login

Mapping servlet links with session bound random values

+Pie Number of slices to send: Send
Hi Guys,

Here I am again, full of question marks about this specific issue bugging me. First of all, this is my first web project, so the concepts bound to this kind of
applications are all new to me which in turn make it possible for me to ask a very obvious question in terms of the answer to experienced eyes. But this
is the way to learn. Anyway my question is:

I am using direct links on my pages to some actions like edit, delete customer records and etc. I am very sensitive to protection of personal data, so even
the first names are encrypted, and being in a security kind of mindset, having my database key values exposed to users makes me worry.

What I mean is, here may be an example of an edit link : servlet/fslcs?flecID=2886&deraid=1232

In this example we expose ( I mean I expose and lots of the sites I have been examining expose) the internals of our storage, it may be not a big issue,
but having the internal key values exposed to the end user makes me really worry not that I can think of an attack but the possibility may be there .

So what I am thinking is generating random values, bound these values to real internal ids, and store them in a session object to remap and get the real
values to work on, so there can be no replay, or may be substitute attacks possible since every session will have new mappings.

More clearly, I am saying that instead of putting servlet/fslcs?flecID=2886&deraid=1232 as an action link to a servlet on a page, what about putting
servlet/fslcs?flecID=!@ssdq@@&deraid=454dfed! and map !@ssdq@@ to 2886 and 454dfed! to 1232 in session to protect real keys.

Is it a feasible, good enough approach or what I really wonder is that is it the way you guys implement such protections?

Thank you for your time for reading yet another boring post : )
+Pie Number of slices to send: Send
Sure, it's feasible, and trivial to implement, and I'm sure there are sites that do this.

Is it necessary? Meh. Normally the DB wouldn't be exposed externally, so having an ID alone shouldn't be enough to give anybody an entrance into system internals. You'd still have to build in access protection, to guard against intentional, and unintentional, request value manipulation, errors, etc.--knowing someone's ID should never be enough for a user with insufficient privileges to do or see something they shouldn't be able to.
+Pie Number of slices to send: Send
 

David Newton wrote:Sure, it's feasible, and trivial to implement, and I'm sure there are sites that do this.

Is it necessary? Meh. Normally the DB wouldn't be exposed externally, so having an ID alone shouldn't be enough to give anybody an entrance into system internals. You'd still have to build in access protection, to guard against intentional, and unintentional, request value manipulation, errors, etc.--knowing someone's ID should never be enough for a user with insufficient privileges to do or see something they shouldn't be able to.



Thank you for your quick reply David,

Yeah, that is what I think, I mean I can't think of a way to attack but as I said that does not mean somebody else can't think or actually can use
that information as an additional help to launch an evil, genius attack, external or internal : )

I am thinking to implement such an additional layer to customer's account pages only, where he has ability to reach/add/edit/delete his/her personal info along with
his/her Credit Card and other kind of Payment Cards. And before raising all the alarms ( keyword storing CC Info) , I am following PCI Data Security Standards and
planning and hoping! to go through an audit at the end .

My point is when the project is built around such good practices, why not extend these precautions especially if these precautions are easy/trivial to implement.

Thank again for your valuable input and your time.
+Pie Number of slices to send: Send
Like David mentioned, you should also make sure that the application is properly handling the request parameters. Because JDBC only allows for a single SQL statement to be executed at a time, I don't know how big of an issue this is for Java, but you should still be careful.

For example, if you are directly putting the parameters from the request in a SQL query string, then this allows a malicious attacker to insert his own SQL code. Suppose the value of the "id" parameter was "1; DELETE FROM table;":


With this code, you would get two SQL statments, the last of which would delete everything from the table!

Again, I believe JDBC throws an exception in this case because you are trying to run two statements in a single statement, but still, in situations where you are building a SQL query based on the client's input, you should use a PreparedStatement:

+Pie Number of slices to send: Send
 

Michael Angstadt wrote:Like David mentioned, you should also make sure that the application is properly handling the request parameters.


No, I wasn't referring to SQL injection; didn't really seem related to the original question.
+Pie Number of slices to send: Send
There are of course many elements involved in what makes a site, or application secure, and yet I raised a question about one them.
Thanks again for valuable inputs, it is really important to get feedback about what one's think about a proposed solution to a specific problem
especially when experience is the problem ( and that is me).

And thanks Michael for the prepared statement pointer.

I am already using prepared statements both for performance and security issues ( clearly SQL injections). I opened another thread some time ago again in these
forum pages about it, but the best practice I have discovered is combined with, if you guys are familiar with design patterns, Data Access Object pattern, combined
with Data Transfer Object Pattern to carry in and out information and in this case powered with prepared statements, and also Factory Pattern to power up the thing
in a way that it can work with multiple database products ( MSSQL for now, but who knows future, Oracle, MySQL, etc is supported with this pattern), I also put Facade
pattern at the top to simply the API and for now, it looks like a clean job ( not yet managed to mess it) .

I consider my question resolved, happy weekend to all.
+Pie Number of slices to send: Send
 

David Newton wrote:No, I wasn't referring to SQL injection; didn't really seem related to the original question.


Oh ok, sorry to have misinterpreted . That's just the first thing that came to my mind when I heard "request value manipulation".

Also, "encrypting" the request parameters like this would make it hard for the user to bookmark those pages because the parameters are encrypted differently every session. But it sounds like the pages you are talking about typically wouldn't be bookmarked by the user (pages for editing specific entries).

Anywho, good luck!
+Pie Number of slices to send: Send
Could you use post method instead?

Another thing you can do is to validate each request programatially. So you would validate your user, its session, its role, and then, execute it.

[=
+Pie Number of slices to send: Send
@Hebert: how would using a POST help?!
+Pie Number of slices to send: Send
 

David Newton wrote:@Hebert: how would using a POST help?!



The ID would not be exposed like in the link, so an amateur hacker would not be tempted to do that.
Post is idempontent.
And the concept of GET is just to get some info and not to change info (altough is just for conpcet).
+Pie Number of slices to send: Send
POST does zero for security, and you're suggesting it to somebody that wants to encrypt *all* of their parameters? I think you two are thinking about security on vastly different levels.

And no, POST is *not* idempotent; GET is (ideally)--you have the definition backwards.
+Pie Number of slices to send: Send
 

David Newton wrote:POST does zero for security, and you're suggesting it to somebody that wants to encrypt *all* of their parameters? I think you two are thinking about security on vastly different levels.

And no, POST is *not* idempotent; GET is (ideally)--you have the definition backwards.



Ops, Ideed, is not idempotent! haha, my bad.

I was think post instead get as I said, a hacker without experince would see a get link with a ID and may try something. [=

I know some people that did some hacking because of the link with ID.
+Pie Number of slices to send: Send
That's not "hacking", that's "seeing." *Hacking* requires knowledge beyond changing a number in a URL...
+Pie Number of slices to send: Send
 

David Newton wrote:That's not "hacking", that's "seeing." *Hacking* requires knowledge beyond changing a number in a URL...



Indeed. But what im saying is that you are protect some ID from eyes. From what the people are seeing. If I pass a mouse on a link and there is ID=3874837 I could try to get a link with ID=287327382. As I told you, some people tried to invade the server because they saw the ID (using knowledge to do it).
+Pie Number of slices to send: Send
I understand what you're saying, I'm just disagreeing that it's significantly more secure, and it's certainly far below the level of security the original poster is trying to achieve.
I'm a lumberjack and I'm okay, I sleep all night and work all day. Lumberjack ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1626 times.
Similar Threads
Exposing a servlet as a web service
agents as servlets
Attributes, Session and ServletContext
Head First Problem
a session problem
How do sessions really work on client side
Tomcat behind Apache with SSL terminated at firewall - share session between Tomcat connectors?
HashMap doesn't show/contain the keys!
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 03:04:54.