Skip to main content
Known Participant
March 19, 2018
解決済み

Bug in CF11/2016 in http.addParam

  • March 19, 2018
  • 返信数 2.
  • 1370 ビュー

Hi there

I have found an annoying bug in CF11/CF2016, both versions, both updated to latest Hotfixes.

It is in the http() object. Setting a header strips out %0A …. Absolutely weird.

To repro, do this (shortened):

---

GET https://nova-test-ws.sbb.ch/login HTTP/1.1

Authorization: Basic bm92YV9tZ2JfYXBwX3Rlc3Q6NzB4WTBIRE9nSkFYakl2dzgzdHk=

Host: nova-test-ws.sbb.ch

Accept-Encoding: gzip,deflate

---

You will get a large cookie, like this (only start is shown):

---

Set-Cookie: SAML-Ticket=%3Csaml2%3AAssertion+Version%3D%222.0%22+ID%3D%22SAML-afb7ce33-11c0-40fa-8ed6-acfb070f5b01%22+IssueInstant%3D%222018-03-19T13%3A19%3A14Z%22+xmlns%3Asaml2%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertion%22%3E%3Csaml2%3AIssuer%3ESBB-WSG-TEST%3C%2Fsaml2%3AIssuer%3E%3CSignature+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23%22%3E%0A%3CSignedInfo%3E%0A++%3CCanonicalizationMethod+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2FTR%2F2001%2FREC-xml-c14n-20010315%22%2F%3E%0A++%3CSignatureMethod+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1%22%2F%3E%0A++%3CReference+URI%3D%22%23SAML-afb7ce33-11c0-40fa-8ed6-acfb070f5b01%22%3E%0A++++%3CTransforms%3E%0A++++++%3CTransform+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23enveloped-signature%22%2F%3E%0A++++++%3CTransform+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2FTR%2F2001%2FREC-xml-c14n-20010315%22%2F%3E%0A++++%3C%2FTransforms%3E%0A++++%3CDigestMethod+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23sha1%22%2F%3E%0A++++%3CDigestValue%3Ermc17n90iP74fIMgugaysiRgedc%3D%3C%2FDigestValue%3E%0A++%3C%2FReference%3E%0A%3C%2FSignedInfo%3E%0A++++%3CSignatureValue%3EZo%

---

I store it to a variable because I have to use it on another call ….

My code is

---

saml_cookie = login.ResponseHeader["Set-Cookie"];

h = new http ( Charset = "utf-8", Method  = "POST", URL     = "https://nova-test-ws.sbb.ch/kontrolle/1.6/sicherheitselementservice");

h.addParam (type="header", name="Content-Type", value="text/xml;charset=utf-8");

h.addParam (type="header", name="Cookie", value=saml_cookie);

h.addParam (type="body", value='<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sic="http://nova.voev.ch/kontrolle/1.6.0/sicherheitselemente"> <soapenv:Header/> <soapenv:Body> <sic:sicherheitselementPingRequest/> </soapenv:Body> </soapenv:Envelope>');

result = h.send().getPrefix();

---

When you use a tool like Fiddler to intercept SSL and to see what is going on, you inspect that cookie and see this difference (red parts show that %0A is no longer there):

---

SAML-Ticket=%3Csaml2%3AAssertion+Version%3D%222.0%22+ID%3D%22SAML-afb7ce33-11c0-40fa-8ed6-acfb070f5b01%22+IssueInstant%3D%222018-03-19T13%3A19%3A14Z%22+xmlns%3Asaml2%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertion%22%3E%3Csaml2%3AIssuer%3ESBB-WSG-TEST%3C%2Fsaml2%3AIssuer%3E%3CSignature+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23%22%3E%3CSignedInfo%3E++%3CCanonicalizationMethod+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2FTR%2F2001%2FREC-xml-c14n-20010315%22%2F%3E++%3CSignatureMethod+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1%22%2F%3E++%3CReference+URI%3D%22%23SAML-afb7ce33-11c0-40fa-8ed6-acfb070f5b01%22%3E++++%3CTransforms%3E++++++%3CTransform+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23enveloped-signature%22%2F%3E++++++%3CTransform+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2FTR%2F2001%2FREC-xml-c14n-20010315%22%2F%3E++++%3C%2FTransforms%3E++++%3CDigestMethod+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23sha1%22%2F%3E++++%3CDigestValue%3Ermc17n90iP74fIMgugaysiRgedc%3D%3C%2FDige

---

As you see, the %0A are stripped out … there is ABSOLUTELY NO REASON why CF does this.

Since the whole cookie is digitally signed I cannot use this cookie to authenticate cause it is broken ... the ping soap request therefore gets a 403 forbidden.

I have tried tons of variants to preserve the cookie value. It is not the value itself, it is definitively the assignment.

---

  1. h.addParam (type="header", name="Cookie", value=saml_cookie);

---

I assume that is does that do all headers because in http header section, there should be no LF ... but here it is escaped! Looks as if there is a bug in a validation code.

By April, I need to have a solution to this.

Please confirm receipt of this bug report and advise.

PS: Just to let you know: it IS CF's fault …. Since SOAP-UI, also based on Java, does not show this silly behavior.

Any hints and work-arounds greatly welcome ...

    このトピックへの返信は締め切られました。
    解決に役立った回答 BKBK

    Hi Dave

    Good idea. I tried it. No change in behavior. Still wrong. Fiddler again proved it. The %0A is stripped .. I begin to assume that this is because on Windows Platforms LF is not the Line limiter ... CR/LF is. Maybe CF tries to correct "wrong" CR/LFs ..

    Since I am not that good in Java, I am now looking for some trick to get to the http parameters by Java ... to set the string .... any hints here for me? Can I somehow access the Java http object beneath CF?


    Hi Martin,

    I do believe you. Report a bug. In your report, refer to this discussion.

    You don't have to do much to reproduce the bug. Here's an example

    <cfsavecontent variable="urlEncodedString">%3Csaml2%3AAssertion+Version%3D%222.0%22+ID%3D%22SAML-afb7ce33-11c0-40fa-8ed6 -acfb070f5b01%22+IssueInstant%3D%222018-03-19T13%3A19%3A14Z%22+xmlns%3Asaml2%3D%22urn%3Aoa sis%3Anames%3Atc%3ASAML%3A2.0%3Aassertion%22%3E%3Csaml2%3AIssuer%3ESBB-WSG-TEST%3C%2Fsaml2 %3AIssuer%3E%3CSignature+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23%22%3E %0A%3CSignedInfo%3E%0A++%3CCanonicalizationMethod+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2FTR%2F2001%2FREC-xml-c 14n-20010315%22%2F%3E%0A++%3CSignatureMethod+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sh a1%22%2F%3E%0A++%3CReference+URI%3D%22%23SAML-afb7ce33-11c0-40fa-8ed6-acfb070f5b01%22%3E%0A++++%3CTransforms%3E%0A++++++%3CTransform+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23envelope d-signature%22%2F%3E%0A++++++%3CTransform+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2FTR%2F2001%2FREC-xml-c14n-20010 315%22%2F%3E%0A++++%3C%2FTransforms%3E%0A++++%3CDigestMethod+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23sha1%22 %2F%3E%0A++++%3CDigestValue%3Ermc17n90iP74fIMgugaysiRgedc%3D%3C%2FDigestValue%3E%0A++%3C%2FReferenc e%3E%0A%3C%2FSignedInfo%3E%0A++++%3CSignatureValue%3EZo%</cfsavecontent>

    <cfcookie name="testCookie" value="#urlEncodedString#">

    <cfoutput>#cookie.testCookie#</cfoutput>

    The output omits all occurrences of %0A. That's buggy.

    返信数 2

    Charlie Arehart
    Community Expert
    Community Expert
    March 19, 2018

    Tinu, Dave beat me to it on the point about your expectation of a "fix". But even before you may file a bug report, you could clarify something (for us and for them).

    1) You say "it is definitively the assignment", but then you point to the addparam. Have you confirmed if it may well be already so in "the assignment" that preceded it:

    saml_cookie = login.ResponseHeader["Set-Cookie"];

    Because it may be. Have you dumped that saml_cookie? and better, the responseheader? or even the whole login object (you don't show us what's doing that, but perhaps a similar http/cfhttp call?

    2) As for the addparam, the docs (for its corollary, cfhttpparam) say that headers are NOT encoded. I know you're saying it's "escaped" Could you try adding an argument telling it "no", don't encode/escape things, and see if that makes a difference. (The docs for addparam, ColdFusion Help | http, don't refer to such an argument, but I'd guess it would take it as a final argument.)

    Let us know what you find, on my point 1 and 2.

    /Charlie (troubleshooter, carehart. org)
    tinu8805作成者
    Known Participant
    March 19, 2018

    Hi Charlie

    Many years ago, I met you in Zürich ... I still remember you ... of course

    I included the reproduction ... please do it ... then you see you get the SAML-Ticket as an urlencoded ("escaped") string. The cookie itself is a XML stuff. Obviously, there is a LF after the closing > of an element. That is why the LF appears as %0A after each %3E

    So I get the whole thing as a simple string. I save it to a variable. The task is to JUST MIRROR that string as a cookie in the next http call.

    So it is obvious that I can only use h.addParam (type="header", name="Cookie", value=saml_cookie). I would prefer to learn about another method ...

    This always caused a 403 Forbidden by the remote system. No one had an idea why this happens as everything looked well ... under 4 eyes too. So I had to intercept the SSL traffic and finally figured that the cookie CF delivers has the string parts %0A removed ...

    I'd be glad to see my errors in the code ... if there are any ...

    Regards

    Martin

    Charlie Arehart
    Community Expert
    Community Expert
    March 22, 2018

    Thanks, Martin. But you didn't answer my question. I appreciate the added info (about how challenging it's been), and I realize you say that you have provided what we need to recreate the problem. Can you save us having to do that (since it's not as it stands a completely read-to-run example) and just let us know if you see the problem in the assignment, BEFORE the addparam? And if it is NOT, did you try adding the argument for that as I proposed?

    /Charlie (troubleshooter, carehart. org)
    Community Expert
    March 19, 2018

    I don't have an answer for your question, but this is not how you submit bugs to Adobe. This is an open forum. Use Adobe's bug tracker to submit bugs:

    Tracker

    Dave Watts, Fig Leaf Software

    Dave Watts, Eidolon LLC