Bezpieczeństwo skryptów PHP, Jak zabezpieczyć się przed włamaniem |
Bezpieczeństwo skryptów PHP, Jak zabezpieczyć się przed włamaniem |
13.04.2006, 14:29:58
Post
#41
|
|
Grupa: Zarejestrowani Postów: 504 Pomógł: 2 Dołączył: 31.03.2006 Skąd: Londyn Ostrzeżenie: (0%) |
Wracajac do powyższej dyskusji na temat include to chcialbym i cos od siebie dodac.
Założmy, że manual klamie (to tak tylko na cele posta ) i include nie pozwala dołączać URLi z zewnatrz. Ważne jest tez, że administrator nie wpadł na takowy pomysł i nie ma poistawionego Apache'a na chroocie. Mamy podany wyzej include o postaci:
Warto dodac ze skrypt taki umiescimy w pliku index.php No i teraz czas na zabawe, katalogi moga byc różne w zależnosci od Linuxa u mnie na jednym serwerze z OpenBSD i Apachem na chroocie oczywiscie nie dziala ale na drugim z Red Hatem mozna sie pobawic. Przekazujemy takie adresy http://domena/index.php?zmienna=/etc/my.cnf (jak mowilem w zaleznosci od serwera) i widzimy konfiguracje MySQLa, idzmy dalej http://domena/1.php?zmienna=/etc/passwd titaj mamy informacje o userach na serwerze adresow do tego typu plikow mozna szukac wiecej stopien niebezpieczenstwa zależy od stopnia wiedzy intruza. Ale to tak chcialem dorzucic bo nie lubie jak ktos pisze bzdury ze inni bzdury piszanie patrzac nawet do manuala zachowuje sie wtedy jak moj stary tzn chodzbym mu dowod na pismie na cos przedstawil to stary i tak uwaza ze ma racje Pozdrawiam -------------------- "Wizja czasu jest szeroka, lecz kiedy sie przez nia przechodzi, czas staje sie waskimi drzwiami"
|
|
|
13.04.2006, 16:40:36
Post
#42
|
|
Grupa: Przyjaciele php.pl Postów: 2 712 Pomógł: 23 Dołączył: 27.10.2003 Skąd: z kontowni Ostrzeżenie: (0%) |
@thornag: dziękujemy za jakże wnikliwą analizę problemu. Zanim uraczysz nas kolejnymi rewelacjami bądź łaskaw czytać dokładnie wątki, w których się udzielasz. Jeśli nie całe to chociaż pierwsze strony.
-------------------- "Coś się kończy, coś się zaczyna." Andrzej Sapkowski
|
|
|
13.04.2006, 21:27:45
Post
#43
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) |
Co znaczy apach na chroocie?
-------------------- ”Godzina nauki w życiu nowoczesnego apostoła jest godziną modlitwy.”
(św. Josemaría Escrivá, Droga, 335) |
|
|
14.04.2006, 02:19:00
Post
#44
|
|
Grupa: Zarejestrowani Postów: 504 Pomógł: 2 Dołączył: 31.03.2006 Skąd: Londyn Ostrzeżenie: (0%) |
Cytat(kszychu @ 2006-04-13 15:40:36) @thornag: dziękujemy za jakże wnikliwą analizę problemu. Zanim uraczysz nas kolejnymi rewelacjami bądź łaskaw czytać dokładnie wątki, w których się udzielasz. Jeśli nie całe to chociaż pierwsze strony. Wszak nawet nie smiem twierdzic ze to rewelacje chyba wiekszosc forumowiczow doskonale o tym wie. Watek czytalem acz byc moze umknely mi posty o wyswietlaniu plikow konfiguracyjnych. Pozatym nie pisze tego by raczyc rewelacjami a jedynie by pokazac tym ktorzy w nieswiadomosci zyja ze cos takiego jest mozliwe. I nawiazujac wlasnie do tego co przed momentem napisalem a dokladniej mowiac do przydatnosci posta odpwoiem na pytanie poprzednika: chroot to taki mechanizm, ktory sprawia, ze np. Apache uznaje, że katalogiem głównym systemu jest dla niego katalog instalacji czyli np. /var/www po to by nikt nie mogl zrobic directory traversal nawet jak przejmiesz apache, to nie wyleziesz do prawdziwego katalogu. To trak w skrocie czyli tyle co sam wiem co mi przekazano Edit: kszychu ==> rzeczywiscie zwracam honor, przy czytaniu umknela mi strona nr.2 moj blad jak najbardziej przyznaje racje, aczkolwiek musze zaznaczyc ze nie mialem złych zamiarow Ten post edytował thornag 14.04.2006, 02:22:15 -------------------- "Wizja czasu jest szeroka, lecz kiedy sie przez nia przechodzi, czas staje sie waskimi drzwiami"
|
|
|
14.04.2006, 03:26:13
Post
#45
|
|
Grupa: Zarejestrowani Postów: 180 Pomógł: 0 Dołączył: 5.02.2006 Skąd: Bytom Ostrzeżenie: (10%) |
Witam,
Mam pytanie, czy ten kod jest w miare bezpieczny?
uzycie funkcji zapisz() jest w if(isset($_COOKIE["Admin"])) (jezeli cookie sie nie zgadza nie ruszy) Zreszta podam adres skryptu http://firefoks.be/admin.php (który zresztą za niedługo opublikuje ) Pozdrawiam Ten post edytował Nightwalk 14.04.2006, 03:30:52 -------------------- Warsztat: http://traktor.net.pl/
|
|
|
30.05.2006, 07:45:59
Post
#46
|
|
Grupa: Zarejestrowani Postów: 3 Pomógł: 0 Dołączył: 30.05.2006 Ostrzeżenie: (0%) |
Witam
Jestem nowy na forum i zgodnie z sugestią mike_mech'a przeczytałem cały wątek. Wydaje mi się że nie znalazłem odpowiedzi na moje pytanie, więc pozwolę sobie zapytać Jakiś czas temu pojawił mi się problem z atakami przez formularze (np. mailowe) - we wszystkich wykorzystuję metodę $_POST. Mója znajmomość php pozwoliła mi na uzyskanie mniej więcej takiej jakości zabezpieczeń:
Ale wciąż mam wrażenie, że to za mało, albo zbyt toporne to to. Z różnych przyczyn nie bardzo mogę/chcę weryfikować wysyłany formularz generowanym hasłem w obrazku. Czy ktoś ma może takie "wzrocowy" przykład minimum zabezpieczeń dla formularzy? |
|
|
30.05.2006, 08:38:20
Post
#47
|
|
Grupa: Zarejestrowani Postów: 853 Pomógł: 25 Dołączył: 27.08.2003 Skąd: Katowice Ostrzeżenie: (0%) |
zabezpieczając się najpeirw należy się zastanowić przed czym się zabezpieczamy
1. po co htmlspecialchars(strip_tags( ? tego trzeba używać przy umieszczaniu danych w kodzie html (chyba ze na zapas), nie mowiac o tym ze w twoim przypadku jest to bledny zapis poniewaz zarowno strip_tags jak i htmlspecialchars nie moze przyjmowac jako argumentu tablicy. poza tym, przed sprawdzeniem poprawnosci danych nie powinno ich sie raczej zmieniac, uwazam ze walidacje powinno sie dokonywac na surowych danych takich jak dostarczono. 2. $_SERVER['HTTP_REFERER'] nie nawsze jest ustawiane,a moze tez sie roznic jak przechodzi przez rozne proxy. lepszym rozwiazaniem jest zastosoawnie jakiegos tokena (umieszczenie tokena w polu typu hidden i w sesji i potem sprawdzenie czy sie pokrywaja). btw, jest to zabezpieczenie przed proba bezposredniego wyslania danych z pominieciem wlasciwego formularza na stronie. 3. wszystko zalezy od przeznaczenia, jesli uwaznie przeczytales watek to byc moze zauwazyles ze nikt tutaj nie ma jednej skutecznej metody zabezpieczania. jesli umieszczasz dane w zapytaniach to trzeba np. uzyc mysql_real_escape_string, jesli dane wyswietlasz to htmlspecialchars, jesli chcesz sie zabezp przed xss to strip_tags [nawet bez tagow html da sie xss zastosowac, chociazby przez nieumiejetnie wykrozystany i napisany bbcode]. kombinacji i mozliwosc jest wiele, a bardzo duzo zalezy od specyfikacji danego problemu. Ten post edytował sopel 30.05.2006, 08:40:02 -------------------- "If debugging is the process of removing bugs, then programming must be the process of putting them in..."
sobstel.org |
|
|
30.05.2006, 09:26:45
Post
#48
|
|
Grupa: Zarejestrowani Postów: 3 Pomógł: 0 Dołączył: 30.05.2006 Ostrzeżenie: (0%) |
to może trochę sprecyzuję
Te zagrożone formularze na stronie wykorzystuję do przesyłania maili do konkretnego wskazanego odbiorcy w firmie. Jedne z formularzy to typowy formularz kontaktowy (imie, nazwisko, mail, twoja opinia), drugie to ankiety (dużo radiobuttonów, kilka textarea, kilka checkboxów) Jakiś czas temu, ktoś zaczął podpinać się zewnetrznym formularzem i rozsyłać spamy - pakowali swoje nagłówki w maila i mieli pełną swobodę. Dlatego zastosowałem htmlspecialchars(strip_tags($_POST), ENT_QUOTES); - dało to taki efekt że przypinane zewnętrznie headers wyglądają mniej więcej tak: Content-Type: text/plain; charset=\"us-ascii\" więc już jest bezpieczniej, $_SERVER['HTTP_REFERER'] =='url' powinno mnie chyba zabezpieczyć dość skutecznie przed podpinaniem się zewnętrznym formularzem pod mój? |
|
|
30.05.2006, 09:29:06
Post
#49
|
|
Grupa: Zarejestrowani Postów: 853 Pomógł: 25 Dołączył: 27.08.2003 Skąd: Katowice Ostrzeżenie: (0%) |
$_SERVER['HTTP_REFERER'] =='url' powinno mnie chyba zabezpieczyć dość skutecznie przed podpinaniem się zewnętrznym formularzem pod mój? Cytat("sopel") $_SERVER['HTTP_REFERER'] nie nawsze jest ustawiane,a moze tez sie roznic jak przechodzi przez rozne proxy
-------------------- "If debugging is the process of removing bugs, then programming must be the process of putting them in..."
sobstel.org |
|
|
30.05.2006, 10:33:54
Post
#50
|
|
Grupa: Zarejestrowani Postów: 3 Pomógł: 0 Dołączył: 30.05.2006 Ostrzeżenie: (0%) |
2. $_SERVER['HTTP_REFERER'] nie nawsze jest ustawiane,a moze tez sie roznic jak przechodzi przez rozne proxy. Przyznaję, że niestety nie rozumiem tego wytłumaczenia jeśli url www.mojastrona.costam?name=formularz wywołuje skrypt.php (wywoływany tylko if($_GET['name']=='formularz') ) w którym:
to jak to można obejść? jeśli pytanie jest bardzo lamerskie to już więcej nie będę męczył |
|
|
4.06.2006, 19:18:58
Post
#51
|
|
Grupa: Zarejestrowani Postów: 651 Pomógł: 28 Dołączył: 4.12.2004 Ostrzeżenie: (0%) |
Wystarczy wysłać odpowiedni nagłówek i w nim zdefiniować dowolny http referer. Można to zrobić w php lub z użyciem takiego pluginu do firefoxa o nazwie `Live HTTP headers`
-------------------- Sygnatura niezgodna z regulaminem.
|
|
|
4.06.2006, 19:57:25
Post
#52
|
|
Grupa: Zarejestrowani Postów: 853 Pomógł: 25 Dołączył: 27.08.2003 Skąd: Katowice Ostrzeżenie: (0%) |
Przyznaję, że niestety nie rozumiem tego wytłumaczenia nigdy nie mozesz polegac na HTTP_REFERER nawet jak nikt przy nim nie majstruje. ktos moze laczyc sie z twoja strona przez proxy a proxy czasami lubia mieszac z naglowkami HTTP, przez co ten sam uzytkownik moze zwracac np. rozne USER_AGENT, to samo tyczy sie HTTP_REFERER. takze, przegladarka moze wcale tego naglowka nie wysylac i wtedy $_SERVER['HTTP_REFERER'] jest puste nawet, gdy ktos przechodzi z jednej strony na drugą. w ten sposob przez swoje zabezpieczenie ograniczasz dostepnosc aplikacji dla niektorych uzytkownikow. dokladajac fakt, o ktorym wspomnial powyzej Speedy, powoduje to ze HTTP_REFERER raczej nie jest najlepszym rozwiazaniem, nie sadzisz? Ten post edytował sopel 4.06.2006, 19:58:38 -------------------- "If debugging is the process of removing bugs, then programming must be the process of putting them in..."
sobstel.org |
|
|
5.06.2006, 01:40:06
Post
#53
|
|
Grupa: Zarejestrowani Postów: 2 262 Pomógł: 21 Dołączył: 3.05.2004 Skąd: Sopot, Krakow, W-wa Ostrzeżenie: (0%) |
Podziele sie z Wami moim pomyslem jak ja zalatwiam prawie wszystko roboty tego typu w swoich projektach.
Jest formularz
To takie smieszne w nazwie to losowy string - generowany md5 na bazie czasu. Zapisuje sie go w sesji. User wysyla i sie wyciaga z POST wszystkie pola porownujac z tym co jest w sesji zapisane - cos ala token doklejony do nazwy pola. I tyle Roboty wysylajace spam np. na blogi dzialaja na bazie znajomosci nazw pol formularza oraz adresow - bo tak dziala np. CURL - taki prosty patch rozwala wiekszosc na lopatki Jesli nie ma sesji tzn ze ktos cos majstruje Ten post edytował NuLL 5.06.2006, 01:44:36 -------------------- Javascript, Coffeescript, Node.js, Mongo, CouchDb, chmury, workery & inne bajery - zycie jest zbyt krotkie aby miec nudna prace :)
|
|
|
21.07.2006, 21:09:53
Post
#54
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) |
@NuLL: Skoro sprawdzałeś to OK, ale dla mnie to żaden problem by bot odsyłał dokładnie te same nagłówki jakie otrzymał od serwera (chodzi oczywiście o cookies) a wtedy sesja zostanie wykryta.
-------------------- |
|
|
22.07.2006, 12:23:11
Post
#55
|
|
Grupa: Zarejestrowani Postów: 352 Pomógł: 0 Dołączył: 22.01.2006 Ostrzeżenie: (0%) |
NuLL a co z tymi co mają wyłączoną obsługę ciasteczek?
|
|
|
26.07.2006, 13:16:24
Post
#56
|
|
Grupa: Zarejestrowani Postów: 2 262 Pomógł: 21 Dołączył: 3.05.2004 Skąd: Sopot, Krakow, W-wa Ostrzeżenie: (0%) |
NuLL a co z tymi co mają wyłączoną obsługę ciasteczek? Statystycznie 1,5% - mam w powazaniu @Vee - napisalem ze prawie wszystkie - z tego co widze wiekszosc botow nie jest na tyle inteligentna aby to zrobic W najblizszym czasie bede mial mozliwosc testowania tego piszac duzy system blogowy -------------------- Javascript, Coffeescript, Node.js, Mongo, CouchDb, chmury, workery & inne bajery - zycie jest zbyt krotkie aby miec nudna prace :)
|
|
|
1.08.2006, 18:26:12
Post
#57
|
|
Grupa: Zarejestrowani Postów: 800 Pomógł: 0 Dołączył: 26.11.2005 Skąd: Nowy Sącz Ostrzeżenie: (0%) |
Czy przechowywanie id sesji w ciachu jest bezpieczne ?
Bo piszę własną obsługę sesji i to jest konsultowane z bazą danych... -------------------- Jah Music Is On My Mind !
|
|
|
1.08.2006, 19:32:58
Post
#58
|
|
Grupa: Zarejestrowani Postów: 853 Pomógł: 25 Dołączył: 27.08.2003 Skąd: Katowice Ostrzeżenie: (0%) |
Czy przechowywanie id sesji w ciachu jest bezpieczne ? Bo piszę własną obsługę sesji i to jest konsultowane z bazą danych... jest dość bezpieczne, ale najbezpieczeniejsze jest w połączeniu z SSL (https) - w innym przypadku cookies może być podsłuchane (co w gruncie rzeczy znowu aż takie proste dla wielu nie jest). jednakże uznałbym ten sposób mimo wszystko stosunkowo bezpieczny, jeśli wsparty przez odpowiednie dodatkowe zabezpieczenia jak chociażby wygasania sesji np. po 20-30min czy potwierdzanie ważnych czynności hasłem (jak zmiana maila, usunięcie ważnych danych). Ten post edytował sopel 1.08.2006, 19:33:29 -------------------- "If debugging is the process of removing bugs, then programming must be the process of putting them in..."
sobstel.org |
|
|
2.08.2006, 08:21:50
Post
#59
|
|
Grupa: Zarejestrowani Postów: 800 Pomógł: 0 Dołączył: 26.11.2005 Skąd: Nowy Sącz Ostrzeżenie: (0%) |
O to właśnie mi chodziło. Skrypt miałby się w przypadku zmiany danych pytać o hasło i login. Sesja zwykle wygasa u mnie po 30 minutach nieaktywności. Skrypt zbierający śmieci to załatwia.
Ciacho wygasa zawsze po 30 minutach od ostatniej nieaktywności. Niestety SSLa nie potrzebuje, bo to nie jest jakis skrypt bankowy czy coś, tylko prosty zbiór dzieł różnych ludzi... -------------------- Jah Music Is On My Mind !
|
|
|
4.08.2006, 10:43:27
Post
#60
|
|
Grupa: Zarejestrowani Postów: 196 Pomógł: 2 Dołączył: 1.03.2006 Ostrzeżenie: (0%) |
|
|
|
Wersja Lo-Fi | Aktualny czas: 27.09.2024 - 08:03 |