Quero garantir que todos os dados nos meus plugins / temas sejam tratados com segurança antes de entrar no banco de dados e antes de serem enviados ao navegador. Meu problema é que há situações em que a API lida com a higienização para você - como ao salvar os meta-campos de postagem - e outras onde o autor do plugin / tema é totalmente responsável por fazê-lo - como ao salvar configurações personalizadas.

Para o escopo desta pergunta, não estou preocupado em validar 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 email é válido. Estou preocupado apenas com segurança - por exemplo, escapar de consultas SQL para evitar a injeção de SQL ao salvar no banco de dados ou desinfetar dados que saem para modelos HTML para evitar XSS.

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

Para higienização de entrada, eu 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 os meta-campos de postagem para um tipo de postagem personalizado?

No momento, acabei de pesquisar no Core e ler os tutoriais toda vez que uso uma função para descobrir se ela higieniza ou não, mas isso é propenso a erros e consome muito tempo. Espero 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,

A API valida / higieniza

• Salvando meta meta com update_postmeta()
• Salvando a meta do usuário com update_user_meta()
• Saída de um título de postagem - use a variante contextualmente apropriada de the_title()
• etc

Você precisa validar / higienizar manualmente

• Salvando 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 $wpdb->prepare().
• Saída de variáveis ​​em HTML. Use esc_attr(), esc_html(), etc
• etc

Também estaria interessado em entender por que a API a fornece em determinadas situações, mas não em outras. Suponho que tenha algo a ver com a natureza desconhecida dos dados, mas gostaria de ouvir uma explicação completa.

Existem dois conceitos aqui:

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

A validação é, quase universalmente, exclusivamente sua . Você sabe quais dados você está solicitando de um usuário e quais dados você espera - o WordPress não. A validação seria realizada, por exemplo, no save_postgancho antes de salvá-lo no banco de dados update_post_meta, ou pode ser feita através da especificação de uma função de retorno de chamada na API de configurações, chamada pouco antes do WordPress salvar os dados.

Sanitização é um pouco mais misto. Ao lidar com dados que o WordPress conhece nativamente (por exemplo, o bloco de uma 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 do elemento. Daí WordPress terão funções diferentes para o contexto diferente (por exemplo the_title(), the_title_rss(), the_title_attribute()) - então você precisa usar o caminho certo .

Na maioria das vezes, seu plug-in pode lidar com pós-meta - ou talvez dados de eventos de uma tabela personalizada. O WordPress não sabe para que servem esses dados ou para que servem, portanto, certamente não sabe como torná-los seguros. Isso é com você . Isso é particularmente importante no uso de esc_url(), etc esc_attr(), esc_textarea()para impedir que entradas maliciosas possam incorporar código. Como o WordPress sabe que next_posts()é suposto imprimir um URL para a página, ele se aplica esc_url()- mas com o post meta, por exemplo, ele não sabe que armazena um URL - ou o que você quer fazer com ele (se estiver imprimindo esc_url(), se estiver redirecionando esc_url_raw(). Se estiver dobut - erre no lado da cautela e escape sozinho - 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ê fazer necessidade de garantir que os dados é válido. Mas se estiver usando WordPress API ( wp_insert_post(), update_post_meta()etc), então você não precisa higienizar os dados - porque quando salvar dados a única saneantes que você precisa fazer é escapar instruções SQL - e WordPress faz isso. Se você estiver executando instruções SQL diretas (digamos, para ler / gravar dados de uma tabela personalizada), deverá usar a $wpdbclasse para ajudá-lo a limpar suas consultas.

Eu escrevi este post sobre sanitização e validação de dados que você pode achar útil - falo sobre o que é esperado de você a esse respeito.

Não tenho certeza se é tão 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 os métodos $ wpdb->. Todos os dados $ _GET e $ _POST devem ser limpos.

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

Portanto, em conclusão, se houver uma função do WordPress, use-a, caso contrário, desinfete suas variáveis ​​e insira você mesmo.

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