Project

General

Profile

Actions

Bug #320

closed

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

Added by Jim Pingle almost 12 years ago. Updated about 11 years ago.

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

0%

Estimated time:
Plus Target Version:
Release Notes:
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>

Actions #1

Updated by Pierre POMES almost 12 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).

Actions #2

Updated by Tony Graziano almost 12 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.

Actions #3

Updated by Ermal Luçi almost 12 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.

Actions #4

Updated by Chris Buechler almost 12 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.

Actions #5

Updated by Ermal Luçi over 11 years ago

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

Actions #6

Updated by Ermal Luçi over 11 years ago

  • Status changed from New to Feedback

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

Actions #7

Updated by Ermal Luçi over 11 years ago

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

Actions #8

Updated by Chris Buechler over 11 years ago

  • Status changed from Feedback to Resolved

fixed

Actions #9

Updated by Jim Pingle about 11 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

Actions #10

Updated by Jim Pingle about 11 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.

Actions #11

Updated by Jim Pingle about 11 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.

Actions #12

Updated by Chris Buechler about 11 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF