Improving Web Application Security: Threats and - CGISecurity

Chapter 21: Code Review 611Check to see if your code attempts to sanitize input by filtering out certain knownrisky characters. Do not rely upon this approach because malicious users cangenerally find an alternative representation to bypass your validation. Instead, yourcode should validate for known secure, safe input. The following table shows variousways to represent some common characters:Table 21.2 Character RepresentationCharacters Decimal Hexadecimal HTML Character Set Unicode" (double quotes) &#34 &#x22; &quot; \u0022' (single quotes) &#39 &#x27; &apos; \u0027& (ampersand) &#38; &#x26 &amp; \u0026< (lesser than) &#60 &#x3C; &lt; \u003c> (greater than) &#62 &#x3E; &gt; \u003eIdentify Code That Handles URLsCode that handles URLs can be vulnerable. Review your code to see if it is vulnerableto the following common attacks:● If your Web server is not up-to-date with the latest security patches, it could bevulnerable to directory traversal and double slash attacks, such as:http://www.YourWebServer.com/..%255%../winnthttp://www.YourWebServer.com/..%255%..//somedirectory●If your code filters for “/”, an attacker can easily bypass the filter by using analternate representation for the same character. For example, the overlong UTF-8representation of “/” is “%c0f%af” and this could be used in the following URL:http://www.YourWebServer.com/..%c0f%af../winnt●If your code processes query string input, check that it constrains the input dataand performs bounds checks. Check that the code is not vulnerable if an attackerpasses an extremely large amount of data through a query string parameter.http://www.YourWebServer.com/test.aspx?var=InjectHugeAmountOfDataHere