Tylko ze względu na głowę (więc będziesz miał pomysł, dlaczego Fred -ii- powiedział, aby nie używać tego kodu) - zamierzam nieco to rozebrać na części, w kolejności, gdy będę przez to przechodził (to nie jest osobiste wykopanie osoby zadającej pytanie - ale tylko po to, aby dać wyobrażenie, że próba zbudowania w połowie bezpiecznej aplikacji na stosie LAMP wymaga odrobiny ostrożności i przezorności ... i krwawego cynizmu połączonego z zakładaniem najgorszego w ludzkość pomaga):
Punkt 1
Nie jest to duże - ale naprawdę, jeśli masz zamiar rozpocząć sesję, powinieneś rozpocząć sesję niezależnie od tego, czy istnieje $_POST dane, czy nie. Powinieneś prawdopodobnie wymagać swojego pliku konfiguracyjnego i rozpocząć sesję od góry, zanim zrobisz cokolwiek innego.
To nie jest błąd terminala (ponieważ nie masz walidacji sesji) - po prostu dziwne.
Punkt 2
Masz wyjście w tym pliku (echo ), dlatego musi znajdować się w katalogu głównym dokumentu i być dostępny w drzewie sieciowym.
include("config.php");
To nie jest napisane poprawnie, prawdopodobnie powinno być require_once 'config.php'; (zakładając, że jest to wymagany plik programu, a nie opcjonalne dołączenie, które może się nie powieść), ale to nie błąd. Błąd polega na tym, że masz plik konfiguracyjny w głównym katalogu dokumentów. Błędna konfiguracja serwera lub zwykła literówka w tym pliku może teoretycznie pozwolić na wyświetlenie zawartości tego pliku na ekranie w postaci zwykłego tekstu, potencjalnie ujawniając parametry połączenia z bazą danych (i kto wie, co jeszcze) światu + piesowi.
Pliki konfiguracyjne powinny istnieć poza drzewem sieciowym lub, jeśli to się nie powiedzie, w katalogu chronionym czymś w rodzaju .htaccess Deny from all . Nigdy nie powinny być dostępne przez HTTP.
Punkt 3
mysql biblioteka jest przestarzała i nie powinna być w ogóle używana; MySQLi lub PDO to droga, najlepiej z powiązanymi parametrami/wartościami:
Osobiście dostałem PDO.
Punkty 4 i 5
$password = mysql_real_escape_string(stripslashes(md5($_POST['password'])));
Po pierwsze, kolejność tego jest nieprawidłowa. Haszujesz $_POST['password'] i następnie próba stripslashów - po zahaszowaniu nie będzie żadnych ukośników. Jeśli jednak próbujesz uniemożliwić innym używanie ukośników (lub czegokolwiek) w hasłach, musisz je usunąć przed zahaszowaniem ciągu.
Następny md5 nie powinien być używany jako algorytm haszujący hasła, który okazał się słaby i może być brutalnie zmuszony do tworzenia kolizji ciągów znacznie częściej niż powinien.
Tak, powinieneś przechowuj tylko skróty lub "odciski palców" haseł, a nie same hasła, ale najlepiej, jeśli chcesz je wymieszać i haszować (przynajmniej sha1 ) te hasła, zamiast po prostu wrzucać je do md5() funkcja.
Zobacz:http://uk3.php.net/mcrypt na przykład
I wyszukaj „haszowanie haszowania hasła” za pomocą wybranej wyszukiwarki.
Punkt 6
SELECT id FROM $table
WHERE username = '" . $username . "'
and password = '" . $password . "';
Dodałem w = brakowało w pierwotnym pytaniu, ale mimo to nie pasuje do nazwy użytkownika i hasła w zapytaniu ... gdyby komuś udało się wstrzyknąć SQL do Twojej nazwy użytkownika, hasło nigdy nie zostałoby sprawdzone. Wyobraź sobie:
SELECT user.id
FROM user WHERE user.username = 'fred' OR 1 = 1
-- AND user.password = 'abc123'
Lepiej jest wybrać identyfikator użytkownika i odcisk palca hasła z bazy danych, a następnie ocenić hasło w aplikacji, zamiast ufać sprawdzaniu hasła w warstwie bazy danych. Oznacza to również, że możesz użyć dedykowanego algorytmu haszowania i solenia w samej aplikacji, aby zweryfikować swoje hasła.
Punkt 7
$_SESSION['user'] = $_POST["username"];
To tylko przechowywanie nazwy użytkownika w sesji? To w żaden sposób nie powinno być używane jako „weryfikator logowania”, zwłaszcza że (najwyraźniej) w Twojej sesji nie ma nic, co mogłoby zapobiec porwanie .
Identyfikator sesji można łatwo wychwycić z pliku cookie sesji na żywo i to wszystko, co byłoby wymagane do „pożyczenia” cudzego loginu. Powinieneś przynajmniej spróbować zminimalizować ryzyko przejęcia sesji przez powiązanie adresu IP użytkownika, ciągu UserAgent lub innej kombinacji stosunkowo statycznych danych, z którymi możesz porównać na każdej stronie... istnieją jednak wady praktycznie każdego podejścia (zwłaszcza, jak odkryłem, jeśli masz odwiedzających korzystających z AOL) – ale możesz zrobić prawdopodobnie 99% efektywnego odcisku palca sesji, aby złagodzić przechwycenie z bardzo małą szansą na błędne zrzucenie sesji użytkownika.
Najlepiej byłoby również utworzyć token dla sesji, aby złagodzić CSRF ataki, gdy użytkownik musi wykonać "uprzywilejowaną" akcję na bazie danych (zaktualizować swoje dane lub cokolwiek innego). Token może być całkowicie losowym i unikalnym kodem przechowywanym w bazie danych i/lub w pliku cookie SSL, gdy użytkownik się loguje (zakładając, że użytkownik nie może wykonaćżadnej akcji aktualizującej bazę danych poza HTTPS, ponieważ spowoduje to jedynie przesłanie danych czystym tekstem w Internecie — co byłoby złym pomysłem ).
Token jest umieszczany w ukrytym polu formularza dla dowolnych/wszystkich formularzy i porównywany z wartością zapisaną w pliku cookie (lub sesji lub bazie danych) za każdym razem, gdy formularz jest przesyłany. Gwarantuje to, że osoba przesyłająca formularz ma przynajmniej sesję na żywo w Twojej witrynie.
