Welcome to the SecurityisFutile blog

I welcome comments and suggestions, I take criticism very lightly (at least most of the time). My goal for this blog is to document various experiments and research projects I feel are both relevant and prominent in the field of computer security (or lack there of) and share my results and experiences with other fellow computer security enthusiests. Most of my topics are based soley on open source technology and methodology, mostly due to availability and cost. I believe that effective security measures help keep people honest with their technology, for the most part. Security is futile (usless) or at least it feels that way when an inspired opportunist comes around and exploits your weaknesses. With that being said I leave you with a quote of inspiration; There is no security on this earth, there is only opportunity.-- General Douglas MacArthur

Friday, March 26, 2010

Simple Cross-Site Scripting (XSS) Techniques

Web application testing is essential in today's industry. Whether you work in the commercial, private, government sectors you need to ensure that both your data and your customer's data are protected by emerging and persistent threats. Cross-Site Scripting (XSS) vulnerabilities are caused by lack of proper input validation controls on the server (or the victims browser) for user-supplied input, usually executed through Java Script (once called Live Script). XSS vulnerabilities tend to lead to advanced social engineering attacks facilitated through Phishing scams, session hijacking, cookie theft and the list goes on. These threats are real and in order to protect your precious assets affected by these types of attacks you should employ some basic testing concepts when evaluating the security worthiness of your code. Here are some ways to test if your web application is lacking input validation controls:

( I do not condone unethical hacking. Use at your own risk!!!)

Test if parameters passed through a URL are susceptible to XSS attacks. Substitute my examples below for the web application and URL fields/parameters you are evaluating.

Initial Testing

Now substitute the value of the "user=" parameter with some injected java script

If the "user=" parameter does not supply any input validation from the server and the browser allows the java script injection your web browser will be populated with the web source code from the login.jsp page.

Additional Testing
I have found that a good bit of the XSS demonstrations and examples on the web show you how to execute java script in a vulnerable web parameter/field to display the alert pop up window with some random text. Assuming one of your parameters was vulnerable to the java script injection above in Example 1, lets try popping some alert messages using that same parameter/field, just substitute the value for "user=" with the following:

Varying Results and Considerations
There are many variables to consider when performing these types of tests.

1.)Not all web browsers will produce the same expected output. Microsoft Internet Explorer, Firefox, Safari, and so forth may not respond the same way to these tests. It is important to test the vulnerability in different browsers/versions of browsers to see which are and are not susceptible to the vulnerability.

2.) NoScript (Free Mozilla web browser product plug in) and other preemptive script blocking techniques are ways to mitigate these types of attacks. Enabling these features could alter or vary your expected results. However, these features are essential in protecting your assets against these types of issues.

Sources and Worthy Reading Material

OWASP: XSS Cheat Sheet

FireBlog: (Image used at the beginning of post)

No comments:

Post a Comment