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:

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

    Frame29
    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.
    Frame2
    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

You can use these methods not only when building the account registration page, but whenever you need to insert information that must not be altered by other users.

Altering URL Parameters to Access Restricted Areas

Now users can register accounts and login securely to your site. As with most sites, you must provide a way for users to change their account information: e-mail address, password and other personal details. In a multi-user environment, updating the correct account can be an issue.

What makes a user unique, besides the username, is the ID of the corresponding record in the database. A typical update page relies on that ID (the primary key) to allow users change their details. There is nothing wrong with this approach. You could use the username or any other unique field to identify each particular user, just as well. The real issue is passing this value to the profile update page. If you usually do this through an URL parameter or a hidden field, consider this scenario:

  • User A accesses the profile update page to change his password. He notices the URL parameters in the browser's address bar. He realizes that he could change the value of the URL parameter, and thus load the account information for another user. Thus, he could easily edit another user's profile, including password and e-mail. For example, the profile updating page for users is accessed through an URL like this one: www.domain.org/update.cfm?id_usr=27. By modifying the value of id_usr to 1 you can easily edit the respective user's profile (name, e-mail, password etc).

This is a harmless scenario (maybe more annoying than dangerous), but what if he had stumbled over the admin's ID (maybe 1, since the site administrator is usually the first user) and changed the password?

To prevent this from happening, you need to define stricter validation rules, and not make private information accessible to others. The user login forms generated with ImpAKT, besides performing the actual authentication, also create three session variables when and if the login was successful:

  • the user ID: kt_login_id

  • the username: kt_login_user

  • the user's access level (if multiple levels are used): kt_login_level

You can use these variables on any page, and since they are stored on the server, users cannot see or modify them.

Tip: You can define additional session variables to be created on successful login from the InterAKT Control Panel> Login Settings > Session tab. Click the Plus (+) button to add other session variables (such as the user first name, e-mail address etc):


Illustration 21: You can define additional variables

To build the account updating page, you can use the Update Record Form Wizard which has several advantages:

  1. You can define from where to retrieve the user ID in an easy manner, using a drop-down menu and a text box in the second step of the User Registration Wizard.


    Illustration 22: Define the ID and where to get it from

  2. The old password and new password confirmation fields are automatically created because the password column is set to use a Password field form element – automatically, from the Login Settings.


    Illustration 23: Configure the password field

  3. The form that is created has validation options to prevent wrong input: fields that have been defined in the Login Settings (e.g. the e-mail address, name and password) have validation applied automatically, for the rest you must configure the rules in the third step of the User Registration Wizard.


Illustration 24: Generated account update form

Because session variables are unique for each user and cannot be altered from the address bar of the browser, they provide a secure way of building multi-user applications. Now, the account update page displays the information for the user whose ID matches the value of the kt_login_id session variable.

In the next section, you will learn how to check user – entered information, or data that the user can temper with in order to perform malicious code on the server.

Preventing SQL Injections

An SQL injection is the mechanism by which an attacker could execute malicious queries on your database by exploiting the vulnerabilities of your application. To explain things better, let's take this example:

  • One of your site pages (say the one that displays news) receives the record ID as an URL parameter (e.g. www.domain.org/article.cfm?id_art=3).

  • An attacker decides to change the URL parameter in the address bar to something like this:
    www.domain.org/article.cfm?id_art=3;DROP TABLE articles;

  • If your database server supports the DROP command, and the URL parameter is not properly validated, then instead of the initial SELECT query, one more will be executed: the one that deletes the entire articles table.

To prevent this you need to follow a golden rule: every variable that can be entered or altered by the user is not to be trusted and must be validated. Each parameter (not only those used in queries) is to be checked for the expected type. To prevent the situation described above, the site page should check if the URL parameter value is a positive number (therefore, not allowing query strings to be executed).

ImpAKT owners can feel relieved. Whenever using URL or other types of parameters in transactions, they can be checked for the correct type before using them in SQL queries. If the parameter must match a numeric primary key, ImpAKT will check that this value is actually an integer.

Take for example the Update Record Form Wizard. In the user interface, you have to define the table column storing the primary key, its type (numeric or not), and then decide where to get the value from:


Illustration 25 Set the primary key column and its type


Passing an URL parameter as in the example above will not cause any damage, since it will be checked for numeric type first.

In the next section, you will learn how to build a secure login page where registered users can enter their credentials.

Building a Secure Login Page

The login page has one purpose: it allows users to enter the username and password in the corresponding form fields and checks them against the values in the database. As explained earlier, attackers can try (manually or using automated scripts) various username/password combinations until they break in.

With ImpAKT and a little coding, you can implement a mechanism that blocks the login after a specified number of failed attempts. This way, even if someone runs an automated script on the login page, it will have to stop after a specified number of attempts, because the login form will no longer be displayed.

In the following section you will learn how to use ImpAKT to build a secure login page, step by step.

Create the Basic Login Page

After having setup the login options (from the InterAKT Control Panel > Login Settings) as explained earlier, the settings are available to all wizards in MX Kollection 3: registration, login and others. To create the user login page, you can use the Login Form Wizard:

  1. Open the page where you want to create the login form (e.g. login.cfm).

  2. Go to the MX Kollection tab of the Insert bar and click on the Login Form Wizard icon to start the wizard.
    Note: ImpAKT is part of a bigger bundle, named MX Kollection. This is where the tab name comes from.


    Illustration 26: Start the Login Form Wizard by clicking its icon

  3. The wizard is divided into two steps. The first step is only informative, displaying the database settings you have selected in the InterAKT Control Panel. Click Next.


    Illustration 27: Check the defined options

  4. In the second step, you can define extra login options: whether to generate a password reminder page and a “Remember me” check box. The Forgot Password page that is created contains a form where the user can enter the email address. If the e-mail address is found in the database, a new password is generated for the user and sent by e-mail to the specified address:


    Illustration 28: Set Login options

  5. Click the Finish button to close the wizard and apply the changes. The login form will be displayed on the page.


    Illustration 29: Login Form in Browser

At this point, when the wrong credentials are entered, an error message is displayed on the login page:


Illustration 30: Error message for incorrect credentials

Then, an attacker can try to login again, using other credentials, until a valid combination is found. To block the access after a fixed number of attempts, you will modify the login page, as explained next.


Blocking Login After Three Failed Attempts

To block the user login with the standard ImpAKT generated form after three attempts, you must modify the page:

  1. First add a counter that is incremented each time the login page loads. To make it secure, you will store it in a session variable.

  2. The entire login form must be placed in a conditional region. This way, when the counter reaches the limit, the form will no longer be visible to the user.

  3. When the limit is reached, the user must see a warning message and a link to the password reminder page. Perhaps it is not a malicious user, but simply a user that forgot the password, and you should be prepared for each case.

  4. When the login is successful, the counter must be reset.

You will achieve all this using the ImpAKT server behaviors.

To add a custom operation that is executed before the login form is displayed, you will use a Custom Trigger server behavior. This allows you to write your own code and give it an execution priority, by setting the corresponding trigger properties:

  1. Go to the Server Behaviors tab > Plus (+) > MX Kollection > Forms and select the Custom Trigger item.


    Illustration 31: Custom trigger server behavior

  2. The user interface that loads is divided in two tabs: Basic and Advanced. In the Basic tab you can enter the code, while in the Advanced tab you can set the options.

  3. In the Basic tab's main text area, enter the code that increments a session variable (the login counter). For this example, the session variable name is failed_logins:

    <cfset SESSION.failed_logins = SESSION.failed_logins + 1>



    Illustration 32: Code inside the Custom Trigger user interface
  4. Next switch to the Advanced tab and configure the trigger properties:

    • In the Priority text box enter 2. The priority establishes the order of execution. A low priority means an earlier execution.

    • In the Type drop-down menu, select BEFORE (this means the trigger will get executed before the login attempt).


      Illustration 33: Specify trigger properties

    • Click OK to close the user interface and apply the sever behavior.

Now, you must create the conditional region that will display the login form only when the counter is lower than 3:

  1. Select all elements in the login page. Either drag a rectangle around them, or press CTRL+A to select them.

  2. Go to the Server Behaviors tab > Plus (+) > MX Kollection > Conditional Regions and load the Show If Conditional Region server behavior.


    Illustration 34: Apply the conditional region server behavior

  3. The user interface allows defining the condition that must be satisfied in order to display the login form.

  4. In the Expression 1 text box enter code that will retrieve the value of the counter saved in the session variable:

    #SESSION.failed_logins#

  5. In the Condition drop-down menu select what operator to use. Since the counter must be lower or equal to 3, select <= in the drop-down menu.

  6. In the Expression 2 text box enter the number of allowed attempts: 3.

  7. Check the Has ELSE option. This will allow you to create content to be displayed when the condition is not met.

  8. Click OK to apply the server behavior.

    Illustration 35: Build the condition to display the area on

A thin gray line is displayed around the page contents to mark the conditional area. Also, some bogus text (Else text: Replace this) is added, to mark the content that will be displayed when the condition fails to be satisfied. At this point, if you load the login page in a browser and try to login using wrong credentials, after three failed attempts the bogus Else text will be displayed.

You will have to replace this message with your own message:

  1. In Dreamweaver select the bogus text:

    Illustration 36: This is bogus text to replace

  2. Press the Delete key to remove it. Enter the following text, instead:
    The authentication has been blocked because of too many failed login attempts.
    Did you forget your password?

  3. Next you have to turn the Did you forget your password? question into a link to the forgot_password page. Select the text and click on the Folder icon next to the Link text box in the Property Inspector. Browse to the forgot_password page and select it.

  4. Save the page. Now when a user enters the wrong credentials three times in a row, the error message you typed will be displayed.


    Illustration37: 3 tries will lead to this message being shown

The last step is to reset the counter after the user successfully logs in. To do this, you will use another Custom Trigger:

  1. With the login page opened in Dreamweaver, go to the Server Behaviors tab > Plus (+) > MX Kollection > Forms and select the Custom Trigger server behavior.

  2. In the text area of the Basic tab enter the code that sets the session variable to 0:
    SESSION.failed_logins = 0;



    Illustration 38: Code to initialize the session variable

  3. Next set the trigger properties so that it will get executed after the login transaction is completed successfully:

    • In the Type drop-down menu select AFTER.

    • Leave the Priority at the default value (50).



    Illustration 39: Configure trigger properties
  4. Click OK to dismiss the user interface and apply the server behavior.

Save the login page and upload it to the remote server. Now users cannot attempt more than three combinations of username/password before being blocked out.

Where to Go from Here

In this article you have learned about some of the dangers that threaten any web application. Of course there are more out there, and more are found on a regular basis. But if you start with a basically secure application, it will be much easier to prevent future problems, then rebuilding every bit of it.

By going through this article you have learned how to:

  • Build secure login pages.

  • Use account activation to prevent fake accounts.

  • Use password encryption to prevent password theft.

  • Prevent users from tempering with sensitive data that is submitted to the database.

  • Block the login after a specified number of tries.

You have learned how to secure your application with ImpAKT, but it can do much more. For a visual tour of the most important ImpAKT features, check out the Flash demos on the homepage.

To keep in touch with the most important 10 security vulnerabilities you should consult the OWASP report. It can provide some additional insight on application security which may be of interest.

You can learn how to build a full-featured application that makes use of ImpAKT's authentication features, and build yourself a blog in the meantime, by reading the Building a Blog article on the InterAKT Online website. By going through a practical example, and testing the complete work you will understand better how authentication is performed.

About This Tutorial
Author: Cristian Ivascu
Skill Level: Intermediate 
 
 
 
Platforms Tested: CFMX,CFMX7
Total Views: 93,690
Submission Date: January 09, 2006
Last Update Date: June 05, 2009
All Tutorials By This Autor: 1
Discuss This Tutorial
  • What a great tool, been a dreamweaver user and using this extension along with the tutorial makes light work of what was once a difficult job for me. good work regards Kenny

  • ..............k...........

Advertisement


Website Designed and Developed by Pablo Varando.