No code = no issues. No sinks = no vulnerabilities. No user-controlled input = no vector of attack.
- always delete
obsolete,dead,unreachable,unreferenced code. - do not ask the user to provide more input than needed. In several situations, needed data can be generated by the system. e.g. name of the uploaded file
- use least expressive language to talk to the application
Obsolete code: code that may have been useful in the past, but is no longer used, e.g. code to use a deprecated protocol. May be called dead code as well
Dead code: code that is executed but redundant, either the results were never used or adds nothing to the rest of the program. Wastes CPU performance.
function(){
...
// dead code since it's calculated but not saved or used anywhere
$foo + $bar;
}Unreachable code: code that will never be reached regardless of logic flow.
function(){
return 'foobar';
// following line is unreachable
$a = $b + 1;
}Unreferenced: variable (method, function etc.) that is defined but which is never used.
Unreachable, unreferenced and dead code can be found with static analysis ( PHPStan, Phan, Psalm ).
Obsolete(dead) code can be found with dynamic analysis and tombstone concept
The Halting problem is reducible to the problem of finding dead code. That is, if you find an algorithm that can detect dead code in any program, then you can use that algorithm to test whether any program will halt. Since that has been proven to be impossible, it follows that writing an algorithm for dead code is impossible as well.
- Unused code adds complexity
- Unused code is misleading
- Dead code can come alive
Rise of dead code: During the summer of 2012, Knight Capital Group caused a major stock market disruption and suffered a loss of over $400 million when a botched software deployment caused dead order handling code to be executed. The code had not been tested in many years and resulted in a deluge of orders hitting the market that could not be canceled.
Do context-specific escaping on context boundary. Caution is the parent of safety:
- escape data as close to the sink as possible.
- escape any data no matter if it's user-provided or system generated.
- extract the raw value of ValueObject right before escaping
Access to computational power is a privilege
Parse, don'tvalidateinput data as close to thesourceas possible- Use Always valid
ValueObjects(force invariants) - Do not transfer malicious data from
sourcetosink
Parsing: A parser is a software component that takes input data (frequently text) and builds a data structure Validation: Validation is a process that uses routines, often called "validation rules", "validation constraints", or "check routines", that check for correctness, meaningfulness, and security of data that are input to the system.
Source: The program point that reads external resource (user-input or any other data that can be manipulated by a potential attacker).
Sink: The program point that writes to the external resource.
Don't forget information regarding the validity of a certain input
- Do not use strings as a ubiquitous data type for unstructured data. Declare custom types instead, using
ValueObjectsto distinguish different kinds of data - Pass instances of custom types (
ValueObjects) fromsourcetosink - Use raw values of
ValueObjectonly inside a single context, always pass ValueObjects across the boundaries
This is needed to not have to do validation again here and there or blindly assume that validation was done before, in other words, it prevents shotgun parsing problem.
All sources are born at the same architectural level and should be treated equally.
- Apply identical parsing/validation/escaping/sanitization for the same data coming from different
sources.
Throw exceptions (fail hard) for interactive input, degrade gracefully for non-interactive one
Avoid ambiguity
In multi-tier software ensure that every tier parses input identically. (See HTTP request smuggling, HTTP Parameter Pollution)
Use read-once ValueObjects for sensitive data. Its main purpose is to facilitate detection of unintentional use.