CMP3002 Advanced Web Technology Assignment 1: Web Security Audit A web security audit on a proposed eshop website By Adam Wright
Table of Contents Table of Contents... 2 Table of Tables... 2 Introduction... 3 Findings... 4 Findings Summary... 4 The Investigation... 5 Key Findings... 6 Conclusion and Recommendations... 9 References... 11 Bibliography... 12 Appendix A: Web Security Audit Log... 13 Table of Tables Table 1.1 Microsoft s SQL Form Validation Guidelines...9 02/12/09 Page 2 of 32
Introduction Website security is a crucial step that needs to be enforced in today s society. With the increase in web technology within the business environment, security has become more important over the years. Some businesses in the market rely on the World Wide Web as their only front with custom (i.e. Amazon and Play.com). An online article at PC Tools (2008) states that online security is no longer a secondary issue which has been the case for many years prior. Out of the three main areas of security PC Tools (2008) indicated, one of the important ones is data encryption. The majority of web 2.0 websites store lots of information and this needs protecting. This is especially important when user data is stored. Other areas of security include server security and data backup routines. It is very important to look at who uses the website in question, setting access permissions, what is classed as reasonable use (policies) and ways to monitor activity (W3C, 2003). Over the years steps have been made to tighten web security. This is mainly important for web eshops. 30 June 2005 saw a step up in eshop security when major credit card firms came together to produce a set of guidelines that need to be enforced (BBC, 2005). One of these basic guides included password character lengths. Simple steps can make a big impact on web security. This technical report will illustrate the key findings of the security audit taken place on the Web Tools eshop (found at http://hemswell.lincoln.ac.uk/shop) in November 2009. The report will cover a findings summary, a summarised investigation description, key findings and conclusions with recommendations. Appendix A includes a copy of the security audit test log which contains detailed test information with appropriate screenshots. 02/12/09 Page 3 of 32
Findings Findings Summary After a website security audit was carried out on the Web Tools eshop, a few security vulnerabilities were detected. The eshop currently contains no form of Secure Socket Layer (SSL) security. Without SSL, confidential data such as passwords and card details are transmitted between the client s browser and website server(s) in plain text. This can be easily intercepted by a hacker. It is recommended that an SSL application is made to http://www.verisign.co.uk/ once the site has its final server location and domain name. The websites form inputs allow SQL characters to be sent to the server. Although no immediate SQL error has been generated from this, it is recommended that client and server-side validation is applied to form inputs. SQL characters within the state/region field of user registration causes a later error when a customer is ordering an item. Customers viewing a submitted order are able to modify the order ID parameter within the address URL. By doing this, a customer can access other users order information including address and card details. An alternative method to view orders is suggested (other than the GET method) or a checking algorithm should be implemented to make sure the user who submitted an order is the one currently logged in. The chapters which follow this findings summary look at the investigation, findings and recommendations in more detail. Appendix A contains the security audit logs with detailed explanations and screenshots. 02/12/09 Page 4 of 32
The Investigation The web security audit on the Web Tools eshop took place over three days within November 2009; 9 November, 11 November and 19 November. The tests carried out were categorised into three types of test: Visual Practical Hack Visual tests involved looking for weaknesses without any direct input as one would expect with practical and hack tests. One of these visual tests was to see if Secure Socket Layer (SSL) was implemented on the site. Practical tests involved usual actions which standard users would perform e.g. clicking on links and testing out functionalities such as login. Hack-classified tests involved code injection and manipulating the site into performing actions it wasn t intended for. The first session on 9 November 2009 included seven tests that looked at vulnerabilities within each of the three areas mentioned earlier. The visual tests carried out looked at SSL protection and source code. SSL is a major security algorithm that should be present in all websites that carry out transactions such as eshops. Analysing the website source code can explain a lot about the way the site is implemented and how serious the organisation takes web security. Coding comments can give away weak aspects and include over sensitive information. The practical tests carried out looked at the logon functionality of the website. Some websites may allow logon with null (blank) or common user credentials. This poses a high security risk without the hacker trying to hard. The hack-classified tests carried out looked at URL manipulation and code injection within input forms. These sets of tests are important in determining the security vulnerabilities of a website and include harsher actions which can potentially stop a website from operating. The second session of testing on 11 November 2009 included tests within the practical and hack-classified categories with emphasis on the hacking side of the audit. 02/12/09 Page 5 of 32
The practical test involved the analysis of the forgot password mechanism to ensure it operated in the appropriate manner. Nearly all websites with a user base have a forgot password mechanism and is an area of great importance. The hack-classified tests looked at further code injection and webpage manipulation by saving the registration page and running it externally. These sets of tests are highly recommended and provide detailed information about the sites configuration. The third and final session of testing on 19 November 2009 looked at a particular code injection test that became apparent after the previous tests had been fulfilled. A JavaScript alert command was injected into the registration input to determine potential code execution weaknesses. With the above methodology put into practise, the security audit on the Web Tools eshop has covered key areas including basic weaknesses in terms of passwords and SSL and complex weaknesses in terms of SQL and URL modification. The succeeding chapter looks at the results of the tests carried out and explains what they could mean for the eshops future. Key Findings Test session 1 on 9 November 2009 investigated potential problems in all areas of the security framework. Test ID 01 carried out a visual investigation to see if Secure Socket Layer (SSL) technology was implemented on the eshop. The results of this test confirmed that the site does not have SSL and therefore poses as a large security hole. This point-to-point protocol can encrypt personal data between two points (Dacontal, 2003) and is extremely important for eshops that use user passwords and bank card information. As stated in the website brief, the site is not yet released to the public domain and could therefore have SSL implemented at a later stage. However, the briefing also states that adequate security provision has been made. SSL is a cryptographic technology which uses public and private keys in order to achieve maximum security (Webopedia, 2008) and would be advised. Test ID 02 involved a brief analysis of the websites source code within the registration and order cart sections. This test looked for any vulnerabilities in the code with concentration on commenting. The site in question had no apparent risks within the commenting of the code. Commenting is usually used to indicate what a piece of code does and how it does it. Too much commenting information (as with error messages) provides security risks. 02/12/09 Page 6 of 32
Test ID 03 and 04 looked at the login functionality of the eshop. Test 03 attempted to login with null (blank) user credentials. Some websites allow this in error which allows users to access login areas without registering. Without posing any direct threat, it is not something that should happen on your website for long term security purposes. This test was successfully passed as logon with null credentials was refused. Test 04 used commonly used and default credentials in order to attempt forced logon access. The credentials used involved combinations of admin, administrator, user, test, root and password. After testing these combinations, access was not granted. Test ID 05 involved the injection of SQL code into the website inputs. SQL is a powerful database manipulation language that can severely damage a website and cease it from operating. Specialised SQL characters and ; were used to test for SQL vulnerabilities. User registration and site search inputs were used to test this input. No SQL error was generated and information was accepted successfully. With SQL errors not being generated it shows that SQL is not being triggered by injection. One aspect that was noticed was the add slash function when the form refreshes after failed form criteria. This is a very useful function. After injecting SQL characters and lines into the registration fields, it became apparent that a vulnerability was present when pursuing an order. An SQL character entered into the state/region field of a personal area affects the order processing for tax. With the right syntax, SQL could be run through this hole in the system. Test 05 failed because of this result but it was noted that a character maxlength was enforced to limit the amount of code a hacker could enter. Test ID 06 investigated URL modification where GET parameters are used. It was discovered that parameters were visible in the address URL when viewing an order. With order ID displayed in this way, a user can alter it to view other orders. This was successfully performed during the test and revealed order ID 8 rather than the original order ID of 9. This weakness allows users to see other people s addresses, orders and bank card details. Test 06 failed with high severity because of the outcome of the test. Test ID 07 took the URL parameter weakness even further by adding functions onto the URL. By accessing a URL from an image, the function productadd was added in an attempt to modify the eshops listings. The function was recognised but denied access to this administration feature. This denial of function access shows that sufficient user validation is in place within this area. Test session 2 on 11 November 2009 investigated a practical task and numerous hack-classified tests. Test ID 08 looked at the practical task which involved the investigation of the forgot password mechanism. The forgot password mechanism 02/12/09 Page 7 of 32
on the Web Tools eshop worked appropriately and produced an error if you entered another username with your own email address. Test ID 09 involved further SQL character injection into the registration input fields for re-test purposes as the website was potentially being altered slightly. The test results show the same results as the earlier test from session 1 (test ID 05). SQL characters ( and ;) were inputted without error but the state/region field still contained the SQL vulnerability when pursuing an order. Test ID 10 attempted to enter non-latin characters into the sites registration inputs to investigate how the website handled it. This extreme testing method attempted to break the website and reveal unexpected errors. A Hebrew word was entered into the username field which generated a username contains a space error. The test shows that non-latin characters are not accepted and the system claims to detect a space. As good as this may be for security, it holds user constraints. Web security is very important but should not get in the way of HCI and user issues. Test ID 11 saw an extension to the SQL vulnerability in the users state/region address field. By saving the customer registration page and altering the maxlength of the field, longer words could now be entered. This test originally aimed to see if longer SQL commands could be entered but passed due to the forms input maxlength being enforced higher up (presumably at the database level). Commands entered were cut back to the original maxlength after successful submission. Test session 3 on 19 November 2009 investigated a final hack-classified test that came apparent after the previous tests. JavaScript is a powerful coding language that provides interactivity and page manipulation on basic websites. A JavaScript alert command was injected into the continued address input for test ID 12. When a page such as order processing was displayed with user details, the JavaScript command was run. A popup was displayed saying JavaScript possible. This test failed as this opens up the possibility for hackers to modify form values and other parameters through JavaScript technology (Testing Security, 2006). See appendix A to view the original security audit logs which contain detailed test explanations with screenshot evidence. 02/12/09 Page 8 of 32
Conclusion and Recommendations After carrying out the 12 tests outlined in the previous section, it is apparent that the website is not suitable for public release in its current condition. Without SSL, all confidential data such as banking details will be transmitted as plain text for easy interception. The eshop contains small but problematic vulnerabilities with SQL and JavaScript injection which can be used to manipulate the website into performing tasks and making alterations that would not usually be possible. The order ID can be altered via the sites URL when viewing orders to access other people s information including bank card details. Before the website is launched into the public domain, various changes are recommended. Code injection into the website should be prevented at all costs and can be done so using client-side and server-side validation. Microsoft (2008) recommends that web developers block the following characters on input forms: Input Description ; Used as an SQL query delimiter Used as an SQL data string delimiter -- Used as an SQL comment delimiter /* */ Used as an SQL comment delimiter without server evaluation Table 1.1 Microsoft s SQL Form Validation Guidelines Source: http://msdn.microsoft.com/en-us/library/ms161953.aspx Input validation is at its best when performed on the server-side of communication. JavaScript validation on the client-side is easy to execute and manipulate as witnessed in the tests and can be bypassed very easily (Testing Security, 2006). Server-side validation can be carried out via PHP and would be highly recommended. Secure Socket Layer (SSL) protection is a highly recommended algorithm for any eshop in the world market. It retains the security of information as it is sent between the client and website server(s). Without SSL, data is transmitted as plain text which anybody can intercept. VeriSign is the leading SSL authority and currently protects over one million web servers (VeriSign, 2009). By visiting VeriSign UK at http://www.verisign.co.uk/ you can apply for certificates. This will involve server analysis to ensure it is appropriate for SSL and other checks on the website itself. The Web Tools eshop should be moved to the server it will remain hosted on and should be using its permanent domain name before an SSL application is made. 02/12/09 Page 9 of 32
URLs with important parameters such as order ID s need to be carefully looked at in order to prevent people accessing sensitive information. One way to prevent parameters in the URL would be to avoid using the GET request. However, this is not always a practical solution. A practical solution would be to implement an order session token or alternative user checking method (CGI Security, 2009). By identifying the user, access to order information can be granted or denied depending on the match. It is recommended that these changes are implemented before launch and that this documentation is read along with appendix A (Security Audit Logs) before any decision to make the eshop active is made. Some of the references within this report provide a good in-sight into specific security vulnerabilities and how to make sure a website is safe and secure. By making the suggested alterations and keeping track of current security vulnerabilities, the Web Tools eshop should have sufficient security provision. 02/12/09 Page 10 of 32
References BBC (2005). Web Shops Face Tighter Security [online]. Available from http://news.bbc.co.uk/1/hi/technology/4449759.stm [accessed: 21 November 2009]. CGI Security (2009). Parameter Manipulation [online]. Available from http://www.cgisecurity.com/owasp/html/ch11s04.html [accessed: 28 November 2009]. Daconta, Michael C. (2003). Semantic Web, The: A Guide to the Future of XML, Web Services, and Knowledge Management, Wiley, Available from: http://lib.myilibrary.com/browse/open.asp?id=34522&loc=78 [accessed: 1 December 2009]. Microsoft (2008). SQL Injection and Prevention [online]. Available from http://msdn.microsoft.com/en-us/library/ms161953.aspx [accessed: 15 November 2009]. PC Tools (2008). Website Security is Important Business Advised [online]. Available from http://www.pctools.com/industrynews/article/website_security_is_important_businesses_advised-18743243/ [accessed: 21 November 2009]. Testing Security (2006). JavaScript Injection [online]. Available from http://www.testingsecurity.com/how-to-test/injection-vulnerabilities/javascript- Injection [accessed: 19 November 2009]. VeriSign (2009). SSL Certificates, Encryption and Extended Validation [online]. Available from http://www.verisign.co.uk/ssl/index.html [accessed: 28 November 2009]. W3C (2003). The WWW Security FAQ [online]. Available from http://www.w3.org/security/faq/wwwsf1.html#gen-q1 [accessed: 21 November 2009]. Webopedia (2009). What is SSL? [online]. Available from http://www.webopedia.com/term/s/ssl.html [accessed: 28 November 2009]. 02/12/09 Page 11 of 32
Bibliography BBC (2005). Web Shops Face Tighter Security [online]. Available from http://news.bbc.co.uk/1/hi/technology/4449759.stm [accessed: 21 November 2009]. CGI Security (2009). Parameter Manipulation [online]. Available from http://www.cgisecurity.com/owasp/html/ch11s04.html [accessed: 28 November 2009]. Daconta, Michael C. (2003). Semantic Web, The: A Guide to the Future of XML, Web Services, and Knowledge Management, Wiley, Available from: http://lib.myilibrary.com/browse/open.asp?id=34522&loc=78 [accessed: 1 December 2009]. Microsoft (2008). SQL Injection and Prevention [online]. Available from http://msdn.microsoft.com/en-us/library/ms161953.aspx [accessed: 15 November 2009]. PC Tools (2008). Website Security is Important Business Advised [online]. Available from http://www.pctools.com/industrynews/article/website_security_is_important_businesses_advised-18743243/ [accessed: 21 November 2009]. Testing Security (2006). JavaScript Injection [online]. Available from http://www.testingsecurity.com/how-to-test/injection-vulnerabilities/javascript- Injection [accessed: 19 November 2009]. VeriSign (2009). SSL Certificates, Encryption and Extended Validation [online]. Available from http://www.verisign.co.uk/ssl/index.html [accessed: 28 November 2009]. W3C (2003). The WWW Security FAQ [online]. Available from http://www.w3.org/security/faq/wwwsf1.html#gen-q1 [accessed: 21 November 2009]. Webopedia (2009). What is SSL? [online]. Available from http://www.webopedia.com/term/s/ssl.html [accessed: 28 November 2009]. 02/12/09 Page 12 of 32
Appendix A: Web Security Audit Log
CMP3002 Advanced Web Technology Assignment 1: Web Security Audit Security Audit Checklist Website: http://hemswell.lincoln.ac.uk/shop By: Adam Wright 02/12/09 Page 14 of 32
Test Session: 01 Date: 09/11/2009 Tester: ADAM WRIGHT Site: http://hemswell.lincoln.ac.uk/shop ID Description Type Outcome Pass/Fail Severity Notes 01 Check for SSL encryption based on https, padlock symbol and certificate validity. Visual The website lacks SSL support and therefore sends data unencrypted/ Fail High No SSL layer. SSL should be put into practise for eshop launch. 02 Check website source code for any weaknesses in structure and comments. Visual The source code has no apparent failings. Pass Low Source code appropriate. Pass grade does not suggest that the code has in-depth weaknesses. 03 Attempt to log into the user area with null credentials. Practical No access available. No error messages associated with values. Pass Medium Cannot login with null credentials. 04 Attempt to log into the user area with default and common credentials; admin, user, test Practical No access available. Pass High Could not login with common and default passwords. 02/12/09 Page 15 of 32
05 Inject SQL into visible input fields to access or alter information; symbol Hack Fields accept SQL syntax characters without error. Vulnerability with state/region during order processing. Fail Medium SQL error generated during order payment if state/region field contains SQL syntax. Maxlength limits commands. 06 Modifying order ID parameters to display unauthorised information. Hack Access other users order details including card details. Fail High Other users orders accessible. 07 Adding URL GET parameters (productadd) to modify, display and access areas of the site. Hack Administration action access denied. Pass High Access to the admin panel is restricted despite injecting GET parameters in the URL. 02/12/09 Page 16 of 32
Test Session: 02 Date: 11/11/2009 Tester: ADAM WRIGHT Site: http://hemswell.lincoln.ac.uk/shop ID Description Type Outcome Pass/Fail Severity Notes 08 Test the forgot password mechanism to various email addresses. Practical Password reset email received to users corresponding email. Pass Medium Email sent to associated email address. 09 Injecting further SQL characters ( and ;) into input fields for re-test. Hack SQL inputs accepted without error. Pass Medium SQL characters accepted into surname without error. Form refresh shows add /. 10 Inputting non-latin characters (Hebrew) into input fields Hack Would not accept. Claimed there was a space. Pass Low Space in input credentials detected. 11 Cross-site registration page saving to modify Maxlength on state/region SQL weakness. Hack Maxlength altered but injected SQL code remained cut down after submission. Pass High Code entered was cut down. Possible Maxlength on database field. 02/12/09 Page 17 of 32
Test Session: 03 Date: 19/11/2009 Tester: ADAM WRIGHT Site: http://hemswell.lincoln.ac.uk/shop ID Description Type Outcome Pass/Fail Severity Notes 12 Inject JavaScript (alert command) into registration input Hack JavaScript ran and displayed alert popup. Fail Medium Script ran without error. 02/12/09 Page 18 of 32
Screenshots Test ID 03 9 November 2009 12.48 pm 02/12/09 Page 19 of 32
Test ID 04 9 November 2009 12.28pm 02/12/09 Page 20 of 32
Test ID 05 9 November 2009 12.42pm 02/12/09 Page 21 of 32
9 November 2009 12.46pm 02/12/09 Page 22 of 32
9 November 2009 6.43pm 02/12/09 Page 23 of 32
Test ID 06 9 November 2009 1.03pm 02/12/09 Page 24 of 32
Test ID 07 9 November 2009 1.16pm 02/12/09 Page 25 of 32
Test ID 08 11 November 2009 2.49pm 02/12/09 Page 26 of 32
Test ID 09 11 November 2009 4.57pm 02/12/09 Page 27 of 32
11 November 2009 5.07pm 02/12/09 Page 28 of 32
Test ID 10 11 November 2009 4.18pm 02/12/09 Page 29 of 32
Test ID 11 11 November 2009 9.20pm 02/12/09 Page 30 of 32
Test ID 12 19 November 2009 5.51pm 02/12/09 Page 31 of 32
19 November 2009 5.52pm 02/12/09 Page 32 of 32