SQL injection

SQL injection 

Weak Validation Examples	Code Snippets
a)      Replacing single Quotes to double quotes	Sample.aspx.cs catergoryID=Request.QueryString(id); SqlCommand myCommand = new SqlCommand("SELECT  * FROM Products WHERE CategoryID = " + SanitizeSQL(categoryID) +", myConnection); public static string SanitizeSQL(string strSQL)                   {       Return ( strSQL.Replace("'","''") );                   }
Exploit code to bypass this validation	Validation function is assuming that the user will only enter single quote to SQL inject. But this is not the case. For example: Unexpected : 21; Delete from Products where ProductID = 102--
Recommendation	Whenever you are expecting an integer value, the best validation on this type of input is to type cast it and check if it is really an integer. If not, reject the input. Bottom line:  if the input is of a primitive type, one can cast it. e.g             int id; try                         {             id = int.Parse(Request.Form(“userinput”));                                     }             catch (Exception ex)                         {             return;                         } 2.       Use parameterized SQL.

Active X Components 

Weak Validation in Active X	Explanation
Safe for scripting	A control that is marked safe for scripting can be scripted not only by the Web page author who uses it, but by other Web sites on the Internet as well. It gives ability to other Web page authors to reuse the control for malicious purposes.
Exploit code to bypass	ActiveX controls can be hosted by scripting environments and driven by script. In some hosts, such as Microsoft® Internet Explorer, the script can come from an unknown and possibly untrusted source. A control can be initialized by data from an arbitrary interface. This interface could come from either a local or a remote Uniform Resource Locator (URL). This is a potential security hazard because the data could come from an untrusted source.
Recommendation	The SiteLock template enables you to restrict access so that the control is only deemed safe in a predetermined list of domains. SiteLock automatically queries for the URL where the control is hosted, extracts the Uniform Resource Identifier (URI) type and domain name from that URL, and compares the URI to a list to see if the site should be trusted. The developer creates the list at build time. e.g : const CYourObject::SiteList CYourObject::rgslTrustedSites[2] =    {{ SiteList::Deny,  L“http”,  L“users.microsoft.com” },     { SiteList::Allow, L“http”,  L“microsoft.com”       }, Again, it is recommended to use the white list approach here, not the black list approach; Define all sites that are allowed to initiate the control rather than listing out sites which should be denied.

Implementing Client side validation

Implementing client side validation is good as long as you have server side validation controls in place as well. If you only reply on client side validation, your application is wide open for attacks.

To bypass client side validations, an attacker can:

o   Switch off Java script in browsers. Since the browser does not execute any scripts, all script based validations on client end will fail.

o   Use HTTP debugging proxy software’s to fiddle with the incoming responses and outgoing requests. Tools like Fiddler can do this seamlessly.

o   Use SOAPTool like tools to bypass the thick /smart client’s altogether and send malicious data to the back end web services. All thick client based validations will no longer be in effect.