Bug #320
closed
Using special characters (e.g. åäö) in certificate "Descriptive name" breaks entire WebGUI
Added by Jim Pingle almost 15 years ago.
Updated almost 14 years ago.
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>
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).
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.
- 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.
- 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.
Probably filter_var can help here too.
$_POST can be tested for descr/description fields and try to sanitize them.
- Status changed from New to Feedback
Get a new snapshot and try with 'touch /cf/conf/use_xmlreader
This should be fixed now.
All characters will be encoded/decoded properly and they will be shown properly too in the GUI.
- Status changed from Feedback to Resolved
- Status changed from Resolved to New
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.
- 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.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Ermal Luçi 
Updated by 
Updated by