Jen pro zajímavost (abyste měli představu, proč Fred -ii- řekl, že tento kód nepoužívat) - trochu to rozeberu, v pořadí, jak to projdu (není to osobní rýpnutí na osobu, která otázku klade - ale jen pro představu, že pokusit se vybudovat napůl bezpečnou aplikaci na zásobníku LAMP vyžaduje trochu opatrnosti a rozmyslu... a zatraceně smýšlející cynismus spojený s předjímáním toho nejhoršího v lidstvo pomáhá):
Bod 1
Nic velkého – ale pokud chcete zahájit relaci, měli byste ji zahájit bez ohledu na to, zda je tam $_POST data nebo ne. Pravděpodobně byste měli vyžadovat svůj konfigurační soubor a zahájit relaci nahoře, než cokoli jiného.
Nejde o chybu terminálu (protože nemáte žádné ověření relace) – prostě divné.
Bod 2
V tomto souboru máte výstup (echo ), proto musí být v kořenovém adresáři dokumentu a musí být k dispozici ve stromu webu.
include("config.php");
Toto ve skutečnosti není napsáno správně, pravděpodobně by to mělo být require_once 'config.php'; (za předpokladu, že se jedná o povinný programový soubor a ne o volitelné zahrnutí, které může selhat), ale to je ne chyba. Chyba je v tom, že máte konfigurační soubor v kořenovém adresáři dokumentu. Nesprávná konfigurace serveru nebo jednoduchý překlep v tomto souboru by teoreticky mohly umožnit výstup obsahu tohoto souboru na obrazovku ve formátu prostého textu, což by potenciálně odhalilo vaše databázové připojovací řetězce (a kdo ví co ještě) do world + dog.
Konfigurační soubory by měly existovat mimo strom webu nebo, pokud to není možné, uvnitř adresáře chráněného něčím jako .htaccess Deny from all . Nikdy by neměly být přístupné přes HTTP.
Bod 3
mysql knihovna je zastaralá a neměla by se vůbec používat; MySQLi nebo PDO jsou správnou cestou, ideálně s vázanými parametry/hodnotami:
Osobně bych měl za PDO.
Body 4 a 5
$password = mysql_real_escape_string(stripslashes(md5($_POST['password'])));
Za prvé, toto pořadí je špatné. Hashujete $_POST['password'] a pak pokus o odstranění lomítek – po zahašování nebudou žádná lomítka. Pokud se však snažíte lidem zabránit v používání lomítek (nebo čehokoli jiného) v heslech, musíte je před hashováním řetězce odstranit.
Další md5 by neměl být používán jako algoritmus hašování hesel, bylo zjištěno, že je slabý a může být brutálně nucen vytvářet kolize řetězců mnohem častěji, než by měl.
Ano, měli byste ukládejte pouze hash nebo "otisky prstů" hesel, nikoli hesla samotná, ale v ideálním případě chcete sůl a hash (alespoň sha1 ) tato hesla, spíše než je jednoduše hodit do md5() funkce.
Viz:http://cz3.php.net/mcrypt například
A proveďte vyhledávání na "password salting hash" pomocí svého vyhledávače.
Bod 6
SELECT id FROM $table
WHERE username = '" . $username . "'
and password = '" . $password . "';
Přidal jsem do = který v původní otázce chyběl, ale přesto neodpovídají uživatelskému jménu a heslu ve vašem dotazu ... pokud by se někomu podařilo dostat do vašeho uživatelského jména SQL injekci, heslo by se nikdy nezkontrolovalo. Představte si:
SELECT user.id
FROM user WHERE user.username = 'fred' OR 1 = 1
-- AND user.password = 'abc123'
Je lepší vybrat otisk ID uživatele a hesla z databáze a poté heslo vyhodnotit v aplikaci, než věřit kontrole hesla v databázové vrstvě. To také znamená, že můžete použít vyhrazený algoritmus hash a salting v samotné aplikaci k ověření vašich hesel.
Bod 7
$_SESSION['user'] = $_POST["username"];
Jedná se pouze o uložení uživatelského jména v relaci? Toto by v žádném případě nemělo být používáno jako „ověřovač přihlášení“, zvláště když ve vaší relaci (zřejmě) není nic, co by bránilo únos .
ID relace lze snadno vyčíst ze souboru cookie živé relace a to je vše, co by bylo potřeba k „vypůjčení“ přihlášení někoho jiného. Měli byste se alespoň pokusit zmírnit možnost zneužití relace tím, že přiřadíte IP adresu uživatele, řetězec UserAgent nebo nějakou jinou kombinaci relativně statických dat, se kterými můžete porovnávat na každé stránce... prakticky každý přístup má své nevýhody. (zejména, jak jsem zjistil, pokud máte návštěvníky pomocí AOL) – ale můžete vytvořit otisk relace s pravděpodobně 99+% účinností, abyste zmírnili únos s velmi malou pravděpodobností, že bude uživatelova relace chybně vyřazena.
V ideálním případě můžete také chtít vytvořit token pro relaci ke zmírnění CSRF útoky, když uživatel potřebuje provést "privilegovanou" akci v databázi (aktualizovat své údaje nebo cokoli jiného). Token může být zcela náhodný a jedinečný kód uložený v databázi a/nebo v SSL cookie, když se uživatel přihlásí (za předpokladu, že uživatel nemůže provést žádnou akci, která aktualizuje databázi mimo HTTPS, protože by to pouze přenesla data v jasném textu na internetu – což by byl špatný nápad ).
Token se vloží do skrytého pole formuláře pro všechny/všechny formuláře a porovná se s hodnotou uloženou v souboru cookie (nebo relaci nebo databázi) při každém odeslání formuláře. Tím zajistíte, že osoba odesílající formulář bude mít alespoň živou relaci na vašem webu.