http: guard against response splitting in trailers by bnoordhuis · Pull Request #2945 · nodejs/node

bnoordhuis · 2015-09-18T08:20:39Z

Commit 3c293ba ("http: protect against response splitting attacks")
filters out newline characters from HTTP headers but forgot to apply
the same logic to trailing HTTP headers, i.e., headers that come after
the response body. This commit rectifies that.

The expected security impact is low because approximately no one uses
trailing headers. Some HTTP clients can't even parse them.

R=@ChALkeR

CI: https://ci.nodejs.org/job/node-test-pull-request/338/

bnoordhuis · 2015-09-18T08:37:37Z

Note to self: typo in first commit log, s/storeHeader/setHeader/.

rvagg · 2015-09-18T09:15:03Z

this is land-on-v0.12 and maybe land-on-v0.10 isn't it?

ChALkeR · 2015-09-18T09:26:38Z

I would prefer if this was just throwing on any invalid input instead of trying to hide the issue in the user code.
But if throwing is not acceptable, this one is probably fine here.
Another note in the mailing list.

Btw, by «invalid input» I mean not just \n/\r, but anything that is not allowed by the spec as header keys.

bnoordhuis · 2015-09-18T11:29:18Z

Btw, by «invalid input» I mean not just \n/\r, but anything that is not allowed by the spec as header keys.

That didn't escape my notice but that's a tangential issue. This PR just fixes the inconsistency between normal and trailing headers.

Can I get one or two LGTMs?

ChALkeR · 2015-09-18T12:00:00Z

Old logic: if (…) value = …, new logic: value = (…) ? … : value. Does that have a performance impact?
Could you also apply the same function on field?

bnoordhuis · 2015-09-18T12:17:41Z

Old logic: if (…) value = …, new logic: value = (…) ? … : value. Does that have a performance impact?

Not a measurable one, no.

Could you also apply the same function on field?

Maybe in a follow-up PR, I'd like to keep this one free of policy changes.

rvagg · 2015-09-18T12:53:29Z

lgtm, as a first pass at attacking this, we can do more in later PRs where debate can be had, this is simpler to 👍

ChALkeR · 2015-09-18T12:57:08Z

LGTM.

The test verified the output of http.OutgoingMessage#writeHead() but not http.OutgoingMessage#setHeader(). Also check the response body. PR-URL: nodejs#2945 Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Rod Vagg <r@va.gg>

Commit 3c293ba ("http: protect against response splitting attacks") filters out newline characters from HTTP headers but forgot to apply the same logic to trailing HTTP headers, i.e., headers that come after the response body. This commit rectifies that. The expected security impact is low because approximately no one uses trailing headers. Some HTTP clients can't even parse them. PR-URL: nodejs#2945 Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Rod Vagg <r@va.gg>

The test verified the output of http.OutgoingMessage#writeHead() but not http.OutgoingMessage#setHeader(). Also check the response body. PR-URL: #2945 Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Rod Vagg <r@va.gg>

Commit 3c293ba ("http: protect against response splitting attacks") filters out newline characters from HTTP headers but forgot to apply the same logic to trailing HTTP headers, i.e., headers that come after the response body. This commit rectifies that. The expected security impact is low because approximately no one uses trailing headers. Some HTTP clients can't even parse them. PR-URL: #2945 Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Rod Vagg <r@va.gg>

Notable changes * buffer: Fixed a bug introduced in v4.1.0 where allocating a new zero-length buffer can result in the next allocation of a TypedArray in JavaScript not being zero-filled. In certain circumstances this could result in data leakage via reuse of memory space in TypedArrays, breaking the normally safe assumption that TypedArrays should be always zero-filled. (Trevor Norris) #2931. * http: Guard against response-splitting of HTTP trailing headers added via response.addTrailers() by removing new-line ([\r\n]) characters from values. Note that standard header values are already stripped of new-line characters. The expected security impact is low because trailing headers are rarely used. (Ben Noordhuis) #2945. * npm: Upgrade to npm 2.14.4 from 2.14.3, see release notes for full details (Kat Marchán) #2958 - Upgrades graceful-fs on multiple dependencies to no longer rely on monkey-patching fs - Fix npm link for pre-release / RC builds of Node * v8: Update post-mortem metadata to allow post-mortem debugging tools to find and inspect: - JavaScript objects that use dictionary properties (Julien Gilli) #2959 - ScopeInfo and thus closures (Julien Gilli) #2974

Notable changes * buffer: Fixed a bug introduced in v4.1.0 where allocating a new zero-length buffer can result in the next allocation of a TypedArray in JavaScript not being zero-filled. In certain circumstances this could result in data leakage via reuse of memory space in TypedArrays, breaking the normally safe assumption that TypedArrays should be always zero-filled. (Trevor Norris) #2931. * http: Guard against response-splitting of HTTP trailing headers added via response.addTrailers() by removing new-line ([\r\n]) characters from values. Note that standard header values are already stripped of new-line characters. The expected security impact is low because trailing headers are rarely used. (Ben Noordhuis) #2945. * npm: Upgrade to npm 2.14.4 from 2.14.3, see release notes for full details (Kat Marchán) #2958 - Upgrades graceful-fs on multiple dependencies to no longer rely on monkey-patching fs - Fix npm link for pre-release / RC builds of Node * v8: Update post-mortem metadata to allow post-mortem debugging tools to find and inspect: - JavaScript objects that use dictionary properties (Julien Gilli) #2959 - ScopeInfo and thus closures (Julien Gilli) #2974 PR-URL: #2995

rvagg mentioned this pull request Sep 18, 2015
Release Proposal: v4.1.1 #2943
Closed

bnoordhuis added land-on-v3.x labels Sep 18, 2015

bnoordhuis added 2 commits September 18, 2015 21:36

bnoordhuis force-pushed the http-trailers-response-splitting branch from 8035797 to e68a119Compare September 18, 2015 19:37

bnoordhuis closed this Sep 18, 2015

bnoordhuis deleted the http-trailers-response-splitting branch September 18, 2015 19:37

bnoordhuis merged commit e68a119 into nodejs:masterSep 18, 2015

rvagg mentioned this pull request Sep 22, 2015
Release proposal: v4.1.1 #2995
Merged

This was referenced Jun 30, 2021
[Snyk] Security upgrade prismjs from 1.18.0 to 1.24.0 137717unity/node#28
Open
[Snyk] Security upgrade prismjs from 1.20.0 to 1.24.0 baby636/node#13
Open
[Snyk] Security upgrade prismjs from 1.18.0 to 1.24.0 Rednickle/node-1#23
Open

Navigation Menu

Uh oh!

Uh oh!

http: guard against response splitting in trailers - #2945

http: guard against response splitting in trailers#2945
bnoordhuis merged 2 commits into
nodejs:masterfrom
bnoordhuis:http-trailers-response-splitting

bnoordhuis commented Sep 18, 2015

Uh oh!

bnoordhuis commented Sep 18, 2015

Uh oh!

rvagg commented Sep 18, 2015

Uh oh!

ChALkeR commented Sep 18, 2015

Uh oh!

bnoordhuis commented Sep 18, 2015

Uh oh!

ChALkeR commented Sep 18, 2015

Uh oh!

bnoordhuis commented Sep 18, 2015

Uh oh!

rvagg commented Sep 18, 2015

Uh oh!

ChALkeR commented Sep 18, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

bnoordhuis commented Sep 18, 2015

Uh oh!

bnoordhuis commented Sep 18, 2015

Uh oh!

rvagg commented Sep 18, 2015

Uh oh!

ChALkeR commented Sep 18, 2015

Uh oh!

bnoordhuis commented Sep 18, 2015

Uh oh!

ChALkeR commented Sep 18, 2015

Uh oh!

bnoordhuis commented Sep 18, 2015

Uh oh!

rvagg commented Sep 18, 2015

Uh oh!

ChALkeR commented Sep 18, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants