Tweet

Cross-site ScriptingFundamentals. Introduction Xss sites Cross-site scripting vulnerabilities date back to 1996 during the early days of the  World Wide  Web (Web).A time when e-commerce began to take off, the bubble days of Netscape,Yahoo, and the obnoxious blink tag.When thousands of  Web pages were under construction, littered with the little yellow street signs, and the  “cool” Web sites used Hypertext Markup Language (HTML) Frames.The JavaScript programming language hit the scene, an unknown harbinger of cross-site scripting, which changed the Web application security landscape forever. JavaScript enabled  Web developers to create interactive  Web page effects including image rollovers, floating . Hackers found that when unsuspecting users visited their  Web pages they could forcibly load any  Web site (bank, auction, store,Web mail, and so on) into an HTML Frame within the same browser window.Then using JavaScript, they could cross the boundary between the two  Web sites, and read from one frame into the other.They were  able to pilfer usernames and passwords typed into HTML Forms, steal cookies, or compromise any confidential information on the screen.The media reported the problem as a  Web browser vulnerability. Netscape Communications, the dominant browser vendor, fought back by implementing the ”same-origin policy,” a policy restricting JavaScript on one  Web site from accessing data from another. Browser hackers took this as a challenge and began uncovering many clever ways to circumvent the restriction. Finding and exploiting cross-site scripting (XSS) vulnerabilities can be a complex and time consuming task.To  expedite the location of these bugs, we  employ a wide range of tools and techniques. In this chapter, we look at a collection of tools that the authors have  found to be invaluable in their research and testing. It is important to note that many of the XSS bugs out there can be found with nothing more than a browser and an attention to detail.These low hanging fruit are typically found in search boxes and the like. By entering a test value into the form and viewing the results in the response, you can quickly find these simple bugs. However, these are the same bugs that you can find in a fraction of the time with a  Web application scanner. Once these basic vulnerabilities are found, tools become a very  valuable part of the attack process. Being able to alter requests and responses on the fly is the only way  some of the best bugs are found. We  should also mention that these tools are good for more than just locating XSS flaws. They are also very  useful for developers and  Web application penetration testers. Burp  The modern browser is designed for speed and efficiency, which means  Web application security assessment is a painful task, because probing a  Web application requires in-depth analysis. Generally, to test an application, you want to slow down the transmission of data to and from the server to a snail’s pace so you can read and modify the transmitted data; hence the proxy. In the early days of security, proxies were  capable of slowing down the connection in only the outbound direction and as such, a user could only alter the information being transferred to the server; however, that’s only part of the equation when analyzing a  Web application. Sometimes it greatly behooves you to be able to modify the incoming data.  For example, you might want to modify a cookie so that it doesn’t use  HttpOnly, or remove  a JavaScript function. Sometimes you just want a bidirectional microscopic view into every request your browser is making.And then there was Burp Proxy (www.portswigger.com/ suite/. Burp Proxy is part of a suite of Java tools called Burp Suite that allow for  Web application penetration, but for the purposes of this book only one function is particularly useful, and that’s the proxy.To  get started, you need the Java  run time environment installed, which you can get from Java.com’s  Web site. Once that is installed you modify your proxy settings in your browser to use localhost or 127.0.0.1 at port 8080.

 Cross-site ScriptingFundamentals.

Introduction

Xss sites

Hackers found that when unsuspecting users visited their  Web pages they could forcibly load any  Web site (bank, auction, store,Web mail, and so on) into an HTML Frame within the same browser window.Then using JavaScript, they could cross the boundary between the two  Web sites, and read from one frame into the other.They were  able to pilfer usernames and passwords typed into HTML Forms, steal cookies, or compromise any confidential information on the screen.The media reported the problem as a  Web browser vulnerability. Netscape Communications, the dominant browser vendor, fought back by implementing the ”same-origin policy,” a policy restricting JavaScript on one  Web site from accessing data from another. Browser hackers took this as a challenge and began uncovering many clever ways to circumvent the restriction.

Finding and exploiting cross-site scripting (XSS) vulnerabilities can be a complex and time consuming task.To  expedite the location of these bugs, we  employ a wide range of tools and techniques. In this chapter, we look at a collection of tools that the authors have  found to be invaluable in their research and testing. It is important to note that many of the XSS bugs out there can be found with nothing more than a browser and an attention to detail.These low hanging fruit are typically found in search boxes and the like. By entering a test value into the form and viewing the results in the response, you can quickly find these simple bugs. However, these are the same bugs that you can find in a fraction of the time with a  Web application scanner. Once these basic vulnerabilities are found, tools become a very  valuable part of the attack process. Being able to alter requests and responses on the fly is the only way  some of the best bugs are found. We  should also mention that these tools are good for more than just locating XSS flaws. They are also very  useful for developers and  Web application penetration testers.

Burp

 The modern browser is designed for speed and efficiency, which means  Web application security assessment is a painful task, because probing a  Web application requires in-depth analysis. Generally, to test an application, you want to slow down the transmission of data to and from the server to a snail’s pace so you can read and modify the transmitted data; hence the proxy. In the early days of security, proxies were  capable of slowing down the connection in only the outbound direction and as such, a user could only alter the information being transferred to the server; however, that’s only part of the equation when analyzing a  Web application. Sometimes it greatly behooves you to be able to modify the incoming data. 

For example, you might want to modify a cookie so that it doesn’t use  HttpOnly, or remove  a JavaScript function. Sometimes you just want a bidirectional microscopic view into every request your browser is making.And then there was Burp Proxy (www.portswigger.com/ suite/. Burp Proxy is part of a suite of Java tools called Burp Suite that allow for  Web application penetration, but for the purposes of this book only one function is particularly useful, and that’s the proxy.To  get started, you need the Java  run time environment installed, which you can get from Java.com’s  Web site. Once that is installed you modify your proxy settings in your browser to use localhost or 127.0.0.1 at port 8080.