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
- zambezia2013.opx.pl
telcocafe
potrzeba mi informacji o podstawowych zagrożeniach, na które możne się natknąć funkcjonujący CMS, takich jak np SQL Injection. głównie chodzi o nazwy, bo opisy już na necie znajdę.buduję CMSa od podstaw, bez frameworków. bez frameworków dlatego, że chcę sprawdzić swoje umiejętności, więc nie krzyczcie :D .
to jak? ktoś podrzuci trochę info o zagrożeniach?
Tego jest dużo. Na Niebezpieczniku są łącza do 25 najgroźniejszych błędów programisty. Można oglądnąć przykłady.
Wiesz, to że piszesz bez frameworka nie oznacza że "sprawdzasz" swoje umiejętności. Są frameworki mniejsze i większe i wykorzystanie jakiegoś zawsze jest plusem jeżeli liczysz że ktoś ten kod/CMS ma wykorzystać. Zapierniczysz się na miesiące w żmudnym i nudnym klepaniu kodu pisząc wszystko "od zera" i tyle ;) zero zabawy i zero nauki programowania wartościowego na rynku pracy (znajomość frameworków i obecnie panujących metod programowania to podstawa.). Poziom jaki musi mieć serwis żeby odnieść sukces rośnie w zatrważający tempie i nie ma czasu na uniwersyteckie rozwiązania. Liczy się efektywność tworzenia, utrzymania i rozbudowy kodu ;) A nie dumanie jak zrobić system użytkowników, a po miesiącu jak go przepisać bo trzeba dodać drobną funkcjonalność :D Im nowsze technologie poznawałem tym więcej się uczyłem i tym większe dostawałem stawki ;)
Ogólnie:
- walidacja danych (GET/POST)
- zabezpieczenie zapytań (SQL Injection)
- zabezpieczenie przesyłania plików (code injection itd.)
- csrf
- bezpieczeństwo systemu autoryzacji/logowania
Do tego dołóż jeszcze przejrzysty kod, odpowiednią jego strukturę itd. ;)
Użytkownik Riklaunim edytował ten post 25 czerwiec 2010, 14:26
Ogólnie:
- walidacja danych (GET/POST)
- zabezpieczenie zapytań (SQL Injection)
- zabezpieczenie przesyłania plików (code injection itd.)
- csrf
- bezpieczeństwo systemu autoryzacji/logowania
Do tego dołóż jeszcze przejrzysty kod, odpowiednią jego strukturę itd. ;)
co do pierwszego punktu - to ok. jeśli na przykład mam przez GET'a wysłać id artykułu - sprawdzam czy id jest wartością numeryczną. ok.
co do drugiego - chyba wystarczy mysql_real_escape_string albo real_escape_string od mysqli, jeśli to są stringi? jeśli wartości numeryczne to sprawdzam tak jak to opisałem wcześniej?
3. czy chodzi o upload plików na serwer? jeśli tak, nie będzie problemu, bo skrypt nie będzie się tym zajmował.
4. tego do końca nie rozumiem. mógłbyś napisać, o co z tym dokładnie chodzi? co prawda czytałem o tym na wikipedii, ale mało z tego zrozumiałem :D
5. to chyba jest oczywiste przy projektach tego typu :D
Odnośnie CSRF:
Jest sobie strona, na którą się logujesz. Jesteś jej administratorem. Możesz tam usuwać różne rzeczy i robisz to, np., przez adres index.php?mod=arty&cmd=usun&id=1. Ktoś Ci wysyła link, wchodzisz, niby ciekawa strona, przeglądasz. W tle na stronie jest skrypt, który wywołuje takie coś:var img; for (var i = 1; i < 100; i++) { img = new Image(); img.src = 'http://example.com/index.php?mod=arty&cmd=usun&id=' + i; }Zamykasz stronę, wracasz do siebie i co? Nie masz artykułów.
To nie jest oczywiście jedyny przykład. Pomyślisz sobie, że to wina metody usuwania - przez zwykły GET. No to już jak zrobię POST, to nikt mi niczego złego nie wyrządzi. E, eee...var if = document.createElement('iframe'); if.href = 'http://example.com/index.php?mod=arty&cmd=usun'; if.document.onload = function() { var frm = document.getElementsByTagName('form')[2]; var el = document.createElement('input'); el.name = 'id'; el.value = '1'; frm.appendChild(el); var el = document.createElement('input'); el.name = 'usun'; el.value = 'Tak'; frm.appendChild(el); frm.submit(); };I po zabawie. Do takich rzeczy trzeba używać tokenów lub innych zabawek żeby być absolutnie bezpiecznym. No ale jeszcze aby wykonać atak CSRF potrzeba wiedzieć jaka jest struktura panelu administracyjnego. To jednak też nie jest przeszkodą, bo nic trudnego uruchomić skrypt, który prześledzi zawartość strony i wyśle na stronę crackera, a ten przygotuje się do kolejnego ataku - tym razem na celu zniszczenia treści strony.
a jak ochronić się przed CSRF? przychodzi mi na myśl tylko rozwiązanie z HTTP_REFERER, ale z tego, co wyczytałem w sieci, to nie zawsze skutkuje...
Tokeny chyba najczęściej stosowane (m.in. przez Django). Swego czasu robiąc prostą captchę ukrywałem dane captchy w formularzu stosując pośrednią tabelę, która generowała tokeny i pod nimi miała zapisane hasze poprawnej odpowiedzi, plus była ważna przez krótki okres czasu - przez co jednej rozwiązanej captchy nie dało się wielokrotnie wykorzystać.
a co oprócz tokenów jeszcze może pomóc??
//edit: wpisywanie tokena przy każdej akcji admina to trochę toporne zajęcie :D
Użytkownik czychacz edytował ten post 04 lipiec 2010, 15:16
Najpierw rusz z pracą nad skryptem, dobraniem platformy i bibliotek a nie kombinuj jak rozwiązać odleglejsze problemy ;)
Najpierw rusz z pracą nad skryptem, dobraniem platformy i bibliotek a nie kombinuj jak rozwiązać odleglejsze problemy ;)
Ja już pisałem panel administratora do swojej prostej strony, ale w ogóle nie brałem pod uwagę tego zagrożenia bo go nie znałem :(
Pisałem w zwykłym php + mysql. I faktycznie za każdym razem captcha to trochę uciążliwe, pomyślałem nad okienkiem w Javascript potwierdzającym usunięcie, ale podejrzewam, że też można to łatwo obejść i w tle akceptować taki komunikat. Więc jak się bronić ?