Bug #320
closed
Using special characters (e.g. åäö) in certificate "Descriptive name" breaks entire WebGUI
0%
Description
If you create or import a certificate using the certificate manager, and enter a name in the "Descriptive name" field which contains special/foreign language characters such as åäö, the entire WebGUI breaks until you edit the name out of the config.xml.
Error in the system log is:
Jan 24 13:05:36 php: /system_certmanager.php: XML error: Invalid character at line 295
In the config, the test name "Mööse" shows up as:
<name>M\xf6\xf6se</name>
Updated by Pierre POMES almost 15 years ago
Well, I'm afraid this problem occurs on every screen containing a "description" field for which the validation is only done by the function "do_input_validation" (/usr/local/www/guiconfig.inc): I had the same problem when entering such characters in a OpenVPN server description field.
Actually do_input_validation only prevents some control characters, and maybe this function should be improved to cover all fields in the WebGUI (for all pfSense screens).
Updated by Tony Graziano almost 15 years ago
Normally special characters are not allowed in certificates anyway.
"Avoid any special characters like @, #, &, !, etc. Some CAs will reject a certificate request which contains a special character. So, if your company name includes an ampersand (&), spell it out as "and" instead of "&.""
So shouldn;t there simply be help text to alert the admin to NOT use special characters even in the name field. With certificates, consistency is a good thing.
Updated by Ermal Luçi almost 15 years ago
- Status changed from New to Needs Patch
This is very dependent on the input verification done on every subsystem/functionality.
Xmlreader module has support for this and does not bail out, so i would like to postpone this until xmlreader gets the mainline parser.
Updated by Chris Buechler almost 15 years ago
- Status changed from Needs Patch to New
- Priority changed from High to Low
This isn't a high priority, but I think it's something that needs to be addressed somehow. We can't allow entering of data that breaks the system.
Updated by Ermal Luçi over 14 years ago
Probably filter_var can help here too.
$_POST can be tested for descr/description fields and try to sanitize them.
Updated by Ermal Luçi over 14 years ago
- Status changed from New to Feedback
Get a new snapshot and try with 'touch /cf/conf/use_xmlreader
Updated by Ermal Luçi over 14 years ago
This should be fixed now.
All characters will be encoded/decoded properly and they will be shown properly too in the GUI.
Updated by Jim Pingle about 14 years ago
- Status changed from Resolved to New
This is still a problem for sysctl tunables. For some reason their description field is desc and not descr, so they are missed by this protection.
Reported here: http://forum.pfsense.org/index.php/topic,28580.0.html
Updated by Jim Pingle about 14 years ago
The fullname field in the user manager is also another source of this issue. It will either need to be CDATA escaped or renamed to descr to take advantage of the existing protection mechanism.
Updated by Jim Pingle about 14 years ago
- Status changed from New to Feedback
I have renamed the fields in several parts of the config and GUI to descr in an attempt to help resolve this issue. I have fixed the sysctl entries, user manager names, cert/crl/ca entries, and load balancer names. All of these should have CDATA protection now and can handle special characters.
The snapshot building now does not have these fixes, but the next one will. Please update once that snapshot is available (might be early on Oct 20th) and test these changes to ensure that there were no regressions due to the renaming.
Updated by Chris Buechler almost 14 years ago
- Status changed from Feedback to Resolved