Most modern browsers restrict access for all Javascript requests made from a page, allowing only requests made to the server from where the page was loaded. This (same origin policy) is generally a good idea since it goes a long way to prevent XSS.
But sometimes you need that kind of access, for example when developing an HTML based mobile app that retrieves dynamic content from a web server. In that scenario the web pages are run locally in the mobile device (smartphone or tablet) and they make requests and posts to your remote web server, which is by default not allowed.
Almost all of the web apps we build nowadays (at least on the circles I usually move around) rely on the beloved and hated session. This artifact, providing a stateful user wide storage, allows us to relate several HTTP requests together and thus implement the concept of authenticated and secure web applications, that “know” who is using them several requests after they authenticated, despite the root stateless characteristic of the HTTP protocol itself.
To provide a very brief recap, sessions are usually implemented using a hash like memory structure on the server, where each session is stored using a unique identifier string. This string is stored also on the users web browser, typically via a cookie or by sending it back and forth on each request as a POST or GET parameter.
I believe it’s time to move away from this approach and start building session-less web applications that still provide the same feature set and security.
This is a part of my web frameworks review series. Check it out if you haven’t already.
Moving on to Django, the Python based all star.
Django was created by the folks at the Lawrence Journal-World and released to the public in 2005. It’s very active and with a strong group of followers, the framework is currently in it’s 1.4 incarnation, and the last release was done in March/2012.
The next runner up in my web development frameworks evaluation series is Ruby on Rails v3.
Unless you have been living under a bucket without an RJ45 port (yes, some buckets have Internet access), you have probably heard of Ruby on Rails (RoR), it’s a very popular framework with lots of momentum. RoR started as an extract of the Basecamp product at 37signals and is now used in all sorts of web apps.
A friend recently recommended I take a look at the Mustache templating engine. It’s clean, simple and designer friendly, and promotes logic minimization on the template side (I don’t like the term “logic-less”, I don’t think you can get away with absolutely zero logic).
To try it out I decided to build a simple Struts 2 based web app, but I found that there was no out-of-the-box integration between the two. Thankfully both frameworks are easily extendable so I managed to get them playing along quite easily.
As the first candidate of our evaluation series we reviewed the Play Framework v2.0.
The tutorial and reference documentation used for this article is all available from the Play documentation site.
The first part of the article will go over the set of tasks we proposed to do with each framework, then moving on to evaluate each criteria item.
At my company we are evaluating which web development framework we will use for the next few years.
Since our last evaluation we have been using Java application servers powered by Struts 2 as MVC, Tiles as templating engine, jQuery for Javascript awesomennes, DWR for AJAX calls and MyBatis as ORM.
But we think it’s time to re-evaluate and move on to a newer/better/friendlier framework.
In this post I’ll present you with our candidates and the criteria we are evaluating each framework with. Over the next weeks I’ll post the actual evaluation of each framework and finally what our choice is and why.
Cross-site request forgery attacks (CSRF) are very common in web applications and can cause significant harm if allowed. If you have never heard of CSRF I recommend you check out OWASPs page about it.
Luckily preventing CSRF attacks is quite simple, I’ll try to show you how they work and how we can defend from them in the least obtrusive way possible in Java based web apps.
Jul/4/2012: Updated the wrapper code to pre-compile the patterns (making them static) to improve performance by avoiding their re-compilation on each run.
Here is a good and simple anti cross-site scripting (XSS) filter written for Java web applications. What it basically does is remove all suspicious strings from request parameters before returning them to the application. It’s an improvement over my previous post on the topic.
You should configure it as the first filter in your chain (web.xml) and it’s generally a good idea to let it catch every request made to your site.
Afraid of malicious injections in your web app requests, heres a simple way to improve your application security. Push every request parameter through a filtering function before it’s feeded to your application code.
Such a function can be as simple as:
private String cleanParameter(String value) {
if (value != null) {
value = value.replaceAll("<", "<").replaceAll(">", ">");
value = value.replaceAll("\\(", "(").replaceAll("\\)", ")");
value = value.replaceAll("'", "'");
value = value.replaceAll("eval\\((.*)\\)", "");
value = value.replaceAll("[\\\"\\\'][\\s]*javascript:(.*)[\\\"\\\']", "\"\"");
}
return value;
}
This will escape/remove potentially dangerous Javascript code and HTML/XML tags.
You can implement this on a web filter or a struts interceptor or a DWR filter depending on the technology you use for you app.