segurança de arquivos

[criatividade zero 17]

A falha que havia no IPB é exatamente o que estamos comentando:

1. Alguém faz um upload de um arquivo malicioso.

 

acho que minha duvida não ficou clara

o IPB permitia o envio de arquivos, ate ai ok, tudo que entra deve ser tratado

 

um injection sem tratamento ate permite incluir / remover tabelas

mas no caso de submeter um form com algum codigo?

é possivel injetar algum codigo via form para executar a criação de um arquivo contendo dados?

de vez em quando aparece alguem no forum falando de tentativas de invasão com o famoso eval( base64_encode( ... ))

 

essa é a duvida

tratamento contra sqlinjection é moleza, mas as outras tentativas via form eu não sei ate onde vão

[João Batista Neto 448]

acho que minha duvida não ficou clara

 

Ficou sim, amigo. Acho que eu que não consegui ser claro na explicação.

 

é possivel injetar algum codigo via form para executar a criação de um arquivo contendo dados?

 

Sim, é possível.

 

O código contendo o código malicioso pode ser executado pela própria aplicação ou pelo usuário de forma remota.

 

A pessoa que lançar o ataque vai testar sua aplicação, se perceber que existe a vulnerabilidade, ela vai utilizá-la.

 

:seta: http://www.imperva.com/docs/HI_Remote_File_Inclusion.pdf

:seta: http://labs.neohapsis.com/2008/07/21/local-file-inclusion-%E2%80%93-tricks-of-the-trade/

 

Pesquise por Local File Inclusion (LFI) e Remote File Inclusion (RFI), você vai encontrar milhares de conteúdos.

[criatividade zero 17]

bacana João, vou ler a respeito

qualquer coisa volto pra dizer o que aconteceu

 

meu maior medo é entrar um arquivo 'acessivel' ou alguma pagina sofrer alteração

mantenho um log total do que acontece, mas se for um acesso direto e contornar o centro do processo, ai fuu, fico sem saber o que ocorre

 

[]s

[João Batista Neto 448]

Como você vai perceber depois de pesquisar, até logs são modificáveis, então não confie neles caso sofra um ataque.

 

Uma pergunta que você deve fazer a si mesmo é a seguinte: "Quais tipos de arquivos vou permitir?"

 

Se sua aplicação permite apenas imagens (jpg, png, etc) ou documentos (pdf, doc, etc), basta que você verifique o tipo do arquivo recebido. Se não for o esperado, apague o arquivo e notifique o usuário.

 

Veja :seta: http://code.imasters...-de-um-arquivo/

[criatividade zero 17]

Se sua aplicação permite apenas imagens (jpg, png, etc) ou documentos (pdf, doc, etc), basta que você verifique o tipo do arquivo recebido. Se não for o esperado, apague o arquivo e notifique o usuário.

 

meu upload é super restrito, vai para uma pasta apenas os tipos permitidos

depois vou fazer um check na adm para percorrer as pastas e retornar tuqo que for diferente de .php, .log e .txt

além de um log externo com as datas de criação e edição dos arquivos para comparar :)

segurança nunca é d+

 

mas a validação de upload é o de menos, o problema é o caso de injetarem via form.

so de pensar na possibilidade me da calafrios

 

o tratamento de sqlinjection é quase sempre o mesmo, os termos da query, o plik ('), etc

a prevensão de injection de outros tipos tem alguns comandos similares que possam servir como um alerta na hora de enviar o form?

 

tipo:

validacao_sqlinjection( $form )

validacao_fileinjection( $form )

[Andrey Knupp Vital 136]

Hey ..

Contra SQLInjection, eu nunca tive problemas, pois o PDO fornece funções que evita o risco de injection, você já viu os binds ou já usou PDO ?

 

:seta: http://php.net/manual/en/pdostatement.bindparam.php

:seta: http://www.php.net/manual/en/pdostatement.bindvalue.php

[criatividade zero 17]

nao nao... o problema nao é com sqlinjection, foi apenas um exemplo

 

ao submeter o form filtra o anti-sqlinjection

validacao_sqlinjection( $form )

 

 

validacao_fileinjection( $form )

esse seria uma verificação, contra injection de qualquer outra natureza

um filtro com termos que possivelmente causariam problema, como os termos do sqlinjection( ', or, drop, table...)

[Andrey Knupp Vital 136]

O Cara pode mandar um arquivo com o 'nome' table .. entre outras keywords SQL .. isso não é errado, você tem que fazer seu filtro de outra maneira.

[criatividade zero 17]

isso ja foi citado no post #25

o problema é injetar codigos via form

você quais são os termos problemáticos?

 

como citei no exemplo de sqlinjection, ', or, drop, table... são os termos que se previne contra injectio no sql

ha outros termos que podem causar maiores problemas e precisam de filtro

[William Bruno 1501]

caras.. qnta confusão.

 

antes de resolver um problema, pensem como o problema acontece?

se você não conhecer, não é capaz de resolver. Foque no doença e não na dor de cabeça.

 

remover palavras não é a solução! Isso é corromper dados!

[Fvox 0]

Certo, o programador escrever o formulário, e o formulário tem vulnerabilidade, mas esse programador é novato, não conhece essa falha, obviamente, ele quem criou a falha ? ¬¬

Lógico que não, ele apenas criou algo que ele era 100% confiante, mas desconhecendo certa falha, então ele não criou, alguém descobriu e não falou pra ele, vamos dizer assim.

 

Foi por isso que eu citei o "com intenção ou não, quem cria aplicativos vulneráveis é o programador. É ele que escreve os códigos, é ele que os escreve com vulnerabilidade.

 

mas sobre a duvida...

 

editando as permissões é possivel evitar que entre algum arquivo fora da pasta 'upload' e ele edite, altere e remova pastar e paginas fora da pasta onde está?

 

trabalhando com htaccess, jogando os arquivos upados fora da pasta public, torna inacessivel o arquivo?

 

"Permissões" é uma palavra muito vaga para isso. Depende do que você definiu.

Você pode editar as permissões do diretório onde o script é upload, ativar o safe_mode, possuir um kernel relativamente atualizado... Sempre há bypasses pra tudo isso.

O melhor filtro é script-side mesmo.

Escalação de privilégio não é fácil, mas também não é difícil e não podemos confiar depois que o sujeito já está dentro da box.

[criatividade zero 17]

remover palavras não é a solução! Isso é corromper dados!

quem disse que eu vou remover palavras???

[Andrey Knupp Vital 136]

quem disse que eu vou remover palavras???

:seta:

 

esse seria uma verificação, contra injection de qualquer outra natureza

um filtro com termos que possivelmente causariam problema, como os termos do sqlinjection( ', or, drop, table...)

 

Se você não vai remover, explique a utilidade de uma função pra filtrar essas palavras.

[criatividade zero 17]

caras.. qnta confusão.

 

você filtra a agua quando bebe, ou remove a agua da torneira?

 

eu disse filtrar, e não remover

são coisas muito diferentes, eu nao removo nenhuma palavra que possa causar problema com sql injection, apenas trato as palavras de um modo certo.

 

se meu formulario subeteu palavras tipo system, eval ou sei la mais o que que possa causar algum problema, eu vou filtrar, mas nao vou remover

 

 

apenas dei exemplo de que com as palavras certas em mãos, pode-se saber o problema que possa ter

', or, drop, table e afins representam problema para o sql

system, eval e outras que nao conheco podem dar outros problemas

[Andrey Knupp Vital 136]

Certo, você filtra, e daí .. ? que modo certo ?

[William Bruno 1501]

eu vou filtrar, mas nao vou remover

okay, "achando" que eval pode dar problemas, e ai? oq você faz ?

oq exatamente você chama de filtrar ?

 

entrou a string:

"Estamos aqui fazendo um teste de eval para ver oque acontece"

 

me diga qual será a sua saída.

[criatividade zero 17]

entrou a string:

"Estamos aqui fazendo um teste de eval para ver oque acontece"

 

me diga qual será a sua saída.

 

se você nao reparou, este é o intuito do topico

como disse, apenas trato as sql injection pq as conheco e não sei os outros termos problematicos

mas ja que é a prova de fogo e exemplos parecem necessários...

 

ex1: contra sql injection

entrou a string:

"o surfista dropou a onda"

meu filtro vai ver a string e vai chegar a conclusão que não ha problema pq o termo DROP nao esta fora de contexto

 

ex2: contra outros termos

entrou a string:

"o nome do bandido era evaldivio"

a saida será o exemplo anterior

 

ex3: contra outros termos

entrou a string:

"o nome do bandido era 'or''='"

isso nunca entrará no sistema

 

 

como podem ter visto no exemplo, eu nao removo palavras, eu trato analisando o contexto

remover termos é trabalho de porco, por isso termos são importantes para eu saber a situação e pode trata-las com o devido 'respeito'

[William Bruno 1501]

eu nao removo palavras, eu trato analisando o contexto

isso também é desnecessário amigo, e é isso que estou tentando te falar.

 

mesmo que você crie um super algoritmo para entender o contexto, e só remover, se entrar algo absurdo, e sem contexto, essa trabalheira toda não é necessária.

 

Volto no que eu disso no meu outro post:

-> Quando é que se um cara enviar um código php por um input text, q esse código será executado?

 

 

somente qndo você entender qndo e como isso é possível, é que você será capaz de tratar. Filtrar as palavras a sua forma, não é uma solução "bonita", ou que "funcione sempre".

pois está tentando fazer de uma forma complicada, algo que não era necessário.

[Andrey Knupp Vital 136]

apenas trato as sql injection pq as conheco

Tem várias, o 'or' , '=' .. são as mais fraquinhas, e pra te falar verdade, injection é coisa que inventam todo dia, não tem como prever todas.

 

ex1: contra sql injection

entrou a string:

"o surfista dropou a onda"

meu filtro vai ver a string e vai chegar a conclusão que não ha problema pq o termo DROP nao esta fora de contexto

E como você sabe que ele tá fora de contexto, porque não tem o 'table' ou 'schema/database' ou porque não tem espaços a direita e esquerda ?

 

ex2: contra outros termos

entrou a string:

"o nome do bandido era evaldivio"

a saida será o exemplo anterior

Mesma pergunta feita no exemplo anterior.

 

ex3: contra outros termos

entrou a string:

"o nome do bandido era 'or''='"

isso nunca entrará no sistema

Podia entrar, 'or' '=' é uma string normal delimitada por aspas, o cara pode mandar um texto dando uma referencia mais específica à uma palavra, utilizando apostrofo, ou aspas simples / dupla.

 

como podem ter visto no exemplo, eu nao removo palavras, eu trato analisando o contexto

remover termos é trabalho de porco, por isso termos são importantes para eu saber a situação e pode trata-las com o devido 'respeito'

Isso aí, remover termos é trabalho de porco( nesse caso )

[criatividade zero 17]

isso também é desnecessário amigo, e é isso que estou tentando te falar.

 

mesmo que você crie um super algoritmo para entender o contexto, e só remover, se entrar algo absurdo, e sem contexto, essa trabalheira toda não é necessária.

 

o meu projeto é multi idioma, seria impossivel eu remover as palavras so pq estão em ingles, alias, como um ingles escreveria mesa sem ser table?

 

entrada:

My table broke

saida:

My broke

 

qual o sentido disso?

remover palavras fora de um contexto, ou nega-las?

por isso nao posso remover - nao é pt-br apenas

 

 

Volto no que eu disso no meu outro post:

-> Quando é que se um cara enviar um código php por um input text, q esse código será executado?

nao entendi bem, mas creio que seja na hora se inserir na database ou escrever um xml

 

E como você sabe que ele tá fora de contexto, porque não tem o 'table' ou 'schema/database' ou porque não tem espaços a direita e esquerda ?

obvio que não, nao estou desprendendo tempo em vão

 

 

injection é coisa que inventam todo dia, não tem como prever todas.

não isoladamente