• Did you know that 92% of the developers never received
    Security Coding training from their organization ?

    Did you know that only 3% developers had the ability to
    fix the vulnerabilities discovered from a pentest in the first attempt ?

  • Did you know that 59% developers believe that
    security will affect the application functionality and usability
    and hence refrain from implementing security ?

    Did you know that application security revalidations have extended
    to almost 7 iterations for most security conscious organizations ?

Source Code Review

Security Code Review is the process of auditing the source code for an application to verify that the proper security controls are present, that they work as intended, and that they have been invoked in all the right places. This helps to identify whether the developers have misconfigured any application configuration parameters, whether confidential data is stored in code, whether input parameters are validated, comments are sanitized, etc. If done post – development phase, this would help in reducing the cost and time involved due to repetitive vulnerability assessment of the application.

In this service, we will review:


Injection flaws allow attackers to relay malicious code through an application to another system. Any time an application uses an interpreter of any type there is a danger of introducing an injection vulnerability. We carefully validate the data provided to ensure that it does not contain any malicious content, also we ensure that the web application runs with only the privileges it absolutely needs to perform its function. We rigorously check if any user information is been inserted into the command.

Developers use multiple developer user accounts in the development environment and save their credentials in client side code. These developer user accounts are missed out or purposely left out while migrating to the production environment. Accessing the application through these accounts gives complete access to the application.

Buffer overflows are not easy to discover and even when one is discovered, it is generally extremely difficult to exploit. Nevertheless, attackers have managed to identify buffer overflows in a staggering array of products and components. When reviewing code, we understand that there are several avenues where heap related vulnerabilities may arise. Code that seems innocuous at the first glance can actually be vulnerable under certain conditions. Since there are several variants of this vulnerability, we will cover only the issues that are predominant.

Our team reviews whether an application code is vulnerable is to see if each link and form contains an unpredictable token for each user. Without such an unpredictable token, attackers can forge malicious requests. We focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets.

Client side code injection attack wherein an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. In order to run malicious JavaScript code in a victim’s browser, an attacker first find a way to inject a payload into a web page that the victim visits. We produce a set of reusable security components in several languages, including validation and escaping routines to prevent parameter tampering and the injection of XSS attacks.

We ensure that the supplied value is valid, appropriate for the application, and is authorized for the user. By sanitizing input and creating a list of trusted URL's, we suggest all redirects to first go through a page notifying users that they are going off of your site, and have them click a link to confirm.

Cryptography provides for security of data at rest (via encryption), enforcement of data integrity (via hashing/digesting), and non-repudiation of data (via signing). The use of non-standard cryptographic algorithms, custom implementation of cryptography (standard & non-standard) algorithms, use of standard algorithms which are cryptographically insecure (e.g. DES), and the implementation of insecure keys can weaken the overall security posture of any application. We implement aforementioned methods which enables the use of known cryptanalytic tools and techniques to decrypt sensitive data.

The use of a hard-coded password increases the possibility of password guessing tremendously. It may happen that developers tend to hard-code the keys to encrypt the password or the session in the source code. We would evaluate whether such keys are randomly generated or are stored in the code.

Here we focus on detecting anomalies associated to the session ID, such as its manipulation. With the goal of detecting user misbehaviours and session hijacking, we bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. We record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session. subtle

While most of the files within a web server are directly handled by the server itself, it isn't uncommon to find unreferenced or forgotten files that can be used to obtain important information about the infrastructure or the credentials. All these files may grant the tester access to inner workings, back doors, administrative interfaces, or even credentials to connect to the administrative interface or the database server. Here we would not don’t rely on automated scans but we would perform manual checks as a part of our assessment strategy."