Secure coding — Part 1


- Bypass application input validation.
- XSS cross-site scripting.
- SQL injection.
- Command injection.
- Log injection.
- HTTP response splitting.


The purpose of this publication is to detail a set of requirements that should be addressed during the construction phase (e.g. coding) and verified during code reviews to assess the security posture of the application. The aim of these requirements is to prevent most threats and vulnerabilities found in applications through the use of secure coding practices.

Input Validation

Input validation is an effective application security control. It is used to prevent a host of vulnerabilities such as SQL injection, log injection, buffer overflows, etc. All input supplied by an untrusted source, be it a user or another application, must filter the input before processing by the receiving application. Special care must be taken so that the input validation is not bypassed. It is preferable that applications use exact matches for input validation. However, a whitelist, or known good, approach to filtering data is more flexible and business friendly. Known bad, or black list approach, is nearly impossible to get correct as new bad combinations will continue to be added. Black lists should be avoided. Lastly, to avoid bypassing input validation applications should employ the use of canonicalization. Canonicalization is necessary because the input could be in several different encodings (UTF8, UTF16, UTF7, etc.) Without canonicalization applications would have to account for every encoding.

Bypass application input validation

Applications often use client side only validation to ensure the validity of the data within the application. While this technique provides good user experience it does not provide any protection from tampered data on the server side. Proxies and other tools used by attackers can easily bypass any front end input validation controls in place, thus leaving the application wide open for data manipulation attacks.

  • Allowed character set.
  • Minimum and maximum input string length.
  • Whether NULL value is allowed.
  • Whether the input parameter is required or not.
  • Numeric range.
  • Specific format and patterns (regular expressions).
  • Using white listing (e.g. validate what is allowed, deny anything else) instead of blacklisting (invalidate what is not allowed and allow everything else).
  • Keeping user input out of control path; do not let user input control the flow of the application.
  • Not filtering input from unsafe characters.
  • Assuming that malicious data only comes from the client.

XSS cross-site scripting

Cross-site scripting attacks are an instantiation of injection problems, in which malicious scripts are injected into the otherwise benign and trusted web sites.

  • Sanitize all input from any malicious characters, such as (<,>, (,), #, % ‘) that can be used to execute a malicious script on the client browser. In addition to the characters above, checks for the key words “script” and “javascript” should also be done.
  • Observe requirements of output encoding as outlined in section 0.

SQL injection

Constructing dynamic SQL statements from user generated input may allow attackers to change the grammar of the SQL query and run additional SQL commands under user input control.

  • Filter SQL special characters such as “;’-&\ that can be used to alter the SQL query and perform a SQL injection attack.
  • Use, parameterized queries with variables bound to specific data types.
  • Avoid concatenating input parameters with SQL statements, string concatenation of input parameters should be avoided and parameters should be set independently from the query by using appropriate method calls such as SetInt(), SetString() etc.

Command injection

Command injection problems stem from using user controlled input without validating the input. This allows the malicious attacker to inject their own commands and control the program. Command injection is a common problem with wrapper programs. Often, parts of the command to be run are controllable by the end user; a malicious user can inject a delimiting character such as “;” and insert another command of his/her choosing (e.g. CRLF “\r\n”).

  • Line Feed (LF, ASCII 10).
  • Pipe |
  • Semi-colon ;

Log injection

Log injection, or log forging, is the process of un-validated user input ending up in the application logs. This allows an attacker the opportunity to cover their tracks by injecting false log statements into the application and other system log files.

HTTP response splitting

HTTP Response splitting occurs when normally only one response header would be returned, but through code the response is split into two parts. Typically this is exploited by allowing un-validated data enter the web application which can lead to XSS attacks.

  • Filter invalid characters such as CR = %d = \r and LF =%0a =\n.
  • Input validation should be performed on the server side.
  • The client, including cookies should not be trusted without being validated on the server side.

I solve problems to empower operations, maximize performance and increase profits.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store