Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Bom dia, coloquei a função strip_tags em todos os locais onde o usuário pode entrar com dados (Seja GET ou POST), porém mesmo assim alguém está conseguindo editar o banco de dados. Por exemplo, tenho uma linha do banco assim: "Hoje é Dia 07". O usuário "maléfico" está fazendo isso: "Hoje é Dia 07<iframe>www.sitequeelecoloca.com.br/arquivo.exe</iframe>"
Isso da um super problema, pois quando alguém entra no site automaticamente baixa esse arquivo.exe.
Alguma dica de como resolver isso ?
Mas é isso que não entendo Gabriel, como um usuário poderia inserir uma informação no banco (na verdade, editar uma informação, pois até agora foi só isso que ele conseguiu fazer, editar) se todas as entradas estão filtradas com strip_tags.
Certo, estão filtradas....... e você acha que ele consegue editar como ? <_<
Não sei Gabriel, é nisso que espero que me ajudem rsrsrs
Antes de mais nada, de onde você tirou a idéia de que strip_tags resolvo tudo? Se o seu problema é apenas sql injection use PDO e pronto. Se essa inserção/edição de dados está ocorrendo na área publica do seu site um paleativo é você permitir apenas select lá (assumindo que o update/insert/delete não é usado na área pública).
mostre os filtros que está usando
urlencode
urldecode
stripslashes
htmlspecialchars
estas funções devem lhe ajudar!
Já leu sobre PHP Injection?
Antes de mais nada, de onde você tirou a idéia de que strip_tags resolvo tudo? Se o seu problema é apenas sql injection use PDO e pronto. Se essa inserção/edição de dados está ocorrendo na área publica do seu site um paleativo é você permitir apenas select lá (assumindo que o update/insert/delete não é usado na área pública).
Já uso PDO amigo :D
Já uso PDO amigo :D
Legal, agora vem a dica de ouro na participação de qualquer fórum: mostre o script, sem isto fica-se apenas na suposição.
Bom, fica inviável mostrar o script sendo que são muitas páginas, e não sei ao certo onde está o problema.
Bom, vou seguir o concelho do nosso amigo Marcos Xavier e ler sobre PHP Injection
Amigo assim fica um pouco dificil de ajudar.
Você pode mostrar somente o código de autenticar o usuario e codigo que você usa para validar se o usuario esta autenticado no sistema.
Desculpe pessoal, dei a resposta errada, não estou usando PDO neste projeto e sim Sprintf (PDO uso em um outro, me confundi). Será que influência em algo utilizar Sprintf em vez de PDO ou o ideal é trocar para PDo logo ?
Segue minha página de login (acho que ela não está influenciando nisso)
<?php
if (session_id() == "")
session_start();
//ini_set('display_errors', 'On');
//error_reporting(E_ALL);
define('CAMINHO_RAIZ',$_SERVER['DOCUMENT_ROOT']."/");
require "usuario/dao_usuario.php";
if (isset($_SESSION['email']))
header('Location: index.php');
if (isset($_POST['entrar'])){
$daoUsuario = new DaoUsuario;
$email = strip_tags(trim(strtolower($_POST['email'])));
$senha = strip_tags(trim(strtolower($_POST['senha'])));$pojoUsuario = $daoUsuario->BuscarPorEmail($email);
$_SESSION['email'] = $email;
$_SESSION['cod_usuario'] = $pojoUsuario->getCod_usuario();
$_SESSION['data_acesso'] = date("d/m/Y \à\s H:i");
echo "<script type='text/javascript'>location.href='index.php';</script>";
} echo "<script type='text/javascript'> alert('Email/Senha inválido, por favor tente novamente'); </script>";
}
?><html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel="stylesheet" href="../css/login.css" type="text/css" media="screen" />
<link rel="stylesheet" href="../js/jquerymain/dot-luv/jquery-ui-1.8.16.custom.css" type="text/css" media="screen" />
<script type="text/javascript" src="../js/jquerymain/jquery-1.6.2.min.js" ></script>
<script type="text/javascript" src="../js/jquerymain/jquery-ui-1.8.16.custom.min.js" ></script>
<script type="text/javascript">
$(document).ready(function(){
$("input:submit").button();
});
</script>
<title></title>
</head>
<body>
<div id="container">
<div id="login_box">
<form action="" method="post" name="formulario">
<label for="email">E-mail</label><input type="text" class="lower" name="email" id="email" />
<label for="senha">Senha</label><input type="password" class="lower" name="senha" id="senha" />
<input type="submit" name="entrar" value="entrar" />
</form>
</div><!--DIV LOGIN_BOX-->
</div><!--DIV CONTAINER-->
</body>
</html>
<?php unset($daoUsuario); ?>Bom, coloquei o seguinte tratamento para tentar resolver o PHP Injection
<?php
$pg = isset($_GET['pg']) ? $_GET['pg'] : null;
$pg = strip_tags(trim($pg));
if (eregi("http|www|ftp|.dat|.txt|.gif|wget", $pg))
die('Ops, problemas na página.');
if (is_file($pg . '.php'))
include $pg . '.php';
else
include 'home.php';
?>aconselho a ir num ponto mais específico..
em qual tabela do banco de dados está salvo esse frame com o arquivo exe ?
baseado nisso comece a olhar as ações com o db referentes a essa tabela..
e mesmo nesse código do login não há proteção contra sql injection.. então creio que outros scripts estejam na mesma situação..
Poque você diz que nesse código de login não há proteção contra SQL Injection ?
$email = strip_tags(trim(strtolower($_POST['email'])));
strip_tags -> remove tags html, css, js..
trim -> remove espaços antes e depois da string
strtolower -> converte todas as letras para minúsculo
Em seguida, a variável é enviada para o método VerificarLogon do objeto daoUsuario
$daoUsuario->VerificarLogon($email,$senha)
Até esse ponto não há tratamento algum contra SQL injection.. A grosso modo, o que o script faz é corromper os dados e só isso.
A parte mais básica da segurança que é remover as strings de injeção, é inexistente nesse script.
Mas por se tratar de um modelo Orientado a Objetos (seguindo Padrões de Projeto) o tratamento de SQL Injection (com Addslahses) está sendo feito todo dentro da classe DaoUsuario, ou seja, quando é acionado o método VerificarLogon lá tem um Addslashes tratando os parametros.
Addslashes... e o que mais ? posta a função VerificarLogon
Segue o meu método VerificarLogon
public function VerificarLogon($email, $senha) {
$sql = sprintf("SELECT * FROM usuario WHERE email = '%s' AND senha = '%s'", addslashes(strtolower($email)), addslashes(strtolower($senha)));
$result = mysql_query($sql) or die("ERRO ao verificar o logon do usuario, METHOD VerificarLogon, INFORME ESTE ERRO AO SUPORTE TÉCNICO");
if (mysql_num_rows($result) != 1)
return false;
else
return true;
}Você colocou somente addslashes(), podera validar o e-mail, e a senha se contem x numeros de caracteres.
Outra coisa você esta trabalhando com a senha sem criptografia?
Sim, sem MD5.
Sim, sem MD5.
Pecado.
Codifique sua senha, melhore seu conceito em segurança. Da uma olhada em todas as suas páginas da admin, e veja se todas elas estão com o script de verificação das sessões.
Filho, você tem que impedir a entrada da agulha, e não o efeito do veneno.
A falha está em seu sistema de login e verificação das páginas, claro que você deve também, fazer o filtro na inserção dos dados.