e-Commerce stuff

[Juridian]

- Web/e-Commerce Security -

Every once in a while in IRC I hear someone ask what they might need to know for setting up an e-Commerce site. Here are some basic tips about keeping your risk to a minimum. It's by no means a comprehensive list, just some stuff I threw together today when I had spare time.

1) Know your physical security. If your boxes aren't held in a safe place:
A: People can walk off with equipment (hard drives, computers, floppies, cd's, tape backups, etc).

B: People can attempt to log into your machine or use your machine if you leave it logged in.

C: People can plug their computers into your network and watch the little packets go by.

2) Know your operating system well. You need to know it well enough that you can administer the box and do routine maintenance, as well as disable any services that are not needed (to free up resources for the web server, database, etc). You need to know how to secure the boxes, disable accounts that aren't needed, install patches, etc.

3) Know your software. Basic things you need to know how to configure and use are:
A: Your web server

1: Configuring server resources - don't let them DoS your server by making your web server do too much work. Many web servers let you configure the number of hits per day to expect, script time outs, connection time outs, keep alives, the level of protection for your web applications (if it blows up will it take out the whole server, or will it die alone?), etc.

2: Do you have directory browsing turned on? It's best to have this turned off so people can't poke around. Some people don't even lock down the directories the content is in so you can write directly to them. It's best to turn off directory browsing and make a nice custom error page to replace standard server access denied error (or just redirect the user to a page they are allowed to see) and log the attempt with the users ip.

3: Have you removed any and all sample code (web sites, cgi's, etc) that came with the web server? I once found the developers kit for the site's shopping basket software hidden in a web directory...."Ooh not only can I break your site but you tell me how to do it better, how nice!" Allot of problems have been caused by admins leaving in the extra code that came with the server, just get rid of it.

4: If you use any shopping basket software that is bought, or shareware and not built by you, change the default passwords! Someone else has probably worked with that software and they are most likely going to try the default passwords out to see if they work. This also goes for your web server and your database server.

5: Configure your server. If there are directories you do not want users to see, or if there are files you do not want them to have access to, remove those privileges. Just hoping the user never finds out that the files and directories do not exist is not good enough.

6: Turn off detailed error messages. The user does NOT need to see the detailed error message from your code blowing up or the values that caused it. It's better to have code that logs the error and shows the user a nice little "We're sorry" message. Detailed error messages can give away more information about your system than the user needs.

7: Learn how to use and configure ssl. You need to get a certificate and install it. It's good to know how this works to trouble shoot problems the user may be having.

8: Learn how to configure your web logs and what they contain. It is a good idea to buy/create/shareware an app that can parse these web logs and create reports for you. With these reports you can find out about things such as: Broken pages, hack attempts, usage times, user statistics (time on site, pages hit, etc).

9: Create a custom 404 page – this can be a static page or if you really want to get complicated have it use code to log the page the user was trying to hit, the information getting sent to it, the users ip, etc. You can later use this information to troubleshoot and possibly weed out hack attempts.

B: Database Software
1: Configuring server resources - don't let them kill your set up by making your database work too hard. Also it is good to know how to properly configure your database for performance and security. Also do NOT let your web/application code talk to the database as SA. Give it a nice account with only the power it needs to do its job.

2: Know it's quirks - Did you know that the default installation of SQL Server does not encrypt the data that travels back and forth between the application/web server and the database...encryption has to be turned on explicitly. All of the little details like this are good to know.

4) Know your code.
A: HTML - Making things pretty is important if you're trying to sell people things, but here we are more concerned with making sure that all of your links that deal with user information or the checkout process are secure. Also in my opinion it is better to use form post (rather than get) because it keeps the sensitive user information (name, address, credit card info) out of the address box of the browser as well as giving them less stuff to play with (we'll get to this in a minute).

B: Script code - ASP, PHP, JSP, etc. If you're going to use this you need to at least learn how to code and how to test it.

1: If you are displaying text that the user has entered, whether it comes from a form post or a database, you need a filter function to remove any and all characters that delimit scripting languages. It's called a cross browser scripting attack.... read up on it. It is good to run a filter on data being sent to the database as well so it does not muck things up in your stored procedures, etc.

2: If you limited the text box for the user to 10 chars.... you still need to have the code on the receiving end to verify the amount of data received and handle things appropriately. The easiest way to blow up most web servers is to build your own form or simply edit theirs and send them a bit more data than they expected.

3: Verify the data itself. Verify it's type, it's size/length, anything you think you might need. I usually create a nice little utils include that holds all of my verification functions. Most of the data you deal with on the web server is strings.... which makes it easy to deal with. If you're validating a long then have a function that loops through checking each character making sure it's a char between 0-9 (or whatever is valid in your case) and returns the value to the code that needs it. If the value is too big either chop it or discard it and notify the user that they need to enter valid data (so if you only allow a user to purchase 9 of a product and 998 is submitted you can grab just the rightmost character and use that value, or simply bounce the user and tell them to submit valid data).

This also relates to the html section. If you use the get method of forms in your html all of the data will be in the querystring of the URL. You NEED to validate data that is entered this way. Users (such as myself) like to play tricks like entering code, turning your qty or category id into an alphabetic character or negative number when you were expecting a positive long value, etc. It’s in the users face all the time in the browser so they are more tempted to play with the values there to see what they can find/do.

4: Give your includes script file extensions or configure your web server so that the include files cannot be downloaded separately. Sometimes the names of include files can get out (commented out incorrectly in html, whatever) and if the web server does not process that code or block it's download then the person downloading has the ability to see how your stuff runs. This information can then be used to find other holes. Sometimes you can even find server names, ip’s, passwords, new directories to explore, code to exploit, etc.

5: If your code or basket software has a debug mode then make sure it is turned off in your production environment. Some applications give a nice little dump of their variable namespace when it throws an error. This can give the person receiving the dump the ability to see (in some cases at least) passwords, ip's, software you use, etc.

5) Other things to think about...

A: Are your passwords for the users encrypted in the database or are they held plain text? Does it matter? Where is the key for your encryption held?

B: Check and log the number of attempts made to log into a users account. You may want to set up a notification process if too many attempts are made to sign into a users account. This will help to protect from brute force password cracks.

C: Are you storing the user's credit card information? Do you really need to? Are you encrypting that information in your database? With some credit card auth schemes you do not need to store the credit card info at all or just the span. One click ordering is nice but it is also a big risk.

D: If you run your database on it's own server, trim down the number of services it runs to only those that are required. This is especially important in Windows servers, remove the web and mail servers, disable the print spooler service, etc. They just suck up resources and are more holes for people to get into.

E: Create internal reporting tools. You will probably want a report on HUGE orders so you may call the customer and verify that it is not fraud. Or a report for a large number of orders using a customer’s account over a short period of time. Or possibly a report that let’s you see all of the orders purchased/sent to high fraud areas. That and you can always just check to see how your sales are doing. J

F: Do different users have different privileges or prices? Are you verifying that user’s information often enough as they navigate your site? It’s a simple thing to change cookie information or info being posted between pages to see different prices, pages that should not be accessible or information that is not for that user. Make sure you validate the user before anything else is done on the page.


6) Some social engineering aspects
A: Users do not need to know which company you use credit card processing. The bank or the company that issued their credit card can handle everything that customer’s need. The majority of problems with user’s credit cards will be with someone having bad/old address information for them (the bank, the user entering the wrong address for the card, etc) or to remove charges or holds on funds from their card (the bank/issuer does this on their own.). If there is an issue with the card processor the bank/issuer can take it up with them.

B: Make the user identify him/her self. I’ve seen entirely too many people try to validate a customer’s identity by volunteering information and ask if that is correct. “So you are so and so and your password is this?” (This one drives me insane).

C: Users do not need to know the technical details of your site. They do not need to know what software you run and which version. All they need to know is you support their browser, use ssl between you and them, and that you take measures to protect their information (do not tell them the specifics of how, keep it general if they insist on knowing “Yes sir we encrypt your information.”).

[psychosquee]

Thank you. I will use this information well... where would I be without AO? Who knows.

[niboreon]

Good stuff!

You covered a lot of different areas that people might not think about a first go 'round.
Your organization makes this a good check list type tool.

One thing I would add is to verify that you can restore from your backups in case something gets corrupt and to know how long it'll take. If possible, test that process out on a non-production machine before it happens....it'll save a few heart-beats

[Juridian]

As Niboreon pointed out, backing up your data is VERY important. When doing e-Commerce there are a couple of types of backups you should keep.

1: Backups of your web site/application/sql code. You're going to want to have a backup of all the code for your web site (html, asp, css files, etc), the executables required to run your store, scripted out stored procedures, config files, everything you think you will need to rebuild your server as quickly as possible. Also it is a good idea to build a document that details the installation of everything so you do not forget or so someone else may do the installation if required. I highly reccomend using another server for testing and development as well as the use of a source code control application such as Visual Source Safe or CVS. That way you can keep your files together and even label the different versions to be used (you would not want to put an old file onto your live servers and break the store).

Also burn this code or the source control database (or both) to cd and keep it someplace safe just in case. Do this as you see fit, I do mine weekly at least due to the large number of changes I make every week.

2: Backups of your production (live) database. You should know how to do this from learning how to admin your database software. It is advisable to do a full backup of your database at least once a week (once a day would be better), delta's as required, and transaction logs at least every half hour. These should be stored on a separate box or at least a separate hard drive and burned to cd every day. That way if your hard drive ever kicks the bucket you have transaction logs to get you back to at least within half an hours worth of business.


3: Web logs. These are often neglected. These should also be backed up to a seperate server in case of disaster (what good will they do you if someone breaks into your web server and deletes them?). I usually do not burn copies of these, but I do import them into a database on a seperate server and build reports that can tell me my usage statistics, broken pages, hack attempts (some at least), stuff like that. Burning copies of these could be a good idea though if you ever need to use them.

The times involved mentioned above can be adjusted as needed and are there just to give you a basic idea. Also you can use whatever backup medium you prefer (tape, cd, whatever). I do reccomend that you keep copies of your production db on removable media incase of fire, earthquake, whatever (and that you keep these in a physically secure, safe area).

If you do these religiously, you should be fairly safe if a disaster occurs.

[freeOn]

Very nice and informative. You covered alot about how to make an e-commerce site moresafe.
I shall bless you with postive Anti-Points keep up the good threads. One thing I would like to add is that anything you put on the net can become hackable, it could be become hackable in 1 hour or it could be 100 years from now. The point is make sure to get patches, and updates to everything on that computer. It doesn't matter if it's a shopping cart software or an operating system. Get the patches and updates!

[intruder]

hey great info man juridian i have already copied...it ..on my disk....thanks.....for the info once again...

intruder