Secure ASP.NET coding practice for three most critical vulnerabilities in Web Application

<h1>Secure ASP.NET coding practice for three most critical vulnerabilities in Web Application</h1>Author: <a title="Somnath Guha Neogi" href="http://www.articlesbase.com/authors/somnath-guha-neogi/123088.htm">Somnath Guha Neogi</a> Secure ASP.NET coding practice for 3 most critical vulnerabilities in Web Application <a href="http://www.ivizsecurity.com" target="_blank">www.ivizsecurity.com</a> Somnath Guha Neogi (OSCP,CNSM) <a>Introduction:</a> ASP.NET provides several exciting security controls, but these need to be understood properly and used wisely. Failing to use the ASP.NET functions properly results in an insecure web application. We see therefore that ASP.NET does not exempt the programmer from following coding standards and procedures in order to write safe and secure application code. In this paper we will discuss about the code level mitigation for three most frequently found vulnerabilities: Cross Site Scripting SQL Injection Information Leakage <a>Cross Site Scripting:</a> An application is vulnerable to Cross Site Scripting if malicious user input is embedded in the HTML response without passing through any particular validation process. Let’s take a look on a vulnerable chunk of code <%@ Page ValidateRequest="false" %> <html> <script runat="server"> void buttonsubmit_Click(Object sender, EventArgs e) { Response.Write(comment.Text); } </script> <body> <form runat="server"> <asp:TextBox runat="server" /> <asp:Button runat="server" Text="SubmitComment" /> </form> </body> </html> Now an attacker can send malicious request with embedded JavaScript through the comment textbox which will be executed at the client’s browser. To see that this is possible, the above vulnerable script can be fed with the following input: <script>alert([removed])</script> Now this type of script injection attack can be mitigated by adopting a two tire security approach. User input validation will form the first tire of security while HTML-encoding on outgoing user data will form a second layer of security. So we can start assuming that all user input is malicious and to safely allow restricted HTML input developers/testers should adopt three security approaches as follows: a)      Add the ValidateRequest="false" attribute to the @ Page directive to disable the ASP.NET request validation. b)      Encode the string input with HtmlEncode function. c)       White listing approach can be adopted by using a String Builder and calling its Replace method to selectively remove the encoding on the HTML elements that you want to permit. The following .aspx code depicts this as an example. <%@ Page ValidateRequest="false"%> <script runat="server"> void submitbutton_Click(object sender, EventArgs e) { StringBuilder stringbuilder1 = new StringBuilder( HttpUtility.HtmlEncode(Txt1.Text)); // Selectively allow and stringbuilder1.Replace("&lt;b&gt;", ""); stringbuilder1.Replace("&lt;/b&gt;", ""); stringbuilder1.Replace("&lt;i&gt;", ""); stringbuilder1.Replace("&lt;/i&gt;", ""); Response.Write(stringbuilder1.ToString()); } </script> <html> <body> <form runat="server"> <div> <asp:TextBox Runat="server" TextMode="MultiLine" Width="318px" Height="168px"></asp:TextBox> <asp:Button Runat="server" Text="Submit" OnClick="submitbutton_Click" /> </div> </form> </body> The above .aspx page code shows this approach. The page disables ASP.NET request validation by setting ValidateRequest="false". It HTML-encodes the input and then selectively allows the <b> and <i> HTML elements to support simple text formatting. Now the second tire of security can be brought into the frame by encoding the output to know that the text contains HTML special characters or not. Response.Write(HttpUtility.HtmlEncode(Request.Form["text"]));   Or in case of URL strings that contain input to the client.   Response.Write(HttpUtility.UrlEncode(urlString));   As a result, the HTML response stream of the malicious input <script>alert([removed])</script> will look like this &lt;script&gt;alert([removed])&lt;/script&gt; This will ultimately restrict the browser to execute the Javascript code because no HTL <script> tag is present any more in the response.The greater-than and less-than symbols are replaced by their HTML-encoded output,&lt; and &gt; respectively. In addition to this two tire security approach discussed above, we can also use the following countermeasures to prevent cross site scripting as further safe guards. Setting the correct character encoding: Character encoding can be done in page level or in configuration level. To set the Character encoding at the page level we can use <meta> element or the ResponseEncoding page-level attribute as follows: <% @ Page ResponseEncoding="iso-8859-1" %> R <meta http-equiv="Content Type"       content="text/html; charset=ISO-8859-1" />   To set the Character encoding at the configuration level we have to bring certain changes in Web.config file as follows: <configuration>    <system.web>       <globalization          requestEncoding="iso-8859-1"          responseEncoding="iso-8859-1"/>    </system.web> </configuration> Use white listing approach rather than black listing: Sanitizing user input by filtering out known malicious characters is a common practice. But we should not rely on this approach because an attacker can usually find an alternative means of bypassing your validation. Instead, your code should check for known secure, safe input. There are other safe ways of representing these malicious characters. For example < (less than) and > (greater than) can be represented as &lt; and &gt; respectively. Using the HttpOnly Cookie Option: HttpOnly cookie attribute is supported by Internet Explorer 6 Service Pack 1 and later, which prevents client-side scripts from accessing a cookie from the [removed] property. Instead, the script returns an empty string. The cookie is still sent to the server whenever the user browses to a Web site in the current domain. <a>SQL Injection:</a> Secure coding practice in ASP.NET against SQL injection vulnerability should focus on the following countermeasures: Constrain user supplied input Before applying any countermeasure at the code level we should be concerned about the potential risk associated with denying a list of unacceptable characters (blacklisting) because it is always possible to overlook an unacceptable character when defining the list. Also this kind of validation approach can be easily bypassed by representing an unacceptable character in an alternate format. ASP.NET server side validator controls, such as the RegularExpressionValidator and RangeValidator controls can be used to constrain input. Alternatively we can also the Regex class in our server-side code to constrain input. When user input is captured by an ASP.NET TextBox control, we can constrain its input by using a RegularExpressionValidator control as shown in the following aspx code.. <%@ %> <form runat="server">     <asp:TextBox runat="server"/>     <asp:RegularExpressionValidator runat="server"                                             ErrorMessage="Incorrect data"                                     ControlToValidate="text1"                                             ValidationExpression="^\d{3}-\d{2}-\d{4}$" /> </form>   If the user input is from another source, such as an HTML control, a query string parameter, or a cookie, you can constrain it by using the Regex class from the System.Text.RegularExpressions namespace. The following example assumes that the input is obtained from a cookie.   if (Regex.IsMatch(Request.Cookies["SSN"], "^\d{3}-\d{2}-\d{4}$")) {     // perform the database task } else {     // handle exception }   User supplied input parameters need to be validated before being used in SQL statements. The following data access routine can be taken as an example of how validate user input parameters.   using System; using System.Text.RegularExpressions; public void useraccount(string username, string password) {     // check username contains only lower case or upper case letters,     // the apostrophe, a dot, or white space. Also check it is     // between 1 and 40 characters long     if ( !Regex.IsMatch(userIDTxt.Text, @"^[a-zA-Z'./s]{1,40}$"))       throw new FormatException("Invalid username format");       // Check password contains at least one digit, one lower case     // letter, one uppercase letter, and is between 8 and 10     // characters long     if ( !Regex.IsMatch(passwordTxt.Text,                       @"^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,10}$" ))       throw new FormatException("Invalid password format");       // Perform data access operation (using type safe parameters)     ... }   Use parameterized stored procedures: The following code shows how to use parameters with stored procedures. using System.Data; using System.Data.SqlClient;   using (SqlConnection connection = new SqlConnection(connectionString)) {   DataSet userDataset = new DataSet();   SqlDataAdapter myCommand = new SqlDataAdapter(              "LoginStoredProcedure", connection);   myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;   myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 12);   myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text;     myCommand.Fill(userDataset); }   In the above example the @au_id parameter is treated as a literal value and not as executable code. Also, the parameter is checked for type and length. In the preceding code example, the input value cannot be longer than 12 characters. If the data does not conform to the type or length defined by the parameter, the SqlParameter class throws an exception. Note: Using stored procedure with parameters does not necessarily prevent SQL injection.Take a look at the following stored procedure:     CREATE PROCEDURE dbo.RunQuery @var ntext AS         exec sp_executesql @var GO Now despite being a parameterized stored procedure , this one executes whatever is passed to it.Consider the @var variable being set to: DROP TABLE USERS; Use parameterized dynamic sql: Now if you are not using stored procedure, you still should use parameters when constructing dynamic SQL statements. The following code shows how to use parameters with dynamic SQL statement. using System.Data; using System.Data.SqlClient;   using (SqlConnection connection = new SqlConnection(connectionString)) {   DataSet userDataset = new DataSet();   SqlDataAdapter myDataAdapter = new SqlDataAdapter(          "SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id",          connection);                  myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11);   myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text;   myDataAdapter.Fill(userDataset); }   Using a least privileged database account: Your application should connect to the database by using a least-privileged account. If you use Windows authentication to connect, the Windows account should be least-privileged from an operating system perspective and should have limited privileges and limited ability to access Windows resources. Additionally, whether or not you use Windows authentication or SQL authentication, the corresponding SQL Server login should be restricted by permissions in the database. If your ASP.NET application only performs database lookups and does not update any data, you only need to grant read access to the tables. This limits the damage that an attacker can cause if the attacker succeeds in a SQL injection attack. <h3><a>Avoid Disclosing Error Information</a></h3> Use structured exception handling to catch errors and prevent them from propagating back to the client. Log detailed error information locally, but return limited error details to the client. If errors occur while the user is connecting to the database, be sure that you provide only limited information about the nature of the error to the user. If you disclose information related to data access and database errors, you could provide a malicious user with useful information that he or she can use to compromise your database security. Attackers use the information in detailed error messages to help deconstruct a SQL query that they are trying to inject with malicious code. A detailed error message may reveal valuable information such as the connection string, SQL server name, or table and database naming conventions. Information leakage: Remember that __VIEWSTATE data can be viewed The __VIEWSTATE’s Base64 encoding can be easily decoded, and the __VIEWSTATE data can be exposed with minimal effort. Now the attacker can see the information that may be sensitive, such as internal state data of the application.To encrypt the __VIEWSTATE data we have to add the machineKey attribute in web.config  file as follows: <configuration> <system.web> <machineKey validation="3DES"/> </system.web> </configuration>About the Author: Somnath has been working as an Information Security Consultant iViZ Techno Solutions,India and have successfully carried out countless assignments on vulnerability assessment, penetration testing, web application security, Threat modeling,PCI DSS Compliance for various Banking sector firms, financial institutions, Govt. organizations, Defense, Software development Companies, leading BPOs and various small-mid-large industries.He holds security certifications like OSCP and CNSM.Article Source: <a href="http://www.articlesbase.com/">ArticlesBase.com</a> - <a href="http://www.articlesbase.com/security-articles/secure-aspnet-coding-practice-for-three-most-critical-vulnerabilities-in-web-application-889853.html" title="Secure ASP.NET coding practice for three most critical vulnerabilities in Web Application">Secure ASP.NET coding practice for three most critical vulnerabilities in Web Application</a>

Secure ASP.NET coding practice for 3 most critical vulnerabilities in Web Application

www.ivizsecurity.com

Somnath Guha Neogi (OSCP,CNSM)

Introduction:

ASP.NET provides several exciting security controls, but these need to be understood properly and used wisely. Failing to use the ASP.NET functions properly results in an insecure web application. We see therefore that ASP.NET does not exempt the programmer from following coding standards and procedures in order to write safe and secure application code.

In this paper we will discuss about the code level mitigation for three most frequently found vulnerabilities:

Cross Site Scripting

SQL Injection

Information Leakage

Cross Site Scripting:

An application is vulnerable to Cross Site Scripting if malicious user input is embedded in the HTML response without passing through any particular validation process. Let’s take a look on a vulnerable chunk of code

<%@ Page ValidateRequest="false" %>

<html>

<script runat="server">

void buttonsubmit_Click(Object sender, EventArgs e)

{

Response.Write(comment.Text);

}

</script>

<body>

<form runat="server">

<asp:TextBox runat="server" />

<asp:Button runat="server"

Text="SubmitComment" />

</form>

</body>

</html>

Now an attacker can send malicious request with embedded JavaScript through the comment textbox which will be executed at the client’s browser. To see that this is possible, the above vulnerable script can be fed with the following input:

<script>alert([removed])</script>

Now this type of script injection attack can be mitigated by adopting a two tire security approach. User input validation will form the first tire of security while HTML-encoding on outgoing user data will form a second layer of security. So we can start assuming that all user input is malicious and to safely allow restricted HTML input developers/testers should adopt three security approaches as follows:

a) Add the ValidateRequest="false" attribute to the @ Page directive to disable the ASP.NET request validation.

b) Encode the string input with HtmlEncode function.

c) White listing approach can be adopted by using a String Builder and calling its Replace method to selectively remove the encoding on the HTML elements that you want to permit.

The following .aspx code depicts this as an example.

<%@ Page ValidateRequest="false"%>

<script runat="server">

void submitbutton_Click(object sender, EventArgs e)

{

StringBuilder stringbuilder1 = new StringBuilder(

HttpUtility.HtmlEncode(Txt1.Text));

// Selectively allow  and 

stringbuilder1.Replace("", "");

stringbuilder1.Replace("", "");

stringbuilder1.Replace("", "");

stringbuilder1.Replace("", "");

Response.Write(stringbuilder1.ToString());

}

</script>

<html>

<body>

<form runat="server">

<div>

<asp:TextBox Runat="server"

TextMode="MultiLine" Width="318px"

Height="168px"></asp:TextBox>

<asp:Button Runat="server"

Text="Submit" OnClick="submitbutton_Click" />

</div>

</form>

</body>

The above .aspx page code shows this approach. The page disables ASP.NET request validation by setting ValidateRequest="false". It HTML-encodes the input and then selectively allows the and HTML elements to support simple text formatting.

Now the second tire of security can be brought into the frame by encoding the output to know that the text contains HTML special characters or not.

Response.Write(HttpUtility.HtmlEncode(Request.Form["text"])); Or in case of URL strings that contain input to the client.

Response.Write(HttpUtility.UrlEncode(urlString));

As a result, the HTML response stream of the malicious input <script>alert([removed])</script> will look like this

<script>alert([removed])</script>

This will ultimately restrict the browser to execute the Javascript code because no HTL <script> tag is present any more in the response.The greater-than and less-than symbols are replaced by their HTML-encoded output,< and > respectively.

In addition to this two tire security approach discussed above, we can also use the following countermeasures to prevent cross site scripting as further safe guards.

Setting the correct character encoding:

Character encoding can be done in page level or in configuration level. To set the Character encoding at the page level we can use <meta> element or the ResponseEncoding page-level attribute as follows:

<% @ Page ResponseEncoding="iso-8859-1" %> R <meta http-equiv="Content Type" content="text/html; charset=ISO-8859-1" />

To set the Character encoding at the configuration level we have to bring certain changes in Web.config file as follows:

<configuration> <system.web> <globalization requestEncoding="iso-8859-1" responseEncoding="iso-8859-1"/> </system.web> </configuration>

Use white listing approach rather than black listing:

Sanitizing user input by filtering out known malicious characters is a common practice. But we should not rely on this approach because an attacker can usually find an alternative means of bypassing your validation. Instead, your code should check for known secure, safe input. There are other safe ways of representing these malicious characters. For example < (less than) and > (greater than) can be represented as < and > respectively.

Using the HttpOnly Cookie Option:

HttpOnly cookie attribute is supported by Internet Explorer 6 Service Pack 1 and later, which prevents client-side scripts from accessing a cookie from the [removed] property. Instead, the script returns an empty string. The cookie is still sent to the server whenever the user browses to a Web site in the current domain.

SQL Injection:

Secure coding practice in ASP.NET against SQL injection vulnerability should focus on the following countermeasures:

Constrain user supplied input

Before applying any countermeasure at the code level we should be concerned about the potential risk associated with denying a list of unacceptable characters (blacklisting) because it is always possible to overlook an unacceptable character when defining the list. Also this kind of validation approach can be easily bypassed by representing an unacceptable character in an alternate format.

ASP.NET server side validator controls, such as the RegularExpressionValidator and RangeValidator controls can be used to constrain input. Alternatively we can also the Regex class in our server-side code to constrain input.

When user input is captured by an ASP.NET TextBox control, we can constrain its input by using a RegularExpressionValidator control as shown in the following aspx code..

<%@ %> <form runat="server"> <asp:TextBox runat="server"/> <asp:RegularExpressionValidator runat="server" ErrorMessage="Incorrect data" ControlToValidate="text1" ValidationExpression="^d{3}-d{2}-d{4}$" /> </form> If the user input is from another source, such as an HTML control, a query string parameter, or a cookie, you can constrain it by using the Regex class from the System.Text.RegularExpressions namespace. The following example assumes that the input is obtained from a cookie. if (Regex.IsMatch(Request.Cookies["SSN"], "^d{3}-d{2}-d{4}$")) { // perform the database task } else { // handle exception }

User supplied input parameters need to be validated before being used in SQL statements. The following data access routine can be taken as an example of how validate user input parameters.

using System; using System.Text.RegularExpressions; public void useraccount(string username, string password) { // check username contains only lower case or upper case letters, // the apostrophe, a dot, or white space. Also check it is // between 1 and 40 characters long if ( !Regex.IsMatch(userIDTxt.Text, @"^[a-zA-Z'./s]{1,40}$")) throw new FormatException("Invalid username format"); // Check password contains at least one digit, one lower case // letter, one uppercase letter, and is between 8 and 10 // characters long if ( !Regex.IsMatch(passwordTxt.Text, @"^(?=.*d)(?=.*[a-z])(?=.*[A-Z]).{8,10}$" )) throw new FormatException("Invalid password format"); // Perform data access operation (using type safe parameters) ... }

Use parameterized stored procedures:

The following code shows how to use parameters with stored procedures.

using System.Data; using System.Data.SqlClient; using (SqlConnection connection = new SqlConnection(connectionString)) { DataSet userDataset = new DataSet(); SqlDataAdapter myCommand = new SqlDataAdapter( "LoginStoredProcedure", connection); myCommand.SelectCommand.CommandType = CommandType.StoredProcedure; myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 12); myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text; myCommand.Fill(userDataset); } In the above example the @au_id parameter is treated as a literal value and not as executable code. Also, the parameter is checked for type and length. In the preceding code example, the input value cannot be longer than 12 characters. If the data does not conform to the type or length defined by the parameter, the SqlParameter class throws an exception.

Note: Using stored procedure with parameters does not necessarily prevent SQL injection.Take a look at the following stored procedure:

CREATE PROCEDURE dbo.RunQuery @var ntext AS exec sp_executesql @var GO

Now despite being a parameterized stored procedure , this one executes whatever is passed to it.Consider the @var variable being set to:

DROP TABLE USERS;

Use parameterized dynamic sql:

Now if you are not using stored procedure, you still should use parameters when constructing dynamic SQL statements. The following code shows how to use parameters with dynamic SQL statement.

using System.Data; using System.Data.SqlClient; using (SqlConnection connection = new SqlConnection(connectionString)) { DataSet userDataset = new DataSet(); SqlDataAdapter myDataAdapter = new SqlDataAdapter( "SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", connection); myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text; myDataAdapter.Fill(userDataset); }

Using a least privileged database account:

Your application should connect to the database by using a least-privileged account. If you use Windows authentication to connect, the Windows account should be least-privileged from an operating system perspective and should have limited privileges and limited ability to access Windows resources. Additionally, whether or not you use Windows authentication or SQL authentication, the corresponding SQL Server login should be restricted by permissions in the database.

If your ASP.NET application only performs database lookups and does not update any data, you only need to grant read access to the tables. This limits the damage that an attacker can cause if the attacker succeeds in a SQL injection attack.

Avoid Disclosing Error Information

Use structured exception handling to catch errors and prevent them from propagating back to the client. Log detailed error information locally, but return limited error details to the client.

If errors occur while the user is connecting to the database, be sure that you provide only limited information about the nature of the error to the user. If you disclose information related to data access and database errors, you could provide a malicious user with useful information that he or she can use to compromise your database security. Attackers use the information in detailed error messages to help deconstruct a SQL query that they are trying to inject with malicious code. A detailed error message may reveal valuable information such as the connection string, SQL server name, or table and database naming conventions.

Information leakage: Remember that __VIEWSTATE data can be viewed

The __VIEWSTATE’s Base64 encoding can be easily decoded, and the __VIEWSTATE data can be exposed with minimal effort. Now the attacker can see the information that may be sensitive, such as internal state data of the application.To encrypt the __VIEWSTATE data we have to add the machineKey attribute in web.config file as follows:

<configuration>

<system.web>

<machineKey validation="3DES"/>

</system.web>

</configuration>

Somnath has been working as an Information Security Consultant iViZ Techno Solutions,India and have successfully carried out countless assignments on vulnerability assessment, penetration testing, web application security, Threat modeling,PCI DSS Compliance for various Banking sector firms, financial institutions, Govt. organizations, Defense, Software development Companies, leading BPOs and various small-mid-large industries.He holds security certifications like OSCP and CNSM.

Rate this Article:

0 / 5 stars - 0 vote(s)

Re-Publish

Article Source: http://www.articlesbase.com/security-articles/secure-aspnet-coding-practice-for-three-most-critical-vulnerabilities-in-web-application-889853.html

Article Tags: Web Application Security

Related Videos
Related Articles
Ask / Related Q&A

Play

Learn about the Initialization Code Behind the ASP.NET Web Page

Play

How to Add Event Handler and Logical Code in ASP.NET

Play

How to Add Different Types of HTML Controls and Logical Code in ASP.NET

Play

Learn about Microsoft ASP Page Source Code

Play

How To Setup ASP.NET AJAX - Our Focus in This Series

Latest Security Articles
More from Somnath Guha Neogi

Advice On Protecting Your Netbook

By: Mark Walters | 30/12/2009
Useful information and advice on netbooks. Find out how to make a netbook as safe and secure as possible.

Tutorial to Unlock Windows XP Administrator Password!

By: Fiona | 30/12/2009
The Windows XP administrator passwordis the password used to access the "Administrator" account. This account usually doesn't show up on the logon screen and most people don't know it exists. Usually that's okay because you won't need to use your computer under this account very often. There are a few times when you will need this password! When you're accessing the Windows XP Recovery Console or you're trying to boot into Windows XP Safe Mode, you'll need this password before you can contin

Lost or Forgot Computer Password? Reset Windows XP password!

By: Fiona | 30/12/2009
If you have lost or forgotten your password for logging in to a computer running the Windows XP operating system, there are a few different options

Tutorial to Unlock Windows Vista Administrator Password!

By: Fiona | 30/12/2009
Windows Vista administrator password is the password to an account configured with administrator level access in Windows Vista. There doesn't actually have to be an "Administrator" user account. What you need is the password to any account that can act as an administrator. You may need an administrator password in Windows Vista if you're trying to run certain types of programs or access certain Windows Vista password recovery tools.

Find out Windows 7 Password! Reset Windows 7 Password!

By: Fiona | 30/12/2009
There are a few times when you will need this password. You may need an Windows 7 administrator password if you're trying to run certain types of programs or access certain Windows 7 recovery tools.

Tips to Find the Windows Administrator Password

By: Fiona | 30/12/2009
There are several ways to find your administrator password in Windows.

AntiAdd Will Add Spyware to Your PC!

By: Carl Haugen | 30/12/2009
AntiAdd is a misleading antispyware program that erroneously reports threats to the user. This rogue security program advertises through aggressive and frightening warnings, notifying you that spyware, Trojans and other parasites exist on your PC. This application is malware, although it claims to remove this exact thing. Do not spend your money!

Got Security?...Is your PC As Secure As It Can Be?

By: Paul Lubic | 30/12/2009
The environment in which we conduct our home computing tasks, particularly using the Internet, is becoming more and more hazardous to our computer's health. In recent years the threats to our computing environment have gone from relatively harmless recreational hacking of Web sites to today's mass crime waves by organized criminal groups.

Secure use of cookies

By: Somnath Guha Neogi | 25/11/2009 | Security
To understand the importance of cookies it is imperative to understand what they are primarily used for .Cookies do not act maliciously on your computer systems. They are merely text files that can be deleted at any time - they are not plug ins nor are they programs. Cookies cannot be used to spread viruses and they cannot access your hard drive. This does not mean that cookies are not relevant to a user's privacy and anonymity on the Internet.

Importance of Penetration testing in achieving PCI DSS compliance

By: Somnath Guha Neogi | 30/10/2009 | Security
Penetration testing is addressed by PCI DSS Requirement 11.3 and is significantly different from the PCI DSS Requirement 11.2 which addresses internal and external Vulnerability Assessment.

Difference between safe and unsafe check plugins in Nessus

By: Somnath Guha Neogi | 15/05/2009 | Security
To perform a security assessment without causing any harm to the production environment,we need to have a clear understandings of the difference between 'Safe' and 'Unsafe' checks.This article describes the differences between 'Safe' and 'Unsafe' check plugins for the most popular vulnerability scanner Nessus.

Web 2.0 Security Testing Approach

By: Somnath Guha Neogi | 15/05/2009 | Security
Web 2.0 can be defined as the evolving trend of www technologies and web design that aim to enhance creativity, communications, secure information sharing, collaboration and functionality of the web1. 0. In contrast to the static nature of Web 1.0, Web 2.0 systems rely heavily upon user generated content. In fact, Web 2.0 has been described as the “participatory Web.” For example blogs and photo sharing services enable consumers to add and update their own content.

Seceurity Testing For Online Tour & Travel Websites

By: Somnath Guha Neogi | 25/02/2009 | Security
This article will try to cast your attention towards how we test online tour and travel sites in iViZ. Here in iViZ we emphasize more on finding out new classes of business logic vulnerabilities which would directly bring in huge financial loss or impersonation of users for an organization. Here in iViZ we developed a customize framework which is in itself quite exceptional from the traditional Web Application Security testing approaches.