NetTalk Central

NetTalk Web Server => Web Server - Ask For Help => Topic started by: Alberto on May 04, 2009, 03:37:38 AM

Title: Security Advice
Post by: Alberto on May 04, 2009, 03:37:38 AM
Hi,
Suppouse a site like ebay, in which you, and many people, register as a user and have your own profile record and other stuff.
NetTalk access a form with something like:
FormProc?REC__ID=6&Change_btn=Change...
It is very easy to realized that if you change the REC__ID=6 to another value you could access another record that may not be of your own, changing or deleting it.
In the case of a profile you even could look at another username and password.
The "user must be loggin" does not avoid it because the user wich is haking the url is a registered user too and it is logged in.

How to avoid this?
May be cheking if the record belongs to the loggedin user, may be in the same "user must be loggin" check proc?

Thanks
Alberto

Title: Re: Security Advice
Post by: Bruce on May 04, 2009, 07:57:35 AM
Hi Alberto,

these things spring to mind;

a) Use a "Guid" as a record identifier instead of a numeric - this makes it harder (but not impossible) to change other records.

b) validate, before writing a record away, that the logged in user has the right to write that record away.  You can also validate in pre-update etc to make sure the user has rights to read the record.

c) on a "wider scale" you can use the access levels built into NetTalk to limit access to specific tables, and forms etc to specific users. This doesn't address your direct question of records in the same table though.

d) log any cases where you detect this might be happening so you can remove that user from the system. After all, as you point out, this is only susceptible to an actual logged in person.

Cheers
Bruce
 
Title: Re: Security Advice
Post by: Alberto on May 06, 2009, 06:01:39 AM
Thanks Bruce,

b) validate, before writing a record away, that the logged in user has the right to write that record away.  You can also validate in pre-update etc to make sure the user has rights to read the record.

>>>Good Idea! Supposing I have a funtion to allow the view and save of a record.
How do I return from PreUpdate and PostUpdate aborting both, logging out the user and returning to the login page?

Title: Re: Security Advice
Post by: Bruce on May 06, 2009, 06:41:19 AM
log out the user using the normal method;
p_web.SetSessionLoggedIn(0)

you can suppress the file action by setting ans=0 or loc:invalid etc.

Not sure how easy it is to drive them to another page (ie the login page) though.

Oh - perhaps by setting the retry local variable.

** I'm being vague here, so that you are encouraged to go and look at the generated code, and see what it does if a field is invalid - you'll do the same sort of thing. **

Cheers
Bruce
Title: Re: Security Advice
Post by: Alberto on May 06, 2009, 11:39:03 AM
Ok Bruce,
I was investigating and I found the _Only Serve IF_ option of the form advanced tab usefull for this porpouse.
The code that option adds is something like:

IF condition
   RETURN -3
END

The problem is that my condition is based on a field of the form like:

VerCliUser(DAT:ID_MAIN_CLINIC,p_web.gsv('login_id')) = true

I´ve tried to move the code to the Preupdate point, the field has value but it does not returns.

How and where can I move the code for the page not to be server depending on the value of a field?

Thanks
Alberto






Title: Re: Security Advice
Post by: Bruce on May 06, 2009, 10:19:27 PM
Shouldn't this expression be;

VerCliUser(p_web.gsv('DAT:ID_MAIN_CLINIC'),p_web.gsv('login_id')) = true

?

Cheers
Bruce
Title: Re: Security Advice
Post by: Bruce on May 06, 2009, 10:20:46 PM
ie you can use this form of the expression in the template.

your VerCliUser function should handle the case where p_web.gsv('DAT:ID_MAIN_CLINIC')
is 0 - ie where you are inserting a record.

Cheers
Bruce
Title: Re: Security Advice
Post by: Alberto on May 07, 2009, 02:05:46 AM
Bruce,

The problem to solve is only in the case of a Change or delete.

p_web.gsv('DAT:ID_MAIN_CLINIC') or DAT:ID_MAIN_CLINIC
are always 0 (zero) where the template adds the code (precedure setup)
Is there a way to get this value in the procedure setup, before the code?

If you move the code to PreUpdate, both have the correct value but the form does not return with RETURN -3

Thanks
Alberto
Title: Re: Security Advice
Post by: Alberto on May 07, 2009, 12:43:41 PM
Bruce,

Testing a lot I realized that the only field with value before the IF condition is DAT:ID, then I fetch the record and all worked ok.

The field I ned to test is DAT:ID_MAIN_CLINIC, this field is in the browse hotfield tab but it is not available in the Procedure Setup of the form.
Is this correct?

You told me not to put code in the Procedure Setup but... no way... any other idea?
Title: Re: Security Advice
Post by: Alberto on May 07, 2009, 01:16:31 PM
Nop, DAT:Id has no value too, discard my last post, no solution yet, read my previous.

Thanks
Alberto
Title: Re: Security Advice
Post by: Alberto on May 19, 2009, 07:53:00 AM
Recapitulating....

I´m trying to use  _Only Serve IF_ in a form (change and delete) depending on a field value.

I´ve tried with p_web.gsv() but none field has value.

How to doit?
Thanks
Alberto
Title: Re: Security Advice
Post by: Bruce on May 19, 2009, 10:56:35 PM
Hi Alberto,

I think you need to modify an example and post it here to show the effect you are looking for. I expect you have the right technique, you're just missing some crucial point.

Cheers
Bruce
Title: Re: Security Advice
Post by: Alberto on May 20, 2009, 03:42:51 AM
Hi Bruce,
I've modify the web1.app example.
Suppouse you need to serve the form only if the MailboxLimit is greater than 1.
I've set the _Only Serve If_ to MAI:MailboxLimit>1 or p_web.gsv('MAI:MailboxLimit')>1
and the form is never served.
Example attached.

Thanks
Alberto

[attachment deleted by admin]
Title: Re: Security Advice
Post by: Bruce on May 21, 2009, 12:19:34 AM
Hi Alberto,

Your condition presupposes that the form-record has been "loaded" into the session Queue.
But It can't load the record because the form is blocked.

So either the record needs to be loaded into the session queue in the browse (when row clicked & when browse opens) or your test in the form needs to be a tad more sophisticated.

Cheers
Bruce

Title: Re: Security Advice
Post by: Alberto on May 22, 2009, 07:11:59 AM
Ok,

It works ok with the _View Only Mode IF_
Is there any way to exit the form generation at this level??

Thanks
Alberto
Title: Re: Security Advice
Post by: Bruce on May 24, 2009, 09:42:26 PM
Right click, goto Source,
then look for your statement
then add whatever you like.

Be aware that the form does a log more than just Generate Form.
If you put your test this late you may allow a malicious user
access to the reset of the form functionality.

Cheers
Bruce