VULNERABILITY MANAGEMENT IN WEB APPLICATION

VULNERABILITY MANAGEMENT IN WEB APPLICATION Prof. Amit R. Wasukar 1, Mohammad Usman 2 and Neha Sakhare 3 Assistant Professor, C.S.E. Department, J.D.I.E.T. Yavatmal, amitwasukar@gmail.com Final Year Student, C.S.E. Department, J.D.I.E.T. Yavatmal, uv.usman@gmail.com Final Year Student, C.S.E. Department, J.D.I.E.T. Yavatmal,nehasakhare92@gmail.com ABSTRACT Web application security becomes a critical issue as more and more web applications appear and serve common life and business routines in recent years. It is known that web applications are vulnerable due to software defects. Open to public users, vulnerable websites may encounter lots of malicious attacks from the Internet. We present a vulnerability management in web application and new web service platform where system developers can detect, view and patch potential vulnerabilities of their web applications online. Taking advantage of software analysis techniques, our analysis ensures that the patched programs are free from vulnerabilities with respect to given attack patterns and how vulnerabilities get exploited and patched. We report our analysis result on several open source applications, finding and patching various unknown/known vulnerabilities. Keywords : SQL Injection, Threads, Vulnerability, Web Application, XSS. 1. INTRODUCTION Web applications have become a crucial part of commerce, entertainment and social interaction and they are rapidly replacing desktop applications. In the near future, they are expected to play critical roles in national infrastructures such as health-care, national security, and the power grid. However, there is a large stumbling block to the ever-increasing reliance on web applications in almost every aspect of society: they are notorious for security vulnerabilities [1]. Global accessibility of web applications makes this a very serious problem. Malicious users all around the world can exploit a vulnerable web application and cause serious damages [1]. According to the Open Web Application Security Project (OWASP)'s top ten list that identifies the most serious web application vulnerabilities, the top three vulnerabilities in 2007 are Cross Site Scripting (XSS), SQL Injection and Malicious File Execution (MFE). Even after it has been widely reported that web applications suffer from these vulnerabilities, the top two of the vulnerabilities were still listed in the top three of the OWASP's top ten list in 2010 and 2013. The paper is organized as follows: in second section we see literature review. In third section we explain what vulnerability is. In fourth section we briefly discuss different types of vulnerabilities occurs in web application. In fifth section we discuss our vulnerabilities detection by using a vulnerability scanner is software application that used to detect vulnerabilities in networks or host systems and produces a set of scan results. However, because administrators as well as attackers can use the same software for removing or deriving a system, there is a necessity to bearing a scan and fixed a query in advance an attacker can do the similar scan and exploitation any vulnerability found. This paper provides a general overview of vulnerability management. In section six we discuss about architecture of vulnerability scanner. In section seven we see the types of vulnerability scanner. In section eight we discuss about precaution while using vulnerability scanner. In VOLUME-2, SPECIAL ISSUE-1, MARCH-2015 COPYRIGHT 2015 IJREST, ALL RIGHT RESERVED 579

section nine we see some examples of vulnerability scanner. 2. LITERATURE REVIEW 2.1. String Analysis and Vulnerability Detection In security usually, string analysis has been usually considered. One powerful method has been grammarbased string analysis that statically computes an overapproximation of the results of string expressions in Java programs that has also been used to check for many types of errors in Web applications [2]. There are also some latest string analysis tools that use symbolic string analysis centred on deterministic finite automata (DFA) encodings. Few of them are centered on symbolic execution and use a DFA exemplification to model and verify the string manipulation operations in Java programs. HAMPI (Kiezun et al. 2009) is a bounded string constraint solver. It outputs a string that satisfies all the constraints, or reports that the constraints are unsatisfiable. Note that this kind of restricted analysis cannot be used for string analysis whereas the string analysis techniques we adopt in this paper are sound. Yu et al. (2008, 2010) have used single-track DFA based symbolic reachability analysis to verify the correctness of string sanitization operations in PHP programs. Their preliminary results on generating (non-relational) vulnerability signatures using single track DFA were reported in a short paper (Yu et al., 2009). All of the above results use singletrack DFA and encode the reachable configurations of each string variable separately, i.e., they use a nonrelational string analysis. Yu et al. reported the results on foundations of string analysis by means of multitrack automata (Yu et al., 2010) [2]. Multi-track automata read tuples of characters as input instead of only single characters. Each string variable corresponds to a particular track (i.e., a particular position in the tuple), thereby allowing a relational analysis. 3. WHAT ARE VULNERABILITIES? A vulnerability scanner can evaluate different types of vulnerabilities across systems such as computers, network systems, operating systems, and different software applications that may have originated from a vendor, system administration activities, or general user activities [7]: 3.1. Vendor-Originated Vulnerability It includes software bugs, missing OS patches, vulnerable services, insecure default configurations, and web application vulnerabilities. 3.2. System Administration-Originated Vulnerability This includes incorrect or unauthorized system configuration changes, lack of password protection policies, and so on. 3.3. User-Originated Vulnerability This includes sharing directories to unauthorized parties, failure to run virus scanning software, and malicious activities, such as deliberately introducing system backdoors. 4. TYPES OF VULNERABILITIES IN WEB APPLICATION There are many types of vulnerabilities in web application but there are little most important vulnerability is given as follows 4.1. Default Password Default password term explain that in most of the web application the admin or the user password are same as the username. The admin password most of the time is admin or the user password is same as username or related with user day to day activities. Default passwords are most often overlooked by busy system administration staffs, who can be under pressure to get applications/ hardware upgrades on line as quick as possible. There is an assurity for a large number of other default passwords around. There are a number of excellent tools on the market a few (but not all) are listed here: 1. Cain 2. Creddump 3. Fgdump 4. Hydra VOLUME-2, SPECIAL ISSUE-1, MARCH-2015 COPYRIGHT 2015 IJREST, ALL RIGHT RESERVED 580

5. LCP 6. Medusa 7. Ophcrack 4.2. Directory Listing If you create a new directory on your website, and do not put an "index.html" file in it, you may be amazed to find that your visitors can get a directory listing of all the files in that folder. Automatic directory listing/indexing is a web server function that lists all of the files within a requested directory if the normal base file like index.html, home.html, default.htm, default.asp, default.aspx is not present. When a user requests the main page of a web site, they normally type in a URL such as: http://www.example.com/directory1/ - using the domain name and excluding a specific file. The web server processes this request and searches the document root directory for the default file name and sends this page to the client. If this page is not present, the web server will dynamically issue a directory listing and send the output to the client. Essentially, this is equivalent to issuing an "ls" (Unix) or "dir" (Windows) command within this directory and showing the results in HTML form. From an attack and countermeasure perspective, it is important to realize that unintended directory listings may be possible due to software vulnerabilities combined with a specific web request. 4.3. Parameter Manipulation HTTP Parameter Pollution attacks (HPP) have only recently been presented and discussed, and have not received much attention so far. HPP vulnerability allows an attacker to inject a parameter inside the URLs generated by a web application. The consequences of the attack rest on the application s logic, and may vary from a simple annoyance to a complete corruption of the application s behaviour. Because this class of web vulnerability is not widely known and well-understood yet, Even though injecting a new parameter can sometimes be enough to exploit an application, the attacker is usually more interested in overriding the value of an already existing parameter. This can be achieved by masking the old parameter by introducing a new one with the same name. For this to be possible, it is necessary for the web application to misbehave in the presence of duplicated parameters, a problem that is often erroneously confused with the HPP vulnerability itself. However, since parameter pollution attacks often rely on duplicated parameters in practice, we decided to study the parameter duplication behaviour of applications, and measure it in our experiments. 4.4. Blind SQL Injection SQL Injection is a one type of code injection technique, which is used to attack data-driven applications, in which mischievous SQL statements are put into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database. Blind SQL Injection is used when a web application is vulnerable to an SQL injection but the results of the injection are not visible to the attacker. In a 2012 study, security company Imperva observed that the average web application received 4 attack campaigns per month, and retailers received twice as many attacks as other industries. 4.5. Cross Site Scripting Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications. XSS enables attackers to inject client-side script into Web pages viewed by other users. A crosssite scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of 2007. There are two types of cross site scripting shown below: VOLUME-2, SPECIAL ISSUE-1, MARCH-2015 COPYRIGHT 2015 IJREST, ALL RIGHT RESERVED 581

4.5.1. Persistent Cross Site Vulnerability The persistent (or stored) XSS vulnerability is a more overwhelming variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read. 4.5.2. Non Persistent Cross Site Vulnerability The non-persistent (or reflected) cross-site scripting vulnerability is by far the most common type. These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the request. Because HTML documents have a structure which is having flat and serial format that mixes control statements, formatting, and the actual content, any nonvalidated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection. A unique example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed word-perfect on the result page to indicate what was searched for. If this response does not properly match or reject HTML control characters, a cross-site scripting flaw will proceed. 4.6. File Uploads Vulnerability Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step. The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, and simple defacement. It depends on what the application does with the uploaded file and especially where it is stored. 5. VULNERABILITY SCANNER A vulnerability scanner is software application that assesses security vulnerabilities in networks or host systems and produces a set of scan results. However, because both administrators and attackers can use the same tool for fixing or developing a system, administrators need to conduct a scan and fix problems before an attacker can do the same scan and exploit any vulnerability found [7]. 5.1. Benefits of Vulnerability Scanners The first work of a vulnerability scanner is allows quick detection and handling of well-known security problems. By using ongoing security assessments using vulnerability scanners, it is easy to find security vulnerabilities that might be present in the network. The second work of a vulnerability scanner is a new system may be concerned to the network without any authorization. A vulnerability scanner can help to find unauthorized system, which might compromise whole system and network security. The third work of a vulnerability scanner is help to authorize the inventory of all devices on the network. The list includes the device type, operating system version and patch level, hardware configurations and other relevant system information [3]. 5.2. Limitations of Vulnerability Scanners The drawbacks of vulnerability scanners are: 5.2.1. Snapshot Only A vulnerability scanner can simply evaluate a "snapshot of time" in terms of a system security. Thus, scanning needs to be conducted frequently, as new vulnerabilities can occur, or system configuration changes can lead new security holes. 5.2.2. Human Judgment Is Needed Vulnerability scanners can only report vulnerabilities according to the plug-ins installed in the scan database. They cannot fix whether the response is a false negative or a false positive. Human judgment is at all times VOLUME-2, SPECIAL ISSUE-1, MARCH-2015 COPYRIGHT 2015 IJREST, ALL RIGHT RESERVED 582

needed in analyzing the data after the scanning procedure. On the subject of vulnerability scanning, "false negative" is the failure to make out an existence of a flaw in the system or the network under assessment, while "false positive" is the incorrect determination of the presence of vulnerability. The last might be due to missing plug-ins in a scanner database while the latter requires human judgment to confirm. 5.2.3. Others A vulnerability scanner is built to detect known vulnerabilities. It cannot recognize other security vulnerability such as those associated to physical, operational or technical issues [4]. In count, many vulnerability scanners rely on plug-ins to determine potential vulnerabilities. Plug-ins are portion of the knowledge database of the vulnerabilities that the scanner is able of detecting. These databases may be named differently (such as Scanning Profile ) in different scanner products, but the term plug-ins will be used in this paper. The finite number of plug-ins can be another drawback with vulnerability scanners. A scanner can only check for those vulnerabilities that it knows, by cross checking with the presence of its corresponding installed plug-in set. It cannot identify those vulnerabilities that don t have a plug-in. Not all scanners need plug-ins. For example, port scanners do not need any plug-ins as they just scan a target range of ports. 6. ARCHITECTURE OF VULNERABILITY SCANNERS In general, a vulnerability scanner is made up of four modules, Scan Engine, Scan Database, Report Module and a User Interface. 1. The Scan Engine executes security checks according to its installed plug-ins, identifying system information and vulnerabilities. It can scan more than one host at a time and compares the results against known vulnerabilities. 2. The Scan Database stores vulnerability information, scan results, and other data used by scanner. The number of available plug-ins, and the updating frequency of plug-ins will vary depending on the corresponding vendor. Each plug-in might contain not only the test case itself, but also a vulnerability description, a Common Vulnerabilities and Exposures (CVE)2 identifier; and even fixing instructions for a detected vulnerability. Scanners with an "auto-update" feature can download and install the latest set of plugins to the database automatically [5]. Fig1: Component of Scanner 3. The Report Module provides different levels of reports on the scan results, such as detailed technical reports with suggested remedies for system administrators, summary reports for security managers, and high-level graph and trend reports for executives. 4. The User Interface allows the administrator to operate the scanner. It may be either a Graphical User Interface (GUI), or just a command line interface. Most vulnerability scanners are characterized by their modular structure as explained above. However, there are also primitive scanners that are basically sets of scripts or C-code exploits producing simple plain-text files as scanning results. Updates to these primitive scanners are infrequent and require manual intervention. On the other hand, there are now a number of Distributed Network Scanners with more complex architecture. When enterprise networks are widely distributed, Distributed Network Scanners are used. They are composed of remote scanning agents, a plugin update mechanism for those agents, and a centralized VOLUME-2, SPECIAL ISSUE-1, MARCH-2015 COPYRIGHT 2015 IJREST, ALL RIGHT RESERVED 583

management point. Such scanners are capable of assessing vulnerabilities across multiple, geographically dispersed networks from one centralized management console, which can then distribute updates to scanning agents, modify settings in all scan engines, and schedule testing activities across the whole enterprise. Scan results are in turn collected from all remote scanning agents into the central database for analysis and reporting [6]. 7. TYPES OF VULNERABILITY SCANNER Vulnerability scanners can be divided broadly into two groups: network-based scanners that run over the network, and host-based scanners that run on the target host itself. 7.1. Network-Based Scanners A network-based scanner is usually installed on a single system that scans a number of other hosts on the network. It helps to find critical vulnerabilities such as mis-configured firewalls, vulnerable web servers, risks associated with vendor-supplied applications, and risks associated with network and systems administration. Different types of network-based scanners include: 1. Port Scanners that determine the list of open network ports in remote systems. 2. Web Server Scanners that assess the possible vulnerabilities (e.g. potentially dangerous files or CGIs) in remote web servers. 3. Web Application Scanners that assess the security aspects of web applications (such as cross site scripting and SQL injection) running on web servers. It should be noted that web application scanners cannot provide comprehensive security checks on every aspect of a target web application. Additional manual checking (such as whether a login account is locked after a number of invalid login attempts) might be needed in order to supplement the testing of web applications [7]. 7.2. Host-Based Scanners A host-based scanner is installed in the host to be scanned, and has direct access to low-level data, such as specific services and configuration details of the host's operating system. It can therefore provide insight into risky user activities such as using easily guessed passwords or even no password. It can also detect signs that an attacker has already compromised a system, including looking for suspicious file names, unexpected new system files or device files, and unexpected privileged programs. Host-based scanners can also perform baseline (or file system) checks. Networkbased scanners cannot perform this level of security check because they do not have direct access to the file system on the target host. A database scanner is an example of a host-based vulnerability scanner. It performs detailed security analysis of the authorization, authentication, and integrity of database systems, and can identify any potential security exposures in database systems, ranging from weak passwords and security mis-configurations to Trojan horses [7]. 8. PRECAUTIONS 8.1. Potential Threats Caused By the Scan Process A scan can pose risks to systems by, for instance, crashing an already vulnerable server if all plug-ins, counting high-risk ones (DoS scan) are permitted. Therefore, risk calculation and careful scheduling are necessary before scanning. Usually, for a preproduction system, it might be acceptable to enable all plug-ins including high-risk ones. However, for ongoing continual scans on a production system, administrators should consider disabling certain high-risk plug-ins. In addition, when conducting scanning using a networkbased scanner, a large amount of system requests and network traffic will be generated. The administrators have to reminder any failure in the system and network performance of the target system during scanning [4]. 8.2. Handling of the Scanning Results Leakage of scanning results, which hold system vulnerability info, may possibly facilitate attackers in exploiting those loopholes. It is important to defend this information by keeping it in a safe place, or keeping it VOLUME-2, SPECIAL ISSUE-1, MARCH-2015 COPYRIGHT 2015 IJREST, ALL RIGHT RESERVED 584

encrypted to check unauthorized access. If an external party is employed for the assessment process, the organization must ensure that any party involved is reliable and that both results and exclusive information will be kept safe [4]. 8.3. Policies and Actions for the Scanning Process Malicious use of scanning tools could pose a threat and reason incredible damage to systems. Therefore, different methods and processes must be in place to specify whom, in which manner the vulnerability valuation software are to be used. Such policies may include the kind of prior arrangement or notifications, management approval and/or legal clearances that are required before a scanning takes place. Not any one should be permitted to conduct any vulnerability scanning without prior approval. 9. EXAMPLES OF COMMON VULNERABILITY SCANNERS A number of open source freeware or commercial vulnerability scanners are available for download or trial. The following are examples 9.1. Network-Based Scanners 1. Port scanners Nmap Super scan 2. Network vulnerability scanners Nessus GFI LANguard Network Security Scanner (N.S.S.) 3. Web server scanners Nikto Wikto Web application vulnerability scanners Paros Acunetix Web Vulnerability Scanner 9.2. Host-Based Scanners 1. Host vulnerability scanners Microsoft Baseline Security Analyzer (MBSA) Altiris Security Expressions 2. Database scanners Scuba by Imperva Database Vulnerability Scanner Shadow Database Scanner 10. CONCLUSION Web applications reach out to a larger, lesstrusted user base than legacy client-server applications, and yet they are more vulnerable to attacks. Many companies are starting to take initiatives to prevent these types of break-ins. Code reviews, extensive penetration testing, and intrusion detection systems are just a few ways that companies are battling a growing problem. Unfortunately, most of the solutions available today are using negative security logic (working with a list of attacks and trying to prevent against them). Negative security logic solutions can prevent known, generalized attacks, but are ineffective against the kind of targeted, malicious hacker activity. REFERENCES [1] Andrews, M.: The State of Web Security. IEEE Security & Privacy, vol. 4, no. 4, pp. 14-15 (2006). [2] Auronen, L.: Tool-Based Approach to Assessing Web Application Security. Seminar on Network Security (2002). [3] Jovanovic, N. Kruegel, Ch. Kirda, E. Pixy: A Static Analysis Tool for. Detecting Web Application Vulnerabilities. [4] Chess, B., McGraw, G.: Static analysis for security. IEEE Security & Privacy, vol. 2, no. 6, pp. 76-79 (2004). [5] Huang, Y.-W., Huang, S.-K., Lin, T.-P., Tsai, Ch.-H.: Web application security assessment by fault injection and behaviour monitoring. In: Proceedings of the 12th international conference on World Wide Web, May 20-24 (2003). [6] Huang, Y.-W., Lee, D. T.: Web Application Security - Past, Present, and Future. Computer Security in the 21st Century, Springer US, pp. 183-227 (2005). [7] Wiegenstein, A., Weidemann, F., Schumacher, M., Schinzel, S.: Web Application Vulnerability Scanners - a Benchmark. Virtual Forge GmbH (2006). VOLUME-2, SPECIAL ISSUE-1, MARCH-2015 COPYRIGHT 2015 IJREST, ALL RIGHT RESERVED 585