Bug 500736

Summary: \n characters are being incorrectly escaped on profile review form
Product: [Retired] Dogtag Certificate System Reporter: Ade Lee <alee>
Component: CAAssignee: Ade Lee <alee>
Status: CLOSED ERRATA QA Contact: Chandrasekar Kannan <ckannan>
Severity: medium Docs Contact:
Priority: high    
Version: 1.1CC: awnuk, benl
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-22 23:35:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 443788    
Attachments:
Description Flags
patch to fix none

Description Ade Lee 2009-05-13 21:00:32 UTC
Description of problem:
The fix for Bug 223353 allowed users to escape special characters like commas and quotes in the input and allow those to be displayed in all forms, and be added to the certificate.

In particular, the fix changed the following function:


    protected String escapeJavaScriptString(String v) {
        int l = v.length();
        char in[] = new char[l];
        char out[] = new char[l * 2];
        int j = 0;

        v.getChars(0, l, in, 0);

        for (int i = 0; i < l; i++) {
            char c = in[i];

            /* presumably this gives better performance */
            if ((c > 0x23) && (c != 0x5c)) {
                out[j++] = c;
                continue;
            }
            switch (c) {
            case '\n':
                out[j++] = '\\';
                out[j++] = 'n';
                break;

            case '\\':
                out[j++] = '\\';
                out[j++] = '\\';
                break;
            ...

Prior to this fix, the line :
    if ((c > 0x23) && (c != 0x5c)) {

used to say: if (c > 0x23) {

This resulted in (0x5c) "\" characters not being escaped - which was bad because we needed to include escaped \ characters.

The problem is that there are some profile inputs -- the Key and KeyId, in particular, which included the characters '\' and 'n' in their string, rather than the correct character '\n'.  In the  new code, this would be expressed as
"\\n" - rather than "\n" - which would be treated as a newline.

The result would be that the display would be too wide.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Ade Lee 2009-05-13 21:04:07 UTC
The "proper" fix might be to root out the inputs that have this problem and fix them to return strings with '\n' rather than "\n".

This is likely to be deep in the CA code, and may cause problems elsewhere.  I'm going to propose a hack instead.

Basically , we will change the escapeJavaScriptString() code to specifically treat the case of "\n" as one would treat a newline.

See patch.

Comment 2 Ade Lee 2009-05-13 21:07:32 UTC
Created attachment 343876 [details]
patch to fix

awnuk , please review.

Comment 3 Andrew Wnuk 2009-05-14 18:42:25 UTC
attachment (id=343876) +awnuk

Comment 4 Andrew Wnuk 2009-05-14 19:24:18 UTC
remark on attachment (id=343876)
in the line
if ((c == 0x5c) && (in[i+1] == 'n')) {
i+1 - may cross array boundary and it should be checked if it is lower then array length.

Comment 5 Ade Lee 2009-05-18 15:18:34 UTC
check added.

[builder@dhcp231-124 common]$ svn ci -m "Bugzilla Bug #500736 -  \n characters are being incorrectly escaped on profile review form" pki-common.spec ../../base/common/
Sending        base/common/src/com/netscape/cms/servlet/profile/ProfileServlet.java
Sending        dogtag/common/pki-common.spec
Transmitting file data ..
Committed revision 456.

Comment 6 Kashyap Chamarthy 2009-06-21 12:24:42 UTC
I tried to request a cert with the following details

UID=james2,E=james2,CN=james2\n,OU=ou3\n

when the request form is submitted, the above \n is escaped as \\

Comment 7 Ade Lee 2009-06-22 16:31:24 UTC
That is ok.  The basic manifestation of this bug was that \n characters that were added by the server in displaying certificate requests were being escaped.
The result of this was that when you looked at the certificate request in the agent pages, the page looked very wide (and you could see the escaped \n entries in the key and Key ID.

If this is not happening, then the bug can be considered as verified.

Comment 8 Kashyap Chamarthy 2009-06-23 07:52:38 UTC
Vefified. Thanks Ade.