Oto kontekst:środowisko produkcyjne - strona błędu http 500 - brak stosu arkuszy proszę
Pracuję dla bardzo dużego przedsiębiorstwa. Tutaj mamy wiele serwerów WebSphere Application Server, z których każdy ma wiele aplikacji internetowych Java EE. Większość (ale nie wszystkie) z tych aplikacji zawierają specjalne dyrektywy w pliku web.xml w celu wyświetlenia niestandardowej strony błędu po wystąpieniu nieoczekiwanego wyjątku. Oto przykład:
<error-page>
<error-code>500</error-code>
<location>/500.jsp</location>
</error-page>
Robiąc to, oczywiście, staramy się pokazać przyjazną stronę błędu dla naszych klientów, ale poza tym, to głównie na celu ukrycie stacktraces które są zazwyczaj uwzględniane w standardowych http 500 stron błędów .
Co należy wiedzieć, te stosy zawierają wiele wrażliwych danych, takich jak nazwy paczek, nazwy klas, a nawet nazwy metod. Najgorsze, czasem te stosy zawierają wyjątki SQL, które często ujawniają, które oprogramowanie serwera baz danych jest używane. Nawet najgorsze, czasem te stosy zawierają ścieżki do plików i folderów, które z kolei mogą ujawnić, w której rodzinie systemów operacyjnych działa nasz serwer WebSphere Application Server.
Czy muszę podać wszystkie inne, jeszcze bardziej wrażliwe dane, które mogą zostać ujawnione przez te stosy stosów? (Nazwy użytkowników, numery portów, adresy IP, nazwy komputerów/serwerów, nazwy obiektów JNDI ...)
Nie ma tu dużych niespodzianek, więc każde duże przedsiębiorstwo musi ukryć te stosy pieniędzy wśród swoich klientów.
Ale tu jest nasz problem:
Sometime, nawet strona błędu zwyczaj dobrze skonfigurowany w pliku web.xml, WebSphere wysyła podstawową stronę błędu do przeglądarki internetowej klientów. Rozumiem bardzo dobrze, dlaczego to robi WebSphere. Jako przykład, wiem, że gdy nagłówki odpowiedzi HTTP są już zatwierdzone, serwer WebSphere nie może zresetować swojego bufora, aby wysłać niestandardową stronę błędu, a następnie nie może zrobić nic lepszego niż wysłanie podstawowej strony błędu.
Oto moje pytanie:
(1) Czy jest możliwe aby skonfigurować WebSphere więc nigdy nie obejmuje wszelkie StackTrace w swojej podstawowej stronie błąd? W ten sposób, nawet jeśli z jakiegoś powodu technicznego firma WebSphere nie może wysłać naszej niestandardowej strony błędu, przynajmniej podstawowa strona błędu nie będzie zawierała żadnych poufnych danych.
Jak możemy to zrobić?
Dziękujemy,
Nie można odpowiedzieć na konkretne pytanie o wyłączenie ślad stosu, ale nie masz serwer WWW lub serwera proxy w z przodu serwera WebSphere, gdzie można ustawić tam stronę błędu? – dbreaux
Kiedy otrzymasz domyślną stronę błędu, używasz serwera WWW przed WAS i przechodzisz przez wtyczkę http? – ams
Korzystamy z internetowego serwera informacyjnego Microsoft przed naszymi serwerami WebSphere i używamy wtyczki WebSphere (filtr ISAPI) do przekazywania żądań HTTP do naszych serwerów WebSphere. Ponadto używamy konsoli administracyjnej WebSphere do generowania plików "plugin-cfg.xml". Nie możemy edytować tych plików (ponieważ jeśli je edytujemy w celu ich ulepszenia, stale będziemy je ponownie edytować, aby zachować nasze poprawki). Tak więc, jeśli niektóre modyfikacje są wymagane w tych plikach, konsola administracyjna WebSphere będzie uwzględniać te modyfikacje podczas generowania plików "plugin-cfg.xml". – closingBrace