Web Services Vulnerability Testing Using Open source Security Scanners : An experimental Study

Transcription

1 Web Services Vulnerability Testing Using Open source Security Scanners : An experimental Study Manju Khari, Neha Singh Computer Science Department, Guru Gobind Singh Indraprashta University, Dwarka, Delhi, India Abstract Web application users and web application vulnerabilities are increasing. Today web applications turning out to be tools of everyday use by many users with the growing popularity of the web. With this web application users are more prone to malicious attacks consequently the need of web security testing arises as well. As security testing helps to mitigate vulnerabilities in the web applications which is quite intricate process so requires the use of efficient security testing technique. Frequently occurring security vulnerabilities in web applications result from generic input validation problems. Examples are SQL injection and Cross-Site Scripting (XSS) etc. These vulnerabilities are more often exploited by attackers to access sensitive information form the websites for their personal gain. Black Box scanners offers a good choice to test for vulnerabilities in an automated fashion. Although the majority of web vulnerabilities are easy to understand and to avoid but still many web developers are not security aware. As a result, there exist many web sites on the Internet that are vulnerable. This paper Shows the experimental study of open source web scanners that help detecting the potential vulnerabilities. Also there an approach (Black Box based) has been proposed that brings out the rules to confirm the presence of SQL injection vulnerability in particular web application or services.this can help reduce the false positives and increase effectiveness of the scanners. 1.Introduction Black-box web vulnerability scanners are a category of tools that can be used to identify security issues in web Applications[1]. These tools are often known as point-and-click pentesting tools that automatically assess the security of web applications with little or no human intervention. These tools access a web application in the same way users do, and, therefore they are independent of the particular technology being used to implement the web application at the server side. However, these tools should also be able to access and test the application s various components, which are often hidden behind forms like JavaScript-generated links and Flash applications[3]. Black-box web application vulnerability scanners are automated tools that explore web applications for security vulnerabilities. In black-box testing, the source code is not examined instead, special input test cases are generated and sent to the application. Then, the results returned by the application are analyzed for unforseen behavior that indicate loopholes or vulnerabilities[2]. Some features of Black-box web vulnerability scanners are: Black-box web vulnerability scanners are a modern choice for finding security loopholes in web applications in an automated manner. These tools functions in a point-and-shoot manner, testing any web application regardless of the server-side language for common security vulnerabilities. Black-box tools suffer from a number of limitations, particularly when interacting with complex applications that have multiple actions. If a vulnerability analysis tool does not take into consideration changes in the web 790

2 application s state, it might ignore vulnerabilities or completely overlook entire portions of the application[4]. Classical black-box web scanners crawl a web application to enumerate all reachable pages and then inject some input data (URL parameters, form values, cookies) to trigger vulnerabilities. However, this approach ignores a key aspect of modern web applications: The state of the web application changes according to the current request[3]. Web application (black-box) scanners perform security tests on Web applications by (usually) first crawling through the entire Web site that s holding the Web application, and then running specific security test cases wherever possible. All the tests are performed over the HTTP protocol.they are not only effective at finding attack incidents like cross-site scripting and SQL injection, but also at finding configuration management issues (related to Web servers). These tools are usually not aimed at developers, this makes the mitigation process complex[10]. 2.Web Service Introduction. A Web service is a standardized way of establishing communication between two Web-based applications by using open standards over an internet protocol backbone. Generally web applications work using HTTP and HTML, but web services work using HTTP and XML. Which as added some advantages over web applications. HTTP is transfer independent and XML is data independent, the combination of both makes web services support a heterogeneous environment.[3] 2.1 Web service architecture Processes Description Invocation Transport Fig 1. Web service Architecture Service Processes (UDDI): This part of the architecture generally involves more than one Web service. For example, discovery belongs in this part of the architecture, since it allows us to locate one particular service from among a collection of Web services. Service Description (WSDL): One of the most interesting features of Web Services is that they are self-describing. This means that, once you've located a Web Service, you can ask it to 'describe itself' and tell you what operations it supports and how to invoke it. This is handled by the Web Services Description Language (WSDL). Service Invocation(SOAP): Invoking a Web Service (and, in general, any kind of distributed service such as a CORBA object or an Enterprise Java Bean) involves passing messages between the client and the server. SOAP (Simple Object Access Protocol) specifies how we should format requests to the server, and how the server should format its responses. In theory, we could use other service invocation languages (such as XML-RPC, or even some ad hoc XML language). However, SOAP is by far the most popular choice for Web Services. Transport: Finally, all these messages must be transmitted somehow between the server and the client. The protocol of choice for this part of the architecture is HTTP (HyperText Transfer Protocol), the same protocol used to access conventional web pages on the Internet. Again, in theory we could be able to use other protocols, but HTTP is currently the most used one. 3. Experimental Study Our target is to test a small set of web service for potential vulnerabilities using open source web security scanners. With this way the effectiveness of scanners can be computed easily. Other than this our motive is to reduce false positives rate and enhance scanner vulnerability identification rate.[6] In short we say security tests will be done to know the following parameters: Coverage factor of scanners False positive rate of scanners Identification of most common vulnerabilities

3 Our security tests consists of following steps: Selection: Selection of best open source web scanners and web services that are in public domain. Implementation: Scan the web services using web scanners to detect loopholes. Analysis: In this step we analyze the results obtained and on the basis of which average response time is calculatred for each scanner. 3.1 Vulnerability scanner studied and Web Services Tested First of all, we have selected 3 scanners scanner (publicly available) from our comparative study of various black box security scanners. Websecurify, ZAP, Vega. The next step was to identify a small set of web services that are shown in the results table. 3.2 Results of scanner. The scanner pointed seven different types of vulnerabilities, namely: CSRF: Cross-site Request Forgery (CSRF) is a type of attack whereby unauthorized commands are transmitted from a user that the application trusts. Unlike Cross-site Scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser. solution: Url and Forms that perform important operations must be protected by random tokens (hidden nonce values). These tokens must be checked for validity at the server before the request is processed. url: orm: <form method="post" action=" es.aspx" enctype="application/x-www-formurlencoded" autocomplete="on">... </form> SQL error: Various SQL errors were disclosed within the application source code or other files. This information could be used by attackers to make an educated guess about the application environment type, version and current configuration. In some situations these errors may indicate a weakness which could be exploited via a SQL Injection attack. Solution: sanitize all user supplied data before using it into database. Eg. database: MSSQL request: GET HTTP/1.1 Error Disclosure: Various web errors were disclosed within the application source code or other files. This information could be used by attackers to make an educated guess about the application environment type, version and current configuration. In some situations these errors may indicate a weakness which could be exploited. solution: It is strongly recommended to ensure that any unhandled application errors are trapped and never displayed to the user. The user should only see a generic message which contains enough information to track the error within the application logs. Eg.error: Description: </b>an unhandled exception occurred during the execution of the current web request. Request : POST ufps= HTTP/1.1Content-Type: application/x-www-formurlencoded EVENTTARGET& EVENTAR GUMENT&TextBox1&Command1=Submit Path Disclosure: Various system paths were disclosed within the application client source code or other files. This information could be used by attackers to make an educated guess about the application environment and any inherited weaknesses that may come with it

4 solution: It is recommended to re-examine the system path disclosures and remove their reference from the application's source code. path: /home/130-english/faq/faqada/436-what-istrustedx-adaptive-authentication.. request: GET HTTP/1.1 Banner Disclosure :The server or application disclosed its type and version. This information could be used by attackers to make an educated guess about the application environment and any inherited weaknesses that may come with it.solution: It is recommended to prevent the application from disclosing its type and version. E.g. banner: Server: Microsoft-IIS/6.0 request: GET HTTP/1.1 Autocomplete Enabled : should be disabled (autocomplete="off"), especially in forms which process sensitive data, such as forms with password fields, since an attacker, if able to access the browser cache, could easily obtain the cached information in cleartext. solution: Disable the autocomplete feature (autocomplete="off") on forms which may hold sensitive data. E.g url: orm: <form method="post" action=" es.aspx" enctype="application/x-www-formurlencoded" autocomplete="on">... </form> disclosure: The server or application disclosed s. This information could be used by attackers to make an educated guess about who developed the application, what contact entry points are available or what the internal format looks like, which could also correspond to the format of the application usernames. solution: Ensure that contact s do not disclose any information and are adequately protected against external attacks. E.g kevinc@xmlme.com request: GET abindex=9&tabid=7 HTTP/1.1 Table 1: Websecurify results Service name Number of Vulnerabilities Total Files SQL XSS CSRF Path disc User disc. Error Banner AC Enabled. Chennai emergency Archworks Doweb services Konakart ecommerce Cydne Safelayer Xignite logos Response Time in min

5 Xignite index Shakespeare Abundant Tech Total vulnerabilties of Table 2: Zad attack proxy results Service name Number of Vulnerabilities Total Files SQL XSS CSRF Path disc User disc. Error Banner AC Enabled. Chennai emergency Archworks Doweb services Konakart ecommerce Cydne Safelayer Xignite logos Xignite index Shakespeare Abundant Tech Response Time in min. Total vulnerabilities of

6 Table 3: Vega Results Service name Number of Vulnerabilities Total Response Files Time in SQL XSS CSRF Path User Error Banner AC Ensec disc disc. abled. Chennai emergency Archworks Doweb services Konakart ecommerce Cydne Safelayer Xignite logos Xignite index Shakespeare Abundant Tech Total vulnerabilities of From our results we see that SQL error and Autocomplete Enabled seems to be most common category available in all tested web services. Table 4: Overall results Scanner Category No. of vul. Web Securify SQL Error 210 High Autocomplete enabled 121 Low SQL Error 17 High ZAP Autocomplete 378 Low enabled Vega SQL Error 67 High Autocomplete enabled 157 Risk No. of web services. Low sql. AC enabled error dis. path dis. banner dis. xss user dis. CSRF Fig 2: Graph representing the share of vulnerabilities detected by the scanners

7 Table 5: Response time of scanner Web services Response time for each tool in (s) Websecurify Vega ZAP Scanners Chennai emergency Archworks Doweb services Konakart ecommerce Cydne Scanners Safelayer Xignite logos Websecurify Vega ZAP Xignite index Shakespeare Abundant Tech. Overall Average Fig 3. Average Response time (in Seconds) 4. Black Box based approach to Confirm Sql injection vulnerability( Proposed Approach) On the basis of output obtained of the testing process we can define certain rules to confirm presence of SQL injection vulnerabilities and help eliminate major false positives. With this way we can achieve high coverage factor with low rate of false positives. There are some steps thar are excuted on different parameter in order to explore different way of confirmation of such vulnerabilities. see fig below. 1. Initially when set of request fired for testing then if output received consist of error due to browser incompatibility i.e SOAP error then We can say that no vulnerability detected due to unsuccessful attack. 2. Else if the output is an error then 2.1. If output error exists for unmutated test call i.e without malicious value then It is anlayzed that error occurred due to some another problem like Database server failure or any software fault Else we can use invalid inputs (over parameters) whose values cross the boundary of the input domain i.e robustness testing

8 2.3. If using robustness testing same errors are obtained then we can confirm that cause of error is robustness testing but not a vulnerability 2.4. Else Indication of sql injection vulnerability occurs as all the invalid responses obtained are due to attack only no such was observed while using robustness testing a set of legitimate test calls.from this we can conclude that attack caused the unexpected output but not due to any other problem. This shows a strong Identification mark for presence of sql injection vulnerability. 3. Else i.e in presence of attack if valid output obtained and if the database errors, server errors are found due to execution of valid inputs i.e without malicious values then, we can say that the effect of attack caused web service to execute those parts that were not possible using the set of valid test calls.this shows that sql injection vulnerability has been detected for eg. Authentication mechanism fails in presence when attack made in order to trigger the vulnerability. 4. Else if we compare both the responses ie in the presence of attack or in presence of valid test calls (without mutation )if they are opposite then, Due to attack it leaded to successful execution of operation that were not possible using set of valid test calls. For eg.if we take an any operation that just changes the values in the database and indicates success or non success of the modification. Then it is confirmed that this attack was able to prevent authentication mechanism from further proceedings and thus shows a vulnerability remark. 5. Else, Vulnerability is not present and web service behavior was not changed in any manner by the attack

9 Input request(r) Attackload request(a) 1. Brow Yes Not vulnerable 2. yes A Robustness R W test(r) Yes No yes W Robustness problem Yes 4.. A is opposite of w? Yes Vulnerabilit y found No 5.? Fig 4. Ouput analysis for SQL injection vulnerability

10 5.Conclusion In this paper we selected open source web scanners and a small set of web services.the experimental study was performed to evaluate the effetiveness of the scanners,for this various web services were scanned and potential vulnerabilities were identified. The results showed that every scanners has its own capability,but sql injection is the only vulnerability that was detected by all the three scanners i.e high risk.also the average resonse time for each scanners were computed that resulted wen securify the fast. To reduce the false postive rate an approach has been proposed to confirm the presence of sql injection vulnerability in future which can be applied in the scanner to increase their effectiveness. References 1. L. Xu and B. Xu, A Framework for Web Application Testing, International Conference on Cyberworlds, R.Chopra, SoftwareTesting, n.html?id=utjy3wqllckc. 3. S. Anand and A. Saha, Survey of Web Testing Techniques, International Journal of Computer Applications, B. Donley and J. Offutt, Web Application Testing Challenges, A. Arora, M. Sinha, Web Application Testing: A Review on Techniques, Tools and State of Art, International Journal of Scientific & Engineering Research, J. Bau, E. Bursztein,.D. Gupta, and J. Mitchell, State of the Art: Automated Black-Box Web Application Vulnerability Testing,IEEE, J. Tudor, Web application vulnerability statistics,context information security,june, J. Orloff, Web application security: Testing for vulnerabilities,ibm, L. Suto, Analyzing the Effectiveness and Coverage of Web Application Security Scanners, Mark Curphey and Rudolph Araujo, Web Application Security Assessment Tools, IEEE, A.Doup e, M.Cova, and G.Vigna, An Analysis of Black-box Web Vulnerability Scanners, International Conference on Communications and Information Technology, Gencer Erdogan, Security Testing of Web Based Applications, Department of Computer and Information Science, june S.Azzam, M. N. Al-Kabi, I. Alsmadi, Web services testing challenges and approaches, International Conference on Communications and Information Technology, Feb