Category:Secure programming

Throughout the history of application development, programmers have repeatedly made the same mistakes, their educators have repeatedly inadvertantly missed important nuances, and the industry has globally repeated these mistakes in the corporate world. This has yielded many developers who write vulnerable applications simply without knowing better; in some cases, developers even think that they are securing the application when in fact they are creating the vulnerabilities themselves. Only once developers are properly educated from the ground up does it become possible to foster the proper development methodology and good practices for security-centric and quality-assurance driven development.

Introduction

Many of the common programming pitfalls responsible for modern vulnerabilities are less than obvious and completely language agnostic, or they are entirely small mistakes that are easy to miss or glance over. These pitfalls are mostly based around concepts, so proper and improper implementations exist in nearly each language. This article focuses on interpreted languages, but this does not mean that the vulnerabilities exist only in interpreted languages.

Concepts

It's as simple as realizing that certain things may cause a bug. Bugs are what hamper stability, performance/efficiency, and security. By solving any of these problems in their entirety at least some of the others will be solved in the process. So, talking about bugs - bugs include everything from the program improperly displaying funny characters on the screen to reproducible application crashes. The more accidental impact (complete crash vs. small hiccup) a bug has, typically its impacts in all these areas are to scale with the impact on a user experience - while risk applies to and defines the broader scale (the purpose for the existence of the application or system).

Note: The previous sentence is extremely awkward and unclear. Recommend breaking it into two sentences, something like... The impact that a bug has on security, stability, or performance is typically proportional to the impact that it has on user experience.

Most bugs are the result of a program receiving unexpected data and using it in a way that results in the problem. Because the ways that an application is traditionally programmed to receive input are finite, solutions to several types of problems with user input can be found. Data may contain illegal characters, exceed an allowed length or maximum value, require a type or sign translation, etc. When an application is able to compensate for this, it is because the developer makes one of two choices: to convert the data somehow into acceptable data, or to reject the data entirely with an error message and demand re-submission of the input in proper form. Sometimes the input's "illegal characters" may even be a part of the application's desired output - making the challenge more difficult.

Sanitizing

There are two primary techniques used for input sanitization in interpreted languages: whitelisting and modification. Modification is a process which modifies data submitted or inputted by a user, whereas input whitelisting simply checks to see if the input matches a particular criterium. In the case of input modification, the functionality exposed is usually executed regardless of the resulting data; whereas in the case of input whitelisting, the functionality is only exposed if the input meets the whitelist's criterium. If the functionality provided by a whitelisted input is still exposed, usually the whitelisted input is reset to a particular default value of some sort. Some more specific examples of each technique are below:

Input Whitelisting

A. Cancel process if malformatted - Only input matching a particular format will trigger the processing of the inputted data

B. Cancel process if incorrect type - Only input of a particular type (integer, string, negative number, etc) will trigger the processing of the inputted data

C. Cancel process if out of bounds - Only input of a particular length, between two particular lengths, or between two particular values will trigger the processing of the inputted data

D. Cancel process if not whitelisted - If the inputted data is not in a list of allowed choices, it is not processed.

Input Modification

A. Sanitize-by-reformat - Characters or strings which may be malicious in user input are escaped or encoded to make them safe for evaluation

B. Sanitize-by-typecast - User input is forced into the correct data type. (Casted from string to integer, or vice versa).

C. Sanitize-by-boundary - When a user input reaches a particular size, all additional input is ignored. In some cases (e.g. decimals) this could be a string truncation, an integer whole number cast, or rounding.

D. Sanitize-by-delete - Characters or strings which may be malicious are completely removed from a user input.

Implications

You may notice that whitelisting technique "A" corresponds to modification technique "A", "B" to "B", and so on. In many cases, a combination of both modification and whitelisting is used for sanitizing. Performing these steps in the wrong order, or even inadvertantly casting a value to the wrong data type may prove costly.