Возможные проблемы:
- SQL-инъекция
- XSS Injection (если бы этот код был запросом на вставку, это было бы определенной проблемой)
- Простой текстовый пароль
Ваш оператор SQL может быть проблематичным. Это плохая практика - оставлять себя открытым для SQL-инъекций.
Внедрение SQL плохо . Поверь мне.
Если вы хотите отобразить $ user на HTML-странице, вы можете не захотеть включать возможность "взломать" ваш макет, введя такие команды как
<H1>HI MOM</H1>
или куча javascript .
Кроме того, никогда не храните свой пароль в виде обычного текста (хорошо, поймайте cagcowboy!). Это дает слишком много полномочий людям, управляющим (или взламывающим) вашу базу данных. Вы никогда не должны знать чей-либо пароль.
Попробуйте такую тактику:
// mostly pulled from http://snippets.dzone.com/posts/show/2738
function MakeSafe($unsafestring)
{
$unsafestring= htmlentities($unsafestring, ENT_QUOTES);
if (get_magic_quotes_gpc())
{
$unsafestring= stripslashes($unsafestring);
}
$unsafestring= mysql_real_escape_string(trim($unsafestring));
$unsafestring= strip_tags($unsafestring);
$unsafestring= str_replace("\r\n", "", $unsafestring);
return $unsafestring;
}
// Call a function to make sure the variables you are
// pulling in are not able to inject sql into your
// sql statement causing massive doom and destruction.
$name = MakeSafe( $_POST["user"] );
$pwd = MakeSafe( $_POST["pwd"] );
// As suggested by cagcowboy:
// You should NEVER store passwords decrypted.
// Ever.
// sha1 creates a hash of your password
// pack helps to shrink your hash
// base64_encode turns it into base64
$pwd = base64_encode(pack("H*",sha1($pwd)))