6 replies to this topic

[Howdy]

opa

eu li alguma coisa sobre inject, então estou protegendo meus posts assim:

$dbpg = sprintf(NEGOCIOS, mysql_real_escape_string($_POST['empresa']));

também tenho GET para uma espécie de query string:

$empresat = mysql_real_escape_string($_GET['valor']);
if (isset($empresat)) { 
	$_POST['vt'] = mysql_real_escape_string($empresat);
}

eu uso formulários, select e outros mas todos estão nesse formato
recomendariam mais precauções? eu não sei se posso acabar abrindo espaço pra algum XSS ou inject não achei nenhum artigo, também habilitei o recaptcha para registros

até mesmo para aqueles scripts que usam ajax para editar uma tabela ao clicar ficariam seguros simplesmente usando o mysql real escape? parece fácil demais
obrigado

[dezon]

howdy, não se posso chamar de recomendação mas uma coisa que eu sempre uso nos códigos de Forms é o

$login = addslashes($_POST['login'])

, porque esse ajuda a prevenir sql injection com campos de formulários.

abraços

[Paulo Freitas]

howdy, não se posso chamar de recomendação mas uma coisa que eu sempre uso nos códigos de Forms é o

$login = addslashes($_POST['login'])

, porque esse ajuda a prevenir sql injection com campos de formulários.

abraços

Se você for enviar estas informações para o MySQL/PostgreSQL, isso pouco pode adiantar. Veja o que o manual diz:

It's highly recommeneded to use DBMS specific escape function (e.g. mysqli_real_escape_string() for MySQL or pg_escape_string() for PostgreSQL), but if the DBMS you're using does't have an escape function and the DBMS uses \ to escape special chars, you can use this function.

No que diz respeito ao banco de dados eu uso e recomendo prepared statements da biblioteca PDO. Eis a página de documentação: http://docs.php.net/...pdo.prepare.php

No caso de XSS são muitas coisas a serem consideradas. Os guias da Open Web Application Security Project - OWASP são ótimas fontes - eis alguns deles:

• Cross-site Scripting (XSS)
• Reviewing Code for Cross-site scripting
• Phishing
• Data Validation
• Testing for Cross site scripting

[]’sAté mais

[Howdy]

excelente, estou lendo aqui
só é complicado XSS muita coisa pra entender

['' sem.Ponto]

A função mysql_real_escape_string() vai te proteger contra sql injection. Mas contra XSS não vai, é aí que mora o perigo.

Vou te dar um exemplo...

Se você cadastrar no banco de dados a empresa utilizando mysql_real_escape_string($_POST['empresa']), vai escapar as aspas e NULLs que o usuário colocar. Isso vai evitar o sql injection.

Mas, isso não vai evitar que o usuário cadastre tags html e javascript. Então, eu como usuário posso cadastrar no campo empresa da sua tabela isso aqui por exemplo:

<script>alert('vulnerável');</script>

Na hora que você estiver no seu painel de controle e abrir o meu cadastro, é capaz que esse script seja rodado. Por quê eu disse que é capaz? Porque vai depender de como você está exibindo o valor do campo empresa. A falha parece bobinha, mas eu posso até roubar a sua sessão utilizando javascript, assim eu poderia acessar seu painel de controle sem ter digitado senha nenhuma.

O que deve ser feito é não deixar que os caracteres especiais sejam exibidos. Ou você converte os caracteres especiais com htmlspecialchars() na hora do cadastro ou na hora de recuperar os dados do banco de dados.

Só que é bom lembrar que cada campo é um caso. Num campo empresa por exemplo, os únicos caracteres que me interessam são as letras. Logo no cadastro eu colocaria uma expressão regular que verificaria os caracteres, se o usuário colocasse outros caracteres que não fossem letras, ele receberia uma mensagem de erro dizendo que ele colocou caracteres inválidos.

Quando você pretende permitir o cadastro de qualquer tipo de caractere num campo, até que não tem problema não converter os caracteres especiais na hora do cadastro. Você pode deixar para converter na hora de recuperar os dados para exibir. Mas por que não converter na hora do cadastro? Como eu disse, cada campo é um caso, às vezes a gente define um tamanho exato para um campo (ex.: VARCHAR 20), se convertesse os caracteres especiais já no cadastro, duas aspas por exemplo ocupariam o espaço de 12 caracteres (duas aspas convertidas com htmlspecialchars() vira "").

Nossa, como eu escrevi...

[Squall Robert]

olá....

no caso que nosso amigo falou do campo empresa, existe maneiras de se tratar essas informações
ex\:


o campos empresa , vai reserver o nome da empresa certo... esse campo nao tem por que ter tags nele...
então se colocar tags nele certamente coisa boa não é.

neste caso vc pode usar

strip_tags($var);

que detona se aguém colocar tags no codigo.

mas existe outras maneiras de tratar estas infromações.....

[kdz]

Filtrar entrada e Tratar saída, você precisa disso para ser feliz

Estou postando uma apostila que tenho aqui a bastante tempo, é um pouco superficial mas dá pra ter uma noção do que se deve fazer.

Attached Files

•  ZCE_Study_Guide___traducao_capitulo_10.pdf   217.44KB   7 downloads