Ok, I've read http://forums.asp.net/1/388929/ShowPost.aspx#388929 and looked over PortalSecurity's InputFilter method. It seems that most DNN modules assume that users with Edit permission are trusted.

I checked the Forum Module since that is a module that expects input from many users (who may not all be trusted). Forum Module calls InputFilter for the body of the message, but not the Subject. So a subject like

<SCRIPT>alert('hello');</SCRIPT>

can be entered with surpising results.

I tested this on Forum version 03.10.04.

Actually, I think this is easy to fix. On the Body text you call

objSecurity.InputFilter(_Body, PortalSecurity.FilterFlag.NoScripting)

to filter out any <SCRIPT> or other tags. You cannot HTML encode here because the user may be giving you formated input and you want to preserve it. So, your best option is to accept HTML but filter out nasty stuff.

On the Subject text box, you just take the input and later send it out. Since you really don't want to allow users to provide HTML formating in the subject, you can simply call HttpUtility.HtmlEncode before displaying the subject. This will escape any special HTML characters (like converting < to &lt;) and make it safe to be displayed in a literal or label control.

When presenting the text to be edited in a textbox you don't have to encode it.

I'm not sure what Core security you expect to filter this. I'm pretty sure you have to do it yourself.

Thanks, that was an interesting read.  Instead of taking your advice verbatim, I went and ran the subjects across the XSSController class built into the forum module.  This will handle all those items and allow for control on others from here.  The body of the posts are already being run against the Portal Security you mentioned two posts below.  I am still submitting the module for a full security review, but through my tests after this change it seems this problem is solved.