Annual Web Application Security Report 2011

Transcription

1 Annual Web Application Security Report 2011 An analysis of vulnerabilities found in external Web Application Security tests conducted by NTA Monitor during 2010

2 Contents 1.0 Introduction Summary Number of vulnerabilities found Occurrences of risk levels Risk levels Top five high risks Top five medium risks Sector Analysis Recommendations made on the basis of this report s findings General Advice About NTA Monitor Contact details for NTA Monitor Ltd NTA Monitor Ltd 2010 Page 2

3 1.0 Introduction NTA s Annual Web Application Security Report 2011 highlights significant trends and identifies the most common vulnerabilities discovered through web application testing undertaken on behalf of clients in both the public and private sector across a wide range of industry sectors. The report analyses data gathered from all application tests completed between 1 January and 31 December Risk levels high, medium, low and informational - are defined as: High Medium Low Informational Allows unauthorised external users to obtain system access. The vulnerability is widely known and actively exploited by hackers. Allows external users to disrupt services, permits users to obtain unauthorised access or could provide access to unauthorised external users if incorrectly configured. Provides information that could be valuable to a hacker. Issues that are not directly security exposures, but result in non-optimal Internet performance for users. Informational occurrences typically indicate poor security housekeeping and knowledge of how some Internet mechanisms work. The report s findings present the average risks found, rather than total numbers, in order to provide a consistent overview of the risk levels and occurrences, offering a benchmark for comparison. Data is also presented by sector, enabling those using this report to benchmark their organisation against their peers. Comparisons will also be drawn where appropriate between the findings of this report (referred to as the 2011 report) and the 2010 report, which analysed the results of vulnerability tests conducted during NTA Monitor Ltd 2010 Page 3

4 2.0 Summary Results highlighted a marked jump in the average number of vulnerabilities found per web application up from 14 in 2009 to 15.6 in The total number of flaws identified per test substantially increased too. In 2010, 70% of tests had more than 11 flaws compared with just 47% in Analysis of the test results showed a slight drop in the overall total occurrence of high risk issues in web application tests down from 28% in 2009 to 25% in 2010 but a significant rise in medium risk threats up from 62% in 2009 to 79% in On average, each web application test contained 0.4 high risks, 3.5 medium risks, 8.7 low risks and 2.9 informational risks. SQL injection and cross-site scripting (XSS) were the most common flaws found in web applications in Data from web application tests showed that more than a quarter (27%) of threats identified as high risk were categorised as SQL injection, while 21% of medium risk issues were classified as XSS. Other frequently occurring threats to information security included a lack of patching (16%), Denial of Service (DoS) vulnerabilities affecting Apache web servers (13%), cross-site request forgery (CSRF) (4%), no, or poor, encryption (4%) and issues around password management (4%). Evaluating the test results by industry sector, IT & Telecoms was found to be the least secure with above average high and medium risks (0.6 and 4.1 respectively), and slightly above average total number of vulnerabilities at 16.7 per test. The sector seen to be the most secure according to test data was finance, which had below average high (0.1), medium (2.5) and total number of risks (13.7) per web application test. Figure 1 shows the percentage ratio of risk levels found from all tests conducted by NTA Monitor. Figure 1 Risk levels found in web application tests % 32% 26% 34% High Medium Low Informational NTA Monitor Ltd 2010 Page 4

5 3.0 Number of vulnerabilities found An average of 15.6 vulnerabilities was found per test. The number of issues identified ranged from one to 69 issues in a test. In 2010, testing identified more applications containing a higher number of vulnerabilities than in Of the applications tested, 30% had between one and 10 issues, 47% contained between 11 and 20 flaws, 17% had vulnerabilities, 6% had issues and 1% contained 41+ issues. Figure 2 shows the percentage comparison with Figure 2 Vulnerabilities found per test 41 +* Number % % of tests 2010 % of tests 2009

6 4.0 Occurrences of risk levels On average, 0.4 high risks per application test was found, with high risks accounting for just 3% of the total vulnerabilities discovered across all tests. An average of 3.5 medium level risks was found per test and, overall, medium risks accounted for 23% of all vulnerabilities found. The majority of risks (56%) were of a low risk level and an average of 8.7 low level risks was found, while an average of 2.9 informational vulnerabilities was identified in each test, accounting for 19% of all vulnerabilities. Figure 3 compares the average number of risk levels found per test with last year s results. Figure 3 Average vulnerabilities found per test (all sectors) High Medium Risk Low Informational Total Average number NTA Monitor Ltd 2010 Page 6

7 5.0 Risk levels During 2010, a quarter of web applications tested found at least one high risk vulnerability. Of those tests, 17% found one high risk issue and 8% found more than one high risk vulnerability. High-level risks represent a significant security threat to an organisation because it could allow unauthorised external users to obtain system access. These flaws are often widely known and exploited by attackers. 79% of tests found one or more medium-level risk a significant rise of 17% on The presence of any medium level vulnerability can mean that external users may be able to disrupt services or permit them to obtain unauthorised access. While 98% and 97% of tests contained low and informational risks respectively, which although may not present an immediate security threat to an organisation, could provide information that may be valuable to an attacker, or result in poor Internet performance for users. Informational occurrences tend to indicate inconsistent security housekeeping and lack of knowledge in how some Internet mechanisms work. Analysing the data in detail, the most common high and medium risk flaws have been identified as follows. NTA Monitor Ltd 2010 Page 7

8 5.1 Top five high risks 1. Web application has SQL Injection vulnerability (27%) (not featured) SQL Injection is a result of insufficient input validation on the server side. Often form fields or URL parameters controlled by the user are inserted into dynamic SQL queries on the server-side. If these user-controlled elements are not sanitised it could lead to arbitrary SQL code execution on the backend database. The scope of exploitation is limited to the permissions and access of the database user in use by the application at the time of exploitation. This is why it is important to use a non-privileged database user account and to strip the user of permissions not required for correct application functionality (i.e. INSERT, DELETE, MODIFY). 2. Patch Management (16%) (not featured) The operating system(s) are running out-of-date software packages (ie service pack eg Windows). As each service pack typically contains many service patches, the server may be at risk. With this information, an attacker can perform a denial of service or even compromise the IT systems. 3. Cross-site scripting (6%) (not featured) The web server is vulnerable to an attack known as cross-site scripting (XSS), which enables a hostile web site to cause malicious code, such as JavaScript commands, to be executed in a user s browser and gather information such as session IDs and cookies, which could provide access to the user s account. This vulnerability could enable users who unwittingly click on a malicious link to leak private information to attackers. XSS is considered to be high risk if the web application allows users to store data on the server by entering information through web forms. The vulnerability is much less significant if your site does not have this functionality. 4. Cross-site request forgery (CSRF) (4%) (not featured) CSRF (cross-site request forgery) allows an attacker to submit data on behalf of an authenticated user, without their knowledge. A CSRF, although similar-sounding in name to cross-site scripting (XSS), is a very different form of attack. Where cross-site scripting exploits the trust a user has in a web site, a CSRF exploits the trust a web site has in a user by forging a request from a trusted user. These attacks are often less popular (so there are fewer resources available), more difficult to defend against than XSS attacks, and, therefore, more dangerous. Depending on the forms affected, an attacker could hijack user accounts by changing addresses and then using the forgotten password form to reset or gain access to the account, change passwords, add user accounts, escalate account privileges etc. 5. Password issues (4%) (not featured) A range of password management issues can affect the security of a system in an organisation. Users may be able to change their passwords to ones that are weak and guessable, for example , which increases the chance of unauthorised access to their account. Alternatively, some organisations may not be filtering meta characters from a chosen password. When changing the password, it is possible to include characters with special meaning such as semi-colons in the password field. Failing to filter out such characters could leave an organisation open to piggy-backing attacks where attackers submit data using the intended method but embed commands in this data, which will be executed by back-end systems. NTA Monitor Ltd 2010 Page 8

9 5.2 Top five medium risks 1. Web application has cross-site scripting vulnerability (XSS) (21%) (#1) Cross-site scripting enables a hostile web site to cause malicious code such as JavaScript commands to be executed in a user s browser and gather information such as session IDs and cookies. This vulnerability could enable users who unwittingly click on a malicious link to leak private information to attackers. 2. Denial of Service (DoS Apache) (13%) (#2) The Apache web server is vulnerable to a denial of service attack where a remote attacker can send a specially crafted GET request, containing a false content-length: header, which can cause the connection from attacker to web server to remain open, and un-responsive. This can be used as an attack to consume server resources. An attacker could exploit this flaw to take up all available connections to the web server, thereby denying access to legitimate clients. Due to the nature of this attack, far less bandwidth is consumed than with a conventional attack as it relies on the web server running out of resources, not the Internet gateway bandwidth being saturated. This is due to a combination of default 'TimeOut' and 'MaxClients' server settings and overall server design. 3. No account lockout mechanism (10%) (#3) User accounts are not locked out after several incorrect login attempts. This means that an attacker, given a valid username, could perform a brute force attack on the password i.e. repeatedly guess the password until he finds the correct one. 4. Static session ID is used before and after authentication (5%) (not featured) The session ID issued by an application remains static pre and post login. That is, the user is given the same specific session ID before and after authentication with the web application. Because the session ID stays the same even after the authentication, it is thereby eliminating the need for an attacker to obtain the value of a session ID that an authenticated user could have afterwards. Therefore, if an attacker manages to find a way to fix the session ID of a user, they can authenticate as that user without needing to know the user s username and password. 5. No, or weak, encryption (4%) (not featured) Allowing access to secure areas over plain HTTP can result in users sending account information or sensitive and confidential data unencrypted. This data being sent in the clear may be at risk of being intercepted by attackers/sniffers. NTA Monitor Ltd 2010 Page 9

10 6.0 Sector analysis Evaluating the test results by industry sector, IT & Telecoms was found to be the least secure with above average high and medium risks (0.6 and 4.1 respectively), and slightly above average total number of vulnerabilities at 16.7 per test. The services sector was also found to be as insecure having well above average total number of vulnerabilities at 18.4 per test, high numbers of medium risk vulnerabilities at 5.4, but average high risk flaws. Central and local government organisations, however, have seen a marked improvement in information security from Although local government had above average high risk vulnerabilities at 0.6 per test, the average total number of vulnerabilities per test was just 12.2 compared with 19.3 in And risks classified as a medium threat were well below average too at 2.6 (compared with the all sector average of 3.5). No high risks were indentified in web applications being run by central government departments, but average total numbers of vulnerabilities per test were running at well above sector average at The sector seen to be the most secure according to test data was finance, which had below average high (0.1), medium (2.5) and total number of risks (13.7) per web application test. Figure 4 highlights the average ratio of risk levels for each industry sector, compared with the all sector average. Some sectors have been categorised slightly differently for Figures 5 and 6 (over the page) compare this year s industry sector data with 2009, using historic sector categorisation. Figure 4 Average number of risks found per test per sector 2010 Central Government Education Finance IT & Telecom Law Local gov - council Manufacturing NHS Non-profit Police High Medium Low Info Publishing Retail Services - other Utility Total average NTA Monitor Ltd 2010 Page 10

11 Figure 5 C om parison of average num ber of vulnerabilities per sector 2009 / Government Finance Charities/Non profit Services IT & Telecoms Manufacturing Legal Utilities Total average

12 Figure 6 Changes in risks found per sector from 2009 to Government Finance Charities/Non Profit Services IT & Telecoms Manufacturing Legal Utilities Total average High Medium Low Informational NTA Monitor Ltd 2010 Page 12

13 7.0 Recommendations made on the basis of this report s findings To address SQL issues, it is important that all user input is parameterised (where possible). Most databases and languages support parameterised queries (i.e. PREPARE for MySQL? and PreparedStatement? for Java). If prepared statements are not possible, it is important that all META characters (i.e. single quote) input be sanitised before being allowed to pass to the backend database (i.e. htmlspecialchars with ENT_QUOTES for PHP) It is recommended that systems are updated with the latest service pack and patches. It is also suggested that a patch management policy to update IT systems on a frequent basis is put in place To avoid XSS, all areas of an application must be checked and sanitised against invalid character input where user input is required. All Meta characters and HTML tags (i.e. < >) should be restricted where possible before allowing it to the backend Switching from a persistent authentication method (e.g. a cookie or http authentication) to a transient authentication method (e.g. a hidden field provided on every form) will help prevent CSRF attacks. A similar approach is to include a secret, user-specific token in forms that is verified in addition to the cookie. Contrary to popular belief, using POST instead of GET does not offer sufficient protection. JavaScript can be used to forge POST requests with ease. But, requests that perform an action should always use POST. It is therefore recommended that a random token be applied to each form to provide form-based security and to prevent rogue form submission Tighter restrictions must be placed on password length and more stringent controls on what users can choose as their password are applied. This will help users protect their account more effectively. It would also be beneficial to provide some online documentation on choosing secure passwords. In addition, characters allowed in the password and all other fields submitted using web forms should be reviewed, taking care to filter out any characters, which may cause back-end systems to execute unwanted commands If web servers are running a version of Apache Web Server that is vulnerable to a denial of service, appropriate patches should be applied or servers upgraded to the latest version It is recommended locking accounts out after around three consecutive failed logon attempts. This will prevent attackers from being able to brute force accounts. To avoid locking an account out indefinitely, best practice is lock a user out for a substantial amount of time eg between 30 mins and two hours after three incorrect attempts. There is a good chance that this won t affect the user, but it will certainly hamper an attacker s progress It is recommended that an old session ID is expired and a new session ID is issued after successful authentication Access to sensitive or confidential information should only be allowed over SSL. It is particularly important to ensure login form details are submitted to an HTTPS URL.

14 7.2 General Advice This is a non-exhaustive list of recommendations for improving web application security Regular independent testing In order to ensure that your website s visitors can use the site securely, it is essential to conduct regular, independent web application testing Staff involvement Educating and training staff on Internet security issues can make a significant difference to the number of holes in your network security. For instance, some risks discovered in this report, such as permitting users to choose insecure passwords, can be completed by any individual, and one who knows little about network security will not consider the consequences of their action Clear and up to date security policy Develop, publicise and update a clear security policy. Make sure that as staff and the business change everyone is aware of measures that they can personally take to maintain network and Internet security. Adherence to the company security policy should be tied in with staff contracts and disciplinary procedures Configuration Configure all systems according to the security design and use a standard build for all perimeter systems types. This ensures that all systems are hardened to the same standard. If a flaw is identified in one system, a tested patch can be readily applied to all identical systems Ongoing vigilance Maintain awareness of latest threats, software flaws and countermeasures. Monitor security newsgroups and subscribe to security alert and vendor mailing lists Management focus Allocate sufficient management time, focus and control to ensure that preventative actions are carried out on an ongoing basis to minimise security flaws at all levels. Provide sufficient staff resources to address vulnerabilities that threaten your business. Good housekeeping results in good security and as a large proportion of the risks discovered were an informational risk level, this indicates that security housekeeping is poor Security SLAs When choosing new Internet or managed service providers, insert a security SLA (Service Level Agreement) into the contract. This should define what risk level and time-to-fix the vendor would commit to for the systems managed on your behalf. At the very least, the vendor should agree to fix security holes identified by your staff or independent security advisors. NTA Monitor Ltd 2010 Page 14

15 About NTA Monitor NTA Monitor was the first UK commercial independent provider of information security testing, auditing and consultancy services. With 15 years of experience, NTA Monitor provides a broad range of services to over 650 clients globally. With an increasing emphasis being placed on corporate governance and compliance, NTA is an ideal security partner to help organisations adhere to best practice guidelines and standards. NTA is a founder member of the CREST and CESG CHECK schemes and has continually maintained the highest CHECK Green level. NTA can provide CESG CLAS consultants and is able to deliver services through the NPIA and OGC Buying Solutions frameworks. NTA is also an Approved Scanning Vendor (ASV) under the PCI DSS, which governs security standards for the payment card industry. The company provides a range of security services, which are headlined below. The results detailed in this report are taken from the Web Application Security Test service. EXTERNAL IT SECURITY INTERNAL IT SECURITY CONSULTANCY, POLICY & RISK RM Vulnerability Test Web Application Test PCI Compliance Assessment IPSec / SSL VPN Security Test Citrix Gateway Security Test Webmail Security Test (OWA etc) Wireless Infrastructure Test BlackBerry Audit Laptop Security Review Social Engineering War Dialling Network Architecture Test & Audit Code of Connection IT Health Check Database Testing Configuration & Rulebase Review Data Leakage Prevention VoIP Security Audit VLAN Switch Review Desktop Security Review Removable Media Review Physical Security Review IT Risk Assessment / Gap Analysis Compliance (ISO, PCI, CoCo, SoX) Security Policy & Procedure Vulnerability Toolset Training Web Stress Test Code Review Forensics Consultancy CHECK & CLAS Contact details for NTA Monitor Ltd UK Office 14 Ashford House, Beaufort Court, Medway City Estate, Rochester, Kent, ME2 4FA. Telephone: +44 (0) Fax: +44 (0) marketing@nta-monitor.com Website: Malaysian Office B21-7, Block B, Jaya One, 72 (A), Jalan Universiti, Petaling Jaya, Selangor, Malaysia Telephone: Fax: sales-dept@nta-monitor.com.my NTA Monitor Ltd 2010 Page 15