Pytanie:
Użytkownik nie może przejść do strony internetowej za pośrednictwem interfejsu użytkownika ze względu na uprawnienia, ale może przejść do strony, wklejając adres URL. Jak mam się przed tym chronić?
Michael
2017-10-10 21:33:32 UTC
view on stackexchange narkive permalink

W mojej aplikacji użytkownicy mają określone role, które mają uprawnienia. Te uprawnienia określają, które elementy interfejsu użytkownika są dla nich dostępne na ekranie głównym. Wiele elementów prowadzi do innych stron, których wielu użytkowników nie widzi, ponieważ ich uprawnienia nie pozwalają im przejść do tej strony internetowej.

Na przykład przycisk o nazwie button1 links do losowej strony w aplikacji, powiedzmy http://www.example.com/example.jsp . Jednak użytkownik John ma ustawione uprawnienia, które nie pozwalają mu zobaczyć button1 . Dlatego Jan nie może przejść do http://www.example.com/example.jsp.

Problem polega na tym, że jeśli jestem zalogowany jako John, i Wklejam ten adres URL i przenosi mnie do strony.

Oczywiście jest to ogromne zagrożenie bezpieczeństwa, jeśli osoba atakująca uzyska adres URL, na przykład do strony administratora. Jak więc mogę się przed tym chronić? Czy muszę weryfikować użytkownika dla każdej strony, sprawdzając uprawnienia i upewniając się, że mogą tam być?

W tej aplikacji są setki stron i wydaje się, że jest to bardzo zbędne i nieefektywne do włączenia kod na każdej stronie, aby to zrobić. Czy jest na to łatwiejszy sposób niż metoda, o której wspomniałem?

Ciekawe, czy jest to uważane za ten sam problem co „[Wymuszone przeglądanie] (https://www.owasp.org/index.php/Forced_browsing)”?Ta strona opisuje to jako znajdowanie stron, które nigdy nie miały być publiczne, a nie omijanie sprawdzania uprawnień użytkowników.
@Michael Jeśli wykonanie kodu na każdej stronie w rzeczywistości wymaga modyfikacji każdej strony z osobna, prawdopodobnie robisz również inne rzeczy źle.Jeśli nie masz możliwości przeprowadzenia kontroli bezpieczeństwa i poprawności w całej witrynie, dodaj je raczej wcześniej niż później.Czy programiści mają jakieś szkolenie w zakresie bezpieczeństwa?Wszędzie są czerwone flagi, a naprawienie rzeczy, które znajdziesz, pozostawi rzeczy, których nie znalazłeś, nie naprawione.
Ponieważ wygląda na to, że twoja aplikacja jest oparta na serwletach, warto przyjrzeć się Spring Security (nie musisz używać Springa, aby go używać, mimo że Spring jest niesamowity).
Tak, każda strona i każde destrukcyjne działanie i każde działanie, które ujawnia prywatne dane.To, co tu masz, nazywa się „problemem przekrojowym”
Uprawnienia nie powinny być wymuszane przez po prostu ukrywanie elementów UI;), ale dzięki odpowiedziom myślę, że teraz to rozumiesz
Zawsze próbuję zmienić adres URL dla przyjemności.Kiedy jest tylko enable.php, próbuję na przykład disable.php.
Jeśli obecnie przeprowadzasz kontrole bezpieczeństwa na poziomie klienta (co jest przyjemne, aby uniknąć niepotrzebnych zapytań do serwera, ale w żaden sposób nie jest zabezpieczone), możesz mieć inne problemy z bezpieczeństwem, takie jak wstrzyknięcia SQL.Upewnij się, że Twój serwer prawidłowo obsługuje wszystkie dane, które rzuca na niego klient (i tak, ponieważ wszyscy już wspominali o Twoim serwerze, muszą upewnić się, że aktualnie zalogowany użytkownik może wykonać bieżące zapytanie HTTP).
Nie przeczytałem magicznych słów w żadnej odpowiedzi.**Zrobić.Nie.Zaufanie.Wejście.Zawsze.**.
@usr-local-ΕΨΗΕΛΩΝ Absolutnie, ta jedna zasada dokładnie zastosowana prowadzi do rozsądnego bezpieczeństwa.
@danbru1211 Myślałem, że przypadkowo włamałem się do sieci, dopóki nie zdałem sobie sprawy, że to tylko wersja demonstracyjna produktu, który firma sprzedaje.Hasło „security” było skrótem „md5” po stronie klienta i całkowicie się zepsuło, jeśli zrobiłeś coś podobnego do tego, co opisałeś.Jest to jednak świetny sposób na wykonanie naprawdę podstawowych testów za pomocą pióra.
Mam skrypt GreaseMonkey, który pozwala mi zobaczyć ** wszystkie ukryte elementy ** na stronie po naciśnięciu ** tylko jednego klawisza **!Wyobraź sobie tylko, co mogę zrobić z Twoją witryną, jeśli faktycznie zechcę przeczytać kod źródłowy!
„* Problem polega na tym, że jeśli jestem zalogowany jako Jan *” - Dlaczego w ogóle możesz logować się na konta innych osób?
Implementacja interfejsu `javax.servlet.Filter` jest tym, czego chcesz.Umożliwia przetworzenie każdego żądania.Btw jsp jest rażąco przestarzały i jeśli nie jest to projekt uniwersytecki, należy bezwzględnie porzucić Java EE i przejść do bardziej nowoczesnych frameworków, które mają wbudowane wszystkie te podstawowe potrzeby.
Przepraszamy, ale wygląda na to, że nie rozumiesz w ogóle podstawowych zabezpieczeń aplikacji internetowych.Powinieneś rzucić okiem na [OWASP Top Ten] (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project).
Zdumiewa mnie, jak powszechna jest ta sytuacja ...
Siedem odpowiedzi:
Trickycm
2017-10-10 21:43:34 UTC
view on stackexchange narkive permalink

Czy muszę weryfikować użytkownika dla każdej strony?

Oczywiście. Nie tylko każda strona, ale każde żądanie do uprzywilejowanego zasobu, np. Żądanie POST aktualizacji danych, usunięcia, przeglądania itp. Nie chodzi tylko o przeglądanie stron, chodzi o kontrolowanie, kto może co robić w Twoim systemie.

Wygląda na to, że cały system uwierzytelniania i uprawnień jest uszkodzony w obecnej implementacji. Kroki, aby temu zaradzić, są zbyt szerokie dla tej jednej odpowiedzi. Warto byłoby przeszukać to forum i szerszą sieć, aby znaleźć rozwiązania odpowiednie dla twojego frameworka (JSP, ASP.Net, PHP itp.). Większość platform ma gotowe funkcje umożliwiające rozwiązanie tego problemu.

Dobrym początkiem byłby ten przewodnik wysokiego poziomu od OWASP: Bezpieczeństwo operacyjne: interfejsy administracyjne.

Pragnę tylko powtórzyć, ponieważ pańska odpowiedź nie jest błahostką na etapie PO: tak, to jest absolutnie poprawna i jedyna odpowiedź.Każda strona musi odpowiednio egzekwować zasady bezpieczeństwa.Wygląda na to, że wszystko, co obecnie jest na miejscu, to zabezpieczenia po stronie klienta, które w rzeczywistości nie zapewniają żadnych zabezpieczeń.Istnieją sposoby na napisanie kodu tak, aby można było łatwo zastosować zabezpieczenia na każdej stronie, ale nie ma odpowiedzi, która nie wiąże się z wymuszaniem bezpieczeństwa przy każdym indywidualnym żądaniu.W przeciwnym razie nie masz żadnego zabezpieczenia.
Aby być nieco bardziej precyzyjnym niż to, co mówisz Trickycm, najlepiej byłoby znaleźć ujednolicone rozwiązanie do obsługi zarówno linków nawigacyjnych / przycisku / ... jak i bezpośredniej nawigacji URL.Ponieważ jest ujednolicony, masz znacznie mniejsze szanse na zapomnienie o jednej rzeczy.Bo jeśli tak nie jest, oznacza to, że zawsze musisz obsługiwać co najmniej dwie różne deklaracje tego samego zabezpieczenia (uwaga: mam to obecnie i muszę to ujednolicić,: 3).
Uwaga: ** żądania AJAX ** też są żądaniami i ** powinny zostać zweryfikowane **.Nie ma znaczenia, że to konkretne żądanie AJAX powinno nastąpić tylko ze strony, która już zweryfikowała użytkownika.Wiem, że odpowiada to „każdemu żądaniu” w odpowiedzi.po prostu upewniając się, że OP też to wie.
Dodatkowy punkt: To sprawdzenie musi być wykonane ** na serwerze ** - a nie przez kod javascript, który jest (lub nie) uruchomiony na kliencie.Złośliwy użytkownik może uniknąć uruchomienia kodu javascript.
Wreszcie: używanie javascript do ukrywania linków, do których użytkownik nie ma dostępu, jest w porządku - ale jest to kwestia posiadania fajnego interfejsu użytkownika, a nie bezpieczeństwa.
Przydatne może być umieszczenie terminu „autoryzacja” gdzieś w tym poście, ponieważ jest to również powszechny termin opisujący sprawdzanie / zarządzanie uprawnieniami, więc może być pomocny w wyszukiwaniu.
@MartinBonner Wolałbym "ukryć" linki w PHP - może być wolniejsze, ale jeśli HTML nigdy nie zostanie wygenerowany dla tych linków, klient / użytkownik nie byłby mądrzejszy, nawet gdyby przeczesywał kod źródłowy przez przeglądarkęinspektor.
@psosuna Dlaczego miałoby to znaczenie, jeśli klient / użytkownik może znaleźć adresy URL?Nie mogą * zrobić * z nimi nic.Jeśli spróbują użyć tych adresów URL, serwer powie po prostu „Przepraszamy, nie jesteś administratorem”.
@immibis ze względu na czystość, jeśli w ogóle.Może się zdarzyć, że w witrynie znajduje się * ta jedna strona *, która nie wymusza bezpieczeństwa (tak jak powinno!), A jej adres można znaleźć podczas inspekcji źródła po stronie klienta.Aby złagodzić tę możliwość, lepiej tego nie ujawniać, prawda?Lepiej bezpiecznie niż przepraszam, mówię.
@psosuna: [wzruszając ramionami] Nie obchodzi mnie, gdzie ukrywasz linki.Chodzi o to, że ukrywanie linków nie dotyczy tak naprawdę bezpieczeństwa, chodzi o dobry UX.(Chociaż jest to jeden przypadek, w którym dobry UX z pewnością nie koliduje z bezpieczeństwem).
@MartinBonner całkowicie się z tobą zgadzam, ale generalnie bezpieczeństwo dotyczy warstw.I chociaż ukrywanie linków nie jest oczywiście zabezpieczeniem, może pomóc.Jeśli gdzieś w sprawdzaniu bezpieczeństwa jest błąd, brak linków nadal coś dodaje, więc wolę też nie wysyłać danych do klientów w pierwszej kolejności.(Widzę to jako kolejną warstwę).
Ze wszystkich zamiarów i celów wszelkie zasoby / żądania, których serwer nie uwierzytelnia i nie autoryzuje bezpośrednio, należy uznać za publiczne.Jeśli nie sprawdzisz, czy żądanie X pochodzi od zarejestrowanego użytkownika z odpowiednimi uprawnieniami, żądanie X jest publiczne i każdy może uzyskać do niego dostęp, niezależnie od tego, co zapewni Twój interfejs użytkownika.
Stilez
2017-10-11 22:42:57 UTC
view on stackexchange narkive permalink

Szybka odpowiedź brzmi: tak, jak już wiesz. Ale nie musi to być ogromna praca, o której myślisz. (Cała kwestia bezpieczeństwa może być duża, ale to tylko jedna jej część). Masz o wiele poważniejsze problemy.

Dlaczego to ma znaczenie

WSZYSTKO, co stworzysz, zostanie uderzone próbami jego rozwiązania. Ktoś będzie ciekawy. Ktoś zrobi coś, czego nigdy się nie spodziewałeś i co przeczy Twojemu myśleniu. Ktoś będzie zaciekawiony, złośliwy lub wścibski.

Powinieneś także przyjąć za pewnik, że Twoje oprogramowanie / aplikacja internetowa będzie mocno przetestowana przez automatyczne narzędzia . Serwery z portalami internetowymi (prawie każdego rodzaju) są wykrywane przez hakerów w ciągu kilkudziesięciu minut od pierwszego przejścia do trybu online i zaczynają być badane pod kątem jednego z tysięcy możliwych luk lub przeoczeń w zabezpieczeniach. Oznacza to, że badają, co dokładnie działa „za kulisami”, a także pod kątem wszelkich wykrywalnych błędów, które można wykorzystać (w walidacji danych, walidacji krzyżowej, wstrzykiwaniu kodu SQL lub binarnego, hakowaniu JavaScript, samym zapleczu, co słabości mogą powstać, zmuszając coś do awarii, jakie dane można ujawnić ...).

Twój (e) serwer (y) WWW będą sprawdzane w ten sposób, stale, pod kątem wszelkich możliwych błędów kodu WWW i błędów zaplecza, przez setki, jeśli nie tysiące zautomatyzowanych narzędzi. To tak samo dobrze jak ludzie i użytkownicy, a nie zamiast.

Czy wolałbyś, żeby to było daleko w tyle i mocno zwrócone na twoją uwagę przez krytyków, media i zirytowanych użytkowników, czy też doprowadziło do odpowiedzialności? A może wolisz to naprawić?

Jak to rozwiązać

W pewnym sensie nie jest to wielka praca. Tworzysz strukturę zabezpieczeń, a następnie każda strona importuje ją lub używa. Koncepcje, jak to zrobić, nie są trudne i są dobrze udokumentowane. Więc liczba stron nie jest duża.

Najtrudniejszą częścią pracy jest to, że bezpieczeństwo jest trudne . Twoim prawdziwym problemem jest to, że z faktu, że te problemy istnieją i zadajesz te pytania, nie masz wystarczającej wiedzy, aby mieć nadzieję na zrobienie tego bez pomocy. Poważnie. Ty. Zrobić. Nie.

Nie wiem, jaki masz zespół lub jakie masz zasoby. Potrzebujesz tego - i prawdopodobnie nie masz nadziei na zrobienie tego bez pomocy z zewnątrz.

Moje prawdziwe zmartwienie

To powiedziawszy, moim prawdziwym zmartwieniem nie jest aplikacja internetowa . To sposób myślenia sugeruje to pytanie.

Wyobraź sobie, że rozważam zakup lub używanie Twojej aplikacji.

Nie pomaga to ani nie zapewnia czytelnika, że ​​najwyraźniej traktujesz bezpieczeństwo jako po namyśle, zakłócenia w pracy lub niedogodności do naprawienia później (lub nie rozumiem tego wystarczająco, że do tej pory traktowałeś to w ten sposób), a być może problemy są naprawdę podstawowymi, takimi jak prawidłowe zakodowanie adresu URL przycisku .

Bezpieczeństwo to Twoja praca, ponieważ bez względu na to, jak wspaniałe są technicznie produkty / usługi i kimkolwiek są ich użytkownicy, Twoim prawdziwym produktem jest zaufanie i zapewnienie, że zaspokoisz moje potrzeby i nie spowodujesz poważnej katastrofy.

Mam powierzyć Twojej aplikacji moje dane? W tej chwili i przykro mi to mówić, myślę, że równie dobrze mógłbym sam opublikować to w Google+. Tak, to „taka zła” sytuacja i wrażenie, i nie, to nie jest wyolbrzymienie tego dla efektu.

Przepraszam.

Teraz, jeśli Twoja aplikacja jest dobra, zaangażuj kogoś innego.

Ta druga część wydaje się sugerować, że klienci decydują się na produkty w oparciu o zabezpieczenia.Z wyjątkiem niektórych bardzo, bardzo specyficznych nisz, jest to po prostu nieprawda, a z punktu widzenia biznesu okropnym pomysłem jest wydawanie więcej niż tylko niezbędna kwota na niefunkcjonalne wymagania, takie jak bezpieczeństwo jako startup.Tak, wszyscy tutaj nienawidzą tego sposobu myślenia, ale faktem jest, że użytkownicy nie dbają o bezpieczeństwo, a nawet jeśli to robili, nie mogliby ocenić, co jest bezpieczne, a co nie (nie wierz w to? Śmiało i sprawdźnumery użytkowników TextSecure / Signal z WhatsApp)
Myślisz z góry.Nie początkowo, nie.Ale kiedy stanie się znany poważny problem - tak.Gdy trafi na recenzje - tak.Kiedy media społecznościowe zaczną otrzymywać komentarze typu „Co się stało i jak to się mogło stać” przez więcej niż jedną lub dwie osoby - tak.Ludzie nie szukają aktywnie bezpieczeństwa, ale patrzą na recenzje i publiczną wiedzę, jeśli tam jest, i po pewnym czasie będzie.(Zgadzam się, że byłoby lepiej, gdyby najpierw spojrzeli, ale jeśli jest to poważny problem, jak wskazuje OP, będzie widoczny dość szybko - o tym, gdy coś się psuje i ktoś pisze o tym ze złością)
Silencer310
2017-10-11 02:46:02 UTC
view on stackexchange narkive permalink

Musisz sprawdzić poziom uprawnień użytkownika dla każdego żądania (GET, POST, PUT, DELETE). Przeglądanie strony, tak jak w Twoim przypadku, jest żądaniem GET. Użytkownik nie powinien również mieć możliwości wysłania prośby bez pozwolenia.

Teraz to, czy musisz dodać kod na każdej stronie aplikacji, zależy od struktury aplikacji. Na przykład, niektóre frameworki (Laravel, Express.JS) pozwalają na grupowanie tras i stosowanie filtru do każdego żądania dla tej trasy, i to jest miejsce, w którym umieszczasz kontrole. W przypadku aplikacji w zwykłym języku PHP kod powinien znajdować się na każdej stronie. Możesz użyć instrukcji „include”, aby zminimalizować powtarzanie całego bloku kodu.

HEAD lub jakiekolwiek inne [dziwne metody HTTP] (https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods) też (chyba że oczywiście * zawsze * je blokujesz).
psosuna
2017-10-11 04:11:22 UTC
view on stackexchange narkive permalink

Zostało to już powiedziane, ale tak, powinieneś zweryfikować swoje poświadczenia użytkownika na każdej stronie. Jeśli na przykład Twoja witryna korzysta z PHP, absolutnie najłatwiejszym sposobem na to jest zapisanie zalogowanego użytkownika i jego poziomu uprawnień w zmiennych sesji, a następnie zweryfikowanie tych zmiennych sesji na początku kodu. Są one wymazywane przy wylogowywaniu (jeśli utworzyłeś logikę wylogowania, aby wyczyścić te zmienne) lub limitu czasu sesji (czas oczekiwania można zdefiniować, ale myślę, że domyślnie jest to 5 minut bezczynności), więc nieautoryzowany użytkownik nie powinien mieć dostępu Strona. Inne technologie będą miały podobne działanie.

Naprawdę nie chcę brzmieć protekcjonalnie, kiedy to mówię, więc mam nadzieję, że nie widzisz tego w takim świetle, ale to jest rodzaj chleba z masłem . Jeśli w jakiś sposób się tego nie nauczyłeś lub nie natknąłeś się na to w swoich samodzielnych studiach, zdecydowanie sugeruję, abyś zwrócił na to uwagę i przeczytał nieco dokładniej na ten konkretny temat, ponieważ jest on bardzo ważny. Będziesz robił to raz po raz dla każdego podobnego zastosowania tego rodzaju.

Zwróć uwagę, że istnieją różne sposoby, aby to zrobić w prosty i skuteczny sposób, a osobistą sugestią ode mnie byłoby przećwiczenie kodowania według własnej logiki, aby w pełni zrozumieć, jak to się dzieje działa, zanim spróbujesz użyć frameworka. Przetestuj go z kilkoma metodami dostępu, a gdy będziesz zadowolony, możesz przyjrzeć się, jak różne struktury wykonują obsługę sesji użytkownika.

EDYTUJ : umieściłem to w komentarzu poniżej, ale w rzeczywistości jest to również dobre źródło informacji dla OP: https://www.w3schools.com/ php / php_sessions.asp

Jakie gwarancje bezpieczeństwa zapewnia PHP dla tych zmiennych sesji?Czy są przechowywane na komputerze klienta;jeśli nie, w jaki sposób klient identyfikuje swoją sesję?Czy dane po stronie klienta są szyfrowane?Czy istnieją zabezpieczenia przed udostępnianiem danych po stronie klienta?
Oto szybkie i łatwe wyjaśnienie sesji PHP: https://www.w3schools.com/php/php_sessions.asp.Informacje i zmienne sesji nie są przechowywane po stronie klienta, tylko po stronie serwera.Klucz jest dostarczany przez serwer do klienta.Klucz służy do identyfikacji sesji, w której aktualnie jest użytkownik.
@jpmc26 dodatkowy bok: PHP = Hypertext * Pre- * procesor.Oznacza to, że kod PHP działa po stronie serwera.Jest wykonywany przed HTML, więc jest wiele rzeczy, których nie trzeba przesyłać na komputer użytkownika.Dlatego PHP jest dobrą opcją do przeprowadzania uwierzytelniania, ponieważ dane wejściowe można zweryfikować przed wysłaniem odpowiedzi z powrotem do klienta.
Och, dobrze znam PHP jako technologię po stronie serwera.(Zarabiam na życie nad aplikacjami internetowymi, ale nie PHP.;)) Ale wiem, że * coś * musi być przechowywane po stronie klienta, aby sesja użytkownika była możliwa do zidentyfikowania.Stąd moje pytania o to, czy te dane są zaszyfrowane i co masz (aby zapobiec przechwyceniu sesji lub celowemu udostępnieniu klucza innemu użytkownikowi).Zobacz na przykład [tę krytykę] (https://security.stackexchange.com/a/18898/46979).Nie wiem, czy coś się zmieniło w ciągu ostatnich 5 lat.
@jpmc26 Myślę, że krytyka jest słabo ukierunkowana: chodzi o źle skonfigurowane serwery współdzielone, aby użytkownicy mieli dostęp do swoich danych.Zamiast szyfrowania, odpowiedzią jest umieszczenie sesji w katalogu, do którego inni użytkownicy nie mają dostępu;jeśli nie ma takiego katalogu, i tak będą mogli uzyskać dostęp do Twojego klucza odszyfrowywania.Nie ma to również nic wspólnego z przejmowaniem sesji, które ogólnie opisuje atakującego kradnącego identyfikator sesji * po stronie klienta *;szyfrowanie też by tam nie pomogło.
@jpmc26 Ze strachu przed wyjściem poza temat, zabezpieczasz sesje za pomocą tokenów CSRF.Każda akcja, którą wykonujesz, odświeża token (więc żądam czegoś z moim tokenem => serwer odsyła nowy token do użycia w następnej czynności).
Majid Khan
2017-10-10 22:11:12 UTC
view on stackexchange narkive permalink

Użytkownik nie może mieć możliwości przejścia do strony bez względu na to, czy wpisze adres, czy kliknie link.

Ogólnym rozwiązaniem problemu jest użycie kontroli dostępu opartej na rolach ( RBAC). Utwórz różne grupy i przypisz użytkownikom o równych uprawnieniach do odpowiedniej grupy. Podobnie grupuj strony internetowe i inne zasoby w różnych folderach; każdy należący do określonej grupy. Użyłem chgrp (zmień grupę), aby to osiągnąć w systemie z wbudowanym Linuksem z lekkim serwerem WWW. To samo można osiągnąć na serwerze WWW Apache, umieszczając plik .htaccess i odmawiając dostępu, jak wspomniano w przepełnieniu stosu.

W przypadku elementów interfejsu użytkownika będziesz musiał utworzyć różne strony (lub ukryć elementy, sprawdzając grupę). Będziesz musiał zidentyfikować użytkownika (zalogować go i określić odpowiednią grupę), a następnie wyświetlić strony internetowe zgodnie z uprawnieniami użytkownika.

Jester
2017-10-11 02:25:04 UTC
view on stackexchange narkive permalink

Krótka sugestia dotycząca implementacji, ponieważ masz pewne obawy dotyczące setek stron. Na przykład w ASP.NET MVC można utworzyć filtr globalny lub stronę „podstawową”, z której wszystkie inne mogłyby dziedziczyć.

Następnie kod, który jest zlokalizowany centralnie, mógłby sprawdzać kontekst / sesję użytkownika i porównaj je z listą praw / uprawnień / lub członkostwa w grupach dla bieżącej strony (może to być struktura danych na każdej stronie lub wyszukiwanie w bazie danych na podstawie nazwy strony itp.).

Readin
2017-10-14 07:44:13 UTC
view on stackexchange narkive permalink

Inne odpowiedzi były bardzo ogólne, więc dodam je, ponieważ wspomniano o stronach JSP, więc myślę, że mogę założyć, że pracujesz w Javie.

W związku z tym , najprawdopodobniej możesz użyć filtrów, aby kod był wykonywany za każdym razem, gdy wysyłane jest żądanie do aplikacji. Jeśli używasz struktury bezpieczeństwa, takiej jak Spring, możesz skonfigurować adresy URL, do których można uzyskać dostęp i przez kogo.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...