Como posso ter certeza de que estou protegido contra caminhos relativos como:
Tenho recebido esses registros recentemente e, apesar de saber que esse não será eficaz, estou interessado em como me proteger contra essa classe de ameaças.
(usando php5, apache2, debian)
Várias opções diferentes;
1) Algum tipo de expressão preg_replace para remover coisas como pontos duplos, o hífen ondulado (não me lembro o que chamou, mas parecem ~), caminhos que começam com um / etc.
2) Crie um conjunto de URLs / caminhos permitidos que possam ser abertos em ether usando reg-exps ou in_array, etc.
3) Ative o modo seguro PHP e defina open_basedir ou chroot PHP / Apache para que eles não possam abrir nenhum arquivo fora dessa árvore
Eu sugiro usar o chroot:
P.S: limpeza dos parâmetros GET / POST / ... & entrada em geral, claro, ajuda também;)
A única resposta que é 100% segura contra esse tipo de ataque é nunca permitir que a entrada do usuário toque nos comandos que acessam o sistema de arquivos. Não fopen($_GET['foo']) , não include($_POST['bar']) , nem mesmo mkdir($_COOKIE['baz']) . Nunca. Período. Sem desculpas.
Se você precisar usar a entrada do usuário para selecionar um arquivo do sistema de arquivos, use a entrada do usuário em uma consulta ao banco de dados (depois de sanear a consulta do banco de dados, é claro, para se defender contra injeção SQL) ou execute-o switch declaração; Em ambos os casos, você deve usar valores hard-or-soft-coded e known-safe para os nomes de arquivos reais, never nenhuma variação de a entrada do usuário em si.
Tudo em $ _POST, $ _GET, $ _COOKIES, $ _REQUEST, e até $ _FILES (exceto 'tmp_name' e 'error' - sim, 'type' é a entrada do usuário!) é entrada do usuário que você tem precisamente zero controle. Então não confie, nunca. Mesmo alguns valores em $ SERVER (por exemplo, os valores 'HTTP *') são introduzidos pelo usuário! Não deixe nenhum desses valores em qualquer lugar perto do seu sistema de arquivos, e não os deixe em qualquer lugar perto de seu banco de dados sem primeiro escapar deles (por exemplo, mysql_real_escape_string() ) ou vinculá-los a declarações preparadas (se você estiver usando o PDO). / p>
Sim, você pode higienizar a entrada, mas e se você esquecer alguma coisa? E se você esquecer que o caractere til (~) tem um significado especial em um sistema * nix? E se você fizer um trabalho perfeito para sanear seu servidor web Linux, mas depois mudar para um servidor Windows? E se algo que você nunca previu mudar em seu ambiente - como um novo caractere especial? E assim e assim por diante. A opção mais segura, a maioria das opções à prova de futuro, é simplesmente não permitir a entrada do usuário perto do seu sistema de arquivos.
Uma coisa a ter em mente, porém, é que há muitos aplicativos da web disponíveis, que são vulneráveis aos tipos de ataques que você está vendo em seus registros. Isso não significa que qualquer coisa no seu servidor seja: muitas vezes, os script kiddies apenas apontarão sua última descoberta em qualquer servidor que encontrarem, sem se preocupar em descobrir se estão vulneráveis . Se você não está vulnerável, você não precisa se preocupar com esse ruído de fundo.