Web Site Security: Basics for protecting your web site from unwanted modifications or hacking

November 26th, 2009

The hardest part of maintaining an online presence is securing both you and your client’s content and information. Security is a 24x7x365 process, so do not follow this check list and figure your security is good and you no longer need to check your web site(s).

Here is a checklist for helping you to secure your web-based applications and forms.

Passwords and UserID:

  1. Do not use the same password and userid for all your databases and administrator logins. Create different userids and strong passwords (8 – 20 characters), then write them down and keep them in a safe place. Password generators are great for this function. DO NOT STORE THEM ON YOUR COMPUTER OR WEB SITE!
  2. FTP. Don’t use ftp unless you have to use this protocol. It is not secure and I can assure you that your ftp password and userid will be stored somewhere on a log file. If you need to use FTP, I recommend using the protocol, then immediately changing your FTP password. You may also want to change your userid at the same time.
  3. Do not use any passwords or userids you have created outside their scope. In other words, do not use a userid or password that you are using for an administrator role for registration on another blog. Not everyone will read this post and have their web sites secure.
  4. IF YOU HAVE THE SLIGHTEST FEELING THAT YOUR USERID AND OR PASSWORD HAS BEEN COMPROMISED – CHANGE THEM!!

Applications:

  1. Research any applications you are planning to deploy to ensure the application creators are maintaining security updates.
  2. Subscribe to any security forums, so you can keep abreast of any security issues before they become a problem on your web site.
  3. Backup the application in a “presine” state along with any databases after the installation. This backup becomes your baseline, so if everything else fails you can restore to your baseline.
  4. Install security plugins first. Once the security plugins are installed, make sure they are functioning properly. Now you want to backup the database and application to create a new baseline.
  5. Change as much as possible within the application to move away from default names. An example would be with the WordPress database. Every table starts with the prefix “wp_”, so change it to something else. Remove any accounts with a userid of “admin” or “admins”. This is the account every hacker will try first. Once again, perform a backup of your database and application to create a new benchmark.
  6. Limit Frill Plugins. Everyone would love to have the latest and greatest plugins available in the application; however, every plugin you install creates another security hole. Unless you need the plugin to generate revenue, leave it out of your application. If you install a plugin, you will need to backup both the application and database.
  7. Limit access to the backend of the application. Unless the user is going to be an author and write text for your blog, then why should you enable the ability to create accounts? Remember, everyone that has a account could potentially exploit a weekness in the software.
  8. Create .htaccess files to limit directory access. .htaccess files work with apache and are a minimal way to secure a directory.
  9. Perform updates as soon as they become available. I have found the best method for performing updates is to: read what the upgrade does for your application, disable all your plugins, backup the database (separate from the upgrade backup), peform the upgrade, reenable your plugins and backup the database and application.

Databases:

  1. Give your database a unique name and password. Do not name the database the same name as your application or web site. Remember to write the database name and password down for safe keeping.  Embedded within every web-based application is the database name and password, because the web-based application needs the ability to update, delete and add new records.
  2. Change the database port number. Everyone that has ever worked with MySQL knows that port 3306 is the default port. Changing the port number will make it more difficult for the “lazy sniffer” to gather information. Or if the database is on the same server as the application, use a socket connection.
  3. Limit Roles. It is very important to limit the roles of database users the bare minimum. Say you have a web site that is displaying content from an existing database, create a new userid and password that only has the scope to issue a “SELECT” statement from the database.
  4. Backup your database on a regular schedule. MySQL backups are in plain text, so you will need to keep these backups in a secure location.
  5. Take the time to go through your database tables and look for obvious field definition problems. If a field is listed as a “date” field, them make sure it is not defined as a text field. This can open a door for SQL insertion attacks.

Web Based Forms:

  1. Only include fields you absolutely require. If you do not require a phone number, then do not place the field on a form.
  2. Limit field sizes. Do not leave the “size” attribute of any form item unset.
  3. Validate data on both the front and back ends prior to email or database insertion.
  4. Place a hidden field on the form that only web_bots will see. When this field has anything in it, then throw the email or data away.
  5. Use a simple form of CAPTCHA. Remember, CAPTCHA is only trying to limit “non human” users and should not become an obstacle for your clients. A white background with black characters should be fine. Remember, a good percentage of web-users are blue-green color blind and old users may have trouble seeing the characters to enter.
  6. Use the POST method for sending data.
  7. Provide your users with SSL (secure socket layer), so their data will travel via a secure port (441).

I hope this information will help with your security efforts. Remember, security is a 24x7x365 activity. However, by taking care of the above mentioned items you can sleep a little easier at night.

Web Form Security: Client side tips to help you secure your web forms

November 23rd, 2009

Here is a little overview of web forms and security. Understand one aspect of security: if someone wants your information they will go to any means to get that information. Security is a cat and mouse game, but you need to keep your customers in mind. Locking a form down against hackers might render the form difficult to use by your customers. The result would be lost revenue.

The first means for securing a web form is data validation. Should there be HTML characters or numbers in the first name? No. So, you want to perform validation on two sides of the process: client and server. Client side validations consists of JavaScript either within the form or on a separate “.js” page. Server side validation is performed on the server using any number of languages, with PHP and Perl being predominant. Let us examine Client Side Validation in this post.

Client Side: Within the HTML form you have the field: First Name.

First Name: <\input name="FirstName" size="20" type="text" />

The submit function will call the JavaScript validation. The scripting is placed within the form tag:

 onSubmit="return formcheck(this);"

Within the top of the page you want to actually place the JavaScript.

if (validate_required(FirstName,"Please provide your first name.")
==false)
	{FirstName.focus();return false;}

The only thing we are checking here is to make sure the first name is filled out. The HTML form will provide the length “size=20” and the JavaScript will ensure there is a value in the field.

Now, we need to examine two aspects that make this validation weak: JavaScript and HTTP Requests. The JavaScript will only work if the client has enabled JavaScript and the form is not submitted by a web_bot. Web_bots are not going to enter values into your form fields, but send them directly to email via HTTP Requests. HTTP Requests will look like this:

http://your domain name/your form name.html/?form_value_name=value.

One method for dealing with this is to insert a field in your web form that only web_bots can see. Here is an example:

 <\input id="email_2" name="email_2" type="text" />

. This web form field will remain hidden from human users, but not to web_bots. A web_bot will see it as an email field and enter an email address. You need to process this field with server side scripting.

Enjoy and I hope this helps.