Jakie są najlepsze praktyki dotyczące zabezpieczania sekcji administracyjnej witryny internetowej? [Zamknięte]

Chciałbym wiedzieć, co ludzie uważają za najlepsze praktyki w zakresie zabezpieczania sekcji administracyjnej witryn internetowych, w szczególności z punktu widzenia uwierzytelniania / dostępu.

Oczywiście są rzeczy oczywiste, takie jak używanie SSL i rejestrowanie całego dostępu, ale zastanawiam się, gdzie powyżej tych podstawowych kroków ludzie uważają, że pasek jest ustawiony.

Na przykład:

• Czy polegasz tylko na tym samym mechanizmie uwierzytelniania, którego używasz w przypadku zwykłych użytkowników? Jeśli nie, to co?
• Czy działasz w sekcji Administracja w tej samej „domenie aplikacji”?
• Jakie kroki należy podjąć, aby uniemożliwić odkrycie sekcji administratora? (czy też odrzucasz całą sprawę „niejasności”)

Jak dotąd sugestie respondentów obejmują:

• Wprowadź sztuczną pauzę po stronie serwera do każdego sprawdzania hasła administratora, aby zapobiec atakom siłowym [grafika dewelopera]
• Używaj oddzielnych stron logowania dla użytkowników i administratora przy użyciu tej samej tabeli DB (aby zatrzymać XSRF i kradzież sesji, zapewniając dostęp do obszarów administracyjnych) [Thief Master]
• Rozważ także dodanie natywnego uwierzytelniania serwera internetowego do obszaru administracyjnego (np. Przez .htaccess) [Thief Master]
• Rozważ zablokowanie adresu IP użytkowników po kilku nieudanych próbach zalogowania się przez administratora [Thief Master]
• Dodaj captcha po nieudanych próbach logowania przez administratora [Thief Master]
• Zapewnij równie silne mechanizmy (przy użyciu powyższych technik) zarówno użytkownikom, jak i administratorom (np. Nie traktuj administratorów w specjalny sposób) [Lo'oris]
• Rozważ uwierzytelnianie drugiego poziomu (np. Certyfikaty klienta, karty inteligentne, miejsce na karty itp.) [JoeGeeky]
• Zezwalaj na dostęp tylko z zaufanych adresów IP / domen, dodaj sprawdzanie do podstawowego potoku HTTP (przez np. HttpModules), jeśli to możliwe. [JoeGeeky]
• [ASP.NET] Zablokuj IPrincipal i Principal (uczyń je niezmiennymi i niewliczalnymi ) [JoeGeeky]
• Federate Rights Elevation - np. Wyślij e-maila do innych administratorów, gdy uprawnienia któregokolwiek administratora zostaną zaktualizowane. [JoeGeeky]
• Rozważ szczegółowe prawa dla administratorów - np. Zamiast praw opartych na rolach, zdefiniuj prawa do poszczególnych działań na administratora [JoeGeeky]
• Ogranicz tworzenie administratorów - np. Administratorzy nie mogą zmieniać ani tworzyć innych kont administracyjnych. Użyj do tego zablokowanego klienta „superadmin”. [JoeGeeky]
• Rozważ certyfikaty SSL po stronie klienta lub piloty typu RSA (tokeny elektroniczne) [Daniel Papasian]
• Jeśli używasz plików cookie do uwierzytelniania, użyj oddzielnych plików cookie dla stron administratora i zwykłych, np. Umieszczając sekcję administratora w innej domenie. [Daniel Papasian]
• Jeśli jest to praktyczne, rozważ pozostawienie witryny administratora w prywatnej podsieci, poza publicznym Internetem. [John Hartsock]
• Ponowne wystawianie biletów autoryzacji / sesji podczas przechodzenia między kontekstami administratora / normalnego użytkowania witryny [Richard JP Le Guen]

To wszystko są dobre odpowiedzi ... Generalnie lubię dodać kilka dodatkowych warstw do moich sekcji administracyjnych. Chociaż użyłem kilku odmian tematu, zazwyczaj obejmują one jedną z następujących:

• Uwierzytelnianie drugiego poziomu : może to obejmować certyfikaty klienta (np. Certyfikaty x509), karty inteligentne, obszar kart itp.
• Ograniczenia domeny / adresu IP : w tym przypadku tylko klienci pochodzący z zaufanych / weryfikowalnych domen; takie jak podsieci wewnętrzne; są wpuszczane do strefy administratora. Zdalni administratorzy często przechodzą przez zaufane punkty wejścia VPN, więc ich sesja byłaby weryfikowalna i często jest również chroniona kluczami RSA. Jeśli korzystasz z ASP.NET, możesz łatwo przeprowadzić te sprawdzenia w potoku HTTP za pośrednictwem modułów HTTP, co zapobiegnie otrzymywaniu przez aplikację żadnych żądań, jeśli testy bezpieczeństwa nie zostaną spełnione.
• Zablokowana autoryzacja IPrincipal i Principal-based : Tworzenie niestandardowych zasad jest powszechną praktyką, chociaż częstym błędem jest uczynienie ich modyfikowalnymi i / lub wyliczalnymi prawami. Chociaż nie jest to tylko kwestia administratora, jest ważniejsza, ponieważ tutaj użytkownicy mogą mieć podwyższone prawa. Upewnij się, że są niezmienne i niewliczalne. Ponadto upewnij się, że wszystkie oceny do Autoryzacji są dokonywane na podstawie Zleceniodawcy.
• Podniesienie uprawnień federacyjnych : Gdy dowolne konto otrzyma określoną liczbę uprawnień, wszyscy administratorzy i szef bezpieczeństwa zostaną natychmiast powiadomieni pocztą elektroniczną. Daje to pewność, że jeśli atakujący podniesie prawa, wiemy od razu. Prawa te zazwyczaj dotyczą praw uprzywilejowanych, prawa do wglądu do informacji chronionych prywatnością i / lub informacji finansowych (np. Kart kredytowych).
• Przyznawaj prawa oszczędnie, nawet administratorom : Wreszcie, w niektórych sklepach może to być nieco bardziej zaawansowane. Prawa autoryzacyjne powinny być możliwie dyskretne i powinny otaczać rzeczywiste zachowania funkcjonalne. Typowe podejście do bezpieczeństwa opartego na rolach (RBS) ma zwykle mentalność grupową . Z punktu widzenia bezpieczeństwa nie jest to najlepszy wzorzec. Zamiast `` Grup '', takich jak ` ` Menedżer użytkowników '', spróbuj bardziej je podzielić ( np. Utwórz użytkownika, Autoryzuj użytkownika, Podnieś / Odwołaj prawa dostępu itp ...). Może to wiązać się z nieco większym narzutem administracyjnym, ale zapewnia elastyczność przydzielania tylko praw, które są faktycznie potrzebne większej grupie administratorów. Jeśli dostęp jest zagrożony, przynajmniej mogą nie uzyskać wszystkich praw. Chciałbym zawrzeć to w uprawnieniach Code Access Security (CAS) obsługiwanych przez .NET i Java, ale to wykracza poza zakres tej odpowiedzi. Jeszcze jedno ... w jednej aplikacji administratorzy nie mogą zmieniać innych kont administracyjnych ani nadawać użytkownikom uprawnień administratora. Można to zrobić tylko za pośrednictwem zablokowanego klienta, do którego ma dostęp tylko kilka osób.

Jeśli strona wymaga logowania zarówno do zwykłych czynności, jak i administratorów, np. Forum, użyłbym oddzielnych loginów, które korzystają z tej samej bazy danych użytkowników. Gwarantuje to, że XSRF i kradzież sesji nie pozwolą osobie atakującej na dostęp do obszarów administracyjnych.

Dodatkowo, jeśli sekcja administratora znajduje się w osobnym podkatalogu, zabezpieczenie tego za pomocą uwierzytelniania serwera WWW (na przykład .htaccess w Apache) może być dobrym pomysłem - wtedy ktoś potrzebuje zarówno tego hasła, jak i hasła użytkownika.

Przesłonięcie ścieżki administratora prawie nie daje żadnego zysku - jeśli ktoś zna prawidłowe dane logowania, najprawdopodobniej może również znaleźć ścieżkę do narzędzia administracyjnego, ponieważ albo wyłudził je, albo wprowadził do keylogera, albo uzyskał je za pomocą inżynierii społecznej (co prawdopodobnie ścieżka też).

Przydatna może być również ochrona typu brute force, taka jak blokowanie adresu IP użytkownika po 3 nieudanych logowaniach lub wymaganie CAPTCHA po nieudanym logowaniu (nie przy pierwszym logowaniu, ponieważ jest to bardzo irytujące dla legalnych użytkowników).

• Odrzucam niejasność
• Używanie dwóch systemów uwierzytelniania zamiast jednego to przesada
• Dla użytkowników należy również zrobić sztuczne przerwy między próbami
• Blokowanie adresów IP nieudanych prób powinno być również wykonywane dla użytkowników
• Silne hasła powinny być również używane przez użytkowników
• Jeśli uważasz, że captcha są w porządku, zgadnij co, możesz ich użyć również dla użytkowników

Tak, po napisaniu tego zdaję sobie sprawę, że tę odpowiedź można podsumować jako „nic specjalnego dla logowania administratora, są to wszystkie funkcje bezpieczeństwa, które powinny być używane przy każdym logowaniu”.

Jeśli używasz tylko jednego loginu dla użytkowników, którzy mają zarówno uprawnienia zwykłego użytkownika, jak i uprawnienia administratora, ponownie wygeneruj ich identyfikator sesji (czy to w pliku cookie, czy w parametrze GET, czy w jakimkolwiek innym ...), gdy nastąpi zmiana poziomu przywilej ... przynajmniej.

Więc jeśli się zaloguję, zrobię kilka normalnych rzeczy użytkownika, a następnie odwiedzę stronę administratora, ponownie wygeneruję mój identyfikator sesji. Jeśli następnie przejdę ze strony administratora do zwykłej strony użytkownika, ponownie wygeneruj mój identyfikator.

Miej dobre hasło administratora.

Nie "123456"tylko sekwencja liter, cyfr i znaków specjalnych wystarczająco długa, powiedzmy 15-20 znaków. Lubię "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".

Dodaj pauzę przy każdym sprawdzaniu hasła, aby zapobiec atakom siłowym.

Oto kilka innych kwestii do rozważenia:

1. Jedną z opcji do rozważenia, zwłaszcza jeśli zarządzasz komputerami administratorów lub są oni technicznie kompetentni, jest użycie czegoś opartego na certyfikatach SSL do uwierzytelniania klienta. Piloty RSA i inne mogą być również używane w celu zwiększenia bezpieczeństwa.
2. Jeśli w ogóle używasz plików cookie - być może do tokenu uwierzytelniania / sesji - prawdopodobnie chcesz mieć pewność, że pliki cookie są wysyłane tylko do stron administratora. Pomaga to złagodzić ryzyko, jakie stanowi kradzież plików cookie w Twojej witrynie poprzez przejęcie warstwy 1/2 lub XSS. Można to łatwo zrobić, ustawiając część administracyjną na innej nazwie hosta lub domenie, a także ustawiając bezpieczną flagę za pomocą pliku cookie.
3. Ograniczanie za pomocą adresu IP może być również sprytne, a jeśli masz użytkowników w całym Internecie, nadal możesz to zrobić, jeśli istnieje zaufana sieć VPN, do której mogą dołączyć.

Używamy Windows Authenticationdo dostępu administratora. Jest to najbardziej praktyczny sposób ochrony obszarów administracyjnych przy jednoczesnym oddzieleniu uwierzytelniania od tego, co dotyczy zwykłych użytkowników końcowych. Administrator systemu zarządza poświadczeniami dostępu użytkownika Admin i egzekwuje zasady dotyczące haseł na koncie użytkownika domeny.

Ścisłym sposobem jest posiadanie dwóch całkowicie różnych „farm”, w tym baz danych, serwerów i wszystkich innych, i przenoszenie danych z jednej farmy do drugiej. Większość nowoczesnych, wielkoskalowych systemów wykorzystuje to podejście (Vignette, SharePoint itp.). Zwykle jest to określane jako mające różne etapy „etap edycji” -> „etap podglądu” -> „etap dostarczania”. Ta metoda pozwala traktować zawartość / konfigurację w taki sam sposób jak kod (dev-> qa-> prod).

Jeśli jesteś mniej paranoikiem, możesz mieć jedną bazę danych, ale tylko sekcja administratora jest dostępna na serwerach „edytujących”. Mam na myśli tylko te skrypty / pliki edycyjne umieszczone na serwerze edycyjnym.

Oczywiście etap edycji powinien być dostępny tylko w lokalnym intranecie i / lub przy użyciu VPN.

Może się to wydawać przesadą i może nie być najłatwiejszym rozwiązaniem we wszystkich przypadkach użycia, ale jest to zdecydowanie najbardziej solidny sposób robienia rzeczy.

Zauważ, że takie rzeczy jak „mieć silne hasła administratora” są fajne, ale nadal pozostawiają administratora otwartego na wszelkiego rodzaju sprytne ataki.

W dużej mierze zależy to od rodzaju danych, które chcesz chronić (wymogi prawne itp.).

• Wiele sugestii dotyczy uwierzytelniania. Myślę, że powinieneś rozważyć użycie uwierzytelniania OpenId / Facebook jako logowania. (Najprawdopodobniej wydadzą więcej zasobów na bezpieczeństwo uwierzytelniania niż Ty)

• Zapisuj zmiany, a także aktualizuj wartości w bazie danych. W ten sposób możesz cofnąć zmiany od użytkownika X lub między datą X i Y.

Nie zauważyłem, żeby ktoś wspomniał o przechowywaniu / sprawdzaniu hasła administratora. Proszę, proszę, proszę nie przechowywać PW w postaci zwykłego tekstu, a najlepiej nawet nie coś, co można odwrócić - użycie coś jak osolonej hash MD5 tak, że przynajmniej jeśli ktoś stanie odzyskać zapamiętaną „hasło” oni nie mają cokolwiek okropnie pożytecznego, chyba że mają też twój plan solny.

Dodaj pole hasła i pytanie bezpieczeństwa, które Administrator będzie znał, np. Jakie było imię Twojej pierwszej dziewczyny, lub losuj pytania za każdym razem, gdy przeglądasz panel administracyjny.

Być może zawsze mógłbyś umieścić sekcję administracyjną w dużym katalogu, np

http://domain.com/sub/sub/sub/sub/sub/index.php

Ale to nie jest dobre, hah.

Być może mógłbyś dołączyć ciąg zapytania do strony głównej, na przykład:

http://domain.com/index.php?display=true

Kiedy to nastąpi, pojawi się pole nazwy użytkownika i hasła.