Forum Moderators: phranque
For a customer to order products from our web-page, they must first log in. Their username and password is checked against the database, and if they match a session variable is created, session("C"), which holds the customer's ID number. When they add products to their order, a check is done to see that session("C") exists and is a valid customer number, and the information is then added to the database.
When the customer has finished adding products to their order, they click on a link which takes them to a secure page with a form where they can enter their payment details. The results of this form are then emailed to us, with their payment details and order number.
I have not yet put this system in place, but I am planning on very soon, unless there are any glaring security issues with this method?
Thanks for any help
2) I'd ensure that your database is not inside the web root since it shouldn't need to be for one, but also if its outside the web root and I want to gain access to it you're going to make me work a whole heap harder to actually get to it.
3) I'd check that your login system was not vulnerable to SQL injection as if it is then it is potentially quite easy to login as any user or just mess with the database.
- Tony
1) The biggie for me would be "The results of this form are then emailed to us, with their payment details and order number.", so correct me where I go wrong but the user inputs data over SSL and then you send that data via simple email over the internet / intranet to yourselves? (Where world+dog could intercept it).
What if I encrypt the email? or should I put this in the database?
2) I'd ensure that your database is not inside the web root since it shouldn't need to be for one, but also if its outside the web root and I want to gain access to it you're going to make me work a whole heap harder to actually get to it.
The database resides in a directory which has has no access. At the moment I am connecting to the database as a file data source, does creating a dsn and accessing it via that have any (dis)advantage? Is it possible to work with an encrypted database?
My other plan was to store the credit card information in the database, then use some forms in a secure subweb to retrieve and delete the information. But I don't like the idea of the credit card numbers lingering, when we have the ability to monitor the email inbox 24-7. Can the emails be encrypted?
3) I'd check that your login system was not vulnerable to SQL injection as if it is then it is potentially quite easy to login as any user or just mess with the database.
I had to turn to good old google for SQL injection. I will look into that. Thanks. Really ;)
One more question, is there going to be many users who will not be able to add products because they have disabled session variables, or their browser does not support them?
Again, thanks for your reply.
1) I couldn't really comment on what would make it more secure, my preference would be to keep this data in the database ensuring that only authorised people have access to it (use database encryption + password + possibly user level access).
If your staff are going to access this data over the 'net in order to view the data make sure they do it over SSL so that they aren't sending the data to themselves in plain text.
2) Moving the database outside of the webroot is really all you need (eg my host gives me a folder called db which exists below my webroot), plus possibly encryption (so the data cant be read as plaintext), a password (trivial to crack but stops rubberneckers), and possibly user-level access control (adds another physical barrier).
3) I don't have stats on what % of users deny session cookies but I can't believe its that high, not if they want to use 90% of the online stores in existance!
- Tony
Yes, Please. ;)
Your help has been excellent already, thank you. I will proceed down the path of an encrypted database. The online ordering traffic on this site I don't expect to be huge anyway, however there has been enough interest to put in place online ordering facilities.
Looking at your description of the login process again, is the session identifier in any way predictable? If it is, then someone might be able to hijack a legitimate user's session by watching to see when a connection is made, and then connecting themselves after the login has taken place, using the predicted session ID.
It probably is right now. I shall look into this also. Thanks.
Are session numbers predictable?
I've had this discussion before elsewhere and the mainstream (ASP/PHP) ones do seem to be as properly average as a computer can generate, although most people would like to see more larger lengths of key in use to make them even harder to break.
If you start seeing cookies with sequential session ids then you can start to worry.
The key thing with session id's is that they expire within a reasonably window after they cease being used so that if I'm attempting to brute force against the known part of the cookie then when I finally reach my objective that session will have expired anyway.
If you want to know more about this sort of thing I suggest [owasp.org...] which is where I started learning about this is a round-about kind of way.
(The owasp project started on the security focus mailing lists for web-application security and so I got to participate and listen to a great many discussions on these types of subjects)
As for your question about how many e-com companies email the details in plaintext I couldn't say, and I seriously doubt they'd tell you themselves.
- Tony
The reason I asked was that it wasn't clear to me from the description whether they were using PHP/ASP session keys or generating their own. I got the impression, without being certain of it, that the customer ID was being used as the session identifier. If that is the case, it's not just a matter of bad entropy, it's no entropy.
Thanks for the pointer. One can never know too much about security considerations.
Thanks again,
Dave
