Podstrony
- telcocafe
- [PHP+MySQL] Problem z połączeniem mysqli('localhost', 'xxx', 'xxx', 'xxx'
- [PHP] Wyrażenia regularne. Zamienić name="info_imie" na name="{info_imie}"
- [php] Dodanie textu do pliku. Problem... :) POMOCY!!!!!!!!!!!!!
- [PHP] Skrypt cenzury Chcę cenzury!!!
- Dobre programy do edycji php Dobre programy do edycji php
- [PHP] podział na strony php: podział na strony
- [PHP i MySQL] jak pobrac liczbe rezultatow Jak pobrac liczbe rezultatow???
- jak zrobic aktualizacje php? pomocy!!!!!
- Błąd w PHP-Fusion pomocy !!!!!
- Daczego nie dziala?? skrypt php nie chce działać!!!
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- kuchniabreni.xlx.pl
telcocafe
Wtam!Ostatnio przeczytałem gdzieś, ze sesje podatne są na atak "session poisoning". Jak można się przed nim bronić? Czy we własnych skryptach wystarczy zmienić ścieżkę do której zapisują się sesje, czy to też jest niebezpieczne?
Sesje, cookie jeżeli są źle używane można przechwycić itp. Same z siebie nie są "dziurawe" :) Cookie można ukraść z pomocą Javascript i luki umożliwiającej wstawienie dowolnego kodu HTML gdzieś na twojej stronie (np poprzez nie sprawdzaną zmienną _GET) i wysłanie tobie takiego linka. Ty jako admin wchodzisz - i cookie admina przechwycone :)
Podstawa to bezpieczny kod - odporny na ataki XSS (wstrzyknięcie kodu HTML) i SQL Injection (modyfikacja zapytań SQL)
a ataki typu session poisoning? Pytam sie, bo obejrzałem ostatnio o tym videoarta na uw-team.org i sie przestraszyłem łatwością włamania...
Session poisoning jest zwykle efektem pisania naprawdę brzydkiego kodu, z kolei XSS jest efektem nieuwagi/braku wiedzy/umiejętności. XSS jest niestety bardzo popularnym błędem, polecam lekturę tego i tego.
najlepszy sposób na ochrone przed błędami sesji - nie tylko s.poisoning - jest napisanie własnego systemu sesji trzymającego dane w bazie danych
najlepszy sposób na ochrone przed błędami sesji - nie tylko s.poisoning - jest napisanie własnego systemu sesji trzymającego dane w bazie danych
Tak, tak, bo twórcy PHP nie wiedzą, jak się system sesji robi, a wszystko, co zrobione samodzielnie jest lepsze. Tak, z pewnością.
wiele skryptów tak obsługuje sesje, a odnośnie bezpieczeństwa samego PHP to ja bym programistom pracującym nad jego rozwojem za bardzo nie ufał ;) the Month of PHP Bugs powstał jak zgłaszane wcześniej przez autora błędy w języku nie były "mile" widziane ;)
tworzenie własnych sesji przy użyciu bazy danych niesie wiele korzyści. A co do tego videoarta z uw-team.org to chyba nie dokładnie słuchałeś bo ataki s.poisoning działają tylko wtedy gdy masz dostęp do tego samego serwera. Więc o wiele bezpieczniej korzystać z sesji opartych o bazę danych. Jak ktoś chce to mogę wpakować całą gotową klasę która by obsługiwała sesję niestandardowe.
Tak, tak, bo twórcy PHP nie wiedzą, jak się system sesji robi, a wszystko, co zrobione samodzielnie jest lepsze. Tak, z pewnością.
swoim postem pokazałeś, że nie masz pojęcia o bezpieczeństwie php,
po 1. link, który podał Riklaunim
po 2. trzymanie sesji w db jest bezpieczniejsze bo jest podatne tyko na sql injection, a standardowa sesja jest podatna na: 1.Session Fixation, Session poisoning oraz Session injection :)
po 3. php jesli chodzi o wykonanie nie swieci przykladem
swoim postem pokazałeś, że nie masz pojęcia o bezpieczeństwie php,
po 1. link, który podał Riklaunim
po 2. trzymanie sesji w db jest bezpieczniejsze bo jest podatne tyko na sql injection, a standardowa sesja jest podatna na: 1.Session Fixation, Session poisoning oraz Session injection :)
po 3. php jesli chodzi o wykonanie nie swieci przykladem
Owszem, nie jestem specjalistą. Uważam jednak, że sam w sobie system sesji nie jest zły, problem jest jego nieumiejętne wykorzystanie. W pisanym samodzielnie systemie mogą wystąpić niemal te same problemy.
Przykładowo wspomniany art z uw-tem - zwykle, jeżeli ma się prawa do zapisu na koncie użytkownika, ma się też prawa do odczytu. Mając prawa do odczytu możemy odczytać plik z konfiguracją bazy danych. Wtedy jest nawet łatwiej włamać się niż za pomocą zwykłego systemu sesji.
Co do 3. zgodzę się - dlatego też odradzam wykorzystywanie PHP.
Przykładowo wspomniany art z uw-tem - zwykle, jeżeli ma się prawa do zapisu na koncie użytkownika, ma się też prawa do odczytu. Mając prawa do odczytu możemy odczytać plik z konfiguracją bazy danych. Wtedy jest nawet łatwiej włamać się niż za pomocą zwykłego systemu sesji.
ciekawe jak to zrobisz gdy:
1. plik leci przez parser
2. .htaccess blokuje dostep do katalogu z plikiem
3. plik jest ponad /public_html
ciekawe jak to zrobisz gdy:
1. plik leci przez parser
2. .htaccess blokuje dostep do katalogu z plikiem
3. plik jest ponad /public_html
Matko, czytaj co piszę... Hm, racja, używasz windowsa, nie dziwne, że nie wiesz, jak się to robi.
Jak to zrobię?
/home/user/public_html/$ cat config.php
Mam nadzieję, że rozumiesz co mam na myśli mówiąc "mając prawa do odczytu".
omg a skąd uzyskasz ten wspaniały dostęp do odczytu do ftp / shella?
a osobiste wycieczki zostaw dla siebie.
Skąd uzyskam? Wywnioskuj z poprzednich wypowiedzi:
A co do tego videoarta z uw-team.org to chyba nie dokładnie słuchałeś bo ataki s.poisoning działają tylko wtedy gdy masz dostęp do tego samego serwera.
Przykładowo wspomniany art z uw-tem - zwykle, jeżeli ma się prawa do zapisu na koncie użytkownika, ma się też prawa do odczytu.
Mam nadzieję, że rozumiesz co mam na myśli mówiąc "mając prawa do odczytu".
Mam dalej tłumaczyć?
1. tu chodzi o wirtualki
2. Ty jako spec od linuksa oraz od uprawnień zapewne wiesz, że jeśli udostępnia się userom dostęp do serwera to mają oni do tego swój katalog w którym tylko mogą się poruszać