Impact
Anyone who is using the default presets and/or does not handle the functionality themself.
Patches
It is impossible to fully guard against this, because users have access to the original raw information. However, as of version 1, if you only access the constrained models, you will not encounter this issue.
Further similar situations are NOT seen as a security issue, but intended behavior.
Workarounds
Fully custom presets that change the entire rendering process which can then escape the user input.
For more information
Even though that I changed all the presets here, the vulnerability is still present throughout. I am using a JSON Schema here for simplicity.
const jsonSchemaDoc = {
$id: 'CustomClass',
type: 'object',
properties: {
'property: any; \n constructor(){console.log("injected")} \n private _temp': { type: 'string' },
}
};
generator = new TypeScriptGenerator(
{
presets: [
{
class: {
property({ propertyName, content }) {
return `private ${propertyName}: any;`;
},
ctor() {
return '';
},
getter() {
return '';
},
setter() {
return '';
}
}
}
]
}
);
const inputModel = await generator.process(jsonSchemaDoc);
This would render
export class CustomClass {
private property: any;
constructor(){console.log("injected")}
private _temp: any;
private additionalProperties: any;
}
Impact
Anyone who is using the default presets and/or does not handle the functionality themself.
Patches
It is impossible to fully guard against this, because users have access to the original raw information. However, as of version 1, if you only access the constrained models, you will not encounter this issue.
Further similar situations are NOT seen as a security issue, but intended behavior.
Workarounds
Fully custom presets that change the entire rendering process which can then escape the user input.
For more information
Even though that I changed all the presets here, the vulnerability is still present throughout. I am using a JSON Schema here for simplicity.
This would render