PHP + MYSQL + HTML tags

[nmb]

Olá pessoal!

Estou com um problema que é o seguinte.

Tento a variável $html com o conteudo:

$html  = '<table border="0" cellpadding="0" cellspacing="0" width="100%">';
$html .= '<tr><td width="100%">Olá!</td></tr>';
$html .= '</table>';

pretendo gravar no bd da seguinte forma:

mysql_query("INSERT INTO `tabela` ( `id` , `html` ) VALUES ( '$id', '$html' )");

mas isto causa um erro de php porque a variável $html contem caracteres " os quais se confundem com os da função mysql_query("");

Alguem sabe como colocar o php a ignorar os tags html?

obg!

[pedrotuga]

mysql_real_escape_string

http://se2.php.net/mysql_real_escape_string

Mas aconselho-te a leres um pouco sobre como 'escapar' caracteres especiais, estás a mergulhar num pantao de falhas de segurança ao andares com conteudo html para trás e para a frente na tua base de dados.

Estas situações que 'confundem' a função mysql_query() têm na verdade um nome: sql injections

[cyclop]

Tu decide-te, de um lado usas aspas, e de outro usas plicas...

[pedrotuga]

Tu decide-te, de um lado usas aspas, e de outro usas plicas...

Isso não é problema, dependendo da situação pode ser mais conveninete usar aspas ou plicas ou mesmo acentos

[nmb]

Pois é isso mesmo. Vou seguir o conselho e dedicar-me a uma leitura e teste sobre esse tema.

Necessito de usar isto pk estou a criar um CMS com includes de richtext editor os quais estou a guardar na base dados.

O curioso é que este problema so se torna mais sério quando trabalho ja no servidor em linux.

Em windows e em localhost este problema não acontece.

Falas em "estás a mergulhar num pantao de falhas de segurança" devido a quê? existe alguma perda de informação ou de segurança na estrutura da base de dados ao usar estes recursos?

Como é que os outros sistemas de CMS resolvem este assunto? ...ou até mesmo o phpmyadmin?

Obrigado pela ajuda

[Battousai]

Já que estás no início do teu projecto,sempre podes começar a usar o AdoDB que ele trata desses problema automaticamente e resolve os problemas básicos de injecção de sql.

[nmb]

O projecto já esta evoluido. Sempre me tenho deparado com o problema mas tenho-o resolvido da forma não da melhor forma.

Por isso estou agora a tentar resolver definitivamente.

Os curiosos podem testar o cms aqui: http://www.semcabo.pt/?lv1=mnpri&lv2=32

[pedrotuga]

O problema é que estás a permitir que se usem coisas como aspas, barras, sinais <,>, =, etc.

Ao fazeres isso estás a dar aso a que hackers arranjem esquemas marados para inserir comandos SQL na tua aplicação injectando o SQL nas tuas variaveis.

Podem por exemplo apagar-te a base de dados toda, ou fazer um sump desta e ter acesso a todos os dados, basicamente podem fazer qq coisa que o sql permita.

Por isso os dados devem ser todo "desinfectadinhos".

Mesmo que afastes todas as possibilidades de injecção de SQL, se permitires o uso de html estás tambem a dar aso a outro perigo que se chama cross site scripting.

Faz download da revista programar Nº 11 e lê o artigo chamado "vulnerabilidades das aplicações web" escrito pelo djthyrax, é uma boa forma de começar.

http://www.revista-programar.info/front/edition/11

[joaoqalves]

Já que estás no início do teu projecto,sempre podes começar a usar o AdoDB que ele trata desses problema automaticamente e resolve os problemas básicos de injecção de sql.

verdade 🙂 O ADOdb é a solução para os teus problemas, lê o artigo da edição 12 da revista programar 😄

[pedrotuga]

Acho que voces se estão a precipitar.

Isso tem algum filtro contra cross site scripting?

[Battousai]

Acho que voces se estão a precipitar.

Isso tem algum filtro contra cross site scripting?

só me estou a referir quanto ao sql. quanto ao resto, depende do que ele queira fazer e de como quer validar...

[djthyrax]

Tu decide-te, de um lado usas aspas, e de outro usas plicas...

Isso é bonito e aplica-se apenas quando o utilizador não influencia de forma alguma as querys (input de dados, pedido de dados, etc)... Ou seja, nem sequer metam essa hipótese em cima da mesa: basta alterar o código e não ter isso em conta que ficas logo agarrado.

Pois é isso mesmo. Vou seguir o conselho e dedicar-me a uma leitura e teste sobre esse tema.

Nem sabes o bem que estás a fazer ao ler um pouco sobre segurança. 🙂

O curioso é que este problema so se torna mais sério quando trabalho ja no servidor em linux.

Em windows e em localhost este problema não acontece.

Um problema é sempre sério, seja ele qual for. Besides, o SO não muda o quer que seja aqui.

Falas em "estás a mergulhar num pantao de falhas de segurança" devido a quê? existe alguma perda de informação ou de segurança na estrutura da base de dados ao usar estes recursos?

Nada disso. Simplesmente abres portas ao utilizador manipular as tuas querys e fazer-te um DROP tabela; por exemplo.

Como é que os outros sistemas de CMS resolvem este assunto? ...ou até mesmo o phpmyadmin?

O phpMyAdmin não resolve, não é suposto resolver 😄 Anyway, a maior parte tem funções próprias para escapar os caracteres perigosos (", ', #, etc), ou então usam o mysql_real_string_escape().

Faz download da revista programar Nº 11 e lê o artigo chamado "vulnerabilidades das aplicações web" escrito pelo djthyrax, é uma boa forma de começar.

http://www.revista-programar.info/front/edition/11

Que por acaso está como sticky na secção de PHP (raiz).

verdade 😄 O ADOdb é a solução para os teus problemas, lê o artigo da edição 12 da revista programar 😄

Não é exactamente a mesma coisa, mas sim, serve o propósito.

Acho que voces se estão a precipitar.

Isso tem algum filtro contra cross site scripting?

Não. Para isso deve-se usar htmlentities() por exemplo, também abordei isso no meu artigo que referiste.

[pedrotuga]

djthyrax, o html entities não resolve problemas de cross site scripting.

Isso é o mesmo que dizer que a solução para os acidentes de autimóvel é proibir o uso de automóveis.

Os possiveis perigos relacionados com cross site scripting colocam-se quando chega a hora de fazer output de html. Seja ele gerado pelo utilizador directamente seja ele construido por ti mas com informação que esteja na ua base de dados ou mesmo por outros métodos, por exemplo um parser de bbcode.

Quando usas a função htmlentities não estás a fazer output de html, os problemas colocam-se quando não podes usar o html entities.

O SO aqui tambem pode ter influencia, realmente não estou a ver onde, mas lembro-me por exemplo de uma vez que tive que portar uma aplicação desenvolvida por um colega meu no windows onde tive que mudar manualmente todos os pedidos SQL pois no windows o mysql não era case sensitive.

Mas de qualquer das formas, se esse tipo de problemas aparece é porque há coisas que não estão muito bem escritas, se tudo for feito em conformidade e não 'assim funciona por isso desenrasca' então não haverá problemas de incompatibilidades.

[djthyrax]

djthyrax, o html entities não resolve problemas de cross site scripting.

Isso é o mesmo que dizer que a solução para os acidentes de autimóvel é proibir o uso de automóveis.

Os possiveis perigos relacionados com cross site scripting colocam-se quando chega a hora de fazer output de html. Seja ele gerado pelo utilizador directamente seja ele construido por ti mas com informação que esteja na ua base de dados ou mesmo por outros métodos, por exemplo um parser de bbcode.

Quando usas a função htmlentities não estás a fazer output de html, os problemas colocam-se quando não podes usar o html entities.

Dá-me um exemplo onde não possa usar o htmlentities(). O htmlentities() previne code injection da forma mais rasca possível, mas previne.

[pedrotuga]

Um exemplo?

Por exemplo estes fóruns.

Se fizeres output do código com o htmlentities() não podes usar bbcode.

Outro exemplo mais facil de perceber:

Um form que permita afixar html, por exmeplo no backoffice de um CMS.

Ou simplesmente, um editor de ficheiros online.

Sei lá, tantos exemplos.

[cyclop]

Isso não é problema, dependendo da situação pode ser mais conveninete usar aspas ou plicas ou mesmo acentos

tenta entao fazer isto  e vê se é ou nao é problema, depois olha para o código dele...

$teste='dsfdsfdsfd';

echo("$teste");

echo('$teste');

e depois disto, testa isto, mas sem ser echo, a ser INSERT de uma string, que vai entrar como sendo uma coisa qqr menos aquilo que queres enviar... para isso, usa-se o anticuado 'ponto final' ajudar o motor é bom, se nao um dia destes ficas a pé 😛

[cyclop]

agora a parte... no insert, tenta usar no insert assim ----> "'.$variavel.'", .... a VER se não funciona 😛

[djthyrax]

Um exemplo?

Por exemplo estes fóruns.

Se fizeres output do código com o htmlentities() não podes usar bbcode.

Outro exemplo mais facil de perceber:

Um form que permita afixar html, por exmeplo no backoffice de um CMS.

Ou simplesmente, um editor de ficheiros online.

Sei lá, tantos exemplos.

Uhuh, esse exemplo do fórum não concordo. Tu estás a olhar pelo lado lazy-ass, os dados devem ser SEMPRE filtrados antes de qualquer outra operação, nunca directamente no output. Em relação ao form que permite afixar HTML, aí não se usaria htmlentities() mas sim strip_tags(). Um editor de ficheiros online não teria esse problema, fazia-se download em plain-text (obrigando com o header a informar que é um attachment) ou visualizava-se no browser com o htmlentities().

tenta entao fazer isto  e vê se é ou nao é problema, depois olha para o código dele...

$teste='dsfdsfdsfd';

echo("$teste");

echo('$teste');

e depois disto, testa isto, mas sem ser echo, a ser INSERT de uma string, que vai entrar como sendo uma coisa qqr menos aquilo que queres enviar... para isso, usa-se o anticuado 'ponto final' ajudar o motor é bom, se nao um dia destes ficas a pé 😛

Lol... Erros como esse só acontecem quando o programador não tem qualquer consciência do que a concenetação de strings faz. Além disso, "antiquado ponto final"?

agora a parte... no insert, tenta usar no insert assim ----> "'.$variavel.'", .... a VER se não funciona 😛

Vulnerável a SQL Injection, bastava o utilizador usar apenas uma aspa que isso dava logo erro. 😄

[pedrotuga]

@1 sonhador

exactamente pelas diferenças que apontas é que não é problema. Um programador usar umas vezes aspas e outras vezes plicas, em situações onde se possam usar as duas não é nenhuma inconsistencia. Não entendi o porquê do "tu decide-te"...

tipo

$nomes[0]="carlos";

$nomes[1]='antónio';

Isto não tem qualquer problema.

Respondeste com um exemplo que vai precisamente contra o que tu disseste inicialmete. Ou seja, o teu exemplo só prova que às vezes é mais conveninete o uso de asas do que de plicas.

Eu sei que as aspas expandem as variáves e as plicas não. Mas não estou a ver onde é que isso obriga um programador a usar epnas uma delas, antes pelo contrario, é uma razão para se usarem as duas, conforme seja necessário.

djthyrax,

de que raio estás a falar?

Lazy ass? dados filtrados antes do output????

Não percebo bem o que queres dizer com isso nem em que contexto falas de filtragem de dados. Só te estou a tentar explicar que o htmlentities serve para mostrar caracteres especiais no html e é essa a sua única função.

Não é aí que aparecem os problemas de segurança.

Os problemas de seguraça aparecem sempre que precisas de fazer ouput de html.

Por exemplo, precisas de transformar bbcode em html, se não tiveres cuidado oparser pode ser usado para incluir um script.

Mas o que me intrigou mais foi mesmo isso do strip_tags, etc... tipo, se queres possibilitar o uso de html a um utilizador de um site, vais usar o strip_tags  :bored: ?

Aqui sim, faz sentido falar de um filtro contra XSS.

Ou explicando de uma forma que mais pessoas percebem:

Não cuidar de caracteres HTML especiais quando estes fazem parte de uma página web, não é uma falha de segurança, é um defeito básico de uma aplicação que deve ser colocado muito antes de qualquer preocupação de segurança.

[cyclop]

$nomes[0]="carlos";

$nomes[1]='antónio';

sim, aki tudo bem, agora faz um insert (que era o caso que estava a baila)

insert into tabela bla bla bla values('$nomes[0]') e vê se é a mesma coisa...

ERA O QUE O RAPAZ ESTAVA A FAZER