Don't replace escaped regex / function placeholders in strings #22

JordanMilne · 2016-10-13T22:54:22Z

Previously we weren't checking if the quote that started the placeholder
was escaped or not, meaning an object like

{"foo": /1"/, "bar": "a\"@__R-<UID>-0__@"}

Would be serialized as

{"foo": /1"/, "bar": "a\/1"/}

meaning an attacker could escape out of bar if they controlled both
foo and bar and were able to guess the value of <UID>.

UID is generated once on startup, is chosen using Math.random() and
has a keyspace of roughly 4 billion, so within the realm of an online
attack.

Here's a simple example that will cause console.log() to be called when
the serialize()d version is eval()d

eval('('+ serialize({"foo": /1" + console.log(1)/i, "bar": '"@__R-<UID>-0__@'}) + ')');

Where <UID> is the guessed UID.

This fixes the issue by ensuring that placeholders are not preceded by
a backslash.

yahoocla · 2016-10-13T22:54:23Z

Thank you for submitting this pull request, however I do not see a valid CLA on file for you. Before we can merge this request please visit https://yahoocla.herokuapp.com/ and agree to the terms. Thanks! 😄

JordanMilne · 2016-10-13T23:19:34Z

CLA signed

ericf · 2016-10-14T05:36:35Z

@JordanMilne thanks for digging into this! Do you think it also makes sense to generate a UID with a larger set of possible values?

JordanMilne · 2016-10-14T22:20:11Z

@ericf Yeah, I think that would be sensible. As long as UID is still guessable you could still do things like have

{"foo": /1/, "bar":"@__R-<UID>-0__@"}

serialize as

{"foo": /1/, "bar": /1/}

Far less useful in an attack IMO but might still be a problem.

Math.random() isn't a great source of entropy if you want to prevent attacks like that since it's generally not backed by a CSPRNG, though. I'll add a commit to use a CSPRNG where available and add more entropy to UID.

yahoocla · 2016-10-15T00:54:56Z

CLA is valid!

ericf

@JordanMilne thanks for updating this to add a better source of entropy! I added a few comments…

ericf · 2016-10-17T20:49:43Z

index.js

@@ -6,11 +6,13 @@ See the accompanying LICENSE file for terms.

 'use strict';

-var isRegExp = require('util').isRegExp;
+var isRegExp    = require('util').isRegExp;
+var randomBytes = require('randombytes');


Curious why you chose this package over the built-in crypto.randomBytes()?

I used that so as not to break the serializer when run in a browser. If the serializer intended to be node-only I'll just use crypto.randomBytes()

My intention is node-only. But it's true that I don't know if people are bundling it for the browser. So let's stick with what you have using randombytes.

ericf · 2016-10-17T20:51:28Z

index.js

@@ -37,6 +52,7 @@ module.exports = function serialize(obj, options) {
        options = {space: options};
    }

+    var uid = options.uid || UID;


I don't think it's a good idea to allow options.uid. But curious why you added it?

I need a deterministic value for UID for the regression test I added, the other option is to monkeypatch crypto.randomBytes() in the tests like I was doing with Math.random(), but that felt a little brittle. I'm fine with whichever you prefer

I'd prefer the monkey patch for the tests because I don't want people setting options.uid and getting pwned.

ericf · 2016-10-17T20:53:45Z

index.js

+        // The placeholder may not be preceded by a backslash. This is to prevent
+        // replacing things like `"a\"@__R-<UID>-0__@"` and thus outputting
+        // invalid JS.
+        if (backSlash) {


Now with a better source of entropy, is the backslash escape still required, or did you want to leave it for extra protection?

I don't think there's any harm in having it. I'm more confident that this will correctly prevent user input from escaping strings than I am in my knowledge of CSPRNGs :)

ericf · 2016-10-21T15:01:27Z

@JordanMilne if you don't mind replacing options.uid which monkey patching randombytes in the test, then I'll merge this and get a release out. Thanks!

Previously we weren't checking if the quote that started the placeholder was escaped or not, meaning an object like {"foo": /1"/, "bar": "a\"@__R-<UID>-0__@"} Would be serialized as {"foo": /1"/, "bar": "a\/1"/} meaning an attacker could escape out of `bar` if they controlled both `foo` and `bar` and were able to guess the value of `<UID>`. UID was generated once on startup, was chosen using `Math.random()` and had a keyspace of roughly 4 billion, so within the realm of an online attack. Here's a simple example that will cause `console.log()` to be called when the `serialize()`d version is `eval()`d eval('('+ serialize({"foo": /1" + console.log(1)/i, "bar": '"@__R-<UID>-0__@'}) + ')'); Where `<UID>` is the guessed `UID`. This fixes the issue by ensuring that placeholders are not preceded by a backslash. We also switch to a higher entropy `UID` to prevent people from guessing it.

JordanMilne · 2016-10-21T22:42:14Z

switched to monkeypatching crypto.randomBytes in the test and squashed

okuryu · 2017-07-17T00:33:18Z

test/unit/serialize.js

+var crypto = require('crypto');
+var oldRandom = crypto.randomBytes;
+crypto.randomBytes = function(len, cb) {
+    var buf = new Buffer(len);


new Buffer() is deprecated. I think we should use Buffer.from() instead.

okuryu

please resolve the conflicts.

eugef · 2020-02-28T10:16:56Z

@JordanMilne @okuryu this issue is still reported as a security vulnerability of the serialize-javascript package.

Are there any plans to merge the fix?

JordanMilne · 2020-02-28T15:49:44Z

I'm not sure if a fix was merged, you should be able to check by seeing if the testcase in the PR repros.

I'm not likely to update this to work with the new serialization code if it turns out this does still repro, as I no longer work on any code that has serialize-javascript as a dependency. Feel free to use this code as the basis for another PR if you like though, I've already signed the CLA.

ericf reviewed Oct 17, 2016

View reviewed changes

JordanMilne force-pushed the dont_replace_escaped_placeholders branch from 58bd2b6 to 31ad2d3 Compare October 21, 2016 22:40

okuryu reviewed Jul 17, 2017

View reviewed changes

okuryu requested changes Jul 17, 2017

View reviewed changes

JordanMilne closed this Feb 28, 2020

Siebes mentioned this pull request Apr 1, 2020

Don't replace regex / function placeholders within string literals #79

Merged

Omrisnyk mentioned this pull request Jan 9, 2024

[Snyk] Fix for 1 vulnerabilities Omrisnyk/npm-lockfiles#138

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Don't replace escaped regex / function placeholders in strings #22

Don't replace escaped regex / function placeholders in strings #22

JordanMilne commented Oct 13, 2016

yahoocla commented Oct 13, 2016

JordanMilne commented Oct 13, 2016

ericf commented Oct 14, 2016

JordanMilne commented Oct 14, 2016

yahoocla commented Oct 15, 2016

ericf left a comment

ericf Oct 17, 2016

JordanMilne Oct 21, 2016

ericf Oct 21, 2016

ericf Oct 17, 2016

JordanMilne Oct 21, 2016

ericf Oct 21, 2016

ericf Oct 17, 2016

JordanMilne Oct 21, 2016

ericf commented Oct 21, 2016

JordanMilne commented Oct 21, 2016

okuryu Jul 17, 2017

okuryu left a comment •

edited

Loading

eugef commented Feb 28, 2020

JordanMilne commented Feb 28, 2020

Don't replace escaped regex / function placeholders in strings #22

Don't replace escaped regex / function placeholders in strings #22

Conversation

JordanMilne commented Oct 13, 2016

yahoocla commented Oct 13, 2016

JordanMilne commented Oct 13, 2016

ericf commented Oct 14, 2016

JordanMilne commented Oct 14, 2016

yahoocla commented Oct 15, 2016

ericf left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericf commented Oct 21, 2016

JordanMilne commented Oct 21, 2016

Choose a reason for hiding this comment

okuryu left a comment • edited Loading

Choose a reason for hiding this comment

eugef commented Feb 28, 2020

JordanMilne commented Feb 28, 2020

okuryu left a comment •

edited

Loading