1

Web Application Security Whitepaper

CE0971A Ethical Hacking 3

Jamie Burkinshaw 1100956

Information contained in this document is for educational purposes only and should be treated as such

2

Contents

Abstract 3

Introduction 4

Method 6

Setup 6

OWASP Zed Attack Proxy 6

PortSwigger Burp Suite 6

OWASP WebScarab 8

Results 9 Zed Attack Proxy 9 Burp Suite 10 WebScarab 12

Discussion 13 Expoitation 13 Countermeasures 14 Evaluation 15

Conclusion 17

References 18

Bibliography 19

Appendices 20 App. 1: BWA Details 20 App. 2: Admin.jsp and Advanced.jsp 21 App. 3: Full ZAP Scan Results 22 App. 4: Full Session ID Analysis 29

3

Abstract

As web technologies have become increasingly more advanced they have been used for more and more serious purposes. Because of this, security is becoming an increasingly prevalent issue regarding the development of web applications. The aim of this investigation was to use several vulnerability scanners to identify vulnerabilities in a deliberately vulnerable web application more effectively and efficiently than manually checking. The three scanners used were OWASP‟s Zed Attack Proxy and WebScarab and PortSwigger's Burp Suite. The vulnerable web application to be tested was Bodgeit Store on the OWASP Broken Web Apps virtual machine. The scanners were effectively and efficiently used to help identify and exploit vulnerabilities in the target. Each was found to have its own individual uses. Overall it was concluded that Zed Attack Proxy was the most effective. Countermeasures were recommended for the major risks discovered which included restricting permissions allowed to an application accessing a database; validating user input and educating web application developers on the topic of security issues.

4

Introduction

When the internet was first conceived and began coming into mainstream use it consisted of websites that are unlike anything seen today. These early websites were simply collections of data stored on servers and the internet was a means of accessing the data. In this form, security threats on the internet were uncommon and any exploited vulnerability would not yield anything of great value as the internet was not as interactive as it is now. Websites did not store user data or any sensitive data and they did not provide a service other than delivering files and information.

As the internet started to grow, web developers realised the potential for the platform presented to them. They began to add new services to the websites they developed such as the ability for users to register and login to their websites, upload their own content and much more. Developers also started developing websites for different, more complex and more serious functions like banking, shopping and gambling which all store sensitive user data, for example, bank details. To achieve these functions systems called Web Applications were developed. Web applications are simply applications written that are stored with the websites that allow them to interact with the browser to complete a task.

Websites and web applications have developed to the point where now the entire world including nearly all large companies, stock exchanges, banks, shops and medical institutions rely on the internet for communication and to carry out their business, web applications are more important than ever and maintaining security is of very high importance. This is because much more sensitive data in much higher volumes is being handled by web applications.

As web applications began to handle more sensitive forms of data, criminals realised that this could be a method to steal user details and even money from institutions that used them. This is obviously a problem for the users of those applications. Security is now a major issue for these companies as hackers find more ways to bypass security features. The top 3 most dangerous vulnerabilities according to OWASP (The Open Web Application Security Project) are:

Code 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)

Broken Authentication and Session Management: (Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users‟ identities.)

Cross Site Scripting: (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 sites.)

(OWASP, 2013)

Because web applications are such an important part of the internet and they can also be very vulnerable. Organisations that implement web application systems need to test them thoroughly to insure they do not lose any user data or data that would allow an attacker to make a profit. This testing is achieved by hiring web application security specialists to

5

identify and attempt to exploit any vulnerability. A method of quickly assessing which vulnerabilities are present in a web application is to use automated vulnerability scanners which attempt multiple attacks on the web application to discover which are successful. The alternative methods would either be manually attempting multiple attacks which would be very time consuming but perhaps more thorough. Another possibility is to scan the code either with an automated tool to ensure the syntax does not allow for vulnerabilities.

The focus of this paper will be on investigating automated web application security scanners for effectiveness, efficiency and ease of use. The Aims of this paper are as follows:

To examine several vulnerability scanner's functions

To investigate the differences between scanners by scanning a deliberately vulnerable web application with multiple scanners and recording the vulnerabilities.

To identify the risks posed by the vulnerabilities discovered and how they can be exploited.

To recommend countermeasures that would help reduce the risk.

The scanners that will be investigated are: The OWASP Zed Attack Proxy and WebScarab as well as PortSwigger‟s Burp Suite. Because it is illegal to test a web application that doesn't belong to you without the owner's permission, A DVWA or deliberately vulnerable web application will be used. A DVWA is an application that has been specifically developed to allow web application security testers to find vulnerabilities placed on purposed for training purpose. The DVWA that will be used in this investigation is the Bodgeit store.

6

Method

Setup

The chosen vulnerable web application, Bodgeit Store, is available under the OWASP Broken Web Apps virtual machine or OWASP BWA, which is a virtual computer distributed by OWASP for the purpose of learning about web application security testing and practising related skills. It hosts many web applications including mutillidae, Damn Vulnerable Web App, WackoPicko and BodgeIt Store which is the application of main concern to this investigation. The settings that were used to run OWASP BWA as well as screen captures from the virtual machine and web interface screen can be found in Appendix 1 in the Appendices section at the rear of this document. The most Important thing to note from the settings is the network mode which is set to NAT which ensures the virtual machine shares the host's IP address.

All of the scanners to be used in this investigation (OWASP Zed Attack Proxy, Burp Suite, and WebScarab) are available on the security focused distribution of Linux called Kali (previously BackTrack) which contains many tools for the use of penetration testers and web application security testers. Kali will be used in its virtual machine format.

OWASP Zed Attack Proxy

OWASP Zed Attack Proxy or ZAP is a web application security testing tool from the Open Web Application Security Project group and is described as “An easy to use integrated penetration tool for finding vulnerabilities in web applications”.(OWASP, 2013) It contains an intercepting scanner for viewing conversations between client and application, a passive scanner which scans the website code for obvious security flaws; an active scanner which attempts different attacks on the application to reveal flaws and a fuzzer which tries even more specific attacks on vulnerable sections of the application.

While running ZAP as a proxy the browser is instructed to navigate to the BodgeIt Store page being hosted. For this investigation the address that ZAP and the other scanners will be investigating is 10.0.0.94/bodgeit. This adds the site to the websites tab in ZAP as the request has passed through and been recorded by ZAP before proceeding to the IP address. This is because ZAP has been set to act as a proxy for the browser. The spider tool in ZAP is then used to discover all sections of the website.

The next step is to run an active scan against the pages discovered by the spider. The settings for the scan carried out were low for Alert Threshold, which ensures all vulnerabilities were reported and insane Attack Strength to ensure all attack vectors were attempted. The fuzzer function of OWASP ZAP tries a dictionary of different code segments in inputs that are found to be vulnerable to identify what is causing it to be vulnerable and how it can be exploited. The ZAP fuzzer was used on the fields that were identified to be vulnerable to SQL injection attacks using all the relevant dictionaries available.

PortSwigger Burp Suite Burp Suite is described as “an integrated platform for performing security testing of web applications”(PortSwigger.com, 2013). The professional Version contains many features such as a scanner and a tool titled “Burp Intruder” which claims to be able to automate and

7

customise attacks against web applications. However the free version of Burp Suite is limited to: proxy functionality as spider tool well as some features entitled: repeater, which allows the user to manipulate and reissue http requests and sequencer, which allows for the testing of randomness in session tokens. The proxy was set to intercept traffic between the target and the host. When the home page had been intercepted the spider tool was used to investigate the rest of the website. Burp Suite was then used to investigate the randomness of the Session Ids generated by Bodgeit store. To do this, first the browser history was deleted and a new Burp Suite session was started. Then the Bodgeit Store home page was requested, the response from the target can be viewed and the session id can be seen, then another request was made for the homepage however it was edited before being sent to the target to remove the original session id. Then the sequencer was instructed to intercept the response from the application and start collecting session IDs, this can be seen below.

Burp Sequencer

Once a sufficient sample had been collected (6051) they were analysed to determine the

8

randomness. The reliability of the result was found to be „good‟ for the sample size. OWASP WebScarab OWASP WebScarab is defined as “a framework for analysing applications that communicate using http and HTTPS protocols”(OWASP, 2013). It includes proxy and spider functions similar to Zed Attack Proxy and Burp Suite. And seems to be an application for testing what information is transferred over a network by applications the user develops and at first look is similar to OWASP ZAP without the scanning functionality. WebScarab is less user friendly than Burp Suite and Zed Attack Proxy. However all of its features are available for free unlike Burp Suite. The interface can be seen below:

WebScarab User Interface The approach used to evaluate WebScarab was similar to that used on ZAP and Burp Suite. Firstly the proxy was set to intercept messages between the attacker and the target, the bodgeit homepage was loaded and the spider tool was used to discover the rest of the website. Due to the lack of a functional scanner it would be difficult to know if any vulnerabilities are present without extensive knowledge or through trial and error.

9

Results

Zed Attack Proxy

The Results of the spider can be seen below. The most significant items revealed by this spider are the items in the red box called advanced.jsp and admin.jsp.

ZAP Spider Results When clicked advanced.jsp shows a verbose error report which could be very useful when enumerating information about a site or when deciding which attacks would be most successful. When admin.jsp is visited it shows a list of the users and the administrators as well as a list of what appear to be purchases from the store. These can be seen in Appendix 2. The results from the active scan can be seen at the top of the following page and the full results for the high level risks can be found in Appendix 3. It can be seen that there are 3 major errors (red flags) these will be the focus of the exploits attempted. There are also many low level warnings (yellow flags) reported. The blue flags are informational notices.

10

ZAP Vulnerabilities

When the fuzzer was used on the vulnerable fields (the fields and the login and register pages) it was reported that the parameters that resulted in the code being reflected were single characters such as A, 1 or ? Burp Suite

When the spider tool was used in Burp Suite it also identified advanced.jsp however it failed to identify admin.jsp, this can be seen below.

Burp Suite Spider Results

The session IDs gathered by the sequencer were analysed and were found have an overall rating of “excellent” for randomness and at a significance level of 1%, the amount of effective entropy was estimated to be 110 bits for a token length of 32. However when decoded in Base64 and analysed again, the overall rating of randomness was reduced to “very poor” and the effective entropy was reduced to 12bits at a significance level of 1%. As a reference a good effective entropy would be around 128 bits and significance level is defined by Burp Suite as “how stringent we want our tests to be identifying non-random data” and “the lower the significance, the more obviously non-random a sample needs to be before we reject the conclusion that it is random”(PortSwigger, 2013) 1% is a common and reliable significance level. The results can be seen at the top of the next page:

11

Effective entropy in Session tokens (no decoding)

Effective Entropy after Decoding

The overall result from the analysis is that while the session tokens are not decoded using base64 they are fairly random and unpredictable however when decoded they lose a lot of the randomness and patterns emerge which overall renders the session IDs insecure. Further relevant graphs can be seen in Appendix 4.

12

WebScarab The Results from the WebScarab spider can be seen below:

WebScarab Spider Results

The WebScarab Spider results are not as extensive as those from Burp Suite and nowhere near as extensive as those from OWASP ZAP. Due to the steep learning curve it was difficult to obtain results of any significance that had not already been delivered more easily and efficiently than the other applications tested.

13

Discussion

Exploitation The first vulnerability found is a reflected cross site scripting error which allows the user to make the application process client side code supplied to it by the attacker for example when a user enters the statement:

</font><script>alert(1337)</script></font> into the search box on the

website the result is:

Cross Site Scripting Exploit

This is a problem because using other segments of code could allow an attacker to take more malicious actions than simply showing a message. This could be using a script to intercept a legitimate user‟s session ID cookie, thus allowing the attacker to impersonate a legitimate site user.

The next Vulnerability discovered by ZAP is a SQL Injection error. SQL injection errors allow the attacker to supply server queries to a web applications via the user input methods this can allow the attacker to accomplish anything from deleting all entries in a database to impersonating users and administrators. In this case the user input method is a login form. When the Data “A' OR '1'='1'” is entered in the password field the result that the application logs the attacker in as “user1” this can be seen at the top of the next page:

14

1st SQL Injection Exploit

Another SQL injection error is shown to exist on the register.jsp page. When the username a@a.com' or '1' = '1' is entered along with matching passwords it makes the application show an unusual error message. This shows that the application is accepting user input and using it to generate dynamic content which it should not. This can sometimes be harmless however if malicious code is inserted and ran correctly such as a worm it can have serious security implications. An example of this is the SAMY worm that was released onto the social networking site Myspace and caused it to shut down in 18 hours by overloading it with friend requests.

Because the session Ids are not that random when decoded using base64, the practice of session hijacking could also be a problem. Because the session identifiers are not impossible to guess it could be possible to impersonate another user of the web application. By causing a user to access a website via a link that contains a script that sends their Session ID to the attacker.

Countermeasures One of the reasons that Cross-site scripting (XSS) is such a prevalent threat to the security of web applications is that it is very difficult to completely remove all sources of vulnerability. One method that can help ensure that session ID cookies are not accessed by scripts inserted via cross-site scripting is to set the HTTP only flag on them. From the Zed Attack Proxy active scan results it can be seen that there are 58 instances in which this has not been the case during the study. Other than this the only other method to effectively minimise the risk of XSS attacks is to identify all areas of the application where users are able to enter data and to ensure all data entered is correctly validated. This means only allowing users of the application to only enter data that conforms to a strict set of rules such as not being to long and not containing any forbidden characters. OWASP has a list of several 'rules' for preventing XSS attacks which include “Never insert untrusted data except in allowed locations” and “Sanitise HTML markup with a library designed for the job” as well as escaping pretty much any other language before adding untrusted data to the HTML.(OWASP, 2013).

15

SQL injection is another exploitation of a vulnerability that is difficult to stop as there is no one sure way to stop all attacks and many different methods must be employed to minimise the risk. Combined with this is fact that technologies are always becoming more advanced and attackers are always finding new ways to exploit them. It is no surprise that SQL injection attacks are so common, however there are some methods that can be implemented to help minimise the risk. These include: minimising privileges allowed to the application when it connects to the database so that any attack that manages to access the database does not have full access, this means not connecting as a 'root' or 'admin' account. Also Disabling verbose error messages in PHP; this limits the amount of data that can be gathered by a potential attacker. Another prevention method according to OWASP is the use of “Prepared SQL statements” (OWASP, 2013) instead of dynamically created queries. This minimises the risk that an attacker would be able to alter a query for malicious purposes. As with most security issues, the most effective measure for reducing the risk posed by Cross-site Scripting and SQL injection is education. As Security becomes more important to web applications those who produce them must be made aware of the measures that must be taken to minimise the risk. Once a sufficient standard of security has been defined attackers will find it much harder to find and exploit vulnerabilities in web applications. Evaluation This section will compare and contrast the three scanners used in the study. The scanners will be judged of several criteria which include: comprehensiveness of features, effectiveness of identifying vulnerabilities, and ease of use. All three scanners function in similar ways, for the proxy functionality, each acts as a middle step between the scanning computer and the target for HTTP requests and responses, this allows the user to view and alter the requests, and allows the scanner to scan and investigate the site. The spider tool in each operates by starting on the page captured by the proxy and following all the links on the page. The scanning and fuzzing operations in Zed Attack Proxy and Burp Suite function by trying a pre-defined list of attacks to see which result in a successful exploitation. In terms of number of features OWASP Zed Attack Proxy contains the most features for specifically testing security of web applications. PortSwigger's Burp Suite seems to contain many of the same features however most are restricted to the paid version. However one feature that Burp Suite contains that is both useful for the afore mentioned purpose and not included in ZAP is the ability to collect and analyse session tokens for randomness. OWASP WebScarab also contains the same basic features such as the proxy and spider tools. It also contains a HTTP fuzzer and other features. However it appears as if WebScarab is more suited to the general testing of a web application, for ease of use and consumer experience rather than Security flaws and exploiting vulnerabilities. In terms of effectiveness at identifying vulnerabilities Zed Attack Proxy identified the most by showing that the admin and advanced pages could be used to gather information also using the active scanner it identified several high risk and many low risk vulnerabilities and using the fuzzer tool helped show which parameters exploited which fields. Burp Suites also spidered the application to show the advanced page. However because the scanner feature was restricted to the paid for version it could not identify any specific vulnerabilities however the sequencer feature was very effective at collecting and analysing session

16

tokens, which is a feature neither of the other scanners possessed. WebScarab was poor at identifying vulnerabilities within this investigation. Ease of use is factor that must be taken into account when evaluating these tools as the ease of which they can be operated can effect the success of the testing. Zed Attack Proxy was fairly easy to configure and use, it was easy to set up a proxy, spider the website, scan the website and fuzz specific fields as well as generate reports. Burp suite was also fairly easy to use to obtain the same results and although more specialised knowledge is needed to understand the results, the sequencer tool was easy to use and effective. WebScarab however was not easy to use as there was a fairly steep learning curve with little assistance offered and to achieve the same or similar results would take much more effort if it is even possible.

17

Conclusion

As the Internet has evolved over its history it has become more and more interactive. When it was first established the only information on the internet was in the form of pages. Increasingly advanced technology and more complex user requirements have lead to the increasing number of web applications which are interactive web sites. Web applications are now used for a multitude of different and important functions such as banking, shopping and holding sensitive information. Because of this, security is of paramount importance. The overall aim of this investigation was to use several vulnerability scanners to find vulnerabilities in a deliberately vulnerable web application; to investigate the vulnerabilities found by discovering how to exploit them; recommend countermeasures that could be implemented that could be implemented to help minimise the risk posed posed by these vulnerabilities and to compare the scanners used. Overall this investigation is a success as all of the aims were achieved. It was discovered that the application contained several high risk XSS and SQL injection vulnerabilities as well as many low level risks, it was also discovered that the session tokens used by this application were insecure. All of the exploits were able to be exploited to some degree and countermeasures were recommended for these. The scanners were all different in terms of function, effectiveness and ease of use. Overall Zed Attack Proxy was found to be the most successful in all three criteria though the results gained in the investigation would not have been possible without the Use of Burp Suite however the fact that many of the features available in the paid for version of Burp Suite were available for free on Zed Attack Proxy held it back. WebScarab was also found to be a useful tool for the general investigation of web applications though for the same and more results Zed Attack Proxy was easier to use. The countermeasures recommended for the high risk vulnerabilities include identifying all instances in which the user can enter data and ensuring that all data is validated correctly and that it conforms to rules as to not allow any malicious input. Also restricting permissions that the application has when connecting to databases and the use of prepared statements over dynamically generated queries is recommended. However for any of these countermeasure to be implemented web application developers must be made aware of the risks posed by insecure applications and this can only be achieved through education.

18

References

Open Web Application Security project, 2013. “OWASP Top 10 Project”. Owasp.org. Retrieved from: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project 12th December 2013. Open Web Application Security Project, 2013. “OWASP WebScarab Project”. Owasp.org. Retrieved from https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project. 7th January 2014 Open Web Application Security Project, 2013. “XSS (Cross Site Scripting) Prevention Cheat Sheet” owasp.org. Retrieved from https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet. 8th January 2014 Open Web Application Security Project, 2013. “SQL Injection Prevention Cheat Sheet”. Owasp.org. Retrieved from https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet 8th January 2013. PortSwigger, 2008. “PortSwigger Web Security Blog: Burp Sequencer 101”. Portswigger.com. Retrieved from http://blog.portswigger.net/2008/05/burp-sequencer-101.html. 7th January 2014 PortSwigger, 2013. “Burp Suite”. portswigger.com. Retrieved from http://PortSwigger.net/burp/ 7th January 2014

19

Bibliography

Birkner, M. 2013. “Automated Security Testing of web Applications using OWASP Zed Attack Proxy” codecentric.de. retrieved from https://blog.codecentric.de/en/2013/10/automated-security-testing-web-applications-using-owasp-zed-attack-proxy/ last accessed 12th Decemeber 2013 Open Web Application Security Project, 2013. “OWASP Top 10 Project”. Owasp.org. Retrieved from: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project. Last accessed 12th December 2013. Open Web Application Security Project, 2013. “OWASP Zed Attack Proxy Project”. Owasp.org retrieved from https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project last accessed 12 December 2013. Open Web Application Security Project, 2013. “OWASP WebScarab Project”. Owasp.org. Retrieved from https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project. Last accessed 7th January 2014 Open Web Application Security Project, 2013. “XSS (Cross Site Scripting) Prevention Cheat Sheet” owasp.org. Retrieved from https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet. Last Accessed 8th January 2014 Open Web Appliction Security Project, 2013. “OWASP BWA Project”. Owasp.org. retrieved from https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project last accessed 12th December 2013 Open Web Application Security Project, 2013. “SQL Injection Prevention Cheat Sheet”. Owasp.org. Retrieved from https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet Last Accessed 8th January 2013. PortSwigger, 2008. “PortSwigger Web Security Blog: Burp Sequencer 101”. Portswigger.net. Retrieved from http://blog.portswigger.net/2008/05/burp-sequencer-101.html. Last Accessed 7th January 2014 PortSwigger, 2013. “Burp Suite”. portswigger.net. Retrieved from http://PortSwigger.net/burp/ Last Accessed 7th January 2014

20

Appendices

App. 1 OWASP BWA Details

OWASP Broken Web Apps Web interface

OWASP Broken Web Apps Virtual Machine

Virtual Machine Settings

21

App. 2: Admin.jsp & Advanced.jsp

Admin.jsp

Advanced.jsp

22

App. 3: Full ZAP Scan Results High (Warning) Cross Site Scripting (Reflected)

Description Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.

When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.

There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.

Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.

Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.

URL http://10.0.0.94/bodgeit/search.jsp?q=%3C%2Ffont%3E%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E%3Cfont%3E

Parameter q

Attack </font><script>alert(1);</script><font>

Solution Phase: Architecture and Design

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier

23

to avoid.

Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Phases: Implementation; Architecture and Design

Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.

For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.

Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Phase: Implementation

For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.

To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access

24

to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.

Reference http://projects.webappsec.org/Cross-Site-Scripting http://cwe.mitre.org/data/definitions/79.html

CWE Id 79

WASC Id 8

High (Warning) SQL Injection

Description SQL injection may be possible

URL http://10.0.0.94/bodgeit/register.jsp

Parameter username

Attack ZAP%

Other information The page results were successfully manipulated using the boolean conditions [ZAP%] and [ZAPXYZABCDEFGHIJ] The parameter value being modified was NOT stripped from the HTML output for the purposes of the comparison Data was returned for the original parameter. The vulnerability was detected by successfully restricting the data originally returned, by manipulating the parameter

Solution Do not trust client side input, even if there is client side validation in place.

In general, type check all data on the server side.

If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'

If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.

25

If database Stored Procedures can be used, use them.

Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!

Do not create dynamic SQL queries using simple string concatenation.

Escape all data received from the client.

Apply a 'whitelist' of allowed characters, or a 'blacklist' of disallowed characters in user input.

Apply the privilege of least privilege by using the least privileged database user possible.

In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.

Grant the minimum database access that is necessary for the application.

Reference https://www.owasp.org/index.php/Top_10_2010-A1 https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

CWE Id 89

WASC Id 19

High (Warning) SQL Injection

Description SQL injection may be possible

URL http://10.0.0.94/bodgeit/register.jsp

Parameter username

Attack ZAP%

Other information The page results were successfully manipulated using the boolean conditions [ZAP%] and [ZAPXYZABCDEFGHIJ] The parameter value being modified was stripped from the HTML output for the purposes of the comparison Data was returned for the original parameter. The vulnerability was detected by successfully restricting the data originally returned, by manipulating the parameter

Solution Do not trust client side input, even if there is client side validation in place.

In general, type check all data on the server side.

26

If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'

If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.

If database Stored Procedures can be used, use them.

Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!

Do not create dynamic SQL queries using simple string concatenation.

Escape all data received from the client.

Apply a 'whitelist' of allowed characters, or a 'blacklist' of disallowed characters in user input.

Apply the privilege of least privilege by using the least privileged database user possible.

In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.

Grant the minimum database access that is necessary for the application.

Reference https://www.owasp.org/index.php/Top_10_2010-A1 https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

CWE Id 89

WASC Id 19

High (Warning) SQL Injection

Description SQL injection may be possible

URL http://10.0.0.94/bodgeit/login.jsp

Parameter password

Attack ZAP' OR '1'='1

Other information The page results were successfully manipulated using the boolean conditions [ZAP' AND '1'='1] and [ZAP' OR '1'='1] The parameter value being modified was NOT stripped from the HTML output for the purposes of the comparison Data was NOT returned for the original parameter. The vulnerability was detected by successfully retrieving more data than originally returned, by manipulating the parameter

27

Solution Do not trust client side input, even if there is client side validation in place.

In general, type check all data on the server side.

If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'

If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.

If database Stored Procedures can be used, use them.

Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!

Do not create dynamic SQL queries using simple string concatenation.

Escape all data received from the client.

Apply a 'whitelist' of allowed characters, or a 'blacklist' of disallowed characters in user input.

Apply the privilege of least privilege by using the least privileged database user possible.

In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.

Grant the minimum database access that is necessary for the application.

Reference https://www.owasp.org/index.php/Top_10_2010-A1 https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

CWE Id 89

WASC Id 19

High (Warning) SQL Injection

Description SQL injection may be possible

URL http://10.0.0.94/bodgeit/login.jsp

Parameter password

Attack ZAP' OR '1'='1

Other information The page results were successfully manipulated using the boolean conditions [ZAP' AND '1'='1] and [ZAP' OR '1'='1] The parameter

28

value being modified was stripped from the HTML output for the purposes of the comparison Data was NOT returned for the original parameter. The vulnerability was detected by successfully retrieving more data than originally returned, by manipulating the parameter

Solution Do not trust client side input, even if there is client side validation in place.

In general, type check all data on the server side.

If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'

If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.

If database Stored Procedures can be used, use them.

Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!

Do not create dynamic SQL queries using simple string concatenation.

Escape all data received from the client.

Apply a 'whitelist' of allowed characters, or a 'blacklist' of disallowed characters in user input.

Apply the privilege of least privilege by using the least privileged database user possible.

In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.

Grant the minimum database access that is necessary for the application.

Reference https://www.owasp.org/index.php/Top_10_2010-A1 https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

CWE Id 89

WASC Id 19

29

App. 4: Full Session ID Analysis

Character Position Analysis before base64 decoding

30

Character Position Analysis after base64 decoding

Bit Position Analysis before base64 decoding

Bit Position Analysis after base64 decoding