Approach for Source Code Review
The
approach for SCR is fundamentally different from an Application
Penetration Test. While an Application Penetration Test is driven by apparently visible use-cases
and functionalities, the maximum possible view of the application in
terms of its source code and configuration is usually available during
an SCR. Apart from auditing important use-cases following standard practices, our approach consists of two broad steps:
Finding Security Weaknesses (Insecure/Risky Code Blocks) (Sinks)
A security weakness is an insecure practice or a dangerous API call or an insecure design. Some examples of weaknesses are:
- Dynamic SQL Query: string query = "SELECT * FROM items WHERE owner = '" + userName + "' AND itemname = '" + ItemName.Text + "'";
- Dangerous or risky API call such as RunTime.exec, Statement.execute
- Insecure Design such as using only MD5 hashing of passwords without any salt.
Correlation between Security Weakness and Dynamic Input
Dynamic
construction of an SQL Query without the necessary validation or
sanitization is definitely a security weakness, however it may not lead
to security vulnerability if the SQL query does not involve any
untrusted data. Hence it is required to identify code paths that start
with an user input and reaches a possibly weak or risky code block. The
absence of this phase will leave huge number of false positive in the
results.
This step
generally involves enumerating sources and finding a path between source
to sink. A source in this case is any user controlled and untrusted
input e.g. HTTP request parameters, cookies, uploaded file contents etc.
