Helper to deal with dangerous strings

[dubzzz]

🚀 Feature Request

JavaScript is subject to very strange bugs when using keys like __proto__ or reserved keywords.

The aim of this feature will be to come with a nice helper able to generate strings including various keywords such as:

'__prototype__', '__proto__' , 'proto'    , 'constructor', 'set'      , 'get'       ,
'break'        , 'case'      , 'class'    , 'catch'      , 'const'    , 'continue'  ,
'debugger'     , 'default'   , 'delete'   , 'do'         , 'else'     , 'export'    ,
'extends'      , 'finally'   , 'for'      , 'function'   , 'if'       , 'import'    ,
'in'           , 'instanceof', 'new'      , 'return'     , 'super'    , 'switch'    ,
'this'         , 'throw'     , 'try'      , 'typeof'     , 'var'      , 'void'      ,
'while'        , 'with'      , 'yield'    , 'enum'       , 'await'    , 'implements',
'let'          , 'package'   , 'protected', 'static'     , 'interface', 'private'   ,
'public'       , 'abstract'  , 'boolean'  , 'byte'       , 'char'     , 'double'    ,
'final'        , 'float'     , 'goto'     , 'int'        , 'long'     , 'native'    ,
'short'

proto and related plus reserved keywords listed in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar

It might also includes known vulnerabilities or keywords coming from other langages: SELECT, FROM...

Bugs like the one of letrec - see #483 - would have been easier to detect with such helper.

[dubzzz]

toString is missing in the list

[dubzzz]

Please note that such construct will need to be able to shrink constant values in case of failure, filter them depending on the parameters passed to the string constructor..

[tinydylan]

Please note that such construct will need to be able to shrink constant values in case of failure, filter them depending on the parameters passed to the string constructor..

Can you explain this further?

Would this just be implemented using fc.constantFrom? If so, this might be an "ideal first issue".

[dubzzz]

One of the remaining questions for this arbitrary is: Should it offer shrinking capabilities?

The other one is: Should it offer options to deal with SQL keywords for instance?

[ethanresnick]

I also wonder (not being a property-based testing expert): should this also be part of the bias of the normal fc.string arbitrary? I’d worry, if it’s only implemented as a separate/standalone arbitrary that a lot of people would forget to write tests with it

[dubzzz]

@ethanresnick

should this also be part of the bias of the normal fc.string arbitrary

It will be the default for the string and other related structures. The target for next versions of fast-check is to consider the full scope of possible inputs and to pin-point as soon as possible when this scope is wrong. If someone says: 'my algorithm can handle any string, then it should also handle proto, otherwise it means that any is falsy'.

@tinydylan

I'm currently POC-ing a new way to build the core arbitraries of fast-check (#1631). One of the aim is to be able to shrink easily any entry even some that were not directly generated through normal generators of fast-check. As a consequence, the string generator will be able to receive any string and shrink it to smaller cases. I hope to be able to unlock this issue with this rework. (for the moment just a POC, it may never be merged).

The consequence will be that magic strings like proto could be shrunk by fast-check, which is not the case today if the string was not produced by it.

[dubzzz]

Will be the default for strings starting in v3.1