API zwracające wyjątek Java. Bezpieczny?
Chciałem tylko zapytać, czy moje obawy są uzasadnione.
Mam świadomość, że zwracanie śladu stosu przez interfejs API jest niebezpieczne. Mam podobną, ale mniej rażącą sytuację, którą próbuję ocenić.
Czy istnieje również jakiś standard dotyczący pakowania wyjątków Java w odpowiedzi 500? Na przykład odesłanie takich rzeczy, jak „DataIntegrityViolationException”, „NullPointerException” itp., Ale bez śladu stosu.
Inaczej mówiąc, gdy wystąpi nieobsługiwany wyjątek, nazwa wyjątku jest wysyłana z powrotem w odpowiedzi 500. Nie ma śladu stosu, ale możemy wywnioskować po stronie klienta, czy na przykład żądanie próbowało zmienić bazę danych w nieprawidłowy sposób.
Obecnie ostrzegam mój zespół przed tym i mówię im, że powinni umieścić na białej liście odpowiedzi serwera (tj. Wysyłać zawartość tylko wtedy, gdy masz ku temu świadomy powód). Chciałem tylko wiedzieć, czy marnuję na to ich czas.
Czy to dobry pomysł?
A może powinien być bardziej ogólny niż ten?
Odpowiedzi
Standardem obsługi błędów dla klienta jest nieujawnianie niczego na temat wewnętrznego działania i dostarczanie tylko tego, co będzie przydatne dla użytkownika, aby odniósł sukces.
Treść komunikatu o błędzie Java nie pomaga użytkownikowi. To, co ostatecznie robisz, to ujawnianie logiki kodu, która może zostać wykorzystana przeciwko tobie przez złośliwego użytkownika.
Przykłady OWASP to po prostu stwierdzenie, że wystąpił błąd. I to jest standard. Wszelkie informacje wykraczające poza to muszą mieć uzasadnienie.