|
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.
[IMAGE] [IMAGE] [IMAGE] Openness is the Key
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
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...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
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
[IMAGE]
[IMAGE]
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.
|
 |
|
