Apenas por uma questão de headstuff (para que você tenha uma idéia de por que Fred -ii- disse para não usar este código) - vou desmontar um pouco isso, em ordem, à medida que for passando por isso (não é uma escavação pessoal na pessoa que faz a pergunta - mas apenas para dar uma idéia de que tentar construir um aplicativo meio seguro na pilha LAMP requer um pouco de cuidado e premeditação ... e cinismo sangrento emparelhado com assumir o pior em humanidade ajuda):
Ponto 1
Não é grande - mas realmente se você vai iniciar uma sessão, você deve iniciar uma sessão independentemente de haver
$_POST dados ou não. Você provavelmente deve exigir seu arquivo de configuração e iniciar a sessão no topo antes de qualquer outra coisa. Não é um erro de terminal (já que você não tem validação de sessão) - apenas estranho.
Ponto 2
Você tem saída neste arquivo (
echo ), portanto, deve estar na raiz do documento e disponível na árvore da web. include("config.php"); Isso não está realmente escrito corretamente, provavelmente deve ser
require_once 'config.php'; (supondo que seja um arquivo de programa obrigatório e não uma inclusão opcional que pode falhar), mas isso é não o erro. O erro é que você tem seu arquivo de configuração dentro da raiz do documento. Uma configuração incorreta do servidor ou um simples erro de digitação nesse arquivo poderia, teoricamente, permitir que o conteúdo desse arquivo fosse exibido na tela em texto simples, potencialmente revelando suas strings de conexão de banco de dados (e quem sabe o que mais) para world + dog. Os arquivos de configuração devem existir fora da árvore da web ou, na falta disso, dentro de um diretório protegido com algo como
.htaccess Deny from all . Eles nunca devem ser acessíveis por HTTP. Ponto 3
O
mysql biblioteca está obsoleta e não deve ser usada; MySQLi ou PDO são o caminho a seguir, idealmente com parâmetros/valores vinculados:http://uk3.php.net/PDO
http://uk3.php.net/mysqli
Pessoalmente eu tenho para DOP.
Pontos 4 e 5
$password = mysql_real_escape_string(stripslashes(md5($_POST['password']))); Primeiro, a ordem disso está errada. Você está fazendo o hash de
$_POST['password'] e então tentando tirar as barras - não haverá barras depois de ter sido hash. No entanto, se você está tentando impedir que as pessoas usem barras (ou qualquer outra coisa) em senhas, você precisa removê-las antes de fazer o hash da string. Próximo
md5 não deve ser usado como um algoritmo de hash de senha, pois foi considerado fraco e pode ser forçado a criar colisões de strings com muito mais frequência do que deveria. Sim, você deve apenas armazene hashes ou "impressões digitais" das senhas em vez das próprias senhas, mas, idealmente, você deseja sal e hash (com pelo menos
sha1 ) essas senhas em vez de simplesmente jogá-las em um md5() função. Veja:http://uk3.php.net/mcrypt por exemplo
E faça uma pesquisa sobre "hashing de salga de senha" usando o mecanismo de pesquisa de sua escolha.
Ponto 6
SELECT id FROM $table
WHERE username = '" . $username . "'
and password = '" . $password . "';
Eu adicionei no
= que estava faltando na pergunta original, mas ainda assim, não corresponde ao nome de usuário e senha em sua consulta ... se alguém conseguisse uma injeção de SQL em seu nome de usuário, a senha nunca seria verificada. Imagine:SELECT user.id
FROM user WHERE user.username = 'fred' OR 1 = 1
-- AND user.password = 'abc123'
É melhor selecionar o ID do usuário e a impressão digital da senha no banco de dados e, em seguida, avaliar a senha no aplicativo, em vez de confiar em uma verificação de senha na camada do banco de dados. Isso também significa que você pode usar um algoritmo de hashing e salting dedicado no próprio aplicativo para validar suas senhas.
Ponto 7
$_SESSION['user'] = $_POST["username"];
Isso está apenas armazenando o nome de usuário na sessão? Isso de forma alguma deve ser usado como um "verificador de login", especialmente porque não há (aparentemente) nada em sua sessão para impedir sequestro .
O id da sessão pode ser facilmente rastreado a partir do cookie de uma sessão ao vivo e isso é tudo o que seria necessário para "emprestar" o login de outra pessoa. Você deve pelo menos tentar mitigar a chance de a sessão ser sequestrada associando o endereço IP do usuário, a string do UserAgent ou alguma outra combinação de dados relativamente estáticos que você possa comparar em todas as páginas ... (especialmente, como eu descobri, se você tem visitantes usando AOL) - mas você pode fazer uma impressão digital de sessão provavelmente 99+% efetiva para mitigar o seqüestro com muito pouca chance de a sessão do usuário ser despejada erroneamente.
Idealmente, você também pode criar um token para a sessão para mitigar CSRF ataques quando o usuário precisa realizar uma ação "privilegiada" no banco de dados (atualizar seus dados ou qualquer outra coisa). O token pode ser um código totalmente aleatório e exclusivo armazenado no banco de dados e/ou em um cookie SSL quando o usuário fizer login (assumindo que o usuário não pode executar nenhuma ação que atualize o banco de dados fora do HTTPS, pois isso apenas transmitiria os dados em texto claro na Internet - o que seria uma má ideia ).
O token é colocado em um campo de formulário oculto para qualquer/todos os formulários e verificado em relação ao valor armazenado no cookie (ou sessão ou banco de dados) sempre que esse formulário é enviado. Isso garante que a pessoa que envia o formulário tenha pelo menos uma sessão ao vivo em seu site.
