Static code analysis analyses source code and identifies the bugs before the program is run. Vulnerabilities are identified in the source code through Static source code analysis (SSCA); Developers use SSCA to ensure that codes are error-free.
Developers are some of the most creative individuals, but sometimes, while developing functionality, logic or creating any new technology all over, they can unintentionally introduce vulnerabilities, and this is where the static source code analysis jumps in.
Static Source Code Analysis (SSCA) debugs a set of codes before they are executed or pushed as the main application. SSCA is done by scrutinizing the code against programming standards/policies and analyzing important functionalities of the application to find either logic flaws, use of outdated packages, code vulnerabilities, dangerous functions or a lot more.
1. Programming Language
Programs written in safe languages like C# or Java are less susceptible to security bugs like buffer overflows than other languages like C and C++. While working on a SAST, the programming language you are working with determines the bug types in the application.
Performing SAST can be a good starting point for strengthening the security, but even an impeccably executed SAST cannot help reduce 100% of the risk. That’s why code reviewers need prioritization; they need to prioritize functionalities or bugs for testing. Start with finding critical severity bugs and gradually move into the low-level bugs. Lines of code too can determine the number of bugs that can be present in a source code: the more the number of lines in the source code, the more chances of finding security bugs.
3. Resources, Time allocation and the deadline
Assigning resources can be a bit tricky; a complicated application will require someone with a deep understanding of the programming concept, logic, along with the ability to swiftly analyze the code. Further, the assigning must be time-bound; Time plays a vital role in source code review; any complicated program requires more time and resources; if the same project is allotted less time, prioritizing the bugs and functionalities should become the first task.
Though, there exists a decent number of good Source Code Analysis tools that can help a reviewer by finding many code vulnerabilities in a source code with only a few false positives. But ideally, these tools don’t touch the unexplored territories of Business Logic Vulnerabilities; they come with a very limited understanding of bugs and their logic. Design flaws are something these tools can barely evaluate. And Lastly, many times, issues reported by these tools are a false positive and not a security vulnerability.
Nevertheless, SASTs can many times be helpful and save a lot of time for a reviewer. Choosing a proper SAST is an essential task too. Few tips to follow while looking for a proper SAST:
Static Source Code review, used only for, identifies “Insecure Code”, and an application developed without proper secure coding standards will be prone to various vulnerabilities. Secure Coding or Defensive Coding loosely translates to following best coding practices while keeping the security of the application in mind. Applications developed via these practices are less susceptible to vulnerabilities and promise the best application security.
Below are some Secure Coding Standards a Developer must follow:
Injection attacks allow any malicious user to add or inject arbitrary commands or content into an application that can eventually cause the application to behave in an unintended way.
Injection vulnerabilities can lead to various security issues such as:
Let us discuss one of the most common injection vulnerabilities:
Considering that SQLi is the most common injection vulnerability that exists, These can be easy to exploit. The issue with handling SQL queries in the legacy applications is that previously developers gave close to zero thoughts about secure coding practices and many times ended up using string concatenation of user input with a predefined SQL statement, which an attacker could use to leverage the vulnerability.
When the SQL parser is unable to differentiate between actual code and user input, an attacker can craft a malicious SQL payload and compromise the application’s data.
Taking the example of an insecure Java code dealing with an SQL Query
String query = “SELECT * FROM users WHERE forename = ‘ “+ ﬁrstname +” ‘ AND surname= ‘ ” + lastname+ ” ‘ “;
Statement stmt = connection.createStatement(); ResultSet rs = stmt.executeQuery(query);
Here the value of the variables “forename” & “surname” is directly being concatenated to the SQL query string without any encoding, malicious character escaping or any kind of input sanitization. When an attacker provides malicious input to either of the variables, the SQL Parser, not able to differentiate between the actual line of code and user-input, will eventually add the malicious input as a valid code into the SQL query, thus eventually executing a successful SQL injection attack.
SQLi demonstration for the non-compliant code:
String query = “SELECT * FROM users WHERE forename = ‘ “+ ﬁrstname +” ‘ AND surname= ‘ ” + lastname+ ” ‘ OR ‘1’=’1’ “;
Statement stmt = connection.createStatement(); ResultSet rs = stmt.executeQuery(query);
</Compliant Code via Parameterized SQL Queries>
String query = “SELECT id, ﬁrstname, lastname FROM authors WHERE forename =
? and surname = ?”;
PreparedStatement pstmt = connection.prepareStatement( query ); pstmt.setString( 1, ﬁrstname );
pstmt.setString( 2, lastname );
In the above Code Snippet, SQL Query is crafted in a manner that does not rely on client-side input and then the “PreparedStatement -> pstmt” is generated from it. The “setString” function is used to replace the 1st question mark with the string value of “firstname” and the 2nd question mark with the string value of “lastname”. The “setString” function, when called, makes sure that no SQL syntax is present in the string value.
Few checks to perform to prevent SQL injection:
Web applications and web services both use authentication as the mean of access control via valid credentials. Access control to any web application or service is essential as it protects the CIA triad of the application.
Authentication is the first step towards the protection of any application. An authenticated user has the privilege of authorization, wherein they can interact with the application with a certain privilege, whereas an unauthenticated user is denied from using the same application.
A web session is a sequence of HTTP requests and response cycles linked to the user. The session enables establishing access rights, interacting with the application and a lot more.
Any code reviewer must be able to determine the technique employed for session management of the user so that they can spot vulnerabilities related to that technique.
The implementation of a secure session must meet the following requirements:
While reviewing the code for Session management, do look out for few common issues, such as, code reviewer needs to understand what information is being stored into an application cookie. They need to make sure that no sensitive information is leaking in the cookie content:
<forms loginUrl=”member_login.aspx” cookieless=”UseCookies”
requireSSL=”true” path=”/MyApplication” />
void session_set_cookie_params ( int $lifetime [, string $path [, string
$domain [, bool $secure = true [, bool $httponly = true ]]]] )
A developer must always remember to enable custom error pages so that any attackers can not mine any sensitive information.
<customErrors mode=”Oﬀ” />
<customErrors mode=”RemoteOnly” />
<customErrors mode=”On” defaultRedirect=”YourErrorPage.htm” />
Hardcoded credentials must always be removed from the configuration file. If left out, you are providing attackers direct access to the application.
<user name=”John” password=”[email protected]″/>
<forms timeout=”129600″ name=”myWebApp” protection=”All” slidingExpiration=”false” loginUrl=”~/Account/login.aspx” cookieless=”UseCookies”/>
Debugging mode enabled can help an attacker learn sensitive information about the application and may formulate an attack plan.
<compilation debug=”true” targetFramework=”4.5″>
<compilation debug=”false ” targetFramework=”4.5″>
Asp.net web application allows storing the session token in the page URLs rather than a cookie.
Tracing features can help a developer to debug an application, but for an attacker, Tracing features are like a goldmine as an attacker can utilize this feature to attack the application.
<trace enabled=”true” localOnly=”false”/>
<trace enabled=”false” localOnly=”true”/>
Static source code analysis helps to analyze the code without executing it. This allows the developer to identify vulnerabilities hiding in the remote and unattended section of the code. Static code analysis can spot bugs in the early stages of the development cycle, thereby; leading to a sharp decrease in bug fixing costs. Static source code analysis must be integrated into any organization’s software developing process.