Web Application Audit

In this article we will be diving deep about this interesting topic Web Application Audit. But before that, let us see what this Web Application Audit really means !

Defining the Web Application Audit


The auditing looks for the security misconfiguration, vulnerabilities, end-points, and also the loopholes present within the Web Application.
   
It also includes static and dynamic code analysis part (I.e, secure coding) and looking for the flaws of business logic present in the web application. Well, now you got to know what it really is.
Now, let us see what components will the audit deals with.
The security audit mainly deals with the following components.

  • Software used by the web application
  • Plugins used by the web application
  • Themes used by the web application
  • Third-Party components used by the web application
  • Software and Hardware configurations used by web application
  • Server settings used by the web application
  • Extensions used by the web application
  • Secure Sockets Layer (SSL) connections used by the web application

Secure Sockets Layer (SSL) connections used by the web application

Now you know where does the security audit deals with. It is time to know why you really need Web Application Audit.
   
Let us see that.

Need of Web Application Audit


Reputation
   
    Cyber attacks often lead  to data breaches, financial loses and degrades the reputation of the organization.
   
    So, in order to stay one step ahead, it is preferable to conduct web application audit.
   
Challenges the Security Mechanisms
   
    Security audits often challenges and validates the already implemented security policies and testing mechanisms and helps to improve the security of the web application.
   
A Step Ahead
   
    Security audits helps to discover the loopholes, vulnerabilities, business logic flaws before a hacker finds them.
   
    Since audits helps us to find before an attacker finds through this we can know the severity of the discovered bug and take appropriate measures to fix the vulnerabilities.
   
    Now you understood why you need the web application audit.
   
    Now let us see what are the steps involved in the auditing process.

Steps of Web Application Audit Process


Auditing is done in 5 steps. Let us see what are they !

Step 1 : Reviewing The Web Application

This is the first step and it is used to reviewing the web application from a high level.
   
 Here, we understand the components so that we can come out with a plan to address all of the potential security vulnerabilities, performance bottlenecks and other issues that can arise from an application that has been ignored for a while.
   
    It mainly focuses on the following :
   
    Architecture – Web application architecture ranges from monolith applications hosted on internal rack servers to micro services hosted on small cloud instances.
    Database – Web application databases come in many shapes and sizes, ranging from PostgreSQL to MongoDB to Redis, while many applications use multiple databases.
   Third-party libraries – Since third-party libraries are unavoidable in many situations, it is important to ensure they are secure and updated at all times.
   Testing – Writing automated tests and running them before each new code contribution, developers can avoid introducing bugs that cause the failure.
       

Best example is Test-driven development (TDD) which is widely considered a best practice for the modern web applications.

Step 2 : Assess Security

This is the step where we have a clear checklist of vulnerability checks to perform on the web application. it consists of wide range of security risks.
   
    The Open Web Application Security Project ([OWASP](https://owasp.org)) provides the required standards for the web applications which will be helpful during the auditing process.
   


   
  This [pictograph](https://owasp.org/Top10/assets/mapping.png) shows the OWASP top 10 risk factors which gets updated for every 4-years. 

The OWASP provides [top 10 risk factors](https://owasp.org/Top10/) which we should have an eye on !

Step 3 : Check Compatibility

This is the step where we run the compatibility check to see what might break if we update everything.
This compatibility check occurs in two ways
   
  Language compatibility : It represents how does a small upgrade in the web application’s programming language or framework will impact its functionality.
   Dependency compatibility : It refers to the compatibility of various third-party dependencies with a different version of the underlying programming language or the framework. 

Let us say you have a PHP web application running on version 5.x. With the upcoming updates by the PHP the current version is no longer maintained and there are several known security vulnerabilities, which means that you must upgrade, but you’re not sure if the application will still work if you upgrade because of the compatibility.

Step 4 : Run Code Metrics

This is the step where we come up with an action plan which runs some basic code metrics. These code metrics provide insights into complexity, performance, errors and other issues which can guide in the upgrading process.
   
The following are the main important code metrics :

    Cohesion of methods : It deals with the responsibility of a class. This metric should be equal to one in an ideal world.
   Maintainability Index : It measures the maintainability of a project by looking at the commented lines, LOCs (line of code), and the complexity.
 Halstead’s Difficulty : It deals with the software’s vocabulary and length of operators and operands.

Step 5 : Compile Recommendations

This is the final step where it involves in making recommendation based on the four areas of the auditing process.
   
These four areas include : 
These recommendations will help to upgrade the web application and keep it up-to-date.

  • Architecture review
  • Security review
  • Compatibility review
  • Code metrics review

These recommendations will help to upgrade the web application and keep it up-to-date.

Tools used in Web Application Auditing


Nikto

   
 Nikto scan output of a web application

Skipfish


Skipfish scan output of a web application

Nessus

Acunetix


OWASP ZAP

OpenVas

Conclusion


That’s all about the Web Application Audit. After reading this essay, I hope you found it enjoyable and learned something new. We have learned what is auditing, why do we need it, where does it impact, what steps are involved, and tools useful in auditing with practical outputs along with some interesting assessment scanners.

Call Us