Tips and Tricks for Building Secure Web Applications

This article discusses some of the things you should keep in mind when building secure web applications. We will also expose some security threats that you might not be aware of, and offer simple solutions for preventing them. Starting with an abundance of fake accounts to data corruption or application take-overs, the web is not a safe boulevard. This article tries to shed some light on the imminent dangers on the web, and help build security awareness among developers.

Web application vulnerabilities and how to prevent them

When building a web application, no matter the goal, there are several common vulnerabilities of which you must be aware. Their risk levels range from simply getting an unauthorized user account to data corruption or even destroying the web application.

Top 3 Vulnerabilities

The most common mistakes resulting in vulnerable web applications are:

1. Unvalidated input and injection vulnerabilities – never trust the user! More precisely, never assume user input is correct. Each value must be checked and validated to make sure it is correct. These vulnerabilities lead to SQL injection risks: malicious code or queries can be executed from your own application pages.

2. Broken access control – when a regular user gets more permissions than he/she should have. This usually happens because of the way user access levels are passed at registration, or how they are stored and read by the server.

3. Insecure storage of data – sensitive information (like credit card numbers or passwords) is stored in the database in plain text. This is like an open invitation for an attack, as anyone who has reading access to the database can find out allegedly confidential information.

These are only a few of the problems that arise in web applications, and which are amongst the top ten known problems, according to the Open Web Application Security Project (OWASP).

Coding defensively to protect yourself, your users and information from the hostile Internet can make the world wide web a more friendly and secure scene.

Vulnerable Areas

Vulnerabilities in a web application can appear on every page, but the user authentication system is a regular land mine field. For developers, this happens because user authentication (starting with the sign-up page and finishing with the profile updating page) deals with private, sensitive information. For crackers, it's the most obvious way to “get in”. It's easier to exploit the application flaws in your favor, instead of trying to break in from some obscure server port.

Let's take a look at each step of the user authentication process and see what problems can arise.

User Registration

This is usually the first step site visitors take. They are required to provide personal information to create an account on your site: username, password, e-mail address. Additionally, if the site content is managed by more users, an access level is usually used to define different user profiles based on permissions (e.g. users are level 0, site editors are level 1, the web master is level 2). This access level is usually recorded in the user profile during registration, without the user's knowledge. At this step, several problems may arise:

• Creating multiple accounts, using invalid e-mail addresses: the user enters bogus text (often invalid) as an e-mail address. This problem can be easily seen as nothing more than a nuisance, simply overloading the e-mail servers which try to send confirmation messages to bogus e-mail addresses.

• Registering an account with more permissions than it should have: instead of registering as a normal user, an attacker can gain additional privileges by modifying the default access level set in the registration page. This problem can be caused by using hidden fields for setting the access level. We'll show how easy it is to break into a web application and register as an administrator, instead of a regular user.

• Creating an account with an identifier that already exists. This usually means creating an account which uses an existing user name, to compromise the existing entry. This is caused by bad planning and lack of proper validation rules.

Account Activation

This is an extra step usually required during user registration, meant to prevent “bots” (short for robots, or automatic scripts) from creating an account. It involves marking the account as inactive after creation, and sending an e-mail with an activation link.

The link points to an update page, which marks the account as active. We strongly recommend using account activation as a way to prevent fake accounts. MX User Login comes with a simple and efficient way of implementing this: select a table column to store the activation status, and check the correct option when building the registration page.

Illustration 1: Check the Use account activation option to generate the corresponding pages and code

However, you should be aware that activation doesn't simply solve all user authentication problems. One problem is that a user may activate or disable other users' accounts. The problem resides in the way the account to-be-activated is passed from the e-mail message to the update page.

If using only the account ID, the application is insecure. An attacker can simply change the URL parameter containing the ID value, and attempt to activate other accounts. Say your activation link is something like http://foo.bar/activate.cfm?id_usr=3. This URL contains your user ID, which is 3. You can simply replace the value 3 with another one, say 4, and thus activate the account of the user having the ID 4.

User Login

This is the door to your site. A user login operation compares the credentials supplied by the user against the ones stored on the server. This step has its share of problems as well:

• Brute force attacks – when an attacker is trying to guess the password of a user by trying various character combinations. When done manually, it would advance slowly, but scripts do come in handy. The principle, as well as the tools are basic: a dictionary file (the larger, the better) with words and a script that uses each word from the dictionary as the password. Eventually, if the password is weak enough, it will be cracked. We'll show you how passwords can be stored safely later in this article.

Account Information Update

After an account has been created, most sites allow users to edit their personal information, change their password or e-mail address. If the page that allows account updates is not secure, an attacker may try to change passwords or other sensitive data. This will grant him access to those accounts, and consequently to other restricted areas of the website.

Of course, the user authentication section of the application is not the only one which should be scrutinized for security. Each and every page is potentially insecure, as it works with user input. Data must be thoroughly checked and validated to prevent code injections.

In this article you will learn how ImpAKT helps you avoid some common security pitfalls, and easily implement automated data encryption, secure account activation and parameter validation without. In the end, you will learn how to use ImpAKT to stop brute force attacks.

Tip: ImpAKT is a Dreamweaver extension developed by InterAKT Online, therefore its installation will be automatically handled by Macromedia Extension Manager. After installation, you'll find ImpAKT's wizards and server behaviors in one of these locations:

• The MX Kollection tab on the Insert bar.

• The MX Kollection menu from the Server Behaviors tab on the Application panel.

Extensions are similar to plugins or add-ons – they enhance the standard functionalities of Dreamweaver, and can vary from simple code snippets to complex applications. Their purpose also varies: they can reduce manual coding, minimize repetitive tasks, fix certain bugs or errors, increase productivity, or build a specific object.

You can find more extensions on the Macromedia Exchange.

Securing User Authentication

Common settings for the user authentication system are stored and managed from a central place – the InterAKT Control Panel. You can change a lot of settings from here, including site language, CSS skin, or date format, but for the moment, you will only be concerned with the Login Settings section. You can access the InterAKT Control Panel from the MX Kollection tab of the Insert bar.

Illustration 2: The InterAKT Control Panel allows defining a range of options

The InterAKT Control Panel has been designed to help you reduce development time, by keeping most common settings in a single place and helping you skip unnecessary or repetitive configuration.

From the Login Settings section, you can define the database table and columns to use, what session variables to create and what pages to redirect to, for all users, or for each separate user level.

Encrypting Passwords

The first security feature provided by MX User Login is the use of encrypted passwords. The algorithm used for encryption is MD5. This is a one-way algorithm, which encrypts data without the possibility of retrieving the original text. This ensures that the passwords stored on the server cannot be deciphered by anyone. This way, even if an attacker gains reading permission to the user table, it will do him no good. MD5 encryption is not infallible: if the password is not strong enough, a brute force attack can still reveal it.

Another advantage of the MD5 algorithm is that the encrypted text has the same length (number of characters), regardless of the initial password length.

The brute force attack performed in order to find an encrypted password is different from the one mentioned at user login. The script first encrypts each word in the dictionary, and than compares it against the value retrieved from the database. If they match, the password has been discovered. Cracking an encrypted password uses a large amount of time and processing power, even on today's computers.

By default, password encryption is turned off in the Login Settings. To enable it, you must take two steps:

1. Reserve enough space in the database password column for the entire encrypted string. ImpAKT's MD5 encryption requires that the table column be at least 32 characters long. To check the maximum allowed length, use your database server software. The password column type should be text (or varchar), and as just said, with a length of at least 32 characters.

2. Open the Login Settings interface, and check the Encrypt password option (from the Options tab). Because of the unified settings stored in the InterAKT Control Panel, password encryption will be applied both at user registration and user login:

   
   Illustration 3: Encrypt passwords easily with ImpAKT

   
   

Now passwords are stored safely in your database. If an attacker looks in the database and sees 8b559844dc7702b649ddbe2ebdbce027, he will have a hard time figuring out that this stands for “InterAKT”.

Note: in order to build the login and registration pages you must have two separate files created, and apply the corresponding wizards. For the login page use the Login Form Wizard, and for the registration page use the User Registration Wizard. You can access each wizard by clicking onits respective button in the MX Kollection tab of the Insertbar:

Illustration 4: Register and login buttons

Enabling Account Activation

When a user registers an account with your website, there are two scenarios:

1. The account can be used immediately without any further checks. This method is the most convenient for the user. After all, who likes to go back and forth just to post a comment on a forum. However, this method can be risky for the website – it's practically an open invitation for bots to sign up accounts and post spam on your site. Even if you leave bots out, there's still a great possibility that your database will soon get piled up with fake accounts that users never intended to use. Annoying, isn't it?

2. The safe way is to use account activation. This means (as explained above) that users receive an e-mail with a link they have to click on before they can use their account. This way, you eliminate two risks at once: if the user misbehaves, you have the e-mail address to send messages to. If the user is a bot, it can't check the account and login.

Using account activation when registering accounts is easy: just check the option in the last step of the User Registration Wizard.

Illustration 5: Check the option to generate an activate page, and add the e-mail sending code

Prior to this, there are some conditions to be met though:

1. You must have a database column that stores the activation status (0 for inactive accounts, and 1 for active). This field will be checked at login to verify if the user account has been activated:

   
   Illustration 6: New accounts must be activated before login

2. You must enable this feature in ImpAKT. Go to InterAKT Control Panel > Login Settings > Database tab, and select the proper database column in the Active drop-down menu.
   

   
   Illustration 7: Configure the Active column

3. When creating the user registration page by using the User Registration Wizard, make sure you check the Use account activation option in the last step.
   
   Illustration 8: Decide whether to use Activation or not
   Note: If you have not defined an Active database column, the checkbox will be disabled.

4. Configure the E-mail settings so that the user will receive the message with the activation link. Configure this from the InterAKT Control Panel > E-mail Settings section. Specify the outgoing SMTP server, port, username and password, as well as a default sender address. This address will be used for site e-mails.

   
   Illustration 9: Define e-mail settings for the site

The User Registration Wizard will generate a page called activate.cfm in the same folder as the registration page which will be accessed via the e-mail link during the activation process.
After users fill in the registration form and submit it, they are redirected to the login page and a warning message similar to this one will be displayed:

Illustration 10: Prompt to activate before using the account

The e-mail message that is automatically sent by the site can be customized, but in its default form, it should contain the same basic information as the sample below:

Illustration 11: Account activation e-mail

The e-mail displays the username and two links: one to activate the account and one to login. Once you click on the activation link, the account is enabled.

Using account activation provides a safer way to allow users register an account. However, the method used above is not completely safe. Take a closer look at the activation link to learn what it's made of:

• One of the parameters passed by the link is kt_login_id, which takes a numeric value. If you guess that it is the user ID, as stored in the database, you are right!

• The second parameter is kt_login_email, which takes as value the e-mail address used at registration (in plain text, that is, not encrypted).

Based on the information contained in the link, an attacker can easily figure out how to activate fake accounts or other people's accounts. All it takes is to replace the ID and e-mail parameters with the fake ones.

Fortunately, ImpAKT helps you strengthen the account activation by adding a random and unique value to the activation URL. ImpAKT has automated this task as well. Simply select the table column that will store the random key, and the rest is taken care of.

In the InterAKT Control Panel > Login Settings > Database select a column (at least 32 characters long) for the random key.

Illustration 12: Define the random key for account activation

Now the activation link doesn't use the e-mailaddress as an URL parameter anymore. Instead, a randomly generated value is used:

Illustration 13: Activation link with random key

In the next section, you will learn how to prevent users from registering with an existing username.

Preventing Duplicate Usernames

An user account is basically defined by at least two values: the username and the password. If the password can be anything the user wants, the username has but one constraint: to be unique. That is, no two users can share the same username, even if they use different passwords. This, too, can be a way to break in.

Let's say the designer was careless and forgot to add code that checks if a new username is already taken and – if so – blocks the registration. Consequently, a user can create a new account with a username that already exists, and then try to login. Because an account already exists, the login query will retrieve two records. Now either only one of the users will be able to login, or neither, depending on how the login page has been built.

When building the registration page with ImpAKT's User Registration Wizard, the username check is added automatically. If an user enters a name that is already taken, an error message is displayed, and the registration process is halted until a different name is chosen:

Illustration 14: The username field is marked

In the next section, you will learn how to use various ImpAKT features to make sure sensitive information will not be modified client-side.

Protecting Sensitive Information

When working with a dynamic site, you no longer have the option of keeping all the sensitive information in the local database where no one can access it. Now credit card numbers, passwords, access levels and all sorts of data that must not be publicly visible may accidentally become at everybody's reach. The most common example is the access level that is generated when a new account is created. Access levels help distinguish between different user roles, having different rights.

Most dynamic websites have two user roles: regular users and administrators. Regular users can browse the site front-end and look for information or register an account to become more involved (post comments, receive updates or access private areas). Site administrators have full access. They can change site information from the Administration section (or back-end) simply by logging in using their credentials. For an attacker, getting administrator privileges is like hitting gold.

How can regular users get more privileges than they should? Take a second and think how you store accounts. The typical answer is: all accounts are stored in one database table, but with different access levels, say “9” for administrators and “7” for regular users. When regular users register, their access level must be set to 7. To get more rights, an attacker can change the level at registration.

If you use hidden fields to set the access level, you may be at risk, without even knowing it. An attacker may save the registration page, change the value of the hidden field using a tool like Mozilla's DOM Inspector, and then re-submit the form with the altered access level.

Illustration 15: Change hidden field's value with the DOM inspector

Voila! You have a new site administrator, without even knowing it.

To avoid this common security pitfall, you can use ImpAKT, which provides no less than three solutions:

1. Do not use a hidden field for the level. Use text instead.

   • When completing the User Registration Wizard, for the access level set to use a text type element. This will be represented in the page as plain text, which cannot be altered.
     
     
     Illustration 16: Use a Text element
     
   • When you are done with the wizard, select and remove the row displaying the user level from the page.
     
     
     Illustration 17: You can remove the access level from the form
     
   • Notice that removing the text that displays the access level does not remove the field from the actual transaction. Let's look into the code by switching to Code View, to check this:
     
     
     Illustration 18: The access level field remains in the transaction
     
     As a result, the value of the access level will still be inserted in the database, without revealing any sensitive information to potential attackers.

2. Do not add the field to the form at all, but instead supply its value directly from server-side code using the Add Transaction Fields server behavior. This is a trigger that gets executed before the actual Insert transaction and which can add one or more fields and their values to the insert transaction. The Add Transaction Fields server behavior is a part of ImpAKT and can be accessed from the Server Behaviors tab >MX Kollection > Forms > Advanced menu.
   
   Again, the access level will not be exposed on the page, but will be instantiated at run-time and inserted in the database.

   
   Illustration 19: Add values for database columns directly

3. Finally, you can add the access level field after you complete the registration wizard, by editing the Insert Transaction which is responsible for executing the insert query. You can alter this server behavior to add more fields, which are not in the final page HTML code. The field and its value are generated at run-time by the server, with no user interaction whatsoever.

Illustration 20: Configure the user registration form fields