• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

nmb

PHP + MYSQL + HTML tags

25 mensagens neste tópico

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!

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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 :D

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Acho que voces se estão a precipitar.

Isso tem algum filtro contra cross site scripting?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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...
0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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 :D 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 :D O ADOdb é a solução para os teus problemas, lê o artigo da edição 12 da revista programar :D

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.
0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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.
0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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é :P

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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é :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 :P

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

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

@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.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

$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

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não era não.

Se reparares ele tem isto:

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

Ou seja, a string toda é embrulhada em aspas, as plicas no interior dela são tratadas como um caracter normal e as variáveis são expandidas. O que está bem.

No SQL estão acentos e plicas, isso não deve criar qq problema.

No caso dele só aconteceram problemas porque provavelemte a variável $html tem plicas que quebram o SQL.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
@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.

Concordo em parte contigo e com ele... :P Isso é inconsistente, torna o código menos organizado, na minha opinião. Mas nada disso significa que haja qualquer diferença e que vá fazer diferença na aplicação, porque não vai, mas que é inconsistente, é...

Eu por norma costumo usar plicas quando são indexs, pequenas tags ou assim, quando é texto tipo de frases e cenas mais longas (ou caso precise de usar cenas especiais como \n ou variáveis sem estar a concatenar) uso aspas.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Boas pessoal

deste já quero agradecer a todos os que responderam até aqui! tem sido mto útil para o perceber do problema.

estive a estudar o SQL INJECTION e mais propriamente a função mysql_real_escape_string, mas não entendo onde poderá esta função resolver o problema pois só adiciona backslashes ao código da string...

mysql_real_escape_string() calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.

anteriormente tentei solucionar o problema de forma parecida recorrendo à função str_replace para trocar " por \" mas tudo continua a acontecer pois no codigo continuam a existir plicas ou aspas:

$html  = '<table border="0" cellpadding="0" cellspacing="0" width="100%">';
$html_secure = mysql_real_escape_string($html); 
mysql_query("INSERT INTO `tabela` ( `html` ) VALUES ( '$html_secure' )");

isto irá originar uma má injecção sql:

mysql_query("INSERT INTO `tabela` ( `html` ) VALUES ( '<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\" width=\"100%\">' )");

...o que continua a originar o erro!

O que se pretende de facto seria uma função onde as variáveis fossem simplesmente ignoradas, ou seja, o conteúdo das mesmas estava isolado do restante código do INSERT, SELECT ou UPDATE.. etc

Tudo o que são conteúdos da bd, para a mesma, seria apenas texto ignorado...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Acho que não percebeste o que esta função faz, pois logo de seguida sugeres em alternativa emular o seu comportamento.

Tens que preparsar a tua string. Esta função escapa todos os caracteres perigosos,

Mas na base de dados ficas com a string como deve ser.

$html_secure=mysql_real_escape_string($html_secure);

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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.

Se eu filtrar tudo o que é perigoso assim que o recebo, e não quando vou fazer output, evito situações dessas.
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: ?

Claro, deixo ficar todas as tags excepto as "perigosas": <script>, <style>, etc.
Aqui sim, faz sentido falar de um filtro contra XSS.

Usar o strip_tags é cortar esse mal pela raiz, pelo menos na situação de postar comentários num blog por exemplo.

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.

É um defeito básico que leva a falhas de segurança, logo devem ter tanta ou mais atenção que as falhas de segurança. Tratar de todo o trabalho de filtração antes de processar informação (ir à bd, fazer output, etc) evita que os esquecimentos de invocar sistemas de protecção.

mysql_query("INSERT INTO `tabela` ( `html` ) VALUES ( '<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\" width=\"100%\">' )");

Estás a emular mal a função.

mysql_query("INSERT INTO `tabela` ( `html` ) VALUES ( '".mysql_real_escape_string('<table border="0" cellpadding="0" cellspacing="0" width="100%">')."')");
#é igual a fazeres:
mysql_query("INSERT INTO `tabela` ( `html` ) VALUES ( '<table border=\\\"0\\\" cellpadding=\\\"0\\\" cellspacing=\\\"0\\\" width=\\\"100%\\\">' )");

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora