Bug 500736 - \n characters are being incorrectly escaped on profile review form
Summary: \n characters are being incorrectly escaped on profile review form
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Dogtag Certificate System
Classification: Retired
Component: CA
Version: 1.1
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Ade Lee
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 443788
TreeView+ depends on / blocked
 
Reported: 2009-05-13 21:00 UTC by Ade Lee
Modified: 2015-01-06 01:16 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-07-22 23:35:16 UTC
Embargoed:


Attachments (Terms of Use)
patch to fix (774 bytes, patch)
2009-05-13 21:07 UTC, Ade Lee
no flags Details | Diff

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.


Note You need to log in before you can comment on or make changes to this bug.