Welcome to WebmasterWorld Guest from 54.209.227.199

Forum Moderators: phranque

Message Too Old, No Replies

Will my site be secure

using the following method

     
6:15 am on Oct 9, 2002 (gmt 0)

Preferred Member

10+ Year Member

joined:July 2, 2002
posts:529
votes: 0


I've been working on a web site for our business which will accept online payment via credit cards. I am using an Access database to store our range of products and information. I'm using a seperate Access database for holding account (name, address etc.) and order information (products, qty. etc). The order's database also contains the usernames and passwords of our customers. Our web site resides on an IIS server.

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

7:29 am on Oct 9, 2002 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 25, 2002
posts:872
votes: 0


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).

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

8:28 am on Oct 9, 2002 (gmt 0)

Preferred Member

10+ Year Member

joined:July 2, 2002
posts:529
votes: 0


Thanks for your reply, 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.

8:50 am on Oct 9, 2002 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 25, 2002
posts:872
votes: 0


What you want solutions too?! :)

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

11:49 am on Oct 9, 2002 (gmt 0)

Preferred Member

10+ Year Member

joined:July 2, 2002
posts:529
votes: 0


:What you want solutions too?!

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.

7:52 pm on Oct 9, 2002 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Sept 12, 2002
posts:885
votes: 0


Does anyone here know of any reasonably reliable numbers on how many sites that accept credit cards then e-mail your credit-card details in plain-text? I've heard of it being done often enough that I worry when I visit smallish web sites that accept credit card payment. I think this thread may be the first time I've actually seen a warning about the idiocy of the practice, though.
8:40 pm on Oct 9, 2002 (gmt 0)

Preferred Member

10+ Year Member

joined:July 16, 2001
posts:545
votes: 0


I used to do contract work for a company that did this. It was just scary. They did this for probably 4 years. I believe they finally fixed the system just recently.
10:52 pm on Oct 9, 2002 (gmt 0)

Preferred Member

10+ Year Member

joined:July 2, 2002
posts:529
votes: 0


Interestingly enough, this was what was recommended as acceptable practice, and I did have the same thoughts, which is why I came here :)
7:15 am on Oct 10, 2002 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Sept 12, 2002
posts:885
votes: 0


Dave, congrats on being smarter than your advisors. Packet sniffers are wonderful tools for network diagnostics and for learning, but they are very easy to use and can read anything traveling unencrypted on the same network segment as the machine they are running on.

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.

7:48 am on Oct 10, 2002 (gmt 0)

Preferred Member

10+ Year Member

joined:July 2, 2002
posts:529
votes: 0


:is the session identifier in any way predictable?

It probably is right now. I shall look into this also. Thanks.

7:55 am on Oct 10, 2002 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 25, 2002
posts:872
votes: 0


dingmanm,

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

5:42 pm on Oct 10, 2002 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Sept 12, 2002
posts:885
votes: 0


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.

10:53 pm on Oct 10, 2002 (gmt 0)

Preferred Member

10+ Year Member

joined:July 2, 2002
posts:529
votes: 0


Thanks for the link to owasp, the site was extremely informative and helpful. Its always good to be pointed to a trusted source of information. I am half way through the secure web app manual/pdf and I am seeing lots of places where my current system will be vulnerable. Your help has been invaluable. May lots of good things come your way.

Thanks again,
Dave

 

Join The Conversation

Moderators and Top Contributors

Hot Threads This Week

Featured Threads

Free SEO Tools

Hire Expert Members