FYI: we are investigating the various reports of forum related issues, and once validated will determine the best way to fix them.

As for html code injection, it does not matter whether you provide users with a simple text box, or a more functional html editor, the possibility exists that html/script injection can occur. To counter this, the usual technique is to filter/encode content as it's being stored, so that the content cannot cause issues. To do this we have a core function InputFilter that provides a number of different mechanisms. You can read more about it, and other module security issues in the 'secure module development' document @ http://www.dotnetnuke.com/tabid/940/Default.aspx

Cathal

actually if you check the core modules you'll find this function is extensively used. The guidance is to ensure that it is used where untrusted user input can occur i.e. anywhere where an anonymous individual can post content e.g. forum posts, blog comments, core user registration etc (the forum issue we are investigating looks like a single field is unfiltered). In addition, many modules will also filter various pieces of their content - but that's up to the individual module teams.

As for modules that aren't filtered such as text/html, that's because these modules come with implicit trust i.e. your site administrator has given you the rights to edit that content, meaning you're a trusted user.

FYI: I once attempted to add a core level filter that could be enabled on a module basis e.g override the render of the control and filter the contents. This prove to be very difficult to get working reliably, due to the variances in html content from skins etc. As the standard guidance is to filter/encode content on the way in, rather than the way out, I shelfed this side-project. I may revisit it at some point (e.g. add an additional optional interface to allow output filtering).

Cathal