사용자에게 제시된 오류 메시지에 스택 추적이 있어야합니까?

나는 직장에서 약간의 논쟁을 겪었으며 누가 옳은지, 옳은 일을 알아 내려고 노력하고 있습니다.

컨텍스트 : 고객이 회계 및 기타 ERP에 사용하는 인트라넷 웹 응용 프로그램입니다.

사용자에게 표시되는 오류 메시지 (사고가 발생할 때)에는 스택 추적을 포함하여 가능한 많은 정보가 포함되어야한다고 생각합니다. 물론, "오류가 발생했습니다. 개발자에게 아래 정보를 제출하십시오"라는 큰 친절 편지로 시작해야합니다.

내 추론은 충돌 응용 프로그램의 스크린 샷이 종종 유일하게 쉽게 사용할 수있는 정보 소스가 될 것이라는 것입니다. 물론 클라이언트의 시스템 관리자를 확보하고 로그 파일의 위치 등을 설명하려고 시도 할 수 있지만 느리고 고통 스러울 수 있습니다 (클라이언트 담당자와 대화하는 것이 대부분).

또한 즉각적이고 완전한 정보를 얻는 것이 개발에 매우 ​​유용합니다. 여기서 모든 예외에서 필요한 것을 찾기 위해 로그 파일을 탐색 할 필요가 없습니다. (그러나 구성 스위치로 해결할 수 있습니다.)

불행히도 일종의 "보안 감사"가 있었으며 (소스 없이는 어떻게했는지 알지 못했지만) 보안 위협으로 인용하는 전체 예외 메시지에 대해 불평했습니다. 당연히 클라이언트 (내가 아는 적어도 하나)는 이것을 액면가로 취했으며 이제는 메시지를 정리해야합니다.

잠재적 인 공격자가 스택 추적을 사용하여 이전에는 알아낼 수 없었던 것을 알아낼 수 없었습니다. 누군가 그 일을 한 증거 문서가 있습니까? 우리는이 어리석은 생각과 싸워야한다고 생각하지만 어쩌면 나는 여기 바보 일 것입니다.

누가 옳아?

DB 또는 파일로 응용 프로그램 로그를 작성하고 그러한 정보를 모두 기록하는 경향이 있습니다. 그런 다음 사용자에게 오류 번호를 제공하면 오류와 관련된 로그 항목을 식별하여 다시 가져올 수 있습니다. 이 패턴은 사용자가 문제를 제기하지 않아도 오류를 따를 수 있으므로 유용하므로 문제의 위치를 ​​더 잘 파악할 수 있습니다.

사이트가 클라이언트 환경에 설치되어 있고 사이트에 연결할 수없는 경우 오류 번호에 따라 추출을 보내도록 현장 IT 부서에 문의 할 수 있습니다.

고려해야 할 또 다른 사항은 오류가 발생한 메일 상자에 오류에 대한 세부 정보를 시스템 전자 메일로 보내 문제가 발생하는시기를 알 수 있다는 것입니다.

옳지 않은 일이 발생했을 때 내장을 쏟아내는 시스템을 기본적으로 가지고 있다고해서 기술이 아닌 사용자에게 자신감을 느끼지 못하는 경우가 있습니다. 당신이 올 때 느낌)?

스택 추적에서 :

.Net에서 스택 추적은 핵심 MS 소스 어셈블리에 대한 전체 추적을 표시하고 사용중인 기술 및 가능한 버전에 대한 세부 정보를 표시합니다. 이는 침입자에게 악용 될 수있는 약점에 대한 유용한 정보를 제공합니다.

예, 많이 있습니다.

스택 추적은 공개 할 수 있습니다

• 사용하는 암호화 알고리즘
• 응용 프로그램 서버의 기존 경로가 무엇인지
• 입력을 올바르게 위생 처리하고 있는지 여부
• 객체가 내부적으로 참조되는 방법
• 프론트 엔드 뒤에있는 데이터베이스 버전 및 브랜드

... 목록은 계속 이어집니다. 기본적으로 대규모 응용 프로그램의 모든 디자인 결정은 보안과 관련 이있을 수 있으며 거의 ​​모든 방법이 메서드 또는 모듈 이름을 통해 제공 될 수 있습니다. 제출 된 환경이 안전한 경우 (예 : 인터넷 연결 웹 사이트가 아닌 인트라넷) 스택 추적을 표시하는 것이 여전히 타당하지는 않지만 보안 비용은 확실히 0이 아님을 명심하십시오 .

문제는 스스로 일을 더 쉽게 만드는 것이 우리의 주요 업무가 아닙니다. 최종 사용자가 작업을보다 쉽게하는 것이 우리의 일입니다. 우리에게 스택 추적은 개발자에게 유용한 매우 유용한 정보처럼 보입니다. 사용자에게는 전혀 쓸모없는 완전한 횡설수설처럼 보입니다. 당신이 그들에게 다르게 말하더라도, 그들은 그것을 내면화하지 않습니다. 시스템 관리자로부터 정보를 얻는 것이 어렵다고 생각하면 최종 사용자로부터 정보를 얻는 것이 훨씬 더 나쁩니다.

보안이 진행되는 한 데스크톱 응용 프로그램이라면 문제가 될 수 있습니다. 이 경우 스택 추적을 인쇄해도 공격자가 알지 못하는 것은 없습니다. 웹 앱에서는 해당 정보를 아직 공격자가 사용할 수 없습니다. 실제로 공격을 훨씬 쉽게 할 수있는 내부 세부 정보를 노출하고 있습니다 .

두 가지 우려 소스를 모두 무시하고 예외 보고서가 자동으로 전송되는 이유는 무엇입니까? 이렇게하면 오류를보고하지 않는 사람들에 대해 걱정할 필요가 없습니다.

IT Security SE의이 질문을 살펴보십시오 . 즉, 스택 추적은 공격자에게 더 많은 정보를 제공 할 수 있습니다. 공격자가 보유한 정보가 많을수록 시스템에 침투 할 가능성이 높습니다. 스택 추적이 항상 숨겨져 있다는 사실을 기반으로 보안을 설정하지는 않지만 공격자에게 해당 정보를 제공해야한다는 의미는 아닙니다.

어쨌든 적절한 백엔드 로깅을 통해 대부분의 이점을 얻을 수 있습니다. 약간 덜 유쾌하지만 시스템의 보안을 위협하고 고객을 화나게 할 가치는 없습니다.

다음과 같은 이유로 스택 추적을 표시하지 않을 수 있습니다.

보안

스택 추적을 표시하면 해커 일 가능성이있는 공격 영역이 나타납니다. 인트라넷은 해킹에 영향을받지 않습니다. 당신이 담당하는 응용 프로그램으로 인해 네트워크가 해킹 된 경우 나쁘게 반영됩니다.

사용자 경험

사용자에게 최상의 경험을 제공하기 위해 트랙 추적은 너무 많은 정보입니다. 그렇습니다. 오류 상태에 대한 올바른 정보는 엔지니어가 기록하고주의를 기울여야합니다. 그러나 자동화 할 수있는 작업을 수행하도록 사용자에게 요청하는 것이 사용자에게 최선이 아닙니다.

당신의 명성

웹 사이트에 스택 추적이 표시 될 때마다 나빠 보입니다. 대부분의 사람들은 그것이 무엇인지 전혀 몰라서 웹 사이트가 친숙하지 않은 것처럼 느끼게합니다. 그것이 무엇인지 아는 사람들에게는 응용 프로그램이 잘 생각되지 않았 음을 나타낼 수 있습니다. 잘못 작성된 많은 응용 프로그램은 스택 추적을 ASP.Net과 같은 일부 프레임 워크에서 기본값이기 때문에 너무 자주 표시합니다.

짧은 대답 : 엑스트라 넷 또는 인터넷 사이트에서는 스택 추적을 표시하지 않는 것이 좋습니다. 인트라넷에서 스택 추적 표시의 이점은이를 숨기는 것보다 뛰어납니다.

긴 대답 :

직장에서도 마찬가지입니다. 앱이 실패하면 시끄럽게 실패해야한다고 생각했습니다.

그러나 그들은 저에게 해커가 스택 트레이스에서 많은 것을 유추 할 수 있다고 설명했습니다.

증거가 필요 없다고 생각합니다. 분명하다 더 많은 해커가 더 나은 그를 위해 플랫폼에 대해 알고 그 덜 해커가 더 나은 당신을위한 플랫폼에 대해 알고 .

또한 기업들은 해커가 시스템에 침입 한 방식을 공개하고자하지 않습니다.

다른 한편으로, 그것은 인트라넷 이며, 로그 파일을 검색 해야 할 때 잘못 된 일을 즉각적으로 아는 이점은 큰 이점이 있으며 회사 경계 내에서 스택 추적을 표시하는 보안 위험은 그다지 높지 않다고 생각합니다. 그들은 말하고 있습니다.

배송 된 제품에서이 유형의 오류의 예상 개수는 0이어야합니다. 이 정보를 고객에게 제공하는 유틸리티 는 0입니다. 두 가지 경우 모두 스택 추적을 제시 할 이유가 없습니다. 유용한 컨텍스트가있는 경우 스택 추적이 아니라 고객에게 친숙한 방식으로 제시해야합니다.

반면에 실제 발생 횟수가 0이 아닌 경우이 정보가 절실히 필요하며 고객에게 의존하여 정보를 보내서는 안됩니다. 시간의 99.99 %는 그렇지 않습니다. 고객의 "확인"만으로 정보를 자동으로 제출하는 버그 복원 시스템을 설치해야합니다.