Allow Arbitrary ASCII Characters in Description Fields

Hi,

StarExec forbids "(" and "-" in solver and pre-/post-processor descriptions. I find this both surprising and annoying. The description field should really just be a text field, and it'd be nice if at least all (printable, basic) ASCII characters were allowed.

Best,
Tjark

seconded.

Hello,

Unfortunately, we can't easily allow the use of arbitrary characters in description fields because of the risk of cross-site scripting attacks. Because we display descriptions on the website, allowing special HTML characters in the description field can give anyone the ability to inject browser scripts into the site.

The characters that we've disallowed are the ones specified as "special" on this page about cross-site scripting attacks.

http://support.microsoft.com/kb/252985

An alternative solution would be to encode descriptions before displaying them, but this is unfortunately more difficult than it sounds. We display descriptions in many different contexts, and often we pass descriptions from one context to another. For example, we may read a description in javascript before passing it to the HTML document. Different contexts have different escaping rules, which can make it challenging to correctly escape data that gets passed between contexts. A summary of some of the different contexts is present here.

https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#Why_Can.27t_I_Just_HTML_Entity_Encode_Untrusted_Data.3F

So, for now at least, it is important to leave these restrictions in place in order to maintain security.

Of course, I understand that dropping this restriction (without compromising security) may require some work. As with any feature request, you'll have to decide if and when you have the resources to implement this.

By the way, the Microsoft page already states "Filtering may not be appropriate for some input. For example, in scenarios where you are receiving <TEXT> input from an HTML form, you may instead choose a method such as encoding (see below)."

tjark wrote:Of course, I understand that dropping this restriction (without compromising security) may require some work. As with any feature request, you'll have to decide if and when you have the resources to implement this.

By the way, the Microsoft page already states "Filtering may not be appropriate for some input. For example, in scenarios where you are receiving <TEXT> input from an HTML form, you may instead choose a method such as encoding (see below)."

Certainly, and we'll hopefully be able to relax these restrictions at some point in the future. We do know encoding is an option, and in fact we already do use encoding in several other areas. The problem with descriptions (and some other inputs) is that we display them in several contexts, and also in nested contexts. The XSS prevention guide I posted recommends against attempting to encode such data because of the complexity of getting it right.

"The first rule is to deny all - don't put untrusted data into your HTML document unless it is within one of the slots defined in Rule #1 through Rule #5. The reason for Rule #0 is that there are so many strange contexts within HTML that the list of escaping rules gets very complicated. We can't think of any good reason to put untrusted data in these contexts. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous."