Em quais contextos os plug-ins são responsáveis pela validação / limpeza de dados?

15

Eu quero ter certeza de que todos os dados em meus plugins / temas são tratados com segurança antes de entrar no banco de dados e antes de serem enviados para o navegador. Meu problema é que há situações em que a API lida com a limpeza para você (por exemplo, ao salvar campos meta meta) e outras em que o autor do plug-in / tema é totalmente responsável por fazer isso - por exemplo, ao salvar configurações personalizadas. >

Para o escopo desta pergunta, não estou preocupado com a validação de dados no nível do domínio. Por exemplo, verificar se um campo Idade em um formulário está entre 0 e 120 ou se um endereço de e-mail é válido. Estou preocupado apenas com a segurança, por exemplo, evitar consultas SQL para evitar a injeção de SQL ao salvar no banco de dados ou limpar os dados gerados pelos modelos HTML para evitar o XSS.

Para sanitização de saída, eu sei que você sempre precisa usar funções como esc_html() e esc_attr() ao fazer o eco das variáveis em modelos HTML. Mas, e quando usar as tags de modelo ? Todos eles já higienizam a saída? Em caso afirmativo, para qual contexto (HTML geral, atributos de tags, etc)? Algumas funções têm variantes para diferentes contextos (como the_title_attribute() , mas a maioria não o faz.

Para sanitização de entrada, sei que preciso usar $wpdb->prepare() ao fazer consultas manuais, mas e quando usar a API de configurações para criar uma página de configurações de plug-in ou salvar pós meta campos para um tipo de postagem personalizado?

Neste momento, andei pesquisando o Core e lendo tutoriais toda vez que uso uma função para descobrir se ela limpa ou não, mas isso é propenso a erros e consome muito tempo. Eu estou esperando encontrar algum tipo de lista abrangente de todas as situações possíveis e se a API lida com isso ou não. por exemplo,

API valida / limpa

  • Salvando pós meta com update_postmeta()
  • Salvando meta de usuário com update_user_meta()
  • Como gerar um título da postagem - use a variante contextualmente apropriada de the_title()
  • etc

Você precisa validar / higienizar manualmente

  • Salvando as opções de plug-in com a API de configurações. Passe um retorno de chamada como o terceiro parâmetro de register_setting() .
  • Consultas diretas ao banco de dados: envolva a consulta em $wpdb->prepare() .
  • Saída de variáveis em HTML. Use esc_attr() , esc_html() , etc
  • etc

Eu também estaria interessado em entender por que a API fornece isso em certas situações, mas não em outras. Estou assumindo que tem algo a ver com a natureza desconhecida dos dados, mas adoraria ouvir uma explicação completa.

    
por Ian Dunn 06.09.2012 / 21:48

2 respostas

15

Existem dois conceitos aqui:

  • validação - certificando-se de que os dados são válidos , ou seja, um inteiro é um inteiro, uma data é uma data (no formato correto, etc.). Isso deve ser feito antes de salvar os dados.
  • higienização - tornando a data segura para seu uso no contexto atual (por exemplo, escapando de consultas SQL ou escapando HTML na saída).

A validação é, quase universalmente, exclusivamente para você . Você sabe quais dados está solicitando de um usuário e sabe quais dados está esperando - o WordPress não. A validação seria executada, por exemplo, no gancho save_post antes de salvá-lo no banco de dados com update_post_meta , ou pode ser feito especificando uma função de retorno de chamada na API de configurações, chamada pouco antes do WordPress salvar os dados. p>

A sanitização é um pouco mais mista. Ao lidar com dados que o WordPress conhece nativamente (por exemplo, um bloco de postagem), você pode ter certeza de que o WordPress já tornou os dados seguros. No entanto, 'seguro' depende do contexto; o que é seguro para uso em uma página, não é necessariamente seguro como um atributo de elemento. Portanto, o WordPress terá diferentes funções para diferentes contextos (por exemplo, the_title() , the_title_rss() , the_title_attribute() ) - então você precisa use o caminho certo .

Na maioria das vezes, o seu plug-in pode lidar com dados de pós-meta ou talvez de eventos de uma tabela personalizada. O WordPress não sabe o que são esses dados ou para que servem, portanto, certamente não sabe como torná-los seguros. Isso depende de você . Isso é particularmente importante no uso de esc_url() , esc_attr() , esc_textarea() etc para evitar que entrada maliciosa seja capaz de incorporar código. Como o WordPress sabe que next_posts() deve imprimir uma url para a página, ele aplica esc_url() - mas com o post meta, digamos, ele não sabe que ele armazena uma URL - ou o que você quer fazer com ele (se imprimindo, esc_url() , se redirecionando esc_url_raw() . Se no dobut - errar do lado da cautela e da fuga você mesmo - e faça isso o mais tarde possível.

Finalmente - e quanto a salvar dados? Você precisa torná-lo seguro, então? Como mencionado, você faz precisa ter certeza de que os dados são válidos. Mas se você estiver usando a API do WordPress ( wp_insert_post() , update_post_meta() etc), não precisará limpar os dados - porque ao salvar os dados, o saneamento básico que você precisa fazer é escapar das instruções SQL - e o WordPress faz isso. Se você estiver executando instruções SQL diretas (digamos, para ler / gravar dados de uma tabela personalizada), use o $wpdb class para ajudar você a sanear suas dúvidas.

Eu escrevi esta postagem de blog sobre validação e validação de dados a> que você pode achar útil - nele eu falo sobre o que é esperado de você a esse respeito.

    
por Stephen Harris 07.09.2012 / 01:06
0

Não tenho certeza se ele é completo, mas com qualquer plug-in ou tema, a entrada do usuário deve ser higienizada. As operações do banco de dados devem ser feitas usando o arquivo $ wpdb- > métodos. Todos os dados $ _GET e $ _POST devem ser limpos.

Esta é mais uma prática recomendada para programação PHP do que o WordPress.

Então, em conclusão, se houver uma função do WordPress, use-a, se não, limpe suas variáveis e entradas você mesmo.

Se eu fosse muito vago, faça uma pergunta mais específica.

    
por Ciprian 06.09.2012 / 23:06