JavaWorld
addict
Reged: 06/20/03
Posts: 482
|
|
Graphs for security
|
Paul Stadig
Unregistered
|
|
How is https://server.company.com/app/c?ACTION=FETCH_PERSON&ID=12939 a "sample of bad security in URLs"?
I have dealt with a customer that insisted that the primary keys of database objects not be visible in the URL. I don't see that as "bad security." One way or another, in a stateless HTTP application, the client has to tell the server on what object it wants to operate and which operation to perform. There's no way around that.
The issue basically breaks down the way storing the context for an ACG does. Session = no multiple windows. Form requests = back to the same problem of the user being able to monkey with things. With the values being hidden form fields the user may not be able to bookmark pages in a useful way.
You could encode/encrypt the pk, but the user could just replay that value. If you encode/encrypt the value with time based information, then the user could still replay (say within a certain window of time). I don't see the difference between the user clicking a button labeled "Fetch Person" that submits hidden form values and sending it in the URL (except if it was ...?SSN=123456789 or something).
This is not totally off-topic, because I consider it the job of the AC(L|G) to deny requests like ...?ACTION=DELETE_PERSON... where the current user does not have that privilege, whether the action is passed by URL or hidden form variable.
Even though it's not bad to hide as much from the user as possible, I tend to shy away from hiding information just to make myself feel like it's more secure.
Certainly there are many, many issues to consider (such as proxies caching and/or logging request strings), but there is no "good" or "bad" way to handle it security wise. It's all a matter of balancing user convenience (bookmarking; not bookmarking; etc.) versus the sensitivity of the data.
Paul Stadig
Former ITG employee
|
Efraim Berkovich
Unregistered
|
|
Hi Paul!
The problem with the URL showing what you are doing is that it is possible for the user to easily modify it and have unintended effects. For example, there is a website for a New York state agency (I won't name) which has (and may still have) this problem. The site lets you submit a URL which is supposed to give you a single record about a business. Suitably modifying the fields lets you get the full list of New York state businesses.
The point is that by allowing URLs to clearly show what you are doing, you are providing information about how to attack the system. This may or may not be useful to an attacker, but it is in general not great.
Therefore, any steps taken to guard that information will deter the attacker. Obfuscating fields and parameters is a good start.
The problem you note about hiding this data statelessly can be handled by keeping an alias table at the server. The submitted data maps to an encryption/decryption method/key on the server. So, the client-side data should be relatively unintelligible. Of course, this is breakable, but it requires a higher level of hacking sophistication than simply typing http://server.company.com/app/c?ACTION=search&ID=%.
The ACG model does not directly address these questions. Rather it seeks to add more security and other features to the application flow. It does this by keeping a context, which as you noted must be stored somewhere (client-side or server-side) and so is potentially modifiable.
--Efraim
eqberkovich@yahoo.com
|
Anonymous
Unregistered
|
|
<a href="http://www.yahoo.com">mail<a/>
http://www.yahoo.com
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
