Posts tagged Web Development
The Power of Facelets (Part 1 – Motivation)
Dec 15th
Ever since Java Server Faces (JSF) were released, we utilized them successfully for many web application projects. While being conceptually really nice and well thought through, one problem with JSF has always been the mismatch with JSP (Java Server Pages).
The issue is how to integrate JSP’s dynamic content into JSF’s component-based model. JSPs are singularly focused on generating dynamic output, whereas JSF requires JSP to coordinate building a component model. The disjunct occurs because that task is beyond the original intention of JSP.
Even though most JSF developers simply learn to navigate such problems, it made the usage of JSF in large projects a huge pain and always resulted in ugly code that was difficult to read and maintain. Far from what you want to achieve with a new technology.
The Problem with JSPs
…Well – maybe not JSP per se. JSPs are great for their intended use: Mixing both static and dynamic content made available by other parts of the application – servlets, plain java code, databases, etc.
But keep in mind that – historically – JSPs are nothing more than “fancy servlets” with some added semantic sugar. Their sole purpose of existence is to generate a response to a request; a JSP page is processed in one pass from top to bottom, with JSP action elements processed – here it comes – in the order in which they appear in the page.
JSF are component based and have a much more complex life cycle. They are created, asked to process their input (if any), and then asked to render themselves (I am simplifying here). For JSF to work well, these three things must happen separately in a well-defined order, but when JSF is used with JSP, they don’t. Instead, the component creation and rendering happens in parallel, causing all kinds of problems.
The fact that both JSP and JSF components add content to the response is another cause for a lot hard to track down issues. Unless you understand the difference between how these two technologies write to the response, you’re in for a lot of surprises – such as content appearing out of order or not at all.
There are severe limitations on how JSF and non-JSF tag libraries can be mixed in a JSP page. On top of that, developing a JSF application requires understanding the event-driven component model.
When learning JSF, a JSP developer now has to not only understand those (likely unfamiliar) concepts, but also learn the pitfalls of how to use the two technologies together and – more importantly – how not to. It’s a lot to learn and often unintuitive.
Lets have a look at a very simple example that illustrates the issue with parallel component creation and rendering. Say you want to create a label for a checkbox – bread and butter which we developers don’t even want to think about, right? Intuitively you would write something like this:
There is no intuitive reason this shouldn’t work, but if run this example, you’ll notice that no <label> element is rendered the first time you request the page, but if you request the page a second time, a <label> element is rendered.
This strange behavior has to do with the combination of JSF and JSP. When JSF receives the first request for the page, the component tree for the view represented by the page doesn’t yet exist. JSF creates a tree with just a UIViewRoot at the top and forwards the request to the JSP page to add the real components.
The JSP container now processes the page and invokes the JSF action tag handlers (here it comes again:) in the order they are encountered. A JSF tag handler looks for the JSF component it represents in the component tree. If it can’t find the component, it creates it and adds it to the component tree. It then asks the component to render itself. This means that on the first request, the components are created and rendered in parallel. On subsequent requests, the component tree exists, so no new components are created; the tag handlers just ask the existing components to render themselves.
On the first request, the >h:outputLabel< action creates its component and asks it to render itself. To do so, it needs to find the component identified by the for attribute, but this component doesn’t exist because the action element that creates it appears after the <h:outputLabel> element and hasn’t been invoked yet. Hence, the component created by <h:outputLabel> action can’t render its <label> element. On the second request, all components exist, so the component represented by the <h:outputLabel> finds the component the label belongs to and happily renders the label element.
Of course in this case there are easy workarounds, but hey: Why should I “work around’ something as simple as adding a label to a checkbox? Furthermore – as you start going beyond “Hello World” pages, you encounter more and more examples like the one above, and many of them aren’t as easy to understand. Matters get worse once you start using AJAX, A4JSF and similar technologies.
In a recent project, the code for the view pages were – out of necessity – plastered with <f:verbatim>pages – creating pages with unbalanced tags (hey – we had no choice) and making it almost impossible to work with.
The solution was – of course – to dump JSP altogether and move to Facelets – more about this in the next article.
Know Your Enemy: Malicious Web Servers
Dec 15th
Even seemingly safe web addresses can be full of attack code aiming at vulnerable clients, according to a new study from the The Honeynet Project & Research Alliance(http://www.honeynet.org/). The findings also include that finds that methods such as blacklists can be surprisingly successful in stopping client-side attacks.
“The ‘black hats’ are turning to easier, unprotected attack paths to place their malware onto the end-user’s machine,” they said in the study, called “Know Your Enemy: Malicious Web Servers.”
Users can be led to malicious sites via links, typing in an address manually, mistyping an address or following search-engine results.
Using a “high-interaction” client honeypot called Capture-HPC developed by the Victoria University of Wellington, the researchers analyzed more than 300,000 addresses from around 150,000 hosts.
Analyzed were various site categories, including adult, music, news, “warez,” defaced, spam and addresses designed to grab traffic from users who mistype common web addresses. While some categories were more likely to contain malicious addresses than others, they could be found everywhere:
“As in real life, some ‘neighborhoods’ are more risky than others, but even users that stay clear of these areas can be victimized,” the report said. “Any user accessing the web is at risk.”
While the findings are not really surprising – the existence of this kind of attack is long known – the study also analyzed the effectiveness of safeguards against such infections in some detail, showing that blacklists, if regularly updated, can be a surprisingly effective way of blocking malicious addresses.
While the study also recommends regular patching, but this may not always be straightforward, since the a prevalence of attacks against plug-ins and non-browser applications becomes obvious: “Attacks also target applications that one might have not think about patching, such as Winzip”.
Another technique that can block attacks would be to use a less popular browser, such as Opera: “Despite the existence of vulnerabilities, this browser didn’t seem to be a target”.
The data used for the study as well as the paper can be found here: http://www.honeynet.org/papers/mws/
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.