Home > Software Quality Tips > Application Security Strategies > Anatomy of an XSS hack
Software Quality Tips:
EMAIL THIS
 TIPS & NEWSLETTERS TOPICS 

APPLICATION SECURITY STRATEGIES

Anatomy of an XSS hack


David Strom
04.25.2003
Rating: --- (out of 5)


Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us   




Web Informant #326, 25 April 2003: Anatomy of a hack

After my last column on problems with SBC's Web hosting, I asked Caleb Sima from SPI Dynamics, a Web application and security assessment software firm, to give me some insights about breaking into Web sites. Caleb has a pretty cool job: He gets paid to do this, in the process demonstrating the need for tools such as his employer sells as well as the various weaknesses of people's sites. When he visited me at CMP last fall, he was inside our own Web site and reading stuff that he shouldn't have had access to within a minute or so. Fortunately, our Web folks have tightened things up, but you may not be so lucky.

I asked Caleb to give me an idea of how he manages to find these vulnerabilities so quickly, and he came up with a few suggestions. If you understand how Web servers work and how they have directory structures and input forms just like your computer on your desktop, you can get pretty far -- even without much other specialized knowledge. To give you a flavor of this, I submit his prescription for locating a Web application attack vulnerability called cross-site scripting.

Cross-site scripting (XSS) occurs when dynamically generated Web pages display input that is not properly validated. This allows an attacker to embed malicious JavaScript code into the generated page and execute the script on the machine of any user that views that site. XSS has some far-reaching implications and can impact any site that allows users to enter data. You see this on search engines, in error message screens, in forms and Web message boards, among other places. You can read more about this here at SPI Dynamics' site.

Here are the steps to see if your Web applications are vulnerable to XSS attacks:

Step 1. Open any Web site in a browser, and look for places on the site that accept user input such as a search form or some kind of login page. Enter the word test in the search box and send this to the Web server.

Step 2. Look for the Web server to respond back with a page similar to something like "Your search for 'test' did not find any items" or "Invalid login test." If the word 'test' appears in the results page, you are in luck.

Step 3. To test for XSS, input the string "<script>alert('hello')</script>" without the quotes in the same search or login box you used before, and send this to your Web server.

Step 4. If the server responds back with a popup box that says "hello", then the Web site or Web application is vulnerable to XSS.

Step 5. If Step 4 fails and the Web site does not return this information, you still might be at risk. Click the 'View|Source' option in your browser so you can see the actual HTML code of the Web page. Now find the <script> string that you sent the server. If you see the entire "<script>alert('hello')</script>" text in this source code, then the Web server is vulnerable to XSS.

If these steps don't make much sense to you, not to worry. You can still get some mileage, particularly when you are in the throes of picking a hosting provider. I suggest that you might want to send them this column and see what kind of response you get from them before you give them your business. If you get no response or a canned response, then you probably should go elsewhere. You could also send this column to your IT department. If they don't understand what I am talking about here, then you might want to bring that to the attention of your CEO and find out why.

There are plenty of other Web site vulnerabilities. Hopefully this will get you motivated to seek them out, either by using SPI Dyanmics' product called WebInspect or someone else's, and by being more diligent about what applications you allow access to your Web content. Here's my article that I wrote earlier this year on this subject for VARBusiness.


Entire contents copyright 2003 by David Strom, Inc.
David Strom, dstrom@cmp.com, +1 (516) 562-7151
Port Washington, NY 11050
Web Informant is (r) registered trademark with the US PTO
ISSN #1524-6353 registered with U.S. Library of Congress

If you'd like to subscribe (issues are sent via e-mail), please send an e-mail to: Informant-request@avolio.com?body=subscribe.


Rate this Tip
To rate tips, you must be a member of SearchSoftwareQuality.com.
Register now to start rating these tips. Log in if you are already a member.


Submit a Tip




Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us   


RELATED CONTENT
Threat modeling
Web application security and the PCI DSS
The essentials of Web application threat modeling
How to implement security in Java EE and Java ME
Application security shouldn't involve duct tape, Band-Aids or bubble gum
Stop SQL injection attacks on applications
How to counter XSS attacks
Breaking the same origin barrier of JavaScript
Protection against "zero-minute" exploits
Denial of service and Ajax
CSRF attack vector with Ajax serialization

Software security testing and techniques
Static analysis at the end of the SDLC doesn't work
Website security improved, but more can be done
How to learn white box testing
Security vulnerabilities found in open source Java projects
Fuzzing for Software Security Testing and Quality Assurance: Chapter 3, Testing for Quality
Ajax security -- Is anyone listening?
Critical security issues found in the Spring Framework
Web application security and the PCI DSS
PCI DSS compliance: Web application firewalls (WAFs)
PCI DSS compliance: The basics

Application Security Strategies
Static analysis at the end of the SDLC doesn't work
Web security: Web services an overlooked entry point for attacks
Ajax security -- Is anyone listening?
The realities of using WAFs for PCI DSS 6.6 compliance
The realities of PCI DSS 6.6 application code reviews
Secure software measures: Their strengths and limitations
Writing software requirements that address security issues
Getting started with Web application misuse cases
The essentials of Web application threat modeling
How to prevent XPath injection

RELATED RESOURCES
2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
Search Bitpipe.com for the latest white papers and business webcasts
Whatis.com, the online computer dictionary

DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
SEARCH 
TechTarget provides enterprise IT professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective IT purchase decisions and managing their organizations' IT projects - with its network of technology-specific Web sites, events and magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Reprints  |  Site Map




All Rights Reserved, Copyright 2006 - 2008, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts