My thoughts were:

• Their forum must be really low volume if these spammings managed to get to the top
• UGC (User Generated Content) can easily put your website in a “bad light”, so you should be careful when using it.

Some ideas on how this could have been prevented:

• Provide an easy way for other users to flag messages as spam
• Only advertise on the first page topics which have at least one response and wasn’t flagged as potential spam.
• Use a list of keywords and quarantine posts which contain the given keywords: only show them to the IP address which originally posted it. Of course, such postings should be reviewed and innocent topics be removed from the quarantine status.

This last method leaves the spammer with the impression that the posting was successful. Directly blocking it would just create an arms-race. (This idea is not originally mine and it has been floating around on the intertubes for some time. It is surprising that so few community software packages implement it…)

Do I really need javascript to submit a simple form? Really? As for the server running the given website, its version number isn’t too reassuring either.

Web 1.0: Writing.
Web 2.0: Rating.

Hey, at least I’m Web 2.0

The first thing would be that everything which is covered falls in the category of input validation. While it is good to present different aspects and effects of this problem, it is at least misleading to say that these are the Top 10 vulnerability categories. To see a real and comprehensive list of top 10 vulnerability categories in web applications, visit the OWASP site.

Secondly, many of the technologies and problems presented are not new (in the sense that they predate the whole Web 2.0 craze with several years) and are not primarily used in web applications (like WSDL, XPATH, SOAP).

Thirdly the article tends to invent terminology, probably to get as much attention as possible. Lets take the first element in the list for example: Cross-site scripting in AJAX. This is an unneeded repetition and also somewhat confusing (you are not doing the cross-site scripting IN AJAX, you are doing it in Javascript or VBScript). Also the definition is a bit foggy and slightly incorrect: AJAX gets executed on the client-side by allowing an incorrectly written script to be exploited by an attacker. This is misleading in the sense that one tends to think about client-side scripting when reading the word script in this context, however it is most of the times the server side which includes incorrectly escaped user data in the final page (there are a few exceptions which us client-side scripting to dynamically generate parts of the page based on the user supplied parameters, but they are few and far between).

Last, but not least, some of the things are flat out wrong: at point three of the article Malicious AJAX code execution it basically says that using a XMLHttpRequest object one could send requests to any sites. This is not true, browsers adopt a same domain policy on XMLHttpRequest (meaning that the script can send requests only to the domain from which it was originally loaded). You can send requests to other sites by using IFRAMEs, but IFRAME and XMLHttpRequest are not the same thing (although they can be used in similar manner)

My advice to the management type of people who read these articles would be: don’t panic or start running around in circles because of such articles. There is a good chance that many of the things mentioned in it don’t apply to systems. Then again there are many things NOT mentioned here which may apply, so please don’t make a checklist from it and make your people concentrate only on these issues. Read more useful material, like the OWASP list (have I said already how great they are :)).

My advice for programmers: go read the OWASP list and if a manager comes your way about this article, point her/him to the OWASP list and this blog post.

All this fits in nicely I think with the rush of AJAX-y / Web 2.0-y web applications that we are seeing. Because this liberates us from depending on a given computer / operating system and usually you don’t need a heavy weight machine to use them. This is a step in a “software as service” direction, so it might well be that if you are using Google Reader, you are helping the environment :).

On a more technical note: there are many advantages and disadvantages to these kind of “applications”, many of which have been already discussed years ago during the thin client versus fat client debate. It might well be that this is only a temporary phenomenon made possible by the increase of available bandwidth and that in the future the balance may again shift if the available bandwidth / average application size changes in the opposite direction (which I think is the main reason for choosing one solution over the other)