Home > Information Security Magazine > Features > Tug-of-Web 2.0
EMAIL THIS LICENSING & REPRINTS
Information Security Magazine

  CURRENT ISSUE  

  FEATURES  

  COLUMNS  

  HOT PICK & PRODUCT REVIEWS  

  ARCHIVES  

  SUBSCRIBE/RENEW  
 

Tug-of-Web 2.0
by Justin Gehtland
Issue: Nov 2007
printer-friendly
licensing & reprints
< PREV PAGE   |   1  |   2  |   3  |   4  |   5  |   6  |   7  |   8  |   9  |   10  |   NEXT PAGE  >

THREAT MITIGATION TECHNIQUES
Since there are new vectors by which user data can arrive at the server, and several new ways for data to reach the client, developers need to expand the scope of known threat mitigation techniques. A comprehensive plan will include complete two-way data validation, client-side and server-side enforcement, and a rigorous testing harness. It should go without saying (but unfortunately still doesn't) that automated testing is the most fundamental part of any security infrastructure.

Openness is the Key
Choose your Ajax development framework carefully.

Ajax development should be done in a standard framework. The major frameworks, like Prototype, jQuery, MochiKit and others, have lots of good code for dealing with common problems. More importantly, they have lots of eyes looking at them checking for bugs. Openness benefits security; organizations should choose a framework with an active user base.

However, Ajax frameworks are immature and haven't tackled many major security issues. Testing vendor Fortify reported in April that only the DWR framework had any solution for--or even mentioned--JavaScript Hijacking. Since then, other frameworks, such as Dojo and Prototype, have caught up.

Worse, most of the frameworks--either commercial or open source--poorly document known or suspected vulnerabilities, as well as workarounds.

--Justin Gehtland
String parsers, HTML and JavaScript. When generating HTML, your framework (see "Openness is the Key," above) should be explicit about the uses for each piece of data. If the value is for display as raw data only, the string should be HTML-encoded. This means that any special characters from the HTML specification will be rendered in an escaped format, preventing the data from interacting with the HTML parser during render. For example, the string "< h1 >Some HTML< /h1 >" would be rendered as "& lt;h1& gt;Some HTML& lt;/h1& gt;". When rendered, the user sees the original string, with HTML we decode the string instead of parsing it into DOM elements.

< PREV PAGE   |   1  |   2  |   3  |   4  |   5  |   6  |   7  |   8  |   9  |   10  |   NEXT PAGE  >





TechTarget Security Media
Information Security View this month\\'s issue and subscribe today.
Information Security Decisions Apply online for free conference admission.
SearchSecurity.com
HomeNewsMagazineMultimediaWhite PapersLearningAdviceTopicsEventsAbout Us

About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
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 2003 - 2008, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts