Historyczne wady zabezpieczeń popularnych CMS-ów PHP?

Tworzę PHP CMS, który mam nadzieję będzie używany przez społeczeństwo. Bezpieczeństwo jest głównym problemem i chciałbym uczyć się od niektórych popularnych CMS PHP jak Wordpress, Joomla, Drupal, itp. Jakie są pewne luki w zabezpieczeniach lub luki w zabezpieczeniach, które miały w przeszłości, których mogę uniknąć w mojej aplikacji i jakich strategii mogę użyć, aby ich uniknąć? Jakie są inne problemy, którymi muszę się zająć, które być może nie były traktowane jako podatność, ponieważ od samego początku? Jakie dodatkowe funkcje bezpieczeństwa lub środki można włączyć, cokolwiek od najdrobniejszych szczegółów do podejścia bezpieczeństwa na poziomie systemu? Bądź jak najbardziej konkretny. ogólnie jestem świadomy większości zwykłych wektorów ataku, ale chcę się upewnić, że wszystkie bazy są pokryte, więc nie bój się wspomnieć o oczywistych. Załóżmy PHP 5.2+.

Edit: zmieniam to na wiki społeczności. Mimo że Arkh jest znakomity odpowiedź jest akceptowana, nadal jestem zainteresowany dalszymi przykładami, jeśli je masz.

Author: VirtuosiMedia, 2010-06-01
Source

9 answers

Cross-Site Request Forgery (CSRF)

Opis:

Podstawową ideą jest oszukanie użytkownika na stronę, na której jego przeglądarka zainicjuje POST lub poprosi o atakowany CMS.

Wyobraź sobie, że znasz adres e-mail administratora strony z systemem CMS. Wyślij mu jakąś śmieszną stronę internetową z czym chcesz. Na tej stronie tworzysz formularz z danymi używanymi przez panel administracyjny systemu CMS do tworzenia nowego użytkownika administratora. Przesłać te dane do panelu administracyjnego serwisu, z rezultatem jest ukryty iframe Twojej strony internetowej. Voila, masz własne konto administratora.

Jak temu zapobiec:

Zwyczajowym sposobem jest generowanie losowych krótkotrwałych (15mn do godziny) nonce we wszystkich Twoich formach. Gdy twój CMS otrzyma dane formularza, najpierw sprawdza, czy nonce jest w porządku. Jeśli nie, DANE nie są wykorzystywane.

Przykłady CMS:

Więcej informacji:

Na stronie Wikipedii oraz na stronie projektu OWASP.

Złe przechowywanie hasła

Opis:

Wyobraź sobie, że Twoja baza danych została zhakowana i opublikowana na czymś takim jak wikileak. Wiedząc, że duża część użytkowników używa tego samego loginu i hasła dla wielu stron internetowych, chcesz, aby były łatwe dostać ?

Nie. Musisz złagodzić szkody wyrządzone, jeśli Twoje dane bazy danych staną się publiczne.

Jak temu zapobiec:

    Pierwszym pomysłem jest ich hashowanie. Co jest złym pomysłem z powodu rainbow tables (nawet jeśli hash nie jest md5, ale sha512 na przykład).
  • drugi pomysł: dodaj unikalną losową sól przed hashowaniem, aby hakerzy musieli bruteforce każde hasło. Problem w tym, że haker może szybko obliczyć dużo hasha.
  • tak więc obecny pomysł polega na tym, aby spowolnić hashowanie haseł : nie obchodzi cię to, ponieważ nie robisz tego często. Ale atakujący będzie płakać, gdy dostanie od 1000 hash generowany na ms do 1.

Aby ułatwić ten proces, możesz użyć bibliotekiphpass opracowanej przez jakiegoś Guru haseł.

Przykłady CMS:

Więcej informacji:

Strona phpass .

Cross Site Scripting (XSS)

Opis

Celem tych ataków jest, aby Twoja strona wyświetlała jakiś skrypt, który zostanie wykonany przez twojego uprawnionego użytkownika.

Masz dwa rodzaje tych: trwałe lub nie. Pierwszy z nich pochodzi zazwyczaj z czegoś, co użytkownik może zapisać, drugi liczy na parametry podane przez wysłane żądanie. Oto przykład, nie "persistent": {]} 

<?php
if(!is_numeric($_GET['id'])){
  die('The id ('.$_GET['id'].') is not valid');
}
?>

Teraz twój atakujący może po prostu wysyłać linki typu http://www.example.com/vulnerable.php?id=<script>alert('XSS')</script>

Jak temu zapobiec

Musisz filtrować wszystko, co wydajesz klientowi. Najprostszym sposobem jest użycie htmlspecialchars , jeśli nie chcesz pozwolić użytkownikowi zapisać żadnego html. Ale, kiedy pozwalasz im generować html (albo własny html lub niektóre generowane z innych rzeczy, takich jak bbcode), musisz być bardzo ostrożny. Oto Stary przykład użycia zdarzenia "onerror" tagu img : vBulletin Luka. Albo masz stary Myspace samy .

Przykłady CMS:

Więcej informacji:

Możesz sprawdzić Wikipedię i OWASP . Masz też wiele wektorów XSS na ha.ckers strona.

Wstrzykiwanie nagłówka wiadomości

Opis :

Nagłówki wiadomości są oddzielone sekwencją CRLF (\r\n). Gdy używasz niektórych danych użytkownika do wysyłania wiadomości (jak używanie go do From: lub to:), mogą one wstrzykiwać więcej nagłówków. Dzięki temu mogą wysyłać anonimowe wiadomości z twojego serwera.

Jak temu zapobiec:

Filtruj wszystkie \n, \r, %0a i %0d znaki w nagłówkach.

Przykłady CMS:

Więcej informacji :

Wikipedia to jak zwykle dobry początek.

SQL Injection

Opis:

Stara klasyka. Dzieje się tak, gdy tworzysz zapytanie SQL przy użyciu bezpośredniego wejścia użytkownika. Jeśli Dane wejściowe są tworzone tak, jak są potrzebne, użytkownik może zrobić dokładnie to, co chce.

Jak temu zapobiec:

Proste. Nie formuj zapytań SQL z danymi wejściowymi użytkownika. Użyj zapytań parametryzowanych. Rozważ każde wejście, które nie jest zakodowane przez Ciebie, jako wejście użytkownika, niezależnie od tego, czy nadejdzie z systemu plików, własnej bazy danych lub webservice na przykład.

Przykład CMS:

Więcej informacji:

Wikipedia i OWASP mają naprawdę dobre strony na ten temat.

Dzielenie odpowiedzi Http

Opis:

Podobnie jak nagłówki wiadomości e-mail, nagłówki http są oddzielone według sekwencji CLRF. Jeśli aplikacja używa danych wejściowych użytkownika do nagłówków wyjściowych, może użyć ich do stworzenia własnych.

Jak temu zapobiec:

Jak dla e-maili, filtr \n, \r, %0a i %0d znaki z wejścia użytkownika przed użyciem go jako części nagłówka. Możesz również urlencode swoje nagłówki.

Przykłady CMS:

Więcej informacje:

Pozwolę ci zgadnąć, gdzie można znaleźć wiele informacji na temat tego rodzaju ataku. OWASP i Wikipedia .

Session hijacking

Opis:

W tym przypadku atakujący chce użyć sesji innego uprawnionego (i miejmy nadzieję uwierzytelnionego) użytkownika. W tym celu może zmienić swój własny plik cookie sesji, aby pasował do pliku cookie ofiary lub zmusić ofiarę do użycia własnej sesji (atakującego) dowód osobisty.

Jak temu zapobiec:

Nic tu nie może być idealne : - jeśli atakujący wykradnie plik cookie ofiary, możesz sprawdzić, czy sesja użytkownika jest zgodna z IP użytkownika. Ale może to uczynić Twoją witrynę bezużyteczną, jeśli uprawnieni użytkownicy używają serwera proxy, który często zmienia adres IP. - jeśli atakujący każe użytkownikowi używać własnego identyfikatora sesji, po prostu użyj session_regenerate_id , aby zmienić identyfikator sesji użytkownika, gdy jego prawa ulegną zmianie (login, wylogowanie, get in admin part of the website itd.).

Przykłady CMS:

Więcej informacji:

Wikipedia strona na ten temat.

Inne

  • dawkowanie użytkownika: jeśli zapobiegniesz bruteforcingowi próby logowania, wyłączając wypróbowane nazwy użytkowników, a nie IP, z którego pochodzą próby, każdy może zablokować wszystkich użytkowników w 2mn. To samo podczas generowania nowych haseł : nie wyłączaj Stary, dopóki użytkownik nie potwierdzi nowego (na przykład logując się z nim).
  • użycie danych wejściowych użytkownika do zrobienia czegoś na Twoim systemie plików. Filtruj to tak, jakby to był rak zmieszany z aids. Dotyczy to użycia include I require na plikach, których ścieżka jest wykonana częściowo z danych wejściowych użytkownika.
  • Using eval, system, exec lub cokolwiek z tego typu z wejściem użytkownika.
  • Nie umieszczaj plików, których nie chcesz mieć w Internecie katalog.

Masz wiele rzeczy, które możesz przeczytać na stronie OWASP.

 59
Author: Arkh,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-06-02 15:15:54

Pamiętam dość śmieszny z phpBB. Plik cookie autologin zawierał seryjną tablicę zawierającą userId i zaszyfrowane hasło (bez soli). Zmień hasło na logiczne z wartością true i możesz zalogować się jako każdy, kim chcesz być. Nie kochasz słabych języków?

Kolejny problem, który miał phpBB był w wyrażeniu regularnym do podświetlania wyszukiwanych słów kluczowych, które miały callback( z e modifier), co umożliwiło wykonanie własnego kodu PHP - na przykład, system wywołuje niezabezpieczone systemy lub po prostu wypisuje plik konfiguracyjny, aby uzyskać login/hasło MySQL.

Więc podsumowując tę historię:

  • uważaj, aby PHP było weaktyped (md5( "secretpass" ) == true ).
  • bądź ostrożny z całym kodem, który może być użyty w wywołaniu zwrotnym (lub, co gorsza, eval).

I oczywiście są jeszcze inne kwestie, o których wspomniałem przede mną.

 12
Author: CharlesLeaf,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-06-01 17:53:14

Innym problemem bezpieczeństwa na poziomie aplikacji, z którym widziałem, że CMSE mają do czynienia, jest niewystarczająca autoryzacja dostępu do strony lub funkcji. Innymi słowy, bezpieczeństwo jest ustawiane przez wyświetlanie linków tylko wtedy, gdy użytkownik jest uprawniony do wyświetlania tych linków, ale nie sprawdza w pełni, czy konto użytkownika jest uprawnione do wyświetlania strony lub korzystania z funkcji, gdy znajdują się na stronie.

Innymi słowy, konto administratora ma linki wyświetlane, aby przejść do stron zarządzania użytkownikami. Ale strona zarządzania użytkownikami sprawdza tylko, czy użytkownik jest zalogowany, a nie czy jest zalogowany i admin. Zwykły użytkownik loguje się, ręcznie wpisuje URI strony administratora, a następnie ma pełny dostęp administratora do stron zarządzania użytkownikami i tworzy swoje konto na koncie administratora.

Zdziwiłbyś się, ile razy widziałem takie rzeczy nawet w aplikacjach do koszyka, gdzie dane CC użytkownika są widoczne.

 3
Author: Zak,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-06-01 17:44:20

Największym z nich, o którym tak wiele osób zdaje się zapominać lub nie zdawać sobie sprawy, jest to, że każdy może zamieścić dowolne dane do Twoich skryptów, w tym pliki cookie i sesje itp. I nie zapominaj, że to, że użytkownik jest zalogowany, nie oznacza, że może wykonać dowolną czynność.

Na przykład, jeśli masz skrypt, który obsługuje dodawanie / edycję komentarza, możesz mieć to: 

if ( userIsLoggedIn() ) {
    saveComment( $_POST['commentid'], $_POST['commenttext'] )
}
Widzisz, co się stało? Zaznaczono, że użytkownik jest zalogowany, ale nie sprawdzono, czy użytkownik posiada komentarza, lub jest w stanie edytować komentarz. Co oznacza, że każdy zalogowany użytkownik może dodawać ID komentarza i treść oraz edytować komentarze innych!

Kolejną rzeczą, o której należy pamiętać, dostarczając oprogramowanie innym, jest to, że konfiguracje serwerów różnią się bardzo. Gdy dane są publikowane, możesz chcieć to zrobić, na przykład: 

if (get_magic_quotes_gpc())
    $var = stripslashes($_POST['var']);
else
    $var = $_POST['var'];
 3
Author: DisgruntledGoat,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-06-02 13:47:45

Tak wiele..

Szereg odpowiedzi tutaj wymieniają konkretne vuls pamiętają lub ogólne "rzeczy, o które martwię się pisząc webapp", ale jeśli chcesz dość wiarygodną listę większości zgłoszonych luk znalezionych historycznie, to nie zrobisz znacznie gorzej niż przeszukanie National Vulnerability Database

Istnieje 582 luki zgłoszone w Joomla lub Joomla addons, 199 dla Wordpress i 345 dla Drupal dla Ciebie trawienie.

Dla ogólnego zrozumienia common webapp vuls, projekt OWASP Top Ten został niedawno zaktualizowany i jest niezbędną lekturą dla każdego programisty.

  • A1: Wstrzyknięcie
  • A2: Cross - Site Scripting (XSS)
  • A3: uszkodzone uwierzytelnianie i zarządzanie sesją
  • A4: Niepewne Bezpośrednie Odniesienia Do Obiektów
  • A5: Cross-Site Request Forgery (CSRF)
  • A6: Błąd W Konfiguracji Zabezpieczeń
  • A7: Niepewna Kryptografia Storage
  • A8: Brak ograniczenia dostępu do URL
  • A9: Niewystarczająca Ochrona Warstwy Transportowej
  • A10: nieodwracalne przekierowania i przekierowania
 3
Author: Cheekysoft,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-06-03 11:19:39

Cztery wielkie w moim umyśle:

  • używanie exec na niezaufanych danych / kodzie (lub ogólnie)
  • dołączanie plików ze zdalnych adresów URL do lokalnego wykonywania
  • włączenie Registry globals tak, że get I post zmiennych uzyskaj automatycznie przypisane wartości zmiennych.
  • Brak ucieczki wprowadzonych danych db/ zezwalanie na ataki SQL injection (zwykle dzieje się tak, gdy nie używa się warstwy DB API)
 2
Author: Zak,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-06-01 17:55:57

Wyłącz POST z innej domeny / IP, aby boty nie mogły się zalogować/przesłać formularzy.

 1
Author: Arshdeep,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-06-01 17:45:15

Ludzie , największym zabezpieczeniem jest człowiek głupota . Trust, review code. Potrzebujesz specjalnego zespołu, który przejrzy wszystko, co dodano jako dodatkowy kod w aplikacji, problem cms to outsourcing, przychody, WordPress, Drupal, Joomla i inne popularne cms, takie jak domyślne instalacje, są one naprawdę w bardzo dobrym punkcie bezpieczne. Problem pojawia się, gdy zostawiasz ludzi, aby dodali dodatkowy kod w aplikacji, bez dobrej recenzji (lub lepiej, bez testów penetracyjnych). To jest punkt, w którym WordPress i Joomla mają słabość, tam ponownie tak wiele plugin N twórców motywów, jest tak wiele zatwierdzeń, setki przestarzałych wtyczek N tematów outhere.... Więc imho, jeśli jesteś w stanie zbudować silny zespół, dobry plan bezpieczeństwa, szkolić swoich współpracowników i nauczyć ich, jak kodować bezpiecznie, i z wszystkimi innymi komentarzami przed moimi, wtedy będziesz mógł przejść dalej i powiedzieć: ei cześć to mój cms, i to trochę bardziej bezpieczny niż wszystkie inne cms w sieci;)

 0
Author: StefanoWP,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2019-10-11 01:30:14

Oto potencjalna pułapka zwłaszcza dla adminów forum, ale także dla każdego, kto koduje formularz z rozwijanym selektorem, ale nie potwierdza, że wysłana odpowiedź była rzeczywiście jedną z dostępnych opcji.

Na studiach zdałem sobie sprawę, że selektor 'kraju' użytkownika w phpBB nie ma takiej walidacji.

Na naszym szkolnym forum, zamiast "Stany Zjednoczone" czy "Afganistan", mój kraj może być wszystkim, bez względu na to, jak głupi, czy brudny. Wszystko czego potrzebowałem to formularz html. Zajęło moi koledzy z klasy kilka dni, aby dowiedzieć się, jak to zrobiłem, ale wkrótce wszystkie "fajne dzieci" miały Śmieszne zwroty zamiast krajów wyświetlanych pod ich nazwami użytkowników.

Pójście do geek college było niesamowite. : D

 -2
Author: Steve,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-01-18 04:54:01