Separating content from structure in the Closed Question XML

I'm aware of the fact that there are non-HTML tags in the HTML section that need to be parsed. These tags within CDATA sections will be parsed.

Allowing javascript by default is a potential security risk indeed. But it should be handled on the level of input filters not on the level of Closed Question. The HTML filter which is provided in Drupal by default is there for that reason.

We'll use various javascript applets that will communicate state (selected option for example) to an hidden field which will act as a kind of fill-in question.

I'm fully aware of the fact that CDATA sections are not parsed at the moment. A CDATA parser should only parse the Closed Question related tags (like the inline options) and leave deciding which HTML-tags to allow to the HTML filter.

The beautiful part of my solution is that you can define different input formats with different input filters for different groups of users. In our case we'll have an administrator who will do most of the work so we'll give him full rights. If a student assistant has to do some work, than you can define an other input filter that doesn't allow the usage of <script /> tags.

Added something about backwards compatibility

I created a first proposal: This change allows the disabling of the XML-filtering by a setting. The patch is based on the 6.x-2.x branch and I haven't tested it on 7.x.

Any comments are welcome.

In our past project we simply needed full JavaScript to enable our questions. That's why we created the option. We use input formats to allow or disallow certain people to enter JavaScript or other malicious content.

The default page in Drupal also allows all JavaScript when the right input format is selected. My modifications don't allow JavaScript the be executed by default. You first have to enable full XML parsing in the newly made ClosedQuestion settings and you have to create an input format that allows JavaScript.

We did, but we didn't consider it fit for several reasons:

1. The questions we make are quite unique, we have like 10 different designs at the moment. Also the questions we use do not contain only a java applet but also some textual content or even images.
2. We wanted to treat the ClosedQuestion page just like any other page with the same possibilities.
3. We wanted to provide the people who create questions with the flexibility to use their own JavaScript applets. However these people may not have access to the actual ClosedQuestion source.
4. We don't want to pollute the ClosedQuestion module with whatever question type we think we need. We think that the ClosedQuestion module should provide a solid basis on which more complicated questions can be build.
5. We had to develop the Molecule module which provides the input filter we use anyway because we also use it in normal page nodes. So we added an option to it to sync it with ClosedQuestion questions.

The questions we created are not that difficult for teachers to make. This is an example question (the answer mapping section is removed) even without JavaScript in the body we couldn't make without our changes to the ClosedQuestion parser.

<question type="fillblanks"> 
<text>
<p>Look at the spectrum and structure of 1-hexyne below. Which peak corresponds to the stretch vibration of the indicated bond? Click on the correct peak and then submit.</p>
<spectrum closedquestionsync="PeakID1"  width="450" height="350" file=""/><img src="" /> 
<p style="display:none"><inlineChoice identifier="PeakID1" freeform="1"/></p>
</text>
</question>

We can't run this question through the normal XML filter because the <spectrum /> tag will be filtered out.

This same <spectrum /> tag is also used in content on pages. So in that way we want ClosedQuestion to behave like a normal page.

If you wanted to include these type of questions in ClosedQuestion you would have to include JavaScript specific to our Molecule module. If you wanted the questions to actually work (without downloading extra files) you would even have to include the Java applets themselves. We have plans to embed several more Java or Javascript applets. I don't think that it's a good idea to include all these applets and their code into the ClosedQuestion project.

Our Molecule module works in CQ even if you would disable inline JavaScript. We provide the JavaScript needed in the Molecule module and load this file. However we do provide custom XML tags that have to be included in HTML (for example the <spectrum /> tag in the previous example). The "old" XML parser that CQ uses, has a fixed set of XML tags that are allowed. Of course the <spectrum /> tag isn't allowed so it doesn't work.

So we modified the CQ XML parser to use the input filters provided in Drupal. For example we could create a input filter that only allows our Molecule tags and doesn't allow JavaScript to enable student assistants to create questions but mitigate the attack possibilities by disabling JavaScript tags.

To answer your question: I can't come-up with an realistic attack that would use badly written JavaScript. But I'm not saying that it isn't possible because I could write an attack for this. First of all, JavaScript runs in the browser so any attacker can swap out the existing code with his own in his own browser. You normally don't trust data coming from the client either by normal HTTP requests or requests initiated by JavaScript. The only problem thus left is badly written JavaScript that allows XSS in the CQ results page. This is something that, if present, is also exploitable without bad JavaScript so I don't see any problems here.

To make my point more clear: I don't advocate allowing everybody to use JavaScript in CQ content. For example at the moment we would be perfectly fine with disabling inline JavasScript but allowing our own custom tags. However we would like to make this decision ourselves and even on a per account basis.