First of all folks, my apologies for this delayed post. I have been traveling and busy doing a very interesting Threat Modeling exercise. But i am back & Lets cover some other validation bloopers -
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 |
e.g int id; try { id = int.Parse(Request.Form(?userinput?)); } catch (Exception ex) { return; } 2. Use parameterized SQL. |
| 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.
However, there is no technological restriction enforced to limit which client can communicate with a server, or vice versa; such restrictions are either unrealistic or not possible. Tools like Fiddler, TamperIE, etc make it possible to edit requests and responses between a client and server or to play back a client request or server response. These proxy tools can even alter packets and send data that the vendor?s software would never send.
Keep it Secure.
Anmol Malhotra
Senior Security Consultant
ACE Services
hypnos infosecurity mission hypnos infosecurity team careers at hypnos infosecurity hypnos infosecurity downloads cyber crime news
No comments:
Post a Comment