What follows are some of the most common procedures for documenting and remediating Web app vulnerabilities, and how a pentesting consultant might generally decide to approach such a task. Some of these steps might vary from one organization to the next, but the general procedures remain the same.
What is the proper format for documenting the results of a penetration test?
When documenting the results of a Web app penetration test, it is important that both the pentester and the organization for which he is undertaking the work agree on a format that needs to be followed. This means that there is no set format that pentesters use in general, so there is some flexibility in the documentation aspect of a Web app pentest. It is important that the company which has requested such testing be able to understand the results, as well as what remedial actions are required after the testing. Other parties that will be looking at the report are: developers, project managers, business owners, management and the IT department, as well as those that are responsible for auditing and compliance. The main aspect of reporting to keep in mind is that it must be easy to read and logically set up so that the sequence of testing makes sense to everyone. The list of remedial actions should be clearly defined. The report should also suggest which parties are responsible for gaps in the app’s security; the task of repairing the issue can then be delegated accordingly. Obviously the pentester cannot know all of the internal responsibilities for each of the departments, so in some instances the stakeholders will have to meet after the pentesting has been completed and the report has been finalized and issued.
Does the reporting format for web apps differ from other areas?
This will depend on the application, the company, and how the application is being used. In most instances where vulnerability assessments and pentesting are carried out on Web applications, the product is Internet-facing, which means that all activity that takes place with the website is coming from external sources. The report will reflect this, and as such, would have a different list of vulnerability considerations that need to be addressed, as opposed to an application that runs local instances within the corporate network.
What information should these documents include?
A standard Web application format usually includes the following:
Begin with an executive summary, which includes an overview and summary of findings that are easy to understand for non-technical stakeholders The scope of the report needs to be detailed next. This explains what needed to be tested and how it was tested Impact assessments are then listed, showing the effects of each potential issue Items such as issues that are beyond the scope of the assessment might also be mentioned, as well as the pentesting team that is responsible for the work done Key findings are then presented in a separate section, which shows which issues occurred in which locations and which departments or control areas are responsible for the security findings The control areas and departments also need to be defined, so that the findings can be delegated to the appropriate teams for remediation Next comes a detailed findings section which lays out all of the steps that were taken in performing the pentesting. It explains the reasons for testing these elements, as well as the methods that were used This is then followed up by a technical summary, which explains the general state of Web app vulnerabilities, in terms of the agreed pentesting activities that were carried out A vulnerability-and-impact table is also usually included, with an ID, name of vulnerability, explanation of vulnerability, ease of exploit and the recommended remedy
What should the general tone and technical level be?
The language that is used in the report will differ from section to section. The executive summary usually spells out the entire pentesting procedure, from methodology to implementation to results, in plain language that easy to understand for non-technical personnel. As the report progresses, the detail and technical information become more intensive. This is so that the developers and technical staff can understand what areas of the product need to be shored up and strengthened so that the vulnerabilities are removed from the system.
Should there be multiple reports of the same data to inform non-technical parties?
This is generally not necessary, as it creates additional work for the pentester. If the report has a good mix between plain language, and technical information, then it is usually acceptable to all parties. If there is a need for more technical information, then a separate report can be generated to elaborate further.
Are there ever grounds for not reporting a vulnerability that can be fixed immediately?
All vulnerabilities are reported, except in cases where the vulnerability falls outside of the scope of the penetration test. This is because the report needs to detail only the vulnerabilities that pertain to the specific application that is being pentested. If the consultant was to write a report about all of the vulnerabilities on all of the systems within the organization, then they would not be able to effectively compile the report for which they have been chosen to create it. If a serious issue is detected but is outside of the scope of the investigation, then the pentester may decide to make specific mention of it as an issue which exists but is outside of the scope of the report.
What are some of the most common vulnerabilities found, and what fixes are generally used?
There are many common issues that get picked up in pentesting exercises, and these are often the same issues that are mentioned in the OWASP Top 10 list for Web Applications. The 5 most common web application vulnerabilities for 2017 were:
Vulnerability: Injection
Injection flaws like SQL, No SQL and LDAP injection are very common security vulnerabilities in Web application development. Injection is the process whereby an attacker can send unauthorized code into a database interpreter, tricking it into executing malicious code, causing damage or granting unauthorized access to the attacker. Solution: The recommendation for preventing injection is to keep data separate from commands and queries. This makes it more difficult for attackers to leverage basic SQL injection tools to attack web applications. This is accomplished by using safe APIs, positive whitelists for server-side input validation, escape characters and SQL LIMIT functions.
Vulnerability: Broken authentication
Poorly-implemented user authentication and session management in the application’s code leads to attackers being able to compromise security measures such as passwords, keys and other session information. This has the potential to allow attackers to log onto systems using stolen or compromised credentials. Solution: Implement multi-factor authentication where possible, do not deploy any application with default authentication, implement checks for weak passwords, ensure that proper procedures exist for registration, credential recovery and API-hardening against account enumeration attacks.
Vulnerability: Data exposure
Many web applications fail to protect sensitive information, like financials and confidential and personal data. This information can be leveraged by cybercriminals to commit fraud and identity theft, which means that poorly-designed web applications have the potential to expose the users to criminal activities. Solution: Classify data that is processed, stored or transmitted by an application and then identify which data is sensitive. Once you have classified which data is sensitive, check to ensure that it can be discarded, and in instances where it must be stored, keep storage to a minimum. Data cannot be stolen from your application if it is not being stored.
Vulnerability: XML External Entities (XXE)
Poorly-configured XML processors allow for external entity references to be executed, which gives attackers valuable information about the inner workings of the environment from which the web application is running from. Solution: The most effective way of managing this is to train developers on this vulnerability and how to identify and avoid it when creating web applications. Developers should seek to avoid using complex JSON formats and avoid serializing sensitive data. Disable XML External Entity and DTD processing in all XML parsers within the application.
Vulnerability: Broken access control
Access control is difficult to monitor in applications because it only is effective in two different scenarios. Firstly, when it is enforced on the back end of the application on the server, or secondly, in a serverless API that does not let the attacker check the metadata of the application. If the attacker has access to this information, then they could possibly edit the access rights within the program and elevate their permissions, allowing them to breach the security of the application. Solution: Deny all permissions by default, excepting for public resources. This, in conjunction with access control mechanisms and minimizing CORS instances will go a long way towards securing the application. The application must not allow standard users to edit, update, delete or create records by default, and should thus enforce the record of ownership within the application.
Conclusion
Documenting and remediating vulnerabilities in apps is a time-consuming process that requires a lot of thorough testing, documenting, and compiling of the information into a readable report. Pentesting is more than simply rifling through a customer’s application and uncovering vulnerabilities, but rather, it is a measured and methodical process that takes time, skill and determination to complete. Many times, these reports will be compiled by more than one team member, as the volume of work can be too great for a single person to reasonably complete within a given time limit. It is therefore important for pentesters to be able to operate as individuals, and as a part of an investigative team as well.
Sources
OWASP Top 10 – 2017, OWASP The Penetration Testing Execution Standard Documentation, The PTES Team
