tc39/proposal-symbol-protoProposta TC39 para mitigar a poluição de protótipos
Autores: Santiago Díaz (Google)
Champion: Shu-yu Guo (Google)
Estágio: 1
freeze, seal e preventExtensions
Esta proposta procura mitigar uma vulnerabilidade em nível de linguagem conhecida como poluição de protótipo (prototype pollution) com um mecanismo que complementa as primitivas de congelamento e um mecanismo para tornar a maioria das bases de código compatíveis com ela. Ela descreve um recurso opt-in que torna os protótipos disponíveis somente por meio de APIs de reflexão. Com isso, a declaração obj[key] não consegue mais acessar protótipos. Bases de código compatíveis com esse recurso são mais intencionais na forma como usam protótipos.
Vulnerabilidades de PP permitem que atacantes manipulem objetos que eles não controlam ou aos quais não têm acesso em tempo de execução. Essa primitiva de 'ação fantasmagórica à distância' pode ser usada para alterar a forma de outros objetos e sobrescrever suas propriedades, contaminando assim objetos no runtime.
Objetos contaminados invalidam as premissas subjacentes de um código que de outra forma seria seguro/correto e podem levar à execução arbitrária de código e a uma ampla gama de outros problemas de segurança em bases de código JS. Bugs de poluição de protótipo se manifestam com frequência em aplicações web, mas também afetam runtimes JS fora da web.
As propriedades de objetos em JS podem ser gravadas por qualquer código que possa referenciá-las. Em particular, se muitos objetos dependem de uma propriedade compartilhada, qualquer um deles pode efetuar mudanças em todos os outros.
Uma propriedade especial do PP é que ele é um ataque somente com dados, permitindo que a execução de código seja obtida puramente por meio de dados. Por exemplo, veja o seguinte código vulnerável e um exploit correspondente:
// source is attacker-controlled
function merge(target, source) {
for (let key in source) {
if (typeof source[key] === 'object') {
if(target[key] === undefined) {
target[key] = {};
}
target[key] = merge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
return target;
}
// User input comes as a string
const userSuppliedObj = JSON.parse('{"__proto__": {"polluted": true}}');
// Trigger prototype pollution
merge({}, userSuppliedObj);
// Create a brand new object
const newObj = {};
// Has polluted property
console.log(newObj.polluted); // true
Observe que o exploit consegue contaminar a criação de novos objetos sem injetar nenhum código estranho.
Por causa dessa propriedade especial, mitigações modernas contra problemas de execução de código — como a Content Security Policy ou Trusted Types — ficam aquém da proteção contra PP, pois elas se concentram em impor a proveniência do código.
Nota: ataques somente com dados são relevantes em situações em que o código executado na VM é confiável e a execução arbitrária de código tem impacto de segurança.
freeze, seal e preventExtensionsAs primitivas de congelamento existentes sofrem de problemas de design significativos que tornam improvável sua adoção em larga escala. Elas podem ser úteis para usuários especialistas, mas não são adequadas para serem usadas pela maioria dos desenvolvedores, que razoavelmente esperam que os protótipos sejam mutáveis:
As APIs de congelamento sofrem do erro de sobrescrita e de outras inconsistências que introduzem bugs em bases de código existentes, fazendo-as lançar erros ou, pior, falhar silenciosamente em modo sloppy. Uma investigação anterior sobre o erro de sobrescrita concluiu que ele é acionado em ~10% das bases de código em modo estrito e 20% em modo sloppy. A investigação foi abandonada logo em seguida.
As APIs de congelamento dão aos desenvolvedores a pesada responsabilidade de saber quais protótipos devem ser congelados para manter uma base de código segura, partindo do princípio de que os desenvolvedores são especialistas em segurança. Essas APIs descrevem o quê, mas não o como da segurança. Congelar Object certamente não é suficiente, pois muitos exploits abusam de Array. E Error, Date, Reflect ou Proxy? Ou futuros tipos nativos? As APIs de congelamento não oferecem respostas para essas perguntas.
As APIs de congelamento assumem um ponto de congelamento estável: um momento fixo em tempo de execução em que os protótipos já se estabilizaram e podem ser congelados. Na prática, esse ponto é volátil e muda ao longo do tempo em bases de código em desenvolvimento ativo. Embora seja possível encontrar esse ponto em muitas aplicações hoje, a adição de novas dependências, polyfills, mudanças na estrutura do código e recursos avançados como hotswapping e ferramentas de desenvolvimento fazem dos pontos de congelamento um alvo móvel.
As APIs de congelamento não conseguem proteger toda a cadeia de protótipos. Em JS, objetos podem ser adicionados ou removidos da cadeia de protótipos a qualquer momento. Para proteger toda a cadeia, é preciso lembrar sempre de congelar os objetos adicionados a ela, um processo propenso a erros. Quando são removidos da cadeia, não é mais possível descongelá-los.
Em resumo: um recurso que expõe os protótipos somente a APIs de reflexão. Se os protótipos não fossem disponibilizados por meio de propriedades como __proto__ ou prototype, não estariam expostos a problemas somente com dados.
Isso é melhor compreendido por meio de um exemplo: a declaração obj[one][two] = value é vulnerável a PP por meio de obj.__proto__.polluted. Se alguém deletar a propriedade Object.prototype.__proto__, a mesma declaração não é mais vulnerável, pois não consegue usar o único outro caminho para alcançar protótipos, que é obj.constructor.prototype.polluted. Observe que a propriedade prototype não pode ser deletada.
Esta proposta pode ser implementada fornecendo APIs de reflexão e criando um novo recurso de encapsulamento opt-in que deleta as propriedades dos protótipos. Uma descrição de cada etapa vem a seguir.
__proto__ é um nome de propriedade legado que pode ser deletado, mas o slot interno por trás dele ainda pode ser lido por meio de Object/Reflect.getPrototypeOf e gravado por meio de Object/Reflect.setPrototypeOf, o que simplesmente continuará tornando essa propriedade acessível a código já em execução.