Access control on a commercial website.

[The Natural Philosopher]

This probably is NOT a javascript specific question, but I crave
indulgence, as there is a limit to how many groups one can search or
subscribe to..and this one I am sure has the right answer in the heads
of the people here.

I am doing a top level specification of a commercial website, built
arounnd Linux/Mysql/Apache/Php to perform stock control and sales order
processing with of course an online selling part for people to buy online.


I need to maintain states between forms, naturally, and in the past I
have used hidden variables passed around from frame to frame: This works
well enough if the overall administration parts of sch sites are
protected by passwords, as you can't get to the programs except by valid
logins,done wih .htaccess files etc.

However this time I need to maintain a bit more detail with some finer
controls: I need classes of users on the admin side, so I can disallow
access and indeed modify displayed administration menus on at least a
per user basis..and when processing a sales order, view the 'open' part
of the site, I need to maintain a transaction ID..what concerns me is
that this ID or indeed any other hidden variables could be spoofed.

Are cookies uncrackable? If I use cookies to maintain state, how can
they be spoofed? and so on. To issue a random ID is obviously no
problem, but where can it be stored in a users browser so they can't
modify it? Or indeed find out what it is?


I am less concerned about the session ID than possible access to the
administration areas by script kiddies. Once past any password test, the
browser to server link seems utterly insecure.

I am sure that there is a fundamental gap in my understanding of how
this is normally done. I need rapid education. Please!

 

[The Natural Philosopher]

Everything on the client side is "utterly insecure". Security has to be
managed on the server. Use Sessions and Timeouts and your chances increase.

Yes, but how?

Its all fine to use a password, but every new web page is a new
session..how can I be sure it comes from a previously logged in person,
not a random spoofer?

 

[Marc Bradshaw]

Its all fine to use a password, but every new web page is a new
session..how can I be sure it comes from a previously logged in person,
not a random spoofer?

You said you were from a PHP background. Why not just use sessions?

http://php.net/manual/en/ref.session.php

Marc

 

[Rik]

Yes, but how?

Its all fine to use a password, but every new web page is a new session..

No, it shouldn't, it should be a continued session, identified by a
suitable large random string that has got nothing to do with either the
user, his location, his rights, or any other data.

how can I be sure it comes from a previously logged in person, not a
random spoofer?

Because, on the server you have a list of sessions which _have_ identified
themselves. In PHP, I thought the 'standard' id for a session was a string
of 32 alphanumeric characters, which is somehere in the neighbourhood of
36^32 => 6.3e49 possible id's. How many id's of that do you actually
expect to be logged in at any time? Chances someone magically guesses the
id of a currently logged in user is very, very small. Brute force it may
be possible to cycle through all id's untill you got something that works
(keep in mind authenticated sessions time out, so they might be unlucky
also).

Use HTTPS, a session-cookie, a suitable fast timeout, and some mechanism
to prevent brute force attacks (count failed logins/random id's from an
address and institute a time-out comes to mind).

Session-hijacking is possible, but very rare (well, if you use HTTPS
instead of HTTP). Ask a username/password again for any major
alterations/highly classified material, and you'll be fine.

There is no '100%' security, but 99,999% is quite possible.

This has got nothing to do with javascript anymore BTW.

 

[Marc Bradshaw]

You said you were from a PHP background. Why not just use sessions?

Oops, I misread, I guess you are using sessions. But if 'every page is
a new session' you must be doing something wrong...

Marc

 

[The Natural Philosopher]

You said you were from a PHP background. Why not just use sessions?

http://php.net/manual/en/ref.session.php

Marc

Ah. First of all I am a newbie to PHP - CV is my background, so as far
as I am conmcerned php is just another interted languafe.

I didn't know such support existed, and it does half the job..it looks
like using SSL on the admin side will fix the rest..I had forgot
SSL..dos that encrypt cookies too?

 

[The Natural Philosopher]

Oops, I misread, I guess you are using sessions. But if 'every page is
a new session' you must be doing something wrong...

Marc

Marc: I am usin NOTHING yet. Oter than MS WORD to write a data
dictionary..the rest is to be specified, and finally to be written, but
that will be a mechanical exercise, turning form specs into code.

At least I won't have to write my own session code: Thats done for me it
seems. Nice.

Many hanks for the hint..I cam build on that manual page somewhat.

 

[The Natural Philosopher]

No, it shouldn't, it should be a continued session, identified by a
suitable large random string that has got nothing to do with either the
user, his location, his rights, or any other data.


Because, on the server you have a list of sessions which _have_
identified themselves. In PHP, I thought the 'standard' id for a session
was a string of 32 alphanumeric characters, which is somehere in the
neighbourhood of 36^32 => 6.3e49 possible id's. How many id's of that do
you actually expect to be logged in at any time? Chances someone
magically guesses the id of a currently logged in user is very, very
small. Brute force it may be possible to cycle through all id's untill
you got something that works (keep in mind authenticated sessions time
out, so they might be unlucky also).

Use HTTPS, a session-cookie, a suitable fast timeout, and some mechanism
to prevent brute force attacks (count failed logins/random id's from an
address and institute a time-out comes to mind).

OK, With Marcs link I had just about got there before I read your post.

You have confirmed the basic approach clearly tho, for which many thanks
are due.

Session-hijacking is possible, but very rare (well, if you use HTTPS
instead of HTTP). Ask a username/password again for any major
alterations/highly classified material, and you'll be fine.

There is no '100%' security, but 99,999% is quite possible.

This has got nothing to do with javascript anymore BTW.

Nope. I suspected i wouldn't have anyway, but rightly, I suspected
someone here would have the complete answer,so lets consider it case
closed, many thanks issued to Marc and yourself, and back to the
Mysteries of InnerHTML etc. etc.

 

[Rik]

I didn't know such support existed, and it does half the job..it looks
like using SSL on the admin side will fix the rest..I had forgot
SSL..dos that encrypt cookies too?

Yup. And let the cookies be set to only be sent over https.

 

[The Natural Philosopher]

Yup. And let the cookies be set to only be sent over https.

Okay mate!

I suspect I'll run the whole site apart from the greetings page under
SSL anyway.