Prevenção de injeção de códigos
Ao gerar conteúdos em uma linguagem ou sintaxe específica, é importante que os dados inseridos no conteúdo que sejam originados do usuário sejam devidamente tratados para evitar a injeção de códigos ou comandos maliciosos. Nos cenários de uso mais comuns do sistema, essa preocupação deve ser levada em consideração principalmente na construção de conteúdos HTML apresentados ao usuário e na geração de expressões SQL a serem executadas no banco de dados. No entanto, qualquer geração de arquivo ou documento está passível de ataques, como a criação de um XML de um documento fiscal eletrônico.
Há diversas técnicas para prevenir a injeção de códigos a partir de dados originados do usuário, sendo as mais comuns:
- Sanitização: remoção dos comandos indesejados que foram inseridos em um conteúdo informado pelo usuário.
- Escape: substituição de caracteres de controle ou comandos por uma versão textual que não é processada pelo cliente que receberá o conteúdo.
- Parametrização: uso de identificadores de parâmetros em vez de valores literais, permitindo que os valores dos parâmetros sejam informados separadamente, sem alterar o documento ou a expressão gerada.
Cada linguagem ou sintaxe pode permitir o uso de uma ou várias dessas técnicas, mas a implementação delas é necessariamente específica para a linguagem ou sintaxe desejada. Uma API de escape para HTML é diferente de uma para SQL, pois as sintaxes dessas duas linguagens são distintas e requerem tratamentos especializados. Portanto, as APIs a serem utilizadas devem levar em consideração o formato do conteúdo a ser gerado, não existindo uma API única que possa trata qualquer cenário de uso possível de um dado informado pelo usuário.
Essas técnicas devem ser empregadas preferencialmente no momento da construção dos conteúdos, sempre que forem utilizados dados de origem não confiável. É recomendado que os dados oriundos de variáveis de processo, globais, campos de grade ou até de registros da base de dados sejam sempre tratados como não confiáveis, pois o processo que está utilizando aquele conteúdo não tem como garantir que o dado foi tratado corretamente na entrada. Por exemplo, registros da base de dados podem ter sido inseridos por rotinas customizadas inseguras ou podem até ter sido inseridos por outros sistemas. Também é importante observar que não é possível tratar um dado no momento da sua entrada de forma a tornar o seu uso seguro para qualquer documento ou expressão que faça uso dele, pois as sintaxes podem ser distintas, requerendo tratamentos diferenciados.
A seguir são apresentadas as APIs e estratégias do sistema para prevenir ataques de injeção de código nas linguagens HTML, SQL e JavaScript.
Prevenção de injeção de scripts em HTML
O sistema possui as seguintes APIs que podem ser utilizadas para prevenir ataques de injeção de scripts em conteúdos HTML:
-
toHtmlString: função de escape que substitui os caracteres que iniciam e finalizam as tags (< e >) pelas entidades de caracteres equivalentes (< e >). -
HtmlSanitizer: classe que permite a sanitização de conteúdos HTML, eliminando tags e atributos que podem ser utilizados para injetar scripts.
Essas APIs devem ser utilizadas ao gerar conteúdos HTML a serem apresentados ao usuário, mas, a fim de evitar ataques de reflexão, o Web Framework também faz uso delas de forma automática quando são utilizadas as seguintes propriedades e métodos:
-
Anchor.prototype.hint -
Anchor.prototype.label -
Button.prototype.label -
Field.prototype.label -
Field.prototype.group -
Field.prototype.groupName -
Field.prototype.setValue -
FieldGroup.prototype.label -
Grid.prototype.title -
Grid.prototype.help -
Process.prototype.alert -
Process.prototype.title -
Process.prototype.help -
Process.prototype.status -
Process.prototype.confirm -
Process.prototype.prompt -
Process.prototype.showProgress -
Process.prototype.authenticateUser -
Environment.prototype.alert -
Environment.prototype.confirm -
Environment.prototype.prompt -
FormDialog.prototype.title -
Label.prototype.text -
SimpleDialog.prototype.title -
SimpleDialog.prototype.message -
SimpleLayout.prototype.title -
SimpleLayout.prototype.enterpriseName -
SimpleLayout.prototype.headerComplement -
SimpleLayout.prototype.footerComplement -
SimpleLayout.prototype.newRecord -
SimpleLayout.prototype.writeColumn -
SimpleLayout.prototype.writeLink -
SimpleLayout.prototype.path -
SimpleLayout.prototype.end -
Header.prototype.complement -
Footer.prototype.complement -
Column.prototype.hint -
Column.prototype.label
O tratamento automático realizado pelo Web Framework pode ser desativado em alguns componentes, utilizando as seguintes propriedades:
-
Field.prototype.autoSanitize -
FieldGroup.prototype.autoSanitize -
Label.prototype.autoSanitize -
Link.prototype.autoSanitize -
SimpleLayout.prototype.autoSanitize
Prevenção de injeção de SQL
Ao montar expressões SQL, deve ser garantido que os valores concatenados em uma expressão SQL não contenham eventuais expressões maliciosas informadas pelo usuário. Para isso, o sistema disponibiliza as seguintes APIs:
-
toSqlString: função que converte um dado em uma string que pode ser utilizada com segurança como um valor literal em uma expressão SQL. -
toSqlIdentifier: função que converte um dado em uma string que pode ser utilizada com segurança como um identificador, como o nome de uma coluna ou tabela, em uma expressão SQL. -
QueryUtilities: classe que permite a construção de expressões SQL a partir de um conjunto de chaves ou strings.
É importante observar que não há nenhum tratamento automatizado no Web Framework a fim de prevenir a injeção de SQLs, portanto a prevenção de injeção sempre deve ser realizada no momento da construção das expressões SQL.
Prevenção de injeção de códigos JavaScript
De uma forma geral, não devem ser executados códigos JavaScript que possam ter sido originados
direta ou indiretamente por um usuário final, devendo o uso do
eval
ser evitado. Caso o seu uso seja realmente necessário, deve-se garantir que o código executado
sempre seja de uma origem confiável.
As permissões dos usuários finais do sistema também devem ser devidamente configuradas a fim de garantir que esses usuários não tenham acesso aos processos e ferramentas voltadas para os desenvolvedores, pois elas permitem a criação ou modificação dos códigos executáveis do sistema.