How to Build a Secured ASP.Net Website?

In coming section, we will see more about the below security threats and different ways to prevent the same.

Code Injection Attacks

Session Hijacking

Identity spoofing

Network eavesdropping

Information disclosure

Web Security Testing

Free Web Security Testing Tools

Code Injection Attacks

This is one of the very common attacks where a malicious user can inject some arbitrary scripts into our application. The injected code will then get executed in the application identity to do the intended damage.

Sql Injection and Cross Site Scripting (XSS) attacks are the 2 common attacks under this category. Read the below codedigest articles to know more about these attacks and preventing it.

What is SQL Injection Attack? How to prevent SQL Injection in ASP.Net?

What is Cross-Site Scripting (XSS) attack? How to prevent XSS attack in ASP.Net?

Session Hijacking

Session is a unique identifier generated by a web application to identify a connected/authenticated user. These identifiers are often stored in cookies and urls that travel forth and back the web server. In this attack, an attacker can steal a user’s session id and connect to the website with that session. The web application will receive the attacker’s request and will allow the attacker to access anything the user has access to.

How it is done?

1.      An attacker can use XSS attack and inject some scripts which will then send the cookie information to the attacker. This specific attack where an attacker hijacking a user’s cookie is called Cookie Replay attack.

2.      An attacker can use some network sniffer tools and get the sensitive data that gets transported in the network from the website. This is commonly called as Network eavesdropping.

How to prevent Session Hijacking?

1.      Prevent Cross-Site Scripting vulnerability in your websites. Read the above article.

2.      Prevent storing some secured information in Hidden Fields, Query Strings, View State, Form Fields, etc. This is called Web Parameter Tampering or Parameter manipulation attack.

3.      Always use SSL certificates (https) on authentication pages and in the modules which does some secured transactions.

4.      Don’t allow multiple users to connect to the same session from different machines. You can do this by restricting user to connect only from one IP.

5.      Re-Authenticate users when doing secured transactions.

6.      Verify the user by asking some security verification questions when doing secured transactions.

Identity spoofing

Identity spoofing is a mechanism where an attacker steals the identity of an existing user of your application and gaining access to restricted sections. This is normally done by guessing the username and password, stealing username and password in non-SSL communication link.

How it is done?

1.      Guessing the username and passwords. The attacker can use Brute force attack or Dictionary attack to do this. This will happen when there is no password policy implemented in your websites.

2.      Using network sniffer tools to read the protected data sent over non-SSL communication links i.e. Network eavesdropping attack.

3.      Using Sql Injection attack. An attacker can get the username and password in application when the application stores password as clear text in database.

How to prevent Identity Spoofing?

1.      Have a strong password policy. For example, accept the passwords that have at least one number and a symbol with a minimum length of 8 characters when registering the user.

2.      Always use SSL certificates (https) on authentication pages and in the modules that does some secured transactions.

3.      Prevent code injection attacks.

4.      Display last visited time and the IP from where the user visited to ensure when re-authenticating to the site. This will enable users to reset the password when there is a suspicion.

5.      If required, make the users to change the password every 3 months as part of password policy.

Web Parameter Tampering or Parameter manipulation

Form fields, View State, Query String are vulnerable to this attack. A malicious user can get hold of the sensitive information that is sent through these parameters and can exploit your application.

How it is done?

1.      Using network sniffer tools to read the protected data sent over non-SSL communication links i.e. Network eavesdropping attack.

2.      An attacker can steal the session id from query string and gain access to restricted area.

3.      An attacker can steal the cookies and gain access to restricted area.

How to prevent Web Parameter Tampering or Parameter manipulation?

1.      Always use SSL certificates (https) on authentication pages and in the modules that does some secured transactions.

2.      Don’t use persistent cookies for storing authentication tokens (session ids).

3.      As a user, don’t select “Remember password” option in Logon screen in a public computer.

Network eavesdropping

An attacker can use some network monitoring tools to obtain some sensitive data from the data packets sent between web server and the user.

How it is done?

Using network sniffer tools to read the protected data sent over non-SSL communication links i.e. Network eavesdropping attack.

How to prevent Web Parameter Tampering or Parameter manipulation?

1.      Always use SSL certificates (https) on authentication pages and in the modules that does some secured transactions.

2.      Prevent storing some secured information in Hidden Fields, Query Strings, View State, Form Fields, etc. This is called Web Parameter Tampering or Parameter manipulation attack.

Information disclosure

This can occur when our application use weak exception handling techniques. For example, our application may throw technical details with the exception details when we have not properly handled exceptions. The details like database name, schema details, network path details, etc may get exposed outside.

How it is done?

An attacker can exploit your application by giving appropriate inputs that can generate exceptions with sensitive information.

Consider the below exception message,

System.Data.SqlClient.SqlException: Invalid object name 'Employees1'.

The above message clearly says, there is no object called Employees1 in your database. An application that has Sql injection vulnerability can be exploited easily using the above details. The attacker can guess different table names specific to the functionality the page offers and finally get the correct table name and can do the damage.

How to prevent Information disclosure vulnerability?

1.      Display generic error message in case of exception. You can log the detailed exception, stack trace for debugging purposes.

2.      Redirect to generic error page when any error occurs.

3.      Never set the mode attribute to “Off” in <customErrors> element in Web.Config.

4.      Do not frame the error message with specific information that could hint an attacker to achieve his target. For example, in a login page never show an error messages like “Your userid is invalid” or “Your password does not match the typed userid”. This tells the attacker that the typed in userid is invalid and the former hints that the userid is valid and the password is invalid. You can instead show a generic message like “Login failed. Try again”.

Web Security Testing

Understanding the importance of building secured web applications, nowadays most of the companies have security testing as part of their SDLC process.  There is lots of free and commercial automated web security testing tools available which can be employed for this. Some of them are,

1.      Websecurify

2.      x5s

3.      N-Stalker 

4.      WebCruiser

Just download anyone of the above application and try using it.

Things to consider

1.      As a practice, always provide very minimal permission to the application service account.

2.      Separate each application by creating separate application pool when deploying.

3.      Never use sa account or any account with admin privilege to connect to your database. Provide very minimal permission to the service account.

4.      If you use SQL server authentication to connect to your database or if you use shared hosting, then consider encrypting the connection string in Web.Config.

5.      Always have generic error page. Show only generic error messages. Set either “On” or “RemoteOnly” option to mode attribute of<customErrors> element in Web.Config. Never set “Off”.

6.      Never set ValidateRequest="True" at Web.Config level. If you want to allow HTML input from users, the set ValidateRequest="True" at page level(In @Page directive)

7.      Never turn off the EnableViewStateMac. This attribute will dictate ASP.Net whether to verify or not to verify the ViewState value when the page is posted back to server. If the ViewState is changed when it is posted back then ASP.Net will throw an exception.

8.      Always use CAPTCHA to verify the users in input forms.

9.      Never send the passwords in email.

10.  Always do input validations on server side even though you have JavaScript validation in place. Remember, JavaScript can be turned off in client side and the validations can be easily bye-passed.

11.  Consider re-authenticating users when doing critical transaction. Or you can have a separate transaction password if required.

12.  Use the error messages that are more generic. Never frame an error message that is very subjective which could hint an attacker.