Project

General

Profile

Bug #320

Using special characters (e.g. åäö) in certificate "Descriptive name" breaks entire WebGUI

Added by Jim Pingle over 9 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Low
Assignee:
-
Category:
Web Interface
Target version:
Start date:
01/24/2010
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.0
Affected Architecture:

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>

Associated revisions

Revision ab83fce0 (diff)
Added by Ermal Luçi over 9 years ago

Ticket #320. Use xmlreader and xmlwriter to read/write xml since it encodes decodes itself special chars.

Revision 15864861 (diff)
Added by Jim Pingle almost 9 years ago

Change the description field on sysctl tunables to be 'descr' and not 'desc' so they will gain CDATA protection. Ticket #320

Revision e988813d (diff)
Added by Jim Pingle almost 9 years ago

desc to descr in Load Balancer config, so they gain CDATA protection and standardize field names. Ticket #320.

Revision f2a86ca9 (diff)
Added by Jim Pingle almost 9 years ago

Rename 'name' to 'descr' for CA, Certificates, and CRLs, to gain CDATA protection and standardize field names. Ticket #320.

History

#1 Updated by Pierre POMES over 9 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).

#2 Updated by Tony Graziano over 9 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.

#3 Updated by Ermal Luçi over 9 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.

#4 Updated by Chris Buechler over 9 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.

#5 Updated by Ermal Luçi over 9 years ago

Probably filter_var can help here too.
$_POST can be tested for descr/description fields and try to sanitize them.

#6 Updated by Ermal Luçi over 9 years ago

  • Status changed from New to Feedback

Get a new snapshot and try with 'touch /cf/conf/use_xmlreader

#7 Updated by Ermal Luçi about 9 years ago

This should be fixed now.
All characters will be encoded/decoded properly and they will be shown properly too in the GUI.

#8 Updated by Chris Buechler about 9 years ago

  • Status changed from Feedback to Resolved

fixed

#9 Updated by Jim Pingle almost 9 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

#10 Updated by Jim Pingle almost 9 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.

#11 Updated by Jim Pingle almost 9 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.

#12 Updated by Chris Buechler over 8 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF