I think I mentioned that a few times in the past, but since I recently had to deal with something similar in the form of an exploit, I think it is worth mentioning again:

When using DP tags in HTML sections, the data that replaces the DP tag in the generated skin is not HTML encoded, which can lead to bogus display in some cases.

It also means that you can use almost any data field to inject a script into the skin, although the larger ones, like Overview or Easter Eggs, are more suitable. This applies to all skins, including the Default Preview skin.

If I have used DP tags in my skins, I usually dealt with encoding problems by putting the DP tags into <TEXTAREA> blocks. But that's only fine for fixing encoding problems; it doesn't help against script injection.

For HEADER_VARS, encoding is not a problem as the skin has to deal programatically with the variables anyway. Script injection is still possible, though.

If you enter the following text in, for example, your overview:

<script>/* --> </textarea>*/</script><script> alert('gotcha');</script>

the script will always be executed, regardless whether the skin uses the simple <DP NAME="OVERVIEW"> tag, the same tag enclosed in a <TEXTAREA>, or the HEADER_VARS.

Before you start to panic:

I don't think malicious script injection is a real issue, I merely used it to illustrate my point about the lack of encoding.

The screeners and the voters will probably notice if someone submits script code for a data field. Then again, at least a filter for the Online DB to detect such stuff wouldn't hurt either.

Quoting mediadogg:

Quote:
Hmmm, I'm thinking I might also add an alarm if a <script> tag is detected during edit. Maybe that would be a good thing inside the PCP plugin or inside Database Query also????

Yes please!
But the main task is for Ken to close this.
Even though Matthias thinks that there's no need to panic (and I agree there), history shows that any security vulnerability gets abused sooner or later.

Thanks Matthias

Quoting mediadogg:

Quote:
I think this is an outstanding post, and I totally agree. I plan to put code into BulkEdit to disallow <script> tags in any non-personal text fields. This of course doesn't stop anybody from doing it manually, but at least I'll do my part to prevent a mass insertion.

Hmmm, I'm thinking I might also add an alarm if a <script> tag is detected during edit. Maybe that would be a good thing inside the PCP plugin or inside Database Query also????

As long as the data is kept local only and is not contributed, I see no problem with script code in data fields. I can see useful applications of script code in your local database in many fields (e.g. someone could use the overview field for active content).

I don't think that BulkEdit should prevent such code. The correct point for blocking active code in data fields would be the contribution system.

Quoting mediadogg:

Quote:
I just feel somewhat responsible to try and prevent my plugin from being a tool that could easily be abused.

Every tool can be abused. But as long as the same data could have been entered manually into a profile, there is no reason why you should not be able to enter the same data with any other tool.

Quoting Ken Cole:

Quote:
During contribution evaluation, any HTML code like this should show as plain text...

Which was kinda my point. The simple DP tags should work the same way and create HTML-encoded text. Not only because of the script stuff, but because you can end up with bogus display, if the data field contains special characters like "<", ">" or "&".

The only exceptions to HTML-encoding should be:
- the Overview, where the bold/italic tags should pass through unencoded, if formatting is enabled.
- the Notes, but only if use HTML for Notes is enabled.