Security Exploit for for Ajax Based Applications: JavaScript Hijacking
Dec 15th
In their recent paper (download here) Brian Chess, Yekaterina Tsipenyuk O’Neil, Jacob West from Fortify Software describe a new type of eavesdropping attack against Ajax-style Web applications called Javascript Hijacking.
The attack is possible because Web browsers don’t protect JavaScript the same way they protect HTML – if a Web application transfers confidential data using messages written in JavaScript, in some cases the messages can be read by an attacker.
The authors analyzed 12 popular Ajax frameworks and show that most of them do nothing to prevent JavaScript hijacking. Some actually require(!) a developer to create a vulnerable server in order to function.
Like so many of these sorts of vulnerabilities, preventing the class of attacks is easy. In many cases, just a few additional lines of code are required. And like so many software security problems, programmers need to understand the security implications of their work so they can mitigate the risks they face. But it seems that is that JavaScript hijacking won’t be solved so easily, because – especially in the web application world – developers often times don’t understand the security implications of their work and thus nothing in their code will prevent the attacks.
J2EE – Java Server Faces (JSF) and EJB3 – for Legacy Modernization
Dec 15th
We just finished a project with the objective to rewrite and modernize a legacy web application using JSF and EJB3. The new application was to provide a rich, interactive map component as well as a “desktop-like” user experience with interactive tables, split as well as tabbed panes, etc. Let’s have a quick look at the two main tools used for this project:
Enterprise Java Beans (EJB) 3
It’s always a headache if you don’t have control over your data model. Especially when the model is bad. Especially when the database model is really bad – carried over from the old mainframe days and grown (note the avoidance of the word “matured”) ever since. EJB3 handled this job extremely well. Only 4% of project time was spent on backend implementation, a fair share of that on “Mock Data Services” for testing purposes. Nice…
Java Server Faces
Introduced as an event-driven component model for web application development, Java Server Faces are similar in spirit and function to the models used for standalone GUI applications (like Swing).
JSF shows the signs of a typical “Sun-Version-1″: Nice, well thought through concepts, combined with a very basic, almost rudimentary component set, forcing you to either use third party libraries (often times impossible in large corporate environments due to policies, etc) or “reinvent the wheel” and build your own component sets.
I like working with JSF for many reasons, but once things move beyond “Hello World” and “Guess-The-Number”, you have to know the internals of JSF very well or you will spend many hours debugging issues that are far from being intuitive.
Don’t get me wrong, I am enthusiastic about JSF and think it’s one of the better frameworks out there for large scale web applications, yet I am very much looking forward to version 2….
Some of the things I like about JSF:
The concept of “Component Renderer”, common to desktop frameworks, allows for easy and elegant combination of JSF with existing WEB 2.0 technologies like AJAX.
Being able to reuse existing component renderer for custom components makes it very easy to create new, complex and reusable components for complex and rich GUI elements.
Security: JSF fits very nicely with security libraries like JAAS. Used properly (custom component renderer and phaselistener), the front end developer can be shielded from any security related code without compromising security. I still love the little things like our “securityOutputLink”, which renders a simple text string if the user does NOT have access to the link target, and a regular link otherwise. In the backend, the decision is based on the same xml file which links user roles to page access, all with a handful of code lines. Sweet!
Configuration of navigation rules and backing bean properties in faces-config.xml is a very nice concept and allows “out of the box” for different application configurations for development, testing and production, which is a real timesaver.
On the Minus Side
The very bad integration of JSF with JSP and JSTL. This is certainly my number one criticism when it comes to JSF. As someone put it so nicely: Trying to combine JSF and JSP is like trying to shoehorn a foot into a glove: it’s possible, but it’s really just a stopgap measure until something better comes along. It would be nice, real nice to have a powerful expression language at your disposal. Sometimes you just want a loop without having to write your own component renderer, or conditional execution on a page without having to worry and work around the different variable scopes and execution times of JSF and JSP. Read here for more details
Small and very basic component set. Sortable, pagable tables with row highlighting and selectable rows and columns are certainly bread and butter for every real web application. Since the number one reason for using frameworks like JSF is to make a developer’s life easier, it’s hard to explain why I have to still write this myself (or switch implementations).
Software Development Project Requirements
Dec 15th
An interesting study titled “Requirements Engineering and Software Project Success: An Industrial Survey in Australia and the U.S” ( click here to read the pdf version ) looks at 400 projects in the U.S., Australia, and Chile.
While most of the findings can be shrugged off as “to be expected”, the study reveals some interesting, maybe even surprising facts:
The Surprises (Are They Really?)
- Most projects that had no schedule were successful
- Requirements are needed for project success, but not necessarily early in the project
- Projects often continue successfully for some time with unclear requirements
- The choice of requirements methodology does not matter; UML was “no help”
- Using a development methodology was a success factor, especially when it was “appropriate to the application”
- Very few projects use risk management, and those that do rarely manage those risks
- Post mortem reviews are rarely held, and when they are it is almost always on successful projects
- In the U.S. (but not elsewhere), developers are involved in project estimation only when there are poor requirements (Verner speculated that this is because the powers that be were looking for someone to blame!)
The Predictables
- Success comes from a culture that investigates and deals with problems
- The vision for the project (its business goals) must be shared among all project personnel, especially the project manager
- Project managers should be involved in the estimation activity
- Project managers should be good at customer and developer communication; they need not be good at the technology
The study also provided some interesting numbers:
- 60% of organizations have no process to measure benefits
- 86% of projects had a business case, but 60% ignored it
- 33% of projects said they had no risks, but 62% of those failed
- 49% or organizations have had (one or more) project failures
- In one-third of the projects, the project manager had no say in schedule/budget targets
- 75% of projects were underestimated, none were overestimated
- 5% of projects had no project manager; 16% changed project manager at least once (and that was correlated with project failure)
The study also asked developers what they would call a “successful project”:
- They had a sense they had delivered a quality product
- They had a sense of achievement
- They had enough independence to work creatively
- The requirements were met and the system worked as intended