Urshila Ravindran | Raghu Vamsi Potukuchi*
© 2022 IIETA. This article is published by IIETA and is licensed under the CC BY 4.0 license (http://creativecommons.org/licenses/by/4.0/).
OPEN ACCESS
With the increase in the number of internet users, web applications, user data there is an increase in the number of hackers all over the world. It is becoming challenging for organizations to ensure the security of the data of their employees and their customers around the world. Any cyber-attack on the organization will drastically affect the reputation of the organization as well as the loss of trust from the users or customers. Customers will not invest in these organizations who have encountered a cyber threat or attack. Hence, enabling regular security testing and checks by the penetration testers or security analysts help in preparing the organization from any security threat by testing network and applications. Even after performing the Vulnerability Assessment and Penetration Testing (VAPT) of the applications, it is extremely necessary to follow up the security patches to mitigate all the existing flaws and security vulnerabilities in the web applications under the organization. To this end, this paper presents the common web application security vulnerabilities, prior requirements for performing any security assessment of the web application along with the do’s and don’ts of the assessment in accordance with each vulnerability. This paper also discusses various types of security testing and how VAPT is essential in every organization.
vulnerability assessment, penetration testing, web application, security, ethical hacking, burp suite, application security
Ensuring the security of using the internet and its resources is the paramount importance due to the increase in the users of this technology. Data leak can affect any organization or an individual in terms of its reputation, money and chances of loss of resources. Vulnerability in the security domain is defined as the loopholes or weaknesses present in the system or network of any organization or individual [1]. The attacker then takes advantage of this weakness and exploits using exploitation techniques. The security attacks on e-commerce platform are not new, and they are happening from starting of Web 2.0 [2]. There are more than 24 million e-commerce websites are present on the internet. According to a Forgenix survey [3, 4], 75% of e-commerce websites are at the risk of some cyber attacks. Even reputed and branded companies have vulnerabilities in their websites taking advantage of them these websites are compromised by attackers. Taking the example of reputed brands which already have hit by any type of cyber attacks is predicted to be more than 350 million dollars during the years 2018-19 [5-7]. The main area to focus to curb these attacks is systematic security testing (or penetration testing or pentesting) and vulnerability assessment.
The system can be compromised because of existing vulnerabilities. The network, application or systems consisting of these vulnerabilities are termed as a vulnerable application or network. Therefore, it is important to perform the Vulnerability Assessment and Penetration Testing (VAPT) of the web applications before releasing to the market. The process of vulnerability assessment is to find out the flaws and weaknesses existing in the system by scanning the system or the whole network. Conducting a vulnerability assessment helps to check the security posture of the organization in the cyber world. The key objectives of conducting a vulnerability assessment in the organization would be risk assessment, system accreditation, compliance checking, and network auditing and continuous monitoring.
1.1 Related work
Security testing and various related issues such as privacy and others in web applications, in general, are articulated in recent survey articles [8-12]. Devi and Kumar [13] introduced various tools such as Sparta, Network mapper (Nmap), Zenmap, Netcraft, IP Address Tracking, Virus Total, etc. for information gathering. During the practical experimentation of using security tools on a particular application, it was observed that after using OWASP ZAP tool, it was able to detect medium high as well as low level risks. The medium high-level severity vulnerabilities that were identified are URL rewriting, Application error disclosure, X-frame-options header and SQL injection. Priyanka et al. [14] presented three web application vulnerabilities such as SQL injection, XSS (Cross-site scripting) and CSRF (Cross-site request forgery). It also discusses the tools that can be used for VAPT. This paper concluded that preventive measures to consider for SQL injection attacks are input validation, white listing and sanitization of user input values, use of prepared statements to pass the user input data as parameters, and avoiding the disclosure of sensitive information through error on the web pages. Amin et al. [15] focus on how the red team performs the security assessments of the applications. There are largely three types of teams: 1) red team, 2) purple team and 3) the blue team. The red team imitates the activities that an attacker would do by making the use of tools and techniques to perform a real-world attack just like an attacker would. The blue team refers to the organization’s internal security team that defends against the red team attacks as well as the internal/external attackers. The purple team is a hybrid version of the red team and blue team. The purple team consists of Blue team's defensive techniques and the attacking skills of the Red team. This paper also explained rules of engagement for a red team, some of which are execution of the required engagements, compliance with all the laws, regulations, policies and programs, implementation of the operational methodology of the team, identification of the input to the target environment, research and development of new exploit tools for testing the functionality, perform OSINT, identification and assessment of the actions revealing system vulnerabilities, providing assistance to the red team lead in the development of the final engagement report and also to perform the physical assessment under the leadership of the red team lead. Vats et al. [16] starts with discussing the various pentesting strategies like external pentesting strategy, internal pentesting strategy, blind pentesting strategy, double blind pentesting strategy and targeted pentesting strategy. The different types of pentesting are black box pentesting, gray box pentesting and White box pentesting. This paper discussed some of the common pentesting tools used by testers such as Hping, nmap, httprint, GFI LanGuard Network Security Scanner, Brutus Security tool and others.
Goutam et al. [1] proposed a framework that will give more security to the applications running under any financial institution. The proposed algorithm works in the following manner: first, the user will be required to give his login id and password to this framework. If the user details match with the already registered users, then an OTP is sent to the mobile number as well as the email id. After the OTP is verified, the reference number is asked by the application. If the reference number is not provided, then the user will be redirected back to the login page. The reference number is auto-generated when a user first registers on the application with his/her details. This reference number unique for each customer is not stored in the user details database. The proposed framework was practically tested on a financial application, and it was helpful in detecting vulnerabilities like clickjacking vulnerability (X-frame-options header not included in the HTTP response headers), cross-site scripting protection not enabled, SQL injection vulnerability and private IP disclosure which can be dangerous if accessible to any attacker as it can be used for conducting further attacks on the application. Functionalities of VAPT, testing checklist for assessment of applications, OWASP top 110 security risks and the workflow of penetration testing are presented [17]. Authors presented a checklist that should be followed while practicing secure coding consists of input validation, authentication, password management, output encoding, access control, session management, communication security, cryptographic practices, error handling and logging, system configuration, file management, database security and memory management. Khera et al. [18] performed an analysis of the lifecycle of the VAPT process. It also shortlists some useful VAPT tools for testing and finding the target system vulnerabilities. It explains the need for adoption of vulnerability assessment and penetration testing at various organizational levels to prevent any cyber attacks. It also discussed vulnerability assessment and penetration testing in detail. The main reasons why these vulnerabilities arise are system misconfiguration, weak password combinations, system connected to an unsafe network, poorly designed software and hardware. Hasan and Meva [19] discussed in detail about the VAPT process model, its benefits and the tools used in the process. The paper focuses on the high-risk vulnerabilities like SQL injection, local file inclusion, and cross-site scripting and remote file inclusion. Hasan and Meva [19] also performed a literature survey to perform an analysis of the generalized VAPT process used among all of them and the tools which are actually useful when performing the vulnerability assessment and penetration testing. Yaqoob et al. [20] presented vulnerability assessment and why it needs to perform in every organization. It also discussed common network vulnerabilities, threats to the vulnerable networks and the vulnerability management lifecycle. In addition to this, this paper presented penetration testing process and also performs a comparison with the vulnerability assessment process. Hasan et al. [21, 22] analyzed the different approaches to perform vulnerability assessment and penetration testing in web applications to ensure secure web applications in the ever evolving cyber world. First, the paper [21] discussed the software development life cycle and its phases like planning, analysis, design, implementation, testing, integration and maintenance in detailed manner. Next, the paper divides the vulnerability into two categories: logical vulnerability and technical vulnerability. Paper [22] discussed in detail about penetration testing, how it is done step wise, how it helps in securing the network and what are the tools for performing penetration testing. Penetration testing is an effective way of identifying and assessing the vulnerabilities of the system.
Haque et al. [23] presented the ways to secure the web services, the challenges faced in the security of web services and the recommendations to overcome those security challenges in web services. It also discusses the 10 most common vulnerabilities and also presented the ways to prevent three of these vulnerabilities such as SQL injection, cross site scripting, session management and broken authentication. Similarly, common vulnerabilities are discussed in the studies [24, 25]. Security controls are presented. To illustrate it, a livestock data center is used for a case study to perform the assessment and testing and to propose the relevant security controls [26]. Singh et al. [27] presented methodology of performing penetration testing. It describes what are penetration testing, its various techniques and the reasons to perform penetration testing. Goel et al. [28-33] presented VAPT lifecycle to be performed on the web application infrastructure and this procedure can be helpful in preventing cyber attacks. A study [34-40] shows that the exploring vulnerabilities depend on the type of programming environments and application specifications.
All the aforementioned studies used automated vulnerability scanning methods and tools. Alternative of the automated testing is the manual testing, which is a best option for modern applications. Further, these studies focused on discussing or presenting very limited web application vulnerabilities.
1.2 Contributions and paper organization
To this end, the main objective of this paper is to identify and provide understanding of how different vulnerabilities exist in the system, how the attackers can perform can exploit them. Papers that provide basic understanding the web application infrastructure, vulnerabilities and exploitation of the application, VAPT process flow, what are the measures the beginners of the VAPT process need to take care are very limited. Further, as the users of the web applications are increasing, new vulnerabilities come in to existence and the literature also grow in accordance with it. This paper attempt to provide all these concepts for easy understanding by the beginners and intermediate VAPT testers. Also provides do’s and don’ts for the testers during VAPT process.
Section 2 presents the preliminaries for understanding the VAPT process. Section 3 presents the most commonly used open source tools for conducting VAPT process. This section also presents important add-ons and features available in popularly used Burpsuite tool for web application testing. Section 4 provides a detailed description of the VAPT process in two modes such as active mode testing and passive mode testing. Methods used in each mode are detailed in this section. Section 5 presents the measures to be considered during VAPT process. This section helps the beginners of the VAPT process as a checklist during the testing. Finally, Section 6 concludes the paper with future directions. The list of abbreviations used in this paper is provided at the end of the paper.
2.1 Vulnerability management lifecycle
The vulnerability management lifecycle consists of 6 main steps [1]: 1) discovery, 2) prioritization of assets, 3) assessment, 4) reporting, 5) remediation and 6) verification. The discovery step involves keeping a track of all the vulnerabilities existing in the application or the network on a regular basis. The second step is the prioritization of assets basically involves the categorization and assignment of values to the assets according to their priority. The third step is to create a risk profile based on importance or priority of the reported vulnerabilities. The fourth step is to measure and report the level of business threat with respect to the existing vulnerabilities in the organizational network. The next step is to perform the remediation to fix the vulnerabilities and protect the system from exploitation by the attackers. The final step is the verification to check whether the existing system vulnerabilities have been patched or not.
2.2 Penetration testing
Penetration testing is a type of testing method used by ethical hackers to perform the testing of full integrated and operational system infrastructure or network. Penetration testing is defined as a procedure to find vulnerabilities present in the target system or network infrastructure in order to take certain steps to secure the network from attackers. It helps in checking whether an attacker would be able to penetrate into an organization’s network or not. This testing technique is done by an ethical hacker simulated as an unauthorized user who attacks the system or executes the penetration into the system [41, 42].
2.3 VAPT considerations
While performing the VAPT, the CIA (Confidentiality, Integrity and Availability) principles must be considered. Confidentiality refers to the principle of ensuring that only the authorized people are able to access the restricted information. No other unauthorized person should be able to access or read or edit the data in the application. The application should have proper authentication and authorization mechanism to allow only the authorized personnel’s to access the data, each authorized role should be allowed with only a specific set of functionalities in the application according to their level of authorization that is, a normal user should not be able to perform the functionalities of what an admin can do. The unauthorized users should not be able to access any data present in the application. The confidentiality factor fails if the attacker is able to perform horizontal or vertical privilege escalation. Horizontal privilege escalation is a type of attack in which the users of the same level of authorization are able to access the data of another user. Vertical privilege escalation is a type of attack in which the normal users are able to access data of users of different levels of authorization, that is, any user of lower level is able to access the privilege rights or functionalities of an admin in the application [43, 44].
Integrity means ensuring the sanctity of the data when in transit. No one should be able to perform the modification of the data while it is in transit from the client to the server side of the application. To ensure the integrity of the data, data in transit should use HTTPS or the data should be in encrypted form when in transit so that no intruder in the communication can easily read the data. By encrypting the data, sender can prevent man-in-the-middle attacks like spoofing, hijacking and eavesdropping in the communication channel of a network. The last principle is to always ensure the availability of the system or the application. It should be available to its users in the network anytime they access it. Availability can be affected if there is lack of request limiters in the application. Due to lack of request limiters, an attacker can cause a DOS (denial of service) attack and halt the system or application from sending the response back to any of the requests received due to the application server receiving the request more than it can handle it [45].
To conduct a VAPT, the three areas to check the vulnerabilities are the physical structure, logical structure and the architecture of the target network. Network testing is performed by the tester to find the vulnerabilities existing in the physical design of target system.
2.4 Vulnerability assessment vs. Pentesting
The differences between Vulnerability assessment and Pentesting are as follows [35, 36]:
2.5 Vulnerability assessment methodologies
There are two VA assessment methodologies: 1) automated, and 2) manual. By using automated approach, testers can identify the vulnerabilities present in the application with the help of automated tools and eliminate the false positives. Automated tools are software that interacts with the target sans human intervention. The primary benefit of automated scanners is that they reduce the labor-intensive work required to accomplish the task. Automated scanners like Acunetix will give us an overview of the possible existence of vulnerabilities in the environment. These vulnerabilities are aligned with the following industry-wide accepted standards such as OWASP, SANS, ASVS, WASC.
By using manual approach, the tester will detect every exploitable vulnerability present in the web application. The tester looks out for logical flaws which might compromise the authentication/authorization process, injection attacks, data security, input validations, session management issues, etc. The tester identifies every open port and the service running on the API servers. After that, the tester tests them for security vulnerabilities depending on their level of exploitability and availability in the environment they exist in. Final step involves the verification and validation of these vulnerabilities based on the standard benchmark. The following checks to be performed during manual testing security controls according to industry security standards like OWASP, SANS, MASVS, WASC, etc. are used for testing purposes. They are
2.6 Web application testing strategies
There are two web application testing strategies: 1) black box testing, and 2) grey box testing. Black box testing is a formal technique of application testing in which the examination of the application functionality without any knowledge of its internal or backend working mechanism is performed. It does not have any requirement of the past knowledge of web application or intervention of the vendor of application. Black Box penetration testing will be performed on the application along with its APIs that are interacting with the application using those APIs.
Grey box testing is a type of software/application testing that is performed by a tester having partial prior knowledge about the internal/backend mechanism of an application which is given by the owners or developers in form of walk-through of applications, application data flow, API documentation, tech stack etc. and can most often include the design and architecture documentation and internal access to the assets. The tester also gets test user credentials to assess the application/software post login functionalities. The main intention behind a Grey box assessment is to provide a more efficient & focused security assessment. This activity helps to simulate an attacker which might act as a threat to the application’s sensitive data, assets and eventually to the organization’s reputation.
There are two types of VAPT models [31]: 1) flaw hypothesis model and 2) attack tree model. In the first type, there is a system analysis and penetration prediction technique which consists of compilation of a list of flaws consisting of a hypothesis and performs analysis of the code specification and system documentation. In an attack tree model, the different attack methods or exploits which are possible against a target web application are represented in the form of a tree structure.
2.7 Skill set required for VAPT
Following are some common skills required for Web application assessment:
2.8 VAPT summary
VAPT should be performed on a regular basis especially in the technology-based firms and organizations as they are more prone to the cyber based attacks. The advantages that can be achieved by performing regular Web application VAPT are
There are majorly four types of open source and free VAPT tools that can be useful such as 1) static analysis tools, 2) network testing tools, 3) application testing tools and 4) social Engineering tools [31]. Static analysis tools perform the VAPT by analyzing the source code of the web application. Some of the Static Analysis tools are Flawfinder, Pychecker, Pixy, RATS and OWASP SWAAT. Network Analysis tools are used for scanning the target network for analysis of the loopholes in the target network. Some network analysis tools are nmap, hping, superscan, Xprobe2, Nessus, Brutus and Metasploit. The application testing tools are used to analyze the cyber defence infrastructure of the organisation. Some of the tools used for it are Nmap, Fiddler, Nikto, WebScarab, Arachni and OWASP ZAP. Social Engineering tools are used to check the difficulty level of extraction of the information which is considered confidential, by interaction with the organization’s employees. Following are some basic tools that need to be thoroughly and practically understood in order to start the assessment process [39, 52-55].
These tools may be downloaded and installed individually or specialized penetration testing operating systems are available with all necessary security tools. Some popular operating systems are Kali Linux [49], Parrot OS [50], Security Onion [51], etc. Burp Suite [47] extensions can help in the automation of the web application assessment process, and it also reduces the time in scanning and exploiting the web application vulnerabilities if we already have the following Burp Suite extensions installed and setup in our Burp application. The BApp Store consists of various types of Burp extensions for the detection and exploitation of different web or mobile related vulnerabilities that have been specially written by contributors of Burp Suite to expand the capabilities of the Burp application. Testers can directly install the BApps burp extensions from the extender tab present in the Burp application. Brupsuite is available in two editions: 1) community edition and 2) professional edition (Pro version). Community edition is free to use and it comes with limited functions. While the professional version require licence from the vendor and comes with many interesting features. Some of those functionalities that are useful for web application pentesting are as follows [33-35]:
As shown in the Figure 1, the VAPT process of the web applications will be carried in two modes: 1) Passive mode, and 2) Active mode. During passive testing, the security analyst attempts to understand the logic of the web application and executes the exploration of the test application like a normal user. Various tools that can be used for the purpose of information gathering for example, an HTTP client-side proxy tool like Burp Suite Pro can be used for the purpose of observing all the incoming and outgoing HTTP requests as well as HTTP responses on the application. After this phase the analyst should know all the access points of the web application (e.g., HTTP headers, parameters, cache and cookies). The passive mode of testing will be held in the sequence of steps 1) information gathering, 2) Fingerprinting web server, 3) Web content scanning, 4) web page content review, and 5) SSL verification. Section 4.1 describes these steps, on the other hand, in the active mode of testing, the security analyst performs active tests on the web application which are categorized as follows: 1) server level testing, 2) client level tests, 3) authorization and identity management testing, 4) authentication testing, 5) input validation testing, 6) web content testing, and 7) business logic testing. Section 4.2 presents the methods of active mode in detail.
Figure 1. Modes of VAPT process
4.1 Passive mode testing
Passing mode testing consists of the following steps:
4.2 Active mode testing
Figure 2 depicts the elaborated checks for each test under the active mode of VAPT. Each test of the active mode VAPT is explained in the subsections of this section [45-61].
Figure 2. Categories of active mode VAPT process
4.2.1 Server level testing
It is important to perform the proper security configuration of the single nodes and elements that contribute to make up web application architecture in order to prevent any risks or mistakes that might compromise the security of the whole application architecture. The web server or application server configuration plays an essential role in the protection of the site contents, and it must be reviewed carefully in order to detect the common configuration mistakes. Checks to be conducted for server level testing are as follows
4.2.2 Client level testing
Client-Side testing is a type of testing concerned with the code execution on the client side that typically exists within the web browser or browser plug-in. The execution of code on the client-side of the web application is different from the one executing on the server side of the web application and it returns the subsequent content. Client-side security needs penetration testing to be performed because client-side attacks can quickly risk and compromise the critical data assets and information. It is essential to test the susceptibility and application network’s capability to identify and respond back to the client-side attacks before the damage is irreversible. Client level testing involves checking for following:
4.2.3 Authorization testing
Authorization is the concept or process of allowing access to the restricted resources to only those users that are permitted to use them. For testing authorization settings or configuration in the web application, tester first needs to understand how the authorization process works, and then use that information to plan for the attack on the application using the weak configuration of the authorization mechanism. Authorization is a concept that comes after a successful authentication process, so the analyst will perform the verification of this point after he has the valid user credentials, related to a well-defined set of roles and privilege rights. During the testing of this security control, it should be checked if it is possible to perform the authorization schema bypass, find vulnerability in the path traversal, or tester can also find different ways to conduct the escalation of the privilege rights assigned to the analyst. The tests for checking the Authorization and Identity management are given below.
1. Account enumeration: Often web applications reveal when a username exists on a system, either as a consequence of misconfiguration or as a design decision. For a case, sometimes, after we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password as wrong. The data obtained is employed by an attacker to realize an inventory of users on the system. This information is often used to attack the web application, for instance, through a brute force or default credentials attack. The tester should interact with the authentication mechanism of the application to grasp if sending a particular request causes the application to answer in several manners. This issue exists because the data released from an online application or web server when the user provides a legitimate username is different than after they use an invalid one.
2. Privilege escalation: It takes place when a user can access many other restricted resources or restricted functionalities than they're normally allowed to access, and such elevation or changes should be prevented by the web application. In every portion of the applying where a user can create data/information within the database (e.g., making a payment, adding or removing a contact, or sending a message), can receive information (account statement, order details, etc.), or delete information (delete or drop users, delete messages), it is necessary to record the functionality. The tester should attempt to access such functions as another user so as to verify if it's possible to access a function that ought to not be permitted by the user's role/privilege (but can be permitted as another user). If the tester is able to access such functionalities with a user with the identical user role then it becomes horizontal privilege escalation. If the functions accessed by the analyst as a traditional user belong to a better user role, then it becomes vertical privilege escalation.
3. Insecure direct object reference: Insecure direct object references vulnerability takes place when an application provides direct access to things supported user-supplied input. If this vulnerability exists in the web application, then attackers can bypass authorization and access resources within the system directly, for e.g. database records or files. To test for this type of vulnerability the tester must first plan all locations within the application where user input is employed to reference objects directly. For instance, locations where user input is employed to access a database row, a file, application pages and more. Next, the analyst should modify or change the parameter value tied to reference objects and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization. As shown in Figure 3, consider the sample request at a link http://foo.bar/somepage?invoice=12345, in this case, the worth of the invoice parameter is employed as an index in an invoices table within the database. The analyst should change the worth of invoice and check if the corresponding invoice number details are displayed within the application or not.
4. Directory traversal and file inclusion: Web servers and web applications implement authentication mechanisms to regulate access to files and resources. Web applications use server-side scripts to incorporate different types of files and manage images, templates, load static texts, etc. But there also are security vulnerabilities if these input parameters aren't correctly validated. In order to see which part of the web application is liable to input validation bypassing, the analyst must enumerate all parts of the application that accept content from the user. Few checks which will be performed here are:
Figure 3. Insecure direct object reference (IDOR) attack
Figure 4. Directory traversal attack
As shown in Figure 4, the next stage of testing is analyzing the input validation functions present within the web application. To successfully test for this flaw, the analyst has to have knowledge of the system being tested and also the location of the files being requested. A couple of examples for the following scenario are as follows:
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd
http://example.com/index.php?file=http://localhost:8080
5. Cross-site request forgery: As shown in the Figure 5, Cross-Site Request Forgery (also popularly known as CSRF) is a type of web security attack that forces a user to execute unintended actions on an internet application within which they are currently authenticated. In order to test for CSRF vulnerability within the web application, audit the web application to establish if its session management is vulnerable. If session management relies only on client side values (information available to the browser), then the web application is vulnerable. Client-side values refer to cookies and HTTP authentication credentials (Basic Authentication and other sorts of HTTP authentication; application-level authentication). To perform the exploitation of the CSRF vulnerability, the tester then searches for HTML forms within the application and makes an HTML web page with some hidden fields and hosts it on an area server. Submit such WebPages after logging web application. If the page submits the malicious request successfully, CSRF is exploited.
6. Server side request forgery: As shown in the Figure 6, Server-side request forgery (SSRF) is a type of web security vulnerability that enables an attacker to mislead the server-side application or web server to form a call back connection to itself and in other cases also to the other web-based services within the organization’s infrastructure or to an external third-party system. Manual detection of the Server-Side Request Forgery vulnerability consists of making a careful analysis of the HTTP Requests, taking the inputs parameters and headers whose input values are whole or partial URL references to other internal web resources within or external to the web application.
4.2.4 Authentication testing
Authentication is the mechanism of attempting to perform the verification of the digital identity of the sender in the communication channel. A commonly used example of the authentication process is the login mechanism. For testing the authentication schema, tester need to first understand how the authentication process works and use that information to attack the authentication process considering its flaws and weaknesses. However, most of the web applications have a requirement to perform the authentication process to gain access rights to any sensitive or private information or to execute the tasks therefore not every authentication method is able to provide suitable security to the application. For performing the authentication testing, checks to be conducted are as follows:
Figure 5. Cross site request forgery
Figure 6. Server-side request forgery (SSRF) attack
Cache-Control: no-cache, no-store
Expires: 0
Pragma: no-cache
These directives are generally robust, although additional flags for Cache-Control are also necessary such as:
Cache-Control: must-revalidate, max-age=0, s-maxage=0
4.2.5 Session testing
Web applications consist of implementations of different processes and mechanisms for the storage and validation of the user credentials for a predetermined time. This type of mechanism is called Session Management. For testing the session management mechanism, the tester needs to check whether the session cookies and session tokens are being created in a secure and unpredictable manner. During the testing of session management functionality, the checks to be conducted are as follows:
4.2.6 Input validation testing
Input validation, also popularly known as data validation, is the testing technique done on any user-supplied input parameter on the web application. Input validation should mitigate any improper or inaccurately formed data from being inserted or stored into the application’s information system. Because it is typical to identify any malicious user who is trying to attack software, web applications should verify and perform the validation of all the input that is entered into the web application. Input validation mechanism should take place when input data is received from an external third party and especially when the data is coming from an untrusted data source. Injection attacks, memory leakage, and compromised systems can be caused due to improper input validation. The following are the checks to be conducted during input validation testing.
1. Cross site scripting: There are mainly 3 types of Cross Site Scripting which are as follows:
Figure 7. Reflected XSS attack
Figure 8. Stored cross-site scripting attack
Figure 9. DOM based cross site scripting attack
2. HTTP verb tampering: For testing the HTTP Verb tampering vulnerability, the tester performs the analysis of the HTTP response from the web application to a variety of request methods for accessing the system objects. The tester should test this vulnerability by accessing all of these system objects with all the possible HTTP request methods for every single object that were identified during the web application’s spidering process. If the server at the web application allows the HTTP request method other than POST or GET request method, the test comes out to be a fail or the application is considered safe from HTTP verb tampering, considering that the test web application does not allow the other HTTP request methods. The only remediation is to disable the HTTP request methods other than the GET and POST request methods to the web application servers.
3. HTTP parameter pollution: To test this vulnerability, the tester tests by checking the web application's HTTP response after receiving many HTTP parameters under the same request method or same name; let us consider an example in which the parameter userid is inserted in the request parameters twice. Appending many HTTP parameters with the same name may result in the wrong interpretation of values by the application. With the help of these vulnerabilities to conduct the exploitation, the tester will be able to cause functional modifications or errors in the internal parameters to bypass the mechanism of input validation in the web application. The tester first has to perform the identification of any form action that allows the input of any invalidated user input data.
4. SQL injection: As shown in Figure 10, to perform the testing of SQL injection vulnerability, the tester first verifies whether they can inject any input into the web application in order to perform the execution of a user-controlled SQL query in the web application’s database. The tester first checks if the application takes user input without proper input validation and inserts it into the SQL queries directly. For an SQL Injection attack to be successful, it is necessary for an attacker to create an SQL Query which is syntactically correct to fulfil his malicious intentions. If an error message is returned by the web application after the insertion of into the user supplied input, generating a message stating an incorrect query, then it might help the attacker to craft and modify the logic of the existing application query. It helps the attackers to perform the injection attack successfully. There are a variety of methods that exist to perform the exploitation of SQL injection vulnerability in the web applications such as Union Operator, Blind SQL injection, Error based injection, Boolean conditions based injection, Out-of-band injection, and Time delay based injection.
Figure 10. SQL injection
Figure 11. LDAP injection
Figure 12. XXE injection
5. LDAP injection: As shown in the Figure 11, LDAP injection is a type of vulnerability which exists in the server side, and it is also popularly known as the server side attack, which allows the disclosure, modification and insertion of the sensitive information and data about the users depicted in an LDAP tree structure. This is performed by the manipulation of the input data parameters which is then forwarded to the addition, internal search and data modification functions. If a web application makes use of an LDAP server to perform the verification of the user credentials in the authentication mechanism and if it is having LDAP injection vulnerability, then the tester, we can conduct the bypass of the authentication check mechanism by the injection of an always true LDAP query into the existing query similarly like SQL injection, XML injection, X-PATH injection.
6. XML injection: XML Injection is a type of injection attack which is done by an attacker by injecting any XML (Extensive Mark-up Language) document into the application and checks for process by application. If the XML parser fails to perform the semantic verification of the input data then the application will send back a positive response and results in to successful attack. The tester first checks for the presence of a XML Injection vulnerability in the web application by inserting the XML meta characters such as ‘, , <, >, <!--/→ in the data insertion points. For example, consider that there exists an attribute like the following in the web application:
<node attrib='$inputValue'/>
Considering the condition where if the inputValue = foo’ is instantiated and then inserted as the attrib value shown as below:
<node attrib='foo'/>
Then this XML document is not considered valid.
By defining the new entities, tester can extend the set of valid entities. If URI is the entity definition, then the entity is known as an external entity. External entities usually intend to force the XML parsers for the purpose of accessing the URI specified resources, e.g., a file on a remote system or the local machine. As shown in Figure 12, this configuration makes the application vulnerable to XXE attacks (External XML Entity), which can in turn, be used to perform DOS attack on the local system to gain unauthorized access to perform unauthorized activities like accessing the files on the local machine or a remote system, scanning the remote machines, and perform DOS on the remote systems.
7. SSI injection: SSI Injection, also known as Server-Side Includes injection, is special directives that are parsed by the web server before forwarding this page to the user. Appending an SSI directive into a static HTML document can be done by the following: -
<!--#echo var=DATE_LOCAL →
to print the current date and time.
The first thing that is done by the tester while testing for an SSI Injection vulnerability is to check whether the web server supports SSI directives or not. Followed by the tester tries to find the page in the web application where the insertion point is present in order to submit any input data, then tester performs a verification of whether the application has implemented a proper input validation mechanism.
8. XPATH injection: XPath is a type of programming language that is specifically designed for the purpose of addressing various sections of a document in an XML format. To perform the XPath injection testing, it is first checked whether injection can be done with the XPath query into the HTTP request that is going to be read or interpreted by the application, hence this allows the tester to execute the user-controlled XPath queries. After the successful exploitation of this vulnerability, it becomes possible for the tester to perform the authentication mechanism bypass and then gain the access to the restricted information without any authorization.
9. IMAP/SMTP injection: The purpose of performing this test is to check whether anyone can perform the injection of any arbitrary IMAP/SMTP exploit payload commands and send it to the mail servers due to improper sanitization of the input data. This type of injection attack allows the unauthorized access to the mail server which should not be accessed from the Internet directly. The tester’s role is to perform the analysis of the application’s capability in the input data handling in order to detect the vulnerable input parameters. It is necessary for the tester to send a malicious request to the web application server during the input validation testing phase and then perform an analysis of the response. Finally, after the identification of all the vulnerable parameters, the tester needs to perform the determination of the level of injection that is possible in the application and further exploit the application by designing the test plan.
10. Code injection: To perform the testing of code injection, the tester need to perform the submission of the input data to be dynamically processed by the application’s web server. These types of tests can target different types of scripting engines present in the server-side, e.g.., ASP, JSP and PHP. In order to protect against these types of attacks, secure coding practices and proper input validation is required.
11. Command injection: Command injection, also popularly known as an OS command injection, is a type of attack which takes place through a web application interface by executing the OS commands on the web application server. The web interface is known to be vulnerable to this type of exploit if it is not properly sanitized. The tester will test if this vulnerability exists in the application or not by injecting an OS exploit payload or command to the web application with the help of an HTTP request.
12. HTTP splitting/smuggling: HTTP splitting and smuggling details are as follows:
HTTP Splitting: HTTP Splitting is a type of vulnerability that performs the exploitation of the lack of sanitization of input by allowing an intruder to do the insertion of CR and LF (Carriage Return and Line Feed) characters into the response headers of the web application and to perform the 'splitting' of the HTTP response into two different parts of the HTTP response body. The headers that are most likely to be used by an attacker for conducting this attack are Set-cookie and Location header. The analyst must first detect all the identify all the insertion points present in the application that will directly affect the HTTP response headers, and then perform the verification of whether the insertion of a CR+LF sequence was successful or not.
HTTP Smuggling: HTTP Smuggling is a type of vulnerability that involves different techniques in which a modified HTTP message body can be successfully parsed and then understood by various types of web browser agents or WAF (Web Application Firewall). This attack technique allows the attacker to send one type of request to one device while the other device receives a different type of request. HTTP Request smuggling further provides the facilitation of several possible exploitations like XSS, partial cache poisoning and also bypassing the firewall protection.
13. Host header injection: The main reason why the host header exists is there are situations when there are multiple web applications hosted on the same IP address by the single web server. The HTTP header (or host header) mentions explicitly the website or web application to perform the incoming HTTP/HTTPS request processing. The host header value is used by the web application server for forwarding the HTTP request to the specified web application. The tester checks for the proper validation of the value of this header field by providing another domain in the host header request field. This type of injection attack turns out to be successful when the web application server performs the input processing to send the request to a host controlled by an attacker. Web cache poisoning, Web cache deception and password reset poisoning can be performed by host header injection.
14. Server side template injection: SSTI vulnerabilities occur when the user supplied input data is integrated into the server-side template of the application in an insecure way this improper function setting on the server can cause a remote code execution. Server side template injection vulnerabilities are present in both text and programming language format. In normal text format, users can insert any type of text within the HTML program. Considering the programming language format, the user supplied input data must be inserted inside a template code statement. In both the cases the methodology for testing this vulnerability consist of the following steps:
15. CSV injection: It is a type of injection attack that takes place when the web applications embed the untrusted input inside CSV files. CSV injections are also popularly known as the formula injection. Microsoft Excel or LibreOffice Calc which is a spreadsheet program can be used to open a CSV file, so any cells starting with ‘=’ will be understood by the software as a formula. The tester can check for CSV injection in web applications which have the functionality of generating and exporting the files of CSV format of user supplied data or user input.
16. Rate limiting: Rate Limiting, also popularly known as request limiting, is primarily used for controlling the amount of incoming and outgoing traffic to or from the server or network. Implementation of the limit on upcoming requests to the server is to allow for a better flow of data and to increase the security by preventing attacks such as Distributed DoS attack. Rate Limiting can be checked in the following components:
4.2.7 Business logic testing
For testing the flaws present in the business logic of a multi-functional dynamic web application, it requires unconventional method. If an application's authentication mechanism is developed with the intention of performing a standard procedure following the same steps again and again in a specific order to authenticate a user, the pattern become predictable by any potential attacker and then they might be able to mess up with the actual web application logic and framework. For conducting these tests, the testers to think differently, develop abused and misuse cases or in other words, attack scenarios and use multiple testing techniques followed by the software functional testers. The application must be able to have a functionality to check whether logically valid data is being directly sent to the front end and the server side of an application. Some of the web controls or testing indicators for the business logic testing is as follows
The security analyst should ensure if the application has the file upload functionality, then it should not allow the uploads of files having malicious extensions that are not relevant to the application’s intended functionality. The analyst should also find ways to test if it is possible to bypass any filtering that the developer might have employed in the application’s file upload functionality in order to mitigate and avoid any unwanted file uploads. The analyst performs the front-end (graphical user interface) functional valid testing to check that only the valid values are accepted in the application. Next, the analyst looks for variables where the insertion points take the cost or quality values. After the insertion points are found, the tester starts with the interrogation of the input fields with logically invalid data like unique identifiers. Tester has to check if they are working properly or not and that it does not accept any logically invalid data.
This section presents the do’s and don’ts during the general assessment and technical assessment of web applications. General assessment is the code inspection and walkthroughs held during the development of code. Technical assessment (or specific) inspection focuses on specific possible vulnerability of the web application and will be tested while running the program.
5.1 Do’s & don’ts during the general assessment
Do’s
Don'ts
5.2 Do’s & don’ts during the vulnerability specific assessment
Table 1 presents the list of Do’s and Don’ts during the vulnerability specific assessment.
Table 1. Do’s and Don’ts during the vulnerability specific assessment
|
S.No. |
Vulnerability |
Do’s |
Don’ts |
|
1. |
SQL Injection |
In a black box test on a production environment just check SQL injection using time delay to confirm time-based SQL injection, error to confirm error based SQL Injection |
Don’t use any payload which deletes / updates / inserts any new record in the existing tables of database. |
|
In a grey box test on a UAT environment try to extract database name or version number as a POC |
Don’t drop any table |
||
|
In a grey box test on a UAT environment try to attain Remote Code Execution. After RCE, don’t enumerate everything; instead run whoami and hostname to gain information. |
On a production environment don’t try to extract data from existing database tables or try to get Remote Code Execution |
||
|
If above test fail try to test Double query and Second Order SQL Injection |
Don’t execute harmful commands after gaining shell like shut down, or opening a port and creating a backdoor. |
||
|
2. |
Cross Site Scripting |
Check for any user input that is being reflected in the response/ at some different page. If anything is being reflected in the response try to add a JavaScript code (example: <script>alert(1)</script>) |
In a production environment don’t fuzz the parameters with a list of XSS payloads as it can lead to unwanted payloads getting stored in the website. Also it would generate huge traffic. |
|
If there exits places where images can be uploaded, try uploading malicious svg files with JavaScript code embedded. |
Be careful with Stored XSS on production. After taking POC modify the entity to clear off the script. If not possible then intimate client for the same so that other user’s do not get unnecessary pop ups |
||
|
3. |
Cross Site Request Forgery |
Intercept the requests of some actionable items on the website and verify the presence of an anti CSRF token. If the token is not present generate a CSRF POC using Burp Suite |
During assessment on a production environment do not delete/add/modify any file or perform any action which harms the website. |
|
If the CSRF token is present, try to bypass it by removing the token, adding any random value of the same characters or look if a sequence is being followed. |
On Production, don't change the sensitive field. Do it for non-sensitive fields for POC. |
||
|
4. |
Missing SPF / DMARC Records |
For testing purpose use tools like spoofcheck.py |
Do not send mail to any other person even for testing purposes by exploiting the misconfigured SPF/DMARC records. |
|
If either of the two - SPF or DMARC records is / are found to be missing then try to send a mail from a spoofed fictitious email of a website that is being tested (example: admin@website.com) to your email id. |
|
||
|
5. |
XML External Entity Injection |
Test for XXE wherever the request body contains XML. Try to craft payloads of XML by which either some information is leaked through response in the error or |
Do not try the Billion laugh attack or any such xxe attack which can harm / compromise the server. |
|
6. |
Click Jacking |
If there are any pages on the website that has important input fields, load that page in an iframe |
|
|
7. |
Invalidated File Upload |
Try to upload file other than the expected file type (example - uploading PHP, html, JS files in place where image is expected) and navigate to the URL of the upload file to see if it is executed |
On a production environment, do not upload a reverse/bind shell or any other type of file that can harm the infrastructure of the website |
|
Try to bypass the file upload check using double extension on a file to be uploaded |
On a production environment do not upload very large files as it might caught DoS on the website |
||
|
Try to use Magic bytes of a valid file type ( expected file type) and contents of a file we want to be uploaded ( example - contents of a PHP file like : <? php echo hello?>) |
If any harmful file gets uploaded make sure to intimate the team to delete those files later. |
||
|
In a UAT environment if an invalidated file is uploaded successfully, try to upload a reverse/bind shell and see if it gets executed. |
|
||
|
8. |
Lack of Request Limiters |
It should be tested wherever there is a function of sending an OTP or Email. |
Do not provide email or mobile number of some other person while testing |
|
For a black box test try only with 10 -15 requests in intruder with a single thread set in Burp intruder options. |
In a production environment do not send multiple requests using multiple threads, as it might cause a DoS attack |
||
|
For a grey box test on a UAT environment try with 100 requests with 5 threads set in Burp intruder options |
For testing rate limiters on POST fields, do not over populate the database. Send minimal requests necessary for POC. |
||
|
9. |
LFI / RFI |
In a grey box test on a UAT environment, in every parameter try to traverse directories and see if any file’s content can be used. Use payloads like (../../../etc/passwd if on a linux system) |
If config files are obtained, make sure to obfuscate passwords in report. |
|
In parameters try to access files from some other domain. If you are able to access then it is vulnerable to RFI |
|
||
|
10. |
Slow HTTP DoS |
Use tools like slowloris/slowhttptest to check for the following vulnerability. |
Don’t test this on a production website. Do not put the script in an infinite loop. Causing many open connections, Stop the script once POC is taken. |
|
11. |
Host Header Injection |
On intercepting the request using Burp Suite tamper with the Host header value and instead provide some other domain. If on forwarding the request, the Location header in the Response shows the tampered website, it shows that site is vulnerable to this attack. |
While testing don’t redirect to any website, redirect to a domain that belongs to you. |
|
Try changing HTTP/1.1 to HTTP/1.0 and completely remove the Host Header. After forwarding the request, check if the Location parameter in the Response header shows some private IP |
Do not try to reset any legitimate user’s password (by email) by host header injected request. |
||
|
Try adding X-Forwarded-Host Header in the captured request and add a domain that belongs to you. After forwarding the request, check whether the Location header in the Response has the domain that was entered in X-Forwarded-Host header in the request. |
|
In this paper, the main emphasis made on the most common vulnerabilities found in the web applications.
The paper also discusses in detail about the tools that can be used for automated testing such as Nmap, Acunetix, Nessus, OWASP ZAP, Dirbuster and many other such tools. The most common and popular tool used for penetration testing is tested by the white hat hackers/security analysts using automated and manual testing procedures. The paper provides the security testing techniques that can be done on any web application in an ethical way. The testing techniques are broadly categorized into two types, Black box and Gray box testing. This paper concludes that vulnerability assessment is the identification of the security vulnerabilities and penetration testing is the real time simulation of how an actual exploitation or attack will take place when the weakness, misconfiguration or security flaw existing in the web application. Burp Suite Professional. It can be used for manual exploitation as well as automated crawl and auditing of the web applications. This paper also suggested many burp extensions that can be installed in Burp Suite and can be helpful during the VAPT. Tools which can be helpful for manual exploitation are Metasploit, Wireshark, Burp Suite and many such tools. This paper concludes that VAPT is highly recommended to be performed in every organization as nowadays the data is stored on the internet, and this can pose a threat to the organizations reputation or money if any attack takes advantage of the security flaws existing in the organizations network. As a future work, we attempt to work on the VAPT process of mobile applications.
Authors would like to thank Team Lead at Safe Security Pvt. Ltd, Okhla, Delhi, India. (Formerly Lucideus Technologies Pvt Ltd) for providing supporting environment for conduction of this study.
|
API |
Application Programming Interface |
|
ARP |
Address Resolution Protocol |
|
ASVS |
Application Security Verification Standard |
|
CIA |
Confidentiality Integrity and Authentication |
|
CLI |
Command Line Interface |
|
CORS |
Cross-Origin Resource Sharing |
|
CSS |
Cascading Style Sheets |
|
CRLF |
Carriage Return and Line Feed |
|
CVE |
Common Vulnerabilities and Exposure |
|
CVSS |
Common Vulnerability Scoring System |
|
DHCP |
Dynamic Host Configuration Protocol |
|
DMARC |
Domain Based Message Authentication Reporting |
|
DNS |
Domain Name Server |
|
GUI |
Graphical User Interface |
|
HTML |
Hyper Text Markup Language |
|
HTTP |
Hyper Text Transfer Protocol |
|
ID |
Identifier |
|
IDS |
Intrusion Detection System |
|
IMAP |
Internet Message Access Protocol |
|
IP |
Internet Protocol |
|
IPS |
Intrusion Prevention System |
|
ISS |
Internet Security Scanner |
|
JVM |
Java Virtual Machine |
|
LDAP |
Lightweight Directory Access Protocol |
|
LFI |
Local File inclusion |
|
MASVS |
Mobile Application Security Verification Standard |
|
MITRE |
MITRE Adversarial Tactics, Techniques, and Common Knowledge |
|
ORM |
Object Relational Model |
|
OS |
Operating System |
|
OSI |
Open System Interconnection |
|
OSINT |
Open-source intelligence |
|
OTP |
One Time Password |
|
OWASP |
Open Web Application Security Project |
|
POC |
Proof of Concept |
|
PT |
Penetration Testing |
|
RARP |
Reverse Address Resolution Protocol |
|
RATS |
Remote Access Trojan |
|
SANS |
SysAdmin, Audit, Network and Security |
|
SMTP |
Simple Mail Transfer Protocol |
|
SNMP |
Simple Network Mail Protocol |
|
SOAP |
Simple Object Access Protocol |
|
SPF |
Sender Policy Framework |
|
SQL |
Structured Query Language |
|
SSI |
Server Sides Include |
|
SSL |
Secure Sockets Layer |
|
SSTI |
Server-Side Template Injection |
|
SWAAT |
Securing Web Application Technologies |
|
TCP |
Transfer Control Protocol |
|
TLS |
Transport Layer Security |
|
UAT |
User Acceptance Test |
|
URI |
Uniform Resource Identifier |
|
URL |
Uniform Resource Locator |
|
VA |
Vulnerability Assessment |
|
VAPT |
Vulnerability Assessment and Penetration Testing |
|
WAF |
Web Application Firewall |
|
WASC |
Web Application Security Consortium |
|
WSDL |
Web Services Description Language |
|
XML |
Extensive Markup Language |
|
XSS |
Cross Site Scripting |
|
XXE |
External XML Entity |
|
ZAP |
Zed Attack Proxy |
[1] Goutam, A., Tiwari, V. (2019). Vulnerability assessment and penetration testing to enhance the security of web application. 2019 4th International Conference on Information Systems and Computer Networks (ISCON), pp. 601-605. https://doi.org/10.1109/iscon47742.2019.9036175
[2] Kuruwitaarachchi, N., Abeygunawardena, P.K.W., Rupasingha, L., Udara, S.W.I. (2019). A systematic review of security in electronic commerce- threats and frameworks. Global Journal of Computer Science and Technology, 33-39. https://doi.org/10.34257/gjcstevol19is1pg33
[3] Kashif, M., Javed, M.K., Pandey, D. (2020). A surge in cyber-crime during COVID-19. Indonesian Journal of Social and Environmental Issues (IJSEI), 1(2): 48-52. https://doi.org/10.47540/ijsei.v1i2.22
[4] Foregenix Survey: https://www.foregenix.com/blog /over-75-of-global-magento-websites-at-high-risk-from-hackers-due-to-a-simple-security-oversight, accessed on 9 Aug. 2021.
[5] Humayun, M., Niazi, M., Jhanjhi, N., Alshayeb, M., Mahmood, S. (2020). Cyber security threats and vulnerabilities: A systematic mapping study. Arabian Journal for Science and Engineering, 45(4): 3171-3189. https://doi.org/10.1007/s13369-019-04319-2
[6] Asaduzzaman, M. (2020). Security Aspects of e-Payment System and Improper Access Control in Microtransactions (No. 3717). EasyChair. Available at: https://yahootechpulse.easychair.org/publications/preprint_download/ZFhp.
[7] Pentest monkey. http://pentestmonkey.net/, accessed on 15 Aug. 2021.
[8] Seng, L.K., Ithnin, N., Said, S.Z.M. (2018). The approaches to quantify web application security scanners quality: A review. International Journal of Advanced Computer Research, 8(38): 285-312. https://doi.org/10.19101/ijacr.2018.838012
[9] Toch, E., Bettini, C., Shmueli, E., Radaelli, L., Lanzi, A., Riboni, D., Lepri, B. (2018). The privacy implications of cyber security systems. ACM Computing Surveys, 51(2): 1-27. https://doi.org/10.1145/3172869
[10] Thomas, T.W., Tabassum, M., Chu, B., Lipford, H. (2018). Security during application development. Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems. https://doi.org/10.1145/3173574.3173836
[11] Vamsi, P.R., Jain, A. (2021). Practical security testing of electronic commerce web applications. International Journal of Advanced Networking and Applications, 13(1): 4861-4873. https://doi.org/10.35444/IJANA.2021.13109
[12] P Raghu Vamsi, A.J. (2021). Getting started with android mobile applications security testing. Scientific and Practical Cyber Security Journal. (Available at: https://journal.scsa.ge/papers/getting-started-with-android-mobile-applications-security-testing/).
[13] Devi, R.S., Kumar, M.M. (2020). Testing for security weakness of web applications using ethical hacking. 2020 4th International Conference on Trends in Electronics and Informatics (ICOEI) (48184), pp. 354-361. https://doi.org/10.1109/icoei48184.2020.9143018
[14] Priyanka, A.K., Sai Smruthi, S. (2020). Web application vulnerabilities: Exploitation and prevention. 2020 International Conference on Electrotechnical Complexes and Systems (ICOECS), pp. 729-734. https://doi.org/10.1109/icoecs50468.2020.9278437
[15] Amin, K., Sharma, P. (2020). Red team analysis of information security measures and response. Available https://www.academia.edu/download/64372201/IRJET-V7I4823.pdf.
[16] Vats, P., Mandot, M., Gosain, A. (2020). A comprehensive literature review of penetration testing & its applications. 2020 8th International Conference on Reliability, Infocom Technologies and Optimization (Trends and Future Directions) (ICRITO), pp. 674-680. https://doi.org/10.1109/icrito48877.2020.9197961
[17] Umrao, S., Kaur, M., Gupta, G.K. (2016). Vulnerability assessment and penetration testing. International Journal of Computer and Communication Technology, 200-203. https://doi.org/10.47893/ijcct.2016.1367
[18] Khera, Y., Kumar, D., Sujay, Garg, N. (2019). Analysis and impact of vulnerability assessment and penetration testing. 2019 International Conference on Machine Learning, Big Data, Cloud and Parallel Computing (COMITCon). https://doi.org/10.1109/comitcon.2019.8862224
[19] Hasan, A., Meva, D. (2018). Web application safety by penetration testing. International Journal of Advanced Studies of Scientific Research, 3(9). Available: https://www.academia.edu/download/58290599/SSRN-id3315587.pdf.
[20] Yaqoob, I., Hussain, S.A., Mamoon, S., Naseer, N., Akram, J., UR Rehman, A. (2017). Penetration testing and vulnerability assessment. Journal of Network Communications and Emerging Technologies (JNCET), 7(8): 10-18. Available at: https://www.jncet.org/Manuscripts/Volume-7/Issue-8/Vol-7-issue-8-M-03.pdf.
[21] Hasan, A.M., Meva, D.T., Roy, A.K., Doshi, J. (2017). Perusal of web application security approach. 2017 International Conference on Intelligent Communication and Computational Techniques (ICCT), pp. 90-95. https://doi.org/10.1109/intelcct.2017.8324026
[22] Hussain, M.Z., Hasan, M.Z., Taimoor, M., Chughtai, A., Taimoor, M., Chughtai, A. (2017). Penetration testing in system administration. International Journal of Scientific & Technology Research, 6(6): 275-278. Available: https://www.ijstr.org/final-print/june2017/Penetration-Testing-In-System-Administration.pdf.
[23] Haque, M.F., Miah, M.B.A., Masud, F.A. (2017). Enhancement of web security against external attack. European Scientific Journal, 13(15): 228. https://doi.org/10.19044/esj.2017.v13n15p228
[24] Nagpure, S., Kurkure, S. (2017). Vulnerability assessment and penetration testing of web application. 2017 International Conference on Computing, Communication, Control and Automation (ICCUBEA). https://doi.org/10.1109/iccubea.2017.8463920
[25] Shinde, P.S., Ardhapurkar, S.B. (2016). Cyber security analysis using vulnerability assessment and penetration testing. 2016 World Conference on Futuristic Trends in Research and Innovation for Social Welfare (Startup Conclave). https://doi.org/10.1109/startup.2016.7583912
[26] Nyambo, D., Yonah, Z., Tarimo, C. (2016). On the identification of required security controls suitable for converged web and mobile applications. International Journal of Computing and Digital Systems, 5(1). https://doi.org/10.12785/ijcds/050105
[27] Singh, H., Surender, J., Pankaj, K.V. (2016). Penetration testing: Analyzing the security of the network by Hacker’s mind. Volume V IJLTEMAS, 56-60. https://www.academia.edu/download/46153650/56-60.pdf.
[28] Goel, J.N., Mehtre, B.M. (2015). Vulnerability assessment & penetration testing as a cyber defence technology. Procedia Computer Science, 57: 710-715. https://doi.org/ 10.1016/j.procs.2015.07.458
[29] Lamba, A. (2014). Cyber Attack prevention using VAPT tools (vulnerability assessment & penetration testing). Cikitusi Journal for Multidisciplinary Research, 1(2). http://www.cikitusi.com/gallery/9-996.pdf.
[30] Shah, S., Mehtre, B.M. (2014). An overview of vulnerability assessment and penetration testing techniques. Journal of Computer Virology and Hacking Techniques, 11(1): 27-49. https://doi.org/10.1007/s11416-014-0231-x
[31] Shah, S., Mehtre, B.M. (2013). A reliable strategy for proactive self-defence in cyber space using VAPT tools and techniques. 2013 IEEE International Conference on Computational Intelligence and Computing Research. https://doi.org/10.1109/iccic.2013.6724216
[32] Lallie, H.S., Shepherd, L.A., Nurse, J.R.C., Erola, A., Epiphaniou, G., Maple, C., Bellekens, X. (2021). Cyber security in the age of COVID-19: A timeline and analysis of cyber-crime and cyber-attacks during the pandemic. Computers & Security, 105: 102248. https://doi.org/10.1016/j.cose.2021.102248
[33] Kumar, B., Roy, S. (2021). An empirical study on usability and security of E-commerce websites. Advances in Intelligent Systems and Computing, 735-746. https://doi.org/10.1007/978-981-15-7527-3_69
[34] Toapanta Toapanta, S.M., Mera Caicedo, H.A., Naranjo Sanchez, B.A., Mafla Gallegos, L.E. (2020). Analysis of security mechanisms to mitigate hacker attacks to improve e-commerce management in ecuador. 2020 3rd International Conference on Information and Computer Technologies (ICICT). https://doi.org/10.1109/icict50521.2020.00044
[35] Khera, Y., Kumar, D., Sujay, Garg, N. (2019). Analysis and impact of vulnerability assessment and penetration testing. 2019 International Conference on Machine Learning, Big Data, Cloud and Parallel Computing (COMITCon). https://doi.org/10.1109/comitcon.2019.8862224
[36] Rahman, M.A., Amjad, M., Ahmed, B., Siddik, M.S. (2020). Analyzing web application vulnerabilities. Proceedings of the International Conference on Computing Advancements. https://doi.org/10.1145/3377049.3377107
[37] Lis, A. (2019). Comparison and analysis of web vulnerability scanners (Bachelor's thesis). https://elib.uni-stuttgart.de/bitstream/11682/10634/1/bachelorthesis_alexander_lis.pdf.
[38] Abdullah, H.S. (2020). Evaluation of open source web application vulnerability scanners. Academic Journal of Nawroz University, 9(1): 47. https://doi.org/10.25007/ajnu.v9n1a532
[39] Amankwah, R., Chen, J., Kudjo, P.K., Towey, D. (2020). An empirical comparison of commercial and open‐source web vulnerability scanners. Software: Practice and Experience, 50(9): 1842-1857. https://doi.org/10.1002/spe.2870
[40] Pan, Y. (2019). Interactive application security testing. In 2019 International Conference on Smart Grid and Electrical Automation (ICSGEA), pp. 558-561. https://doi.org/10.1109/icsgea.2019.00131
[41] Vega, E.A.A., Orozco, A.L.S., Villalba, L.J.G. (2017). Benchmarking of pentesting tools. International Journal of Computer and Information Engineering, 11(5): 602-605. https://doi.org/doi.org/10.5281/zenodo.1130587
[42] Building a Pentesting Lab. (2020). The Pentester Blueprint, 65-81. https://doi.org/10.1002/9781119684367.ch5
[43] Felderer, M., Büchler, M., Johns, M., Brucker, A.D., Breu, R., Pretschner, A. (2016). Security testing: A survey. In Advances in Computers, 101: 1-51. https://doi.org/10.1016/bs.adcom.2015.11.003
[44] Sołtysik-Piorunkiewicz, A., Krysiak, M. (2020). The cyber threats analysis for web applications security in Industry 4.0. Studies in Computational Intelligence, 127-141. https://doi.org/10.1007/978-3-030-40417-8_8
[45] Dang, Q.H. (2015). Secure Hash Standard. https://doi.org/10.6028/nist.fips.180-4.
[46] Common Vulnerabilities and Exposures. Available online: https://cve.mitre.org/, accessed on 15 Aug. 2021.
[47] Rahalkar, S. (2020). Extending burp suite. A Complete Guide to Burp Suite, 131-145. https://doi.org/10.1007/978-1-4842-6402-7_9
[48] GitHub, I. (2016). GitHub. URl: https://github.com/, accessed on 15 Aug. 2021.
[49] Kali Linux. URl: https://kali.org/, accessed on 15 Aug. 2021.
[50] Parrot Security. URl: https://parrotlinux.org/, accessed on 15 Aug. 2021.
[51] Security Onion. URl: https://securityonion.net/, accessed on 15 Aug. 2021.
[52] Sy, E., Mueller, T., Burkert, C., Federrath, H., Fischer, M. (2020). Enhanced performance and privacy for TLS over TCP fast open. Proceedings on Privacy Enhancing Technologies, 2020(2): 271-287. https://doi.org/10.2478/popets-2020-0027
[53] Mendez, X. Wfuzz—The Web Fuzzer. Available online: https://github.com/xmendez/wfuzz, accessed on 15 Aug. 2021.
[54] Exploit database. https://www.exploit-db.com/, accessed on 15 Aug. 2021.
[55] Klein, A. (2008). Attacks on the RC4 stream cipher. Designs, Codes and Cryptography, 48(3): 269-286. https://doi.org/10.1007/s10623-008-9206-6
[56] Alenezi, M., Nadeem, M., Asif, R. (2021). SQL injection attacks countermeasures assessments. Indonesian Journal of Electrical Engineering and Computer Science, 21(2): 1121-1131. https://doi.org/10.11591/ijeecs.v21.i2.pp1121-1131
[57] Fossati, T., Tschofenig, H. (2016). Transport layer security (TLS)/datagram transport layer security (DTLS) profiles for the internet of things. Transport. https://doi.org/10.17487/rfc7925
[58] Viega, J., Messier, M., Chandra, P. (2002). Network security with openSSL: cryptography for secure communications. " O'Reilly Media, Inc.".
[59] Pentester Land. https://pentester.land/, accessed on 15 Aug. 2021.
[60] Harris, J.K. (2018). Heartbleed: A case STUDY. Issues in Information Systems, 19(2): https://doi.org/10.48009/2_iis_2018_99-108
[61] Calzavara, S., Roth, S., Rabitti, A., Backes, M., Stock, B. (2020). A tale of two headers: A formal analysis of inconsistent click-jacking protection on the web. In 29th {USENIX} Security Symposium ({USENIX} Security 20), 683-697. Available at: https://www.usenix.org/system/files/sec20fall_calzavara_prepub.pdf.
