Czy ślad stosu powinien znajdować się w komunikacie o błędzie przedstawionym użytkownikowi?

45

Mam kłótnię w miejscu pracy i staram się dowiedzieć, kto ma rację i co należy zrobić.

Kontekst: intranetowa aplikacja internetowa, której nasi klienci używają do księgowości i innych rzeczy ERP.

Uważam, że komunikat o błędzie wyświetlany użytkownikowi (gdy wystąpi awaria) powinien zawierać jak najwięcej informacji, w tym ślad stosu. Oczywiście musi zaczynać się od ładnego „Wystąpił błąd, prześlij poniższe informacje programistom” dużymi, przyjaznymi literami.

Moje rozumowanie jest takie, że zrzut ekranu aplikacji, która uległa awarii, często stanowi jedyne łatwo dostępne źródło informacji. Jasne, możesz spróbować złapać administratora systemu (-ów) klienta, spróbować wyjaśnić, gdzie znajdują się twoje pliki dziennika itp., Ale to prawdopodobnie będzie powolne i bolesne (głównie rozmowa z przedstawicielami klienta).

Ponadto posiadanie natychmiastowych i pełnych informacji jest niezwykle przydatne w programowaniu, w którym nie musisz szukać plików dziennika, aby znaleźć to, czego potrzebujesz przy każdym wyjątku. (Ale można to rozwiązać za pomocą przełącznika konfiguracji).

Niestety zdarzyło się coś w rodzaju „audytu bezpieczeństwa” (nie mam pojęcia, jak to zrobili bez źródeł… ale cokolwiek) i narzekali na pełne komunikaty wyjątków, podając je jako zagrożenie bezpieczeństwa. Oczywiście klienci (przynajmniej jeden, o którym wiem) przyjęli to na pierwszy rzut oka i teraz żądają wyczyszczenia wiadomości.

Nie widzę, w jaki sposób potencjalny atakujący mógłby użyć śladu stosu, aby dowiedzieć się czegoś, czego wcześniej nie mógł zrozumieć. Czy są jakieś przykłady, udokumentowane dowody na to, że ktoś to zrobił? Myślę, że powinniśmy walczyć z tym głupim pomysłem, ale może jestem tu głupcem, więc ...

Kto ma rację

security error-handling Vilx-
źródło
25
Łał. Po prostu ... wow. „ Unfortunately there has been some kind of "Security audit"” - Poważnie? Co to za postawa? Audyty bezpieczeństwa są dla Twojej korzyści - aby ulepszyć twoje systemy, znaleźć problemy, zanim zrobią to źli ludzie. Naprawdę powinieneś rozważyć próbę współpracy z nimi, a nie przeciwko nim. Możesz także spróbować uzyskać więcej informacji na temat zabezpieczeń PoV w Information Security .
AviD
7
A tak przy okazji, audyt bezpieczeństwa niekoniecznie potrzebuje dostępu do kodu źródłowego, prawdopodobnie wykonali test penetracyjny czarnej skrzynki, symulując to, co zrobiłby złośliwy użytkownik - spróbuj zaatakować aplikację jako użytkownik. Chociaż zgadzam się, że dostęp do kodu źródłowego mógłby umożliwić znacznie bardziej skuteczną formę audytu. :-)
AviD
1
@AviD - prawdę mówiąc, nie wiem, co analizowali, ale z niektórych raportów widziałem, że to dla mnie test czarnej skrzynki. Szczerze mówiąc, nie chcę pracować przeciwko nim. Rzeczywiście, podobały mi się wiadomości, kiedy je usłyszałem. Ale ta ich szczególna „wrażliwość” wydaje mi się głupia. W każdej decyzji bezpieczeństwa należy porównać redukcję zagrożenia z redukcją użyteczności. W tym przypadku myślę, że znacznie bardziej zmniejsza użyteczność niż poprawia bezpieczeństwo.
Vilx-
1
Bardzo zgadzam się co do ważenia, ale nie zgadzam się co do jego zastosowania. Bardziej szkodzi bezpieczeństwu, niż myślisz, a także uważam, że twoja droga (sam to zrobiłem, dopóki nie rozmawiałem z niektórymi użytkownikami .....) jest gorsza pod względem użyteczności. Pomyśl o tym w kategoriach zadaniowych - jak powiedziała odpowiedź @ Jona, jego sposób na wykonanie pracy użytkownika jest znacznie lepszy. Użytkownik nie musi troszczyć się o stos (chyba że twoi użytkownicy są programistami ...) Ale moja wiedza jest bezpieczna - a ryzyko jest realne.
AviD
1
@AviD - Może możesz wskazać mi zasoby, które wyjaśniają, w jaki sposób śledzenie stosu może być niebezpieczne? Jestem gotów to zaakceptować, ale chcę czegoś więcej niż ogólną zasadę „pokaż tylko to, czego potrzebujesz”.
Vilx-

Odpowiedzi:

73

Staram się budować dziennik aplikacji, albo w DB, albo w pliku i zapisuję w nim wszystkie takie informacje. Następnie możesz nadać użytkownikowi numer błędu, który identyfikuje element dziennika, z którym związany jest błąd, abyś mógł go odzyskać. Ten wzorzec jest również przydatny, ponieważ można śledzić błędy, nawet jeśli użytkownicy nie zadają sobie trudu, aby je ze sobą zabrać, dzięki czemu można lepiej zrozumieć, gdzie są problemy.

Jeśli Twoja witryna jest zainstalowana w środowisku klienta i nie możesz do niej dotrzeć, możesz poprosić dział IT na miejscu, aby przesłał Ci fragment wyciągu na podstawie błędu nr.

Inną rzeczą, którą możesz wziąć pod uwagę, jest to, że systemowy e-mail zawiera szczegółowe informacje o błędach do skrzynki pocztowej, którą widzisz, abyś wiedział, kiedy coś idzie nie tak.

Zasadniczo posiadanie systemu, który przelewa się, gdy coś jest nie tak, nie budzi zaufania do użytkowników nietechnicznych - zwykle przeraża ich myślenie, że coś jest bardzo nie tak (np. Ile BSOD rozumiesz i jak to zrobić czujesz, kiedy się pojawia)?

Na stacktrace:

W .Net ślad stosu pokaże pełny ślad bezpośrednio w podstawowych zestawach MS, i ujawni szczegóły dotyczące używanych technologii i możliwych wersji. Daje to intruzom cenne informacje o możliwych słabościach, które można wykorzystać.

Jon Egerton
źródło
6
Podoba mi się twoja odpowiedź, ponieważ przedstawia „środkową drogę” - nie pokazuj, ale ułatwiaj wyszukiwanie wyjątków. Spróbuję teraz naciskać, mam nadzieję, że się zgodzą. Dziękuję Ci!
Vilx-
2
Myślę, że jest to w zasadzie standardowe podejście „dojrzałe”. Stacktrace daje również bogactwo informacji, jednak wciąż nie znalazłem rozwiązania, które może automatycznie rejestrować informacje o stanie wraz z stacktrace (bez zmian kodu wszędzie). Wygląda na to, że napisanie własnego debuggera i dołączenie go jest jednym z możliwych sposobów, ale nie jest łatwe do wdrożenia.
Daniel B
@DanielB: W aplikacjach internetowych można uzyskać pewne typowe rzeczy (takie jak identyfikator użytkownika, identyfikator klienta itp.) Z sesji / pamięci podręcznej - ponieważ są one utrzymywane „globalnie”, nawet taka ilość informacji może znacznie pomóc w odtwarzaniu błędów. Bardziej szczegółowe niż to jest bardzo trudne, jak mówisz.
Jon Egerton
2
Niektórzy użytkownicy bardzo krytycznych aplikacji wymagają natychmiastowego rozwiązania każdego błędu, który utrudnia normalny przebieg działalności. Cały proces komunikacji obejmujący różne rozdrobnienia tylko po to, aby narzędzie do rozwiązywania błędów, aby uzyskać stos błędów, może z łatwością zużyć 1 godzinę lub więcej, gdy błąd wystąpi późno w nocy lub w weekendy.
Tulains Córdova
1
@ user1598390: Uzgodniony, w którym to przypadku kopiowanie szczegółów błędu do monitorowanej skrzynki pomocy technicznej może przyspieszyć zbieranie informacji, do tego stopnia, że ​​personel pomocy technicznej wie, że coś jest zepsute, nawet zanim zrobi to użytkownik.
Jon Egerton
29

Tak, jest ich wiele.

Ślad stosu może ujawnić

  • jakiego algorytmu szyfrowania używasz
  • jakie są niektóre istniejące ścieżki na serwerze aplikacji
  • czy odpowiednio odkażasz wkład, czy nie
  • w jaki sposób Twoje obiekty są wewnętrznie wywoływane
  • jaka wersja i marka bazy danych kryje się za twoim frontonem?

... lista jest długa. Zasadniczo każda decyzja projektowa w dużej aplikacji może być istotna z punktu widzenia bezpieczeństwa i prawie wszystkie z nich mogą być przekazywane za pomocą nazw metod lub modułów. Pamiętaj, że nie oznacza to, że wyświetlanie śladu stosu nadal nie ma sensu, jeśli środowisko, do którego jest ono przekazywane, jest bezpieczne (np. Intranet zamiast strony internetowej), ale koszt bezpieczeństwa nie jest z pewnością równy zero .

Kilian Foth
źródło
6
W większości się zgadzam, ale niektóre z tych rzeczy nie powinny mieć znaczenia. Na przykład używany algorytm szyfrowania nie powinien być tajny, aby zabezpieczyć system.
Oleksi
3
Nie powinno to mieć znaczenia, ale świat jest niedoskonały i często ma to znaczenie. Dlatego tak ważna jest obrona głęboka (wykonywanie wielu rzeczy jednocześnie, które powinny wystarczyć, gdyby były doskonałe).
Kilian Foth,
3
Szczerze mówiąc, jeśli ślad stosu ujawnia coś , co mogłoby pomóc atakującemu, robisz to źle !
Mark Booth,
3
@MarkBooth statystycznie rzecz biorąc, prawdopodobnie są to robi źle. Nie, zdrap to - statystyczna pewność , że źle się rozumiesz. Czy naprawdę chcesz pozwolić atakującym znaleźć błędy w zabezpieczeniach, zanim to zrobisz?
AviD
1
@AviD - Nie, zgadzam się, najbardziej przekonującym powodem, aby nie wyświetlać śladów stosu użytkownikom, jest to, że nie mają pojęcia, co z nimi zrobić, a system rejestrowania powinien być zarówno bezpieczny, jak i przechwytywać znacznie więcej stanu niż zrzut ekranu strony internetowej, która kiedykolwiek mogłaby.
Mark Booth
15

Chodzi o to, że naszym zadaniem nie jest ułatwienie sobie. Naszym zadaniem jest ułatwienie użytkownikowi końcowemu. Dla nas ślad stosu wygląda jak niezwykle przydatna informacja dla programisty. Dla użytkownika wygląda to na kompletny bełkot, który nie jest w ogóle przydatny. Nawet jeśli powiesz im inaczej, nie internalizują tego. Jeśli uważasz, że trudno jest uzyskać te informacje od administratorów systemu, uzyskanie ich od użytkowników końcowych jest jeszcze gorsze.

Jeśli chodzi o bezpieczeństwo, możesz mieć rację, jeśli była to aplikacja komputerowa. W takim przypadku wydrukowanie śladu stosu nie zapewnia niczego, czego atakujący jeszcze nie wie. W aplikacji internetowej te informacje nie są już dostępne atakującemu. Rzeczywiście ujawniasz wewnętrzne szczegóły, które znacznie ułatwią atak .

Dlaczego nie ominąć obu źródeł obaw i automatycznie otrzymywać raporty o wyjątkach? W ten sposób nie musisz się już martwić, że ludzie nie zgłaszają błędów.

Karl Bielefeldt
źródło
2
Użytkownicy korzystają z szybkiej naprawy swojego problemu dzięki informacjom dostarczonym przez ślad stosu. Ale rozumiem o co ci chodzi.
Tulains Córdova
11

Spójrz na to pytanie IT Security SE . Krótko mówiąc, śledzenie stosu może dać atakującemu więcej informacji do pracy. Im więcej informacji ma atakujący, tym większe jest prawdopodobieństwo, że przeniknie on do twojego systemu. Nie oparłbym mojego bezpieczeństwa na fakcie, że ślady stosu są zawsze ukryte, ale nie oznacza to również, że powinieneś przekazać te informacje atakującym.

Mimo to możesz uzyskać większość korzyści z właściwego rejestrowania backendu. Jest to nieco mniej wygodne, ale prawdopodobnie nie warto ryzykować bezpieczeństwa systemu i denerwować klientów.

Oleksi
źródło
8

Możesz rozważyć niewyświetlanie śladu stosu z następujących powodów.

Bezpieczeństwo

Pokazanie śladu stosu ujawnia potencjalne powierzchnie ataku, które mogą być hakerami. Intranety nie są odporne na ataki hakerskie. Miałoby to zły wpływ na ciebie, gdyby Twoja sieć została zhakowana z powodu aplikacji, za którą jesteś odpowiedzialny

Doświadczenie użytkownika

Dla najlepszego wrażenia użytkownika ślad śledzenia to zbyt wiele informacji. Tak, właściwe informacje o stanie błędu powinny zostać zarejestrowane i zwrócone na nie uwagę inżyniera. Jednak zachęcanie użytkownika do robienia tego, co można zautomatyzować, nie będzie dla niego najlepsze.

Twoja reputacja

Za każdym razem, gdy na stronie wyświetla się ślad stosu, wygląda to źle. Większość ludzi nie ma pojęcia, co to jest, a to sprawia, że ​​czują, że witryna nie jest dla nich przyjazna. Dla tych, którzy wiedzą, co to jest, może to wskazywać, że aplikacja nie została dobrze przemyślana. Wiele źle napisanych aplikacji wyświetla zbyt często ślady stosu, ponieważ jest to ustawienie domyślne w niektórych środowiskach, takich jak ASP.Net.

Tom Resing
źródło
6
Jako programista, kiedy widzę ślad stosu na ekranie, moje bezpośrednie stwierdzenie brzmi: „Oto bozo, który nic nie wie o radzeniu sobie z błędami, mniej o nich dba, a prawdopodobnie jeszcze mniej o użytkownikach”. Inni obracają się wokół „to gówniane oprogramowanie, nie działa, nie działa, jego obsługa błędów nie działa” i „WTF .... Nie wykonuję dla niego tej pracy” To, co chce wiedzieć twój użytkownik, musi to naprawić. Jak działa śledzenie stosu.
mattnz
6

Krótka odpowiedź: w ekstranecie lub witrynie internetowej sensowne jest, aby nie pokazywać śladu stosu. W intranecie korzyści z pokazywania śledzenia stosu przewyższają jego ukrywanie.

Długa odpowiedź:

To samo przytrafiło mi się w pracy. Kiedyś myślałem, że jeśli aplikacja zawiedzie, powinna zawodzić głośno.

Ale potem wyjaśnili mi, że potencjalny haker może wywrzeć wpływ na wiele rzeczy z stacktrace.

Myślę, że nie ma potrzeby dowodu. Jest oczywiste, że im więcej haker wie o Twojej platformie, tym lepiej dla niego i że im mniej haker wie o Twojej platformie, tym lepiej dla Ciebie .

Również firmy nie chcą ujawniać, w jaki sposób haker włamał się do ich systemów.

Z drugiej strony jest to intranet i myślę, że korzyści wynikające z natychmiastowego dowiedzenia się, co poszło nie tak bez konieczności przeszukiwania pliku dziennika, ma ogromną zaletę, a ryzyko związane z bezpieczeństwem związane z wyświetlaniem śladu stosu w granicach firmy nie jest tak duże, jak oni mówią.

Tulains Córdova
źródło
1
jakie są „zalety natychmiastowego dowiedzenia się, co poszło nie tak” i dlaczego nie można ich odzyskać z pliku dziennika? Wydaje się, że dzięki intranetowi możesz uzyskać dostęp do pliku dziennika nawet łatwiej niż z witryny klienta.
Wonko the Sane
W moim scenariuszu istnieją krytyczne aplikacje, które mają priorytet „7/24”. Dział pomocy technicznej dzwoni do użytkownika, jeśli problemem jest błąd aplikacji lub wyjątek, dział pomocy technicznej dzwoni do opiekuna, który być może jest poza siedzibą. Z informacją o błędzie ekspert może poinstruować osobę na miejscu, jak obejść ten problem ... Często zaoszczędzony czas jest cenny, jeśli aplikacja ma krytyczne znaczenie dla firmy. jeśli ekspert, który jeśli nie ma przesłanek, musi najpierw połączyć się z firmą, przeszukać dziennik itp., krytyczna funkcja biznesowa może niepotrzebnie czekać.
Tulains Córdova
3
@ user1598390, więc zbuduj mechanizm przeglądania logów. Prosta strona internetowa, wprowadź identyfikator zdarzenia, a dział pomocy technicznej może zobaczyć cały odpowiedni dziennik. Oczywiście ogranicz dostęp do tej funkcji i tak dalej ...
AviD,
To, że aplikacja znajduje się w intranecie Twojej firmy, nie oznacza, że ​​nie ma w niej złośliwych użytkowników. Istnieje wielu niezadowolonych pracowników, którzy równie dobrze mogliby niewłaściwie wykorzystywać system wewnętrzny dla własnych korzyści. Ponieważ ci pracownicy wiedzą dużo o firmie i jej zasadach, mogą być bardziej niebezpieczni niż wewnętrzny haker. Przejrzenie plików dziennika jest dość trywialnym zadaniem, szczególnie jeśli postępujesz zgodnie z dobrą praktyką, a także zapisujesz błędy w określonym pliku dziennika błędów.
cliff.meyers
5

W każdym dostarczonym produkcie oczekiwana liczba tego rodzaju błędów powinna wynosić zero. Użyteczność tych informacji dla klienta wynosi zero. W obu przypadkach nie ma powodu, aby prezentować ślad stosu. Jeśli istnieje jakiś użyteczny kontekst, należy go przedstawić w sposób przyjazny dla klienta, a nie jako ślad stosu.

Z drugiej strony, jeśli faktyczna liczba wystąpień nie jest równa zeru, rozpaczliwie potrzebujesz tych informacji i nie powinieneś polegać na kliencie, który ci je wyśle. 99,99% czasu nie będą. Powinieneś zainstalować system usuwania błędów, który automatycznie wysyła informacje, z „ok” od klienta.

ddyer
źródło
Chciałbym głosować za odpowiedzią tylko w następującym wierszu: „Użyteczność tych informacji dla klienta wynosi zero”. . Wszelkie szczegóły techniczne dotyczące elementów wewnętrznych produktu powinny być ukryte, chyba że istnieje uzasadniony powód, aby tego nie robić z prostej przyczyny prostoty i użyteczności dla użytkownika końcowego produktu.
Kjartan