Security

In keeping your data guarded for your application the most key area is your password. Even many developers use very week passwords to protect things like file level access, database access and admin access to web applications. The easiest way to hack into a system is to crack an unsecured password and then a hacker (or to be correct a cracker) can cripple a system or worst steal data.

Well, I have run across a good open source web application called Password Strength Checker that can be used to make a much stronger password. The applications is very easy to use, you simply type in your password and then the form tells exactly how strong your password is. The form also gives you information about what makes your password strong or weak, such as that it is too short or lacks capital letters.

You can go to the applications here. And since it is open source you can download it and run it on your server (it is released under the GPL) you can download the application here. So, if you use this or a similar application I would love to hear about it (you can leave it in the comments or write a blog about it on this blog, using your free Ajaxonomy account).

Over at Reg Developer they have posted a good article regarding Ajax security. The article takes a 1-2-3 approach to security and covers topics like cross site scripting and SQL injection.

Below is an excerpt from the article.

Know what runs where

AJAX is making it increasingly difficult to be sure where your code is going to run. Take the Google Web Toolkit (GWT) for example. You program in Java and the environment takes some of that code and compiles it to JavaScript that runs on the client. If you make a mistake and implement authentication, access control, validation, or other security checks in the code that runs on the client, an attacker can simply bypass them with Firebug.

Imagine you've carefully coded rules to be sure that administrative functions are never shown to ordinary users. This sounds good, but you forgot that the user interface code is running on the client. So the attacker uses Firebug to invoke the administrative functions. If the proper checks aren't in place on the server side, the attacker just gained administrative rights. Many Rich Internet Application (RIA) frameworks also have this issue.

The solution is to be very careful about making the boundary between the client and the server very clear.

Keep data separate from code

Hackers frequently use a technique called "injection" to bury commands inside innocent-looking data and get interpreters to execute their commands for them. This simple trick is at the heart of many security attacks including SQL injection, command injection, LDAP injection, XSS, and buffer overflows. Preventing injection in a target-rich environment like the modern browser takes discipline.

The key to stopping injection attacks is never executing data that might contain code. But with AJAX, lots of data and code get passed around and mashed together in the DOM. There has never been a data structure that mixes together code and data more than modern HTML.

So be very careful with data that might include user input. Assume it's an attack unless you've carefully canonicalized, validated, and properly encoded. Imagine you're invoking a REST interface and the request contains user data. The response you receive is a JSON string that includes that user data. Don't evaluate that string until you're sure that there can't be anything but safe data in there. Even just adding that data to the DOM might be enough to get it to execute if there's JavaScript code buried in there.

Beware encoding

Encoding makes everything complicated. Attackers can hide their attacks inside innocent-looking data by encoding it. Back-end systems may recognize the encoding used and execute the attack. Or they may decode the attack and pass it on to a system that's vulnerable to it.

Attackers may use multiple different encoding schemes, or even double encode to tunnel their attacks through innocent systems. There are dozens and dozens of encoding schemes and no way to tell which schemes will be recognized by the interpreters you're using. This makes recognizing attacks very difficult, if not impossible.

Every time you send or receive data both sides have to know the intended encoding. Never try to make a "best effort" attempt to guess the right encoding. You can't prevent an attacker from sending data with some other encoding through the channel, but you don't have to execute it. Here are a few examples:

Set HTTP encoding in the header:

 
   Content-Type: text/xml, charset=utf-8

Use a meta tag in the HTML:

Set XML encoding in the first line of XML documents:

<?xml version="1.0" encoding="utf-8"?>

You can read the full post here.

Ajax security is very important in developing your Ajax applications and it is something that many developers overlook.

Yahoo! has just announced that it would begin supporting OpenID 2.0 technology for both yahoo.com and flikr.com by the end of the month.

Yahoo!’s initial OpenID service, which will be available in public beta on January 30, enables a seamless and transparent web experience by allowing users to use their custom OpenID identifier on me.yahoo.com or to simply type in “www.yahoo.com” or “www.flickr.com” on any site that supports OpenID 2.0.

Full Press Release

With the addition of 248 million Yahoo! users, the OpenID user community essentially triples in size (going from an estimated 120 million users to 368 million).

More information regarding Yahoo!'s OpenID support can be found here.

OpenID is a great idea as it moves us closer to not having to remember a million user id's and passwords. Way back in February of this year Kevin Rose of Digg.com announced that Digg would be supporting OpenID later this year (click here to read about the original announcement). At the time I was very excited, but unfortunately it doesn't look like we will be seeing it this year (unless one of you readers knows something that I don't).

This got me looking around at various popular social networks and web applications and the only major site that I have found that allows for OpenID login is DZone (which make since as it is a social network for developers). As for the other major social networks (such as YouTube, MySpace and Facebook), unfortunately there has been no adoption of OpenID.

Hopefully early next year we will see Digg.com put OpenID functionality on the site. This would make it the largest Social network (and one of the top sites on the internet, according to Alexa it is currently ranked 117) to place OpenID functionality on the site. Once this is done hopefully many more sites like MySpace and GMail will follow suite and the web will start to become a place where we can always have a single sign on (except perhaps on Microsoft affiliated sites). Well, I can always hope at least.