Updated:  See the alternative fix below... 

In the past 24 hours, I've received numerous panicked emails from dotProject users about the Cross -Site Scripting Vulnerability announced yesterday. True, it is something to be concerned about and it should be addressed. True, it could cause problems for some users.

Unforuntately, these same people seemed to have missed that this has been fixed since the first 2.1 release candidate which came out four months ago. This type of issue was identified to us prior to that time and concrete steps were applied to completely close holes such as this. I know because I helped apply those changes and have been heavily involved in encouraging people to upgrade as soon as possible. In fact, it was due to those security changes that the latest version of the Project Importer - released over a month ago - doesn't work with any version prior to the 2.1 Release Candidates.

Last week, Chris Shiflett pointed wrote about some of the problems and risks involved in Reporting Vulnerabilities. I'll ask a followup question... is it really worth the price?

For example, when I was in college, there was an application which allowed the faculty and administration to log in, review student's schedules and see their picture. Since many students posted their schedule on their dormrooms, this was hardly "sensitive information". At one point, while working for one of the VP's, I discovered that you could log in by giving the name of one of the campus printers. Yes, the printers had no password and some combination of "read-only" admin access. The risk of this vulnerability was quite low and within a year or two, everyone knew about it.

On the other end of the scale, in the past couple years, I've had the opportunity to evaluate a number of codebases. Some are in production, some are not. In one of them, all the content all the time was completely unfiltered by any means. During my testing, I was able to successfully inject SQL, add creative Javascript, and actually insert raw html into the pages. I do not consider myself a security expert, but I am well-armed with the common vulnerabilities and fixes.

On a related note, during an email exchange with Chris a couple weeks ago, I noted my SQL injection tests and sent a bit of sample code which attacked a user's password. It didn't do anything that special, it simply allowed be to authenticate as a random user. Not elegant but still effective. Chris made the point that in these scenarios attacking a username is just as easy but allows you to choose a specific user... preferably an administrator.

So what strategies do I use for reporting vulnerabilities? I don't.

If the owner of the application or site is a potential customer whom I am *actively* speaking with about performing work, transitioning to a better system, etc, I am very careful. I never provide a proof of concept, but I talk about the concept of a BadGuy(tm) inserting malicious code and redirecting users, stealing info, etc. I don't provide any code, I don't identify specific form fields or pages, and I definitely don't demonstrate it for them.

For everyone else, I keep my mouth shut for the reasons outlined in the above article. There are organizations like CERT who can take submissions and handle things from there.

Adaptivepath's article about Ajax has been flying through the blogosphere like wildfire over the past couple of weeks. I'm not linking to it here because it's #2 when searching for "Ajax" on Google.

It essentially calls for a series of small interactions with a web server that happen seemlessly while the user is working with the page. This minimizes the the roundtrip problems that normally happen when working with large forms and large datasets. It also minimizes the waiting time for the end user. The reason this concept has gotten so many electrons lately is because of the elegant implementation by Google for Gmail, Google Suggest, and Google Maps - each of which is impressive in its own right.