Eu descobri hoje, por meio de um XSS relatado externamente, que o Jinja não ativa o escape automático por padrão. Este é um padrão perigoso, ainda mais perigoso pelo fato de que muitas pessoas são apresentadas ao Jinja por meio de seu conhecimento prévio dos modelos do Django, que têm o escape automático habilitado por padrão desde 2007.
Olhando pela internet, parece que esse fato não é muito conhecido. Na verdade, eu até encontrei livros (Python 3 Object Oriented Programming, capítulo 12, cc @buchuki) que recomendam o uso de jinja2 para sites e deixam o escape automático desativado. Uma amostra aleatória de projetos do Github também mostra que a maioria das pessoas não adiciona autoescape = True ou a extensão autoescape a seus projetos.
Embora eu entenda que provavelmente seria difícil migrar para um padrão mais seguro nesse ponto, a documentação deve pelo menos deixar óbvio que o escape automático está desativado por padrão. Talvez adicione autoescape = True a todos os exemplos que criam um objeto jinja2.Environment e / ou adicione uma seção logo no início da documentação.
Jinja não é apenas para HTML, mas um mecanismo de template de uso geral. Acho que a maioria das pessoas usa Jinja no Flask, que ativa o escape automático por padrão para modelos HTML. Se você integrar um mecanismo de modelo em sua própria estrutura, deverá ler a documentação sobre como usá-lo com segurança.
Dito isso, acho que ser muito claro nos documentos que você provavelmente deve usar autoescape ao gerar HTML é uma boa sugestão.
Eu presumiria que a maioria dos principais frameworks acertou (mais olhos, menos bugs, etc.), mas também há muitos projetos menores integrando o Jinja manualmente que cometem esse erro.
E para ser franco, a documentação de Jinja é muito pobre nesse assunto. Aqui está o que você vê pela primeira vez ao abrir a documentação do Jinja:
Jinja2 é uma linguagem de modelos moderna e amigável para o designer para Python, modelada a partir dos modelos do Django. É rápido, amplamente usado e seguro com o ambiente de execução de modelo em sandbox opcional:
"modelado a partir dos templates do Django" e "seguro" pode levar a pensar que ele possui os recursos de segurança dos templates do Django, como autoescaping.
Então, um exemplo, que é HTML. E logo depois, na lista de recursos:
poderoso sistema de escape HTML automático para prevenção de XSS
O que não menciona que é opcional e não habilitado por padrão.
A página de documentos "Uso básico da API" não mostra o escape automático habilitado, mas também não mostra o HTML, então acho que está tudo bem. Mas então, quando você for para a página "Noções básicas" da
from jinja2 import Environment, PackageLoader
env = Environment(loader=PackageLoader('yourapplication', 'templates'))
template = env.get_template('mytemplate.html')
print template.render(the='variables', go='here')
O primeiro exemplo é vulnerável a XSSes triviais. As pessoas estão certas em ficarem confusas.
Parece um bom candidato para uma solicitação de pull :)
Não podemos desligar isso agora sem quebrar o código de todos. No entanto, estou feliz em atualizar os documentos de acordo. Vou fechar isso como um wontfix, mas fique à vontade para abrir um PR para atualizações de documentação.
Comentários muito úteis
Parece um bom candidato para uma solicitação de pull :)