[FX.php List] Obscuring the recid on URL links

[Erik Andreas Cayré]

Den 29/08/2006 kl. 21.45 skrev Jonathan Schwartz:

> Now...having written this out, you might be asking....as I am also  
> asking myself right now...In Mode 2, where the user is an Admin and  
> able to view all records anyway, then what is the need to obscure  
> the recid in the first place?
>
> Honestly, I'm not sure now.  It seemed like a good idea at the time.
>
> So...maybe it is I that is confused. ;-)

Perhaps the question of trust is not only about user/admin, but also  
about the access platform.
I personally trust my admin users to not do foolish things, as I'm  
sure you do your admin users.

There is another point here which hasn't been touched upon yet:  
accessing data using a webbrowser leaves a trail to which  
unauthorised people may have access. In another post, someone noted  
that GET requests are logged by the webserver. Access to the  
webserver log can be a security issue.
The webbrowser itself has a history feature, which in many cases is  
completely ignored by the user. And rightly so: the user of a web- 
enabled application should not concern herself with security issues  
beyond keeping her access credentials private.

Choosing a security level for an application is a lot like purchasing  
an insurance policy. You have to balance the perceived threat vs the  
cost of the security measure. I've read recently of highly publicised  
thefts of laptop computers containing large databases of credit card  
numbers. Those events illustrate how security is a complex multi- 
dimensional issue. Having strong encryption on the website receiving  
CC payments was not enough to protect the credit card holders...!

Back to Jons project.
Using sessions with a login mechanism should be enough for most  
projects. The major point of using GET is as the name implies to get  
something, ie reading data. It has the advantage of being  
bookmarkable for later use. Any page on your site which should not  
display sensitive data to unauthorised users can start with a check  
to see the user is properly authorised. If not you have the user  
login first. Like this, the aforementioned trail in the browser  
history is of no concern, since it's worthless without a successful  
login.

Of course, the login mechanism itself should use only POST, and if  
you're really paranoid, you could consider using https for the login  
page, so that the credentials are not sent in clear text between the  
web browser and we server.

regards



---
Erik Andreas Cayré
Spangsbjerg Møllevej 169
DK-6705 Esbjerg Ø

Home Tel: +45 75150512
Mobile: +45 40161183

»If you can't explain it simply, you don't understand it well enough.«
-- Albert Einstein

»If you don't have time to do it right, when will you have time to do  
it over?«
-- John Wooden, basketball coach


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1856 bytes
Desc: not available
Url : http://www.iviking.org/pipermail/fx.php_list/attachments/20060829/a489b666/smime.bin