Simple Web Development Recommendations

Due to ongoing threats and increasing complexity of attacks it’s suggested that the highest levels of security be implemented into every Web Application, especially the ones that include potentially critical data, such as passwords, confidential information, financial data, etc.

Most threats today focus on the user as the primary vehicle for malicious activity. These attacks exploit the user’s innocent and ignorance in regards to social engineering. Hence, implementing methods of prevention are the best in preempting any future attacks.
Also, since technology is always changing, and new features are added with each new version of software, keeping the application up-to-date is critical to the success of the site.

Therefore, this document is an attempt to inform and urge management and stake holders to the necessity of imposing the requirements to each agency and their developers. Most of the document is informative and will be high level, even though some low level information will also be posted on the end of the document and will expand on the points made in the high level subjects.

Securing Data at the Database Level




Even if the odds are small, gaining access into one’s database allows malicious individuals to view any information from any column or table with simple clicks. Hence, encrypting data in the Database can be the last defense in preventing data loss. At first look, encrypting all the columns in the Database may seam the simplest way to go but it may not be the most efficient both in performance and in theft prevention.

For that reason, deciding which columns needs to be encrypted and then implementing encryption methods can be cheaper and most effective to both DBA (Database Administrators) and stake holders.

Some examples of columns that are best if encrypted are:
  • User’s password
  • Secret Answers (in case of site registration)
  • Income Information
  • Credit Card number and/or PIN
  • Statistics
  • Financial Numbers
Keep in mind that other columns might need to be encrypted. For that reason, it’s best to consult any stake holders, domain experts and even users to assess what should or not be encrypted.

Database Access


Even though this recommendation may create the most work as it deals with user access it allows tight security to Database resources. Since different parts of the Web application may need to perform different tasks, it’s best to separate each process to unique Database users.
  • In the login page, the login controls need access to the database to verify the user and grant access to the website. Therefore, creating a Database user that is only allowed to check whether the user login information is correct will prevent possible attacks such as SQL injections from inside the Database itself.
  • When loading data for a page, a database user may only have the rights to pull the data out.
  • When updating a user, a database user may only have rights to update to that table or stored procedure.



Using Stored Procedures


Stored procedures are pre-formatted instructions given to the Database and they perform specific tasks. By using stored procedures the database becomes free from direct data requests that may come from the web application. Also, if data can only be manipulated via stored procedures then a malicious attempt will be stopped. In addition to using stored procedures, using specific users for key stored procedures can add an additional layer of security and prevent malicious attacks.


Securing Data from Database to Web Application


Because of SQL injections3 and Cross-Site-Scripting (XSS) 2 malicious users may attempt to gain access to user’s sessions, database information, or even deface a website.

By implementing a Data Access Layer (DAL) 4 developers can create a wall between the web application and the Database itself, thus preventing malicious users from attempting to exploit any direct connections.

There are several open source, and open license DALs available such as Nhibernate5, the recent Microsoft MVC, and others. Keep in mind that considering more than one may help decide which will be of most profit to and less costly to implement.

In many cases, a custom DAL may need to be developed depending on the needs or complexity of the Web Application and Database. Nevertheless, it is important to decide on a DAL that will create the most benefit from the features it includes.


Securing the Web Application


Since most attacks come from browsers it’s critical that the Presentation Layer or Web Application to be safe and simple.
Avoiding using Frames, too many pop-ups, and direct database connections can go a long way in preventing attacks.


Request Validation 6


By using client-side-validation, developers save the user’s time from sending data to the server and having to wait for an error. Also, it prevents users from entering wrong data by mistake.

By using server-side-validation, developers can prevent a cross-site-script from sending dirty or malicious requests to the server, as well as validate the user’s request with the same validation as the client-side.


Login Forms


Login forms are the primary point of attack for SQL injection scripts. A malicious individual may attempt to login into an administrator account, or delete data (deface), or even gain information about the server. In addition to using client-side and server-side validation processes, login forms may be allowed only to use a certain stored procedure, or only read access to the database. And through a DAL, this login form will not be able to send dirty data, even if via a cross-site-script.
Usernames and passwords may also gain additional security by being encrypted and by using digest passwords. A Digest password is a combination of the username and password together. This way, a password can never be guessed, even if it’s a simple one as ‘12345’. For example, a username of jsmith and password of 12345 becomes jsmith:12345 as a digest password (AF7A5D230518D9E7FE92B92E81633B17E7B117C4 encrypted). Once encrypted, the password will be nearly impossible to be guessed.


Technology used


In a .NET environment case, since all sites are Microsoft based, the latest technology available in the market is ASP.NET version 3.5. This version offers many new features compared to the old ASP (which has been created in 1996)7. Also, many security and performance improvements have been added to ASP.Net and this reason alone should prove why ASP sites seam slower than they should be (since one can easily compare the speed of an ASP site to an ASP.Net site).

Besides using ASP.Net, the core language choice is also important. While C# is the preferred language for corporate applications (including web), Visual Basic is much more flexible and easy on the developer. And even though taste has much to do with the flavor of language one uses, it is more common to find that higher education developers develop more in C# than in Visual Basic.

Nevertheless, VB scripting is not preferred since they allow for malicious exploits, besides of being visible in the page code and are not easily reusable. Code reuse can greatly reduce the cost of development since developers won’t need to start every project from scratch, even if the two projects are different. Both projects may have similar features and those can be reused.

Again, there are many technologies available for code reuse and effectiveness. The most recent release for Microsoft is the MS MVC1.

Regardless of using AJAX8 (Asynchronous JavaScript and XML), sites need to consider the less overhead possible. A page should be clean and neat, avoiding too many comments that lead malicious individuals from guessing critical information, and should not rely too heavily on View or Sessions variables9. In SQLSession Management cases, Sessions are stored inside a SQL server and variables need to be serialized before being stored. Resources should be used sparingly and managed carefully.

Testing and scanning

Once a site is completed, testing if it is vulnerable to possible attacks is done in order to avoid data loss, defacing, or even hostile takeovers. There are several scanning tools available11.

Database Conceptual and Relational Design


Designing an optimized and well organized database is as important as creating a visually attractive and secure web application. A database that has repeated or incorrect data may slow resources and influence negatively any KPIs related to business. Hence, the database design should be as carefully considered as any other step in the development process.

Once databases are implemented and data is inserted any fixing, adding, or deleting columns or constraints become cumbersome and many times more expensive than good initial design. Designing a database that is normalized 10 and fully structured prevents any future changes and urgent fixes.

There are several techniques for designing conceptual and relational databases. The most commonly found are ER Baker, UML, ORM, and IDEFIX. Keep in mind that while designing a database, derived data should most often not stored, saving on database resources. For example, if birth dates are stored and an age range needs to be created, calculating the current age of a user is as simple as subtracting the current data from the user’s birth date. Therefore, when a user increases age no process is needed to update any rows that might contain that user’s age. This way, derived information is not stored, but can be easily derived at any time.


Low level


Example of Login Stored Procedure:








      IF EXISTS (SELECT Username FROM Users WHERE Username = @USERNAME)


            DECLARE @isActive BIT

                  SELECT @isActive = isActive FROM Users WHERE Username = @USERNAME

                  IF @isActive = 0

                  RETURN -100



                              IF EXISTS (SELECT IsActive FROM Users WHERE Username = @USERNAME)


                                          SELECT @VALIDATED = COUNT(Username) FROM Users WHERE Username = @USERNAME AND [Password] = @PASSWORD

                                          RETURN @VALIDATED      




      RETURN -1


Note that there are several layers of checks in this sproc so it does not mean that this is the only way to implement login scripts. Nonetheless, note that the local variable @Password is of NVARCHAR(64) which is taking into consideration that a password is being sent encrypted as digest.

An example of C# code to encrypt user passwords:

private static string EncryptPassword()


        //starts digest encryption

        _crypt = new SHA1CryptoServiceProvider();

        string digest = _username.ToLower() + ":" + _password;


        byte[] buffer = Encoding.Default.GetBytes(digest);

        string hash = BitConverter.ToString(_crypt.ComputeHash(buffer)).Replace("-", "");

        return hash;


In this case, encrypting Jsmith password will come out as ‘Jsmith:12345’ = AF7A5D230518D9E7FE92B92E81633B17E7B117C4




  1. Microsoft MVC (
  2. Cross-Site-Scripting (
  3. SQL injection (;
  4. Data Access Layer Tutorial (
  5. Nhibernate (
  6. Login Server-side and client-side validation (
  7. ASP History (
  8. Microsoft AJAX (
  9. Session StateVariables (
  10. Normalization (
  11. Web Security Scanning Tools:

By Carlos Casalicchio   Popularity  (1818 Views)