Web Security Standards and Compliance

More often than expected site are getting hacked, cracked, defaced, leak information or are even destroyed by malicious individuals all over the world.


In my experience, consulting with market from various countries and the web agencies they hire to complete their business requirements, many agencies very often do not follow any security standard and end up being flagged down by the headquarters security scan. These vulnerabilities then become very costly to the markets and the web agencies since they delay go-live dates and require many patches and re-work from developers.

On the other hand, for older sites that have been live for longer than a year, if sites are not constantly updated with the latest security technology they face a high risk of breach by malicious individuals.

With that in mind, this document will expand on most common types of vulnerabilities found and how they can be prevented.

Session high-jacking

By taking advantage of a cookie that was not deleted, a malicious individual may attempt to gain access to a valid user by manipulating that lost cookie and using it to impersonate the innocent user that was not even aware that a unsecured cookie was left behind. Using cookies must be avoided as much as possible, whenever possible.

Cookies must always have a timeout parameter so they don’t just sit on someone’s computer forever (or until manually deleted). The “remember me” option should be used sparingly and consciously as well as requiring a new login to access critical personal data.

An alternative to using cookies is enabling a SQL Session State server, which stores the session details on a secured SQL server. Users should also be always able to logout of their sessions, to avoid it still being active as someone else uses that browser, or computer.
Blind SQL Injection
Blink SQL injection may also relate to “Insufficient Validation” but may also be a subject on its own.

A malicious user, either by knowledge or by trial and error, attempts the following line on the login form:
Username = administrator
Password =  ‘ or 1=1 - ‘ and userpass=’’

Then, by luck, he’s able to login as administrator and is free to do any type of damage he/she wishes.

Besides of adding validation scripts on both the server-side and client-side (Insufficient Validation) a good way to prevent injections is to sanitize the code before sending it to the SQL server.

A way to sanitize the parameters is using the TRIM method of both SQL - for stored procedures - and C#.Net or VB.Net.

Also, instead of using simple query string, using SQL parameters, so that any additional input will be cleaned up before being sent to the server.

Cross-site Scripting (XSS)

Cross-site Scripting (XSS) takes advantage of dynamically generated Web pages. In an XSS attack, a Web application is sent with a script that activates when it is read by an unsuspecting user’s browser or by an application that has not protected itself against cross-site scripting. Because dynamic Web sites rely on user input, a malicious user can input malicious script into the page by hiding it within legitimate requests.

A malicious user that knows of this vulnerability in a site may attempt to gain controls of an end-user and steal information from their computer.

An important way of preventing this attack is by avoiding the use of frames or too many JavaScript popups

HTML Comments

Comments in your code are great for development. Nevertheless, they can also teach a malicious user how the site works and potentially hint away structural information or even critical credential information.

Besides, viewing a web page’s source is just as hard as clicking on “view source”. Or, if using a prompt window, the webpage is not rendered, and all the text comes out just as plain as day.

Therefore, before publishing a site it’s important to review any comments that might be present in the pages, so that it does not contain any information that may aid a malicious user

One tier Approach

It’s very common to have a ONE person web agency working on a project for a market since these agencies tend to be the cheapest and the most dynamic. Nevertheless, most times, these agencies, for the sake of time, do not implement the most basic security standards.

By using only one tier, a malicious user may attempt all kinds of attack and attempt to gain as much knowledge as possible from the errors returned, the data, and processes (traces, logs, etc)

Having the web application code access data directly from the DB is dangerous. The three-tier/mid-tier or MVC standard is recommended: Data Layer, Business Layer, and Presentation Layer

For that reason, it’s always better (and sound) to separate the web application in layers, not only to increase security but to promote reusability, as the one layer may be implemented in other projects if not fully coupled into a specific application.

Insufficient Validation

Using the same example from the Blind SQL injection, if there’s no validation on the client side, then once the malicious user clicks on send then the server will attempt to interpret the login information and may end up either throwing an error or worse, return the result like the malicious user expected.

Therefore, using REGEX (regular expressions) along with javascript on the client-side and REGEX on the server-side can double the changes that an error, or malicious activity can be caught before it causes any damage.
No custom Errors
When a page returns an unhandled error, a .NET error page appears and may disclose more information than intended. A malicious user may use this information to gain access to other data, or even deface the site.

Therefore, using the tag <customErrors = “RemoteOnly”… is important since the errors will still be available for troubleshooting from inside the server, but for the end-user a custom page will appear notifying of an error, and not giving any information that should not be given. This process may also be used to send an email to the administrator to notify of the error.

Unencrypted Login

Login forms should always be accompanied by SSL (encrypted) channels. A malicious use may attempt to sniff all the data that is not encrypted and may gain knowledge of a user’s login information and high-jack their account, or even deface the site if the login information is privileged.

Therefore, always use encryption for login Forms.
No testing before launch
The best way to make sure the website is safe is by trying to break it, and hack it. Obviously, this is better if done prior to going live. Therefore, testing the site as the project proceeds is better than having an actual hacker testing it after it’s live.

In the resources section there is a list of online tools for continuing scans.

Hidden Values

Hidden values are useful to avoid clogging the View or Session State. Nevertheless, if it has data that is easy to crack, or if it’s poorly used then a malicious user can attempt to gain access to information from those values (a good hacker know how hidden values work).

Therefore, avoid using hidden values as much as possible.


There are many other types of vulnerabilities but this document expanded on the few most common so that your interest in security increases and pushes your development to higher standards.


SQL blind Injection - <http://en.wikipedia.org/wiki/SQL_injection>
Session High-jacking - <http://en.wikipedia.org/wiki/Session_hijacking>
Cross-Site Scripting (XSS) - <http://en.wikipedia.org/wiki/Cross-site_scripting>
Three-Tier Architecture - <http://en.wikipedia.org/wiki/Three-tier_(computing)>
Custom Errors Tag - <http://msdn.microsoft.com/en-us/library/h0hfz6fc.aspx>
Encrypted login forms - <http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.encrypt.aspx>
web security scanning tools

By Carlos Casalicchio   Popularity  (2293 Views)