Có nên theo dõi ngăn xếp trong thông báo lỗi cho người dùng không?

45

Tôi đã có một chút tranh cãi tại nơi làm việc của mình và tôi đang cố gắng tìm ra ai đúng, và điều gì là đúng.

Bối cảnh: một ứng dụng web mạng nội bộ mà khách hàng của chúng tôi sử dụng cho kế toán và các công cụ ERP khác.

Tôi cho rằng một thông báo lỗi được trình bày cho người dùng (khi sự cố xảy ra) nên bao gồm càng nhiều thông tin càng tốt, bao gồm cả dấu vết ngăn xếp. Tất nhiên, nó phải bắt đầu bằng một "Lỗi đã xảy ra, vui lòng gửi thông tin bên dưới cho các nhà phát triển" bằng các chữ cái lớn, thân thiện.

Lý do của tôi là một ảnh chụp màn hình của ứng dụng bị sập thường sẽ là nguồn thông tin dễ dàng duy nhất có sẵn. Chắc chắn, bạn có thể cố gắng nắm giữ (các) quản trị viên hệ thống của khách hàng, cố gắng giải thích các tệp nhật ký của bạn ở đâu, v.v., nhưng điều đó có thể sẽ chậm và đau đớn (chủ yếu là nói chuyện với đại diện khách hàng).

Ngoài ra, có một thông tin tức thời và đầy đủ là cực kỳ hữu ích trong quá trình phát triển, nơi bạn không cần phải tìm kiếm các tệp nhật ký để tìm thấy những gì bạn cần trên mọi ngoại lệ. (Nhưng điều đó có thể được giải quyết bằng một công tắc cấu hình.)

Thật không may, đã có một số loại "Kiểm toán bảo mật" (không biết làm thế nào mà họ làm điều đó mà không có nguồn ... nhưng bất cứ điều gì), và họ phàn nàn về các thông điệp ngoại lệ đầy đủ trích dẫn chúng là mối đe dọa bảo mật. Đương nhiên, các khách hàng (ít nhất là một khách hàng mà tôi biết) đã thực hiện việc này theo mệnh giá và bây giờ yêu cầu các tin nhắn phải được làm sạch.

Tôi không thấy làm thế nào một kẻ tấn công tiềm năng có thể sử dụng dấu vết ngăn xếp để tìm ra bất cứ điều gì anh ta không thể tìm ra trước đây. Có bất kỳ ví dụ, bất kỳ bằng chứng tài liệu của bất cứ ai từng làm điều đó? Tôi nghĩ rằng chúng ta nên chiến đấu với ý tưởng ngu ngốc này, nhưng có lẽ tôi là kẻ ngốc ở đây, vì vậy ...

Ai đúng

security error-handling

— Vilx-
nguồn

25

Ồ Chỉ là ... wow. " Unfortunately there has been some kind of "Security audit"" - Nghiêm túc chứ? Đó là loại thái độ nào? Kiểm toán bảo mật là vì lợi ích của bạn - để làm cho hệ thống của bạn tốt hơn, tìm ra các vấn đề trước khi kẻ xấu làm. Bạn nên thực sự xem xét việc cố gắng làm việc với họ, không chống lại họ. Ngoài ra, bạn có thể thử lấy thêm thông tin về PoV bảo mật tại Bảo mật thông tin .

— AviD

7

Và btw, kiểm toán bảo mật không nhất thiết cần truy cập vào mã nguồn, họ có thể đã thực hiện kiểm tra thâm nhập hộp đen, mô phỏng những gì người dùng độc hại sẽ làm - cố gắng tấn công ứng dụng với tư cách là người dùng. Mặc dù tôi đồng ý rằng việc truy cập vào mã nguồn có thể đã cho phép một hình thức kiểm toán hiệu quả hơn nhiều. :-)

— AviD

1

@AviD - trong thực tế, tôi không biết những gì họ đã phân tích, nhưng từ một số báo cáo tôi thấy nó có vẻ giống như một thử nghiệm hộp đen đối với tôi. Thành thật mà nói, tôi không muốn làm việc chống lại họ. Thật vậy, tôi đã thích tin tức khi tôi nghe chúng. Nhưng "lỗ hổng" đặc biệt này của họ có vẻ ngớ ngẩn đối với tôi. Trong mọi quyết định bảo mật, bạn phải cân nhắc việc giảm mối đe dọa đối với việc giảm khả năng sử dụng. Trong trường hợp này tôi nghĩ rằng nó làm giảm khả năng sử dụng nhiều hơn là nó cải thiện bảo mật.

— Vilx-

1

Tôi đồng ý rất nhiều về việc cân, nhưng tôi không đồng ý về ứng dụng của nó. Nó gây hại cho bảo mật hơn bạn nghĩ, và tôi cũng nghĩ rằng cách của bạn (cũng đã tự làm điều này, cho đến khi tôi nói chuyện với một số người dùng .....) thì tệ hơn về khả năng sử dụng. Hãy nghĩ về điều đó theo các thuật ngữ định hướng nhiệm vụ - như câu trả lời của @ Jon đã nói, cách của anh ấy giúp công việc của người dùng được thực hiện tốt hơn nhiều. Người dùng không cần quan tâm đến ngăn xếp (trừ khi người dùng của bạn là nhà phát triển ...) Nhưng, chuyên môn của tôi là về bảo mật - và rủi ro là có thật.

— AviD

1

@AviD - Có lẽ bạn có thể chỉ cho tôi một số tài nguyên giải thích làm thế nào một dấu vết ngăn xếp có thể nguy hiểm? Tôi đã sẵn sàng để chấp nhận điều đó, nhưng tôi muốn một cái gì đó hơn là nguyên tắc chung của "chỉ hiển thị những gì bạn cần".

— Vilx-

73

Tôi có xu hướng xây dựng một nhật ký ứng dụng, trong DB hoặc trong tệp và ghi nhật ký tất cả thông tin đó vào đó. Sau đó, bạn có thể cung cấp cho người dùng một số lỗi, xác định mục nhật ký mà lỗi có liên quan đến, để bạn có thể lấy lại. Mẫu này cũng hữu ích vì bạn có thể theo dõi các lỗi ngay cả khi người dùng không bận tâm nâng chúng với bạn, vì vậy bạn có thể biết rõ hơn về vấn đề ở đâu.

Nếu trang web của bạn được cài đặt trong môi trường của khách hàng và bạn không thể truy cập nó, bạn có thể nhờ bộ phận CNTT tại chỗ gửi cho bạn một số trích xuất dựa trên lỗi không.

Một điều khác bạn có thể xem xét là có các chi tiết email hệ thống về lỗi đến hộp thư mà bạn nhìn thấy, để bạn biết khi nào có sự cố.

Về cơ bản, có một hệ thống tràn ra can đảm khi có điều gì đó không đúng không truyền cảm hứng cho niềm tin vào người dùng không có kỹ thuật - nó có xu hướng khiến họ sợ rằng điều gì đó rất sai (ví dụ như bạn hiểu BSOD bao nhiêu và làm thế nào bạn cảm thấy khi một người đi lên)?

Trên stacktrace:

Trong .Net, theo dõi ngăn xếp sẽ hiển thị toàn bộ dấu vết ngay trong các cụm có nguồn gốc MS và sẽ tiết lộ chi tiết về những công nghệ bạn đang sử dụng cũng như các phiên bản có thể. Điều này cung cấp cho những kẻ xâm nhập thông tin có giá trị về những điểm yếu có thể bị khai thác.

— Jon Egerton
nguồn

6

Tôi thích câu trả lời của bạn vì nó trình bày một "đường giữa" - không hiển thị, nhưng làm cho việc tìm kiếm các ngoại lệ trở nên dễ dàng. Tôi sẽ cố gắng thúc đẩy điều đó ngay bây giờ, tôi hy vọng rằng họ sẽ đồng ý. Cảm ơn bạn!

— Vilx-

2

Tôi nghĩ rằng đây là khá nhiều cách tiếp cận "trưởng thành" tiêu chuẩn. Ngoài ra, stacktrace cung cấp rất nhiều thông tin, tuy nhiên tôi vẫn chưa tìm được giải pháp có thể tự động ghi thông tin trạng thái cùng với stacktrace (không thay đổi mã ở mọi nơi). Có vẻ như viết trình gỡ lỗi của riêng bạn và đính kèm nó là một cách có thể để đi, nhưng xa tầm thường để thực hiện.

— Daniel B

@DanielB: Trong các ứng dụng web có thể nắm giữ một số nội dung phổ biến (như userid, clientid, v.v.) từ phiên / bộ đệm - vì nó vẫn tồn tại "trên toàn cầu", thậm chí nhiều thông tin này có thể giúp tái tạo rất nhiều lỗi. Nhiều chi tiết hơn đó là rất khó khăn như bạn nói.

— Jon Egerton

2

Một số người dùng các ứng dụng rất quan trọng yêu cầu các giải pháp tức thời cho bất kỳ lỗi nào cản trở tiến trình kinh doanh thông thường. Tất cả quá trình giao tiếp liên quan đến các bộ xử lý khác nhau chỉ dành cho người giải quyết lỗi để nhận lỗi của ngăn xếp lỗi có thể dễ dàng tiêu thụ 1 giờ trở lên khi lỗi xảy ra vào đêm muộn hoặc cuối tuần.

— Tulains Córdova

1

@ user1598390: Đồng ý, trong trường hợp đó, việc sao chép các chi tiết lỗi vào hộp thư hỗ trợ được giám sát có thể đẩy nhanh việc thu thập thông tin, đến mức nhân viên hỗ trợ biết có gì đó bị hỏng ngay cả trước khi người dùng thực hiện.

— Jon Egerton

29

Vâng, ở đó có nhiều lắm.

Một dấu vết ngăn xếp có thể tiết lộ

bạn sử dụng thuật toán mã hóa nào
một số đường dẫn hiện có trên máy chủ ứng dụng của bạn là gì
bạn có vệ sinh đúng cách đầu vào hay không
làm thế nào các đối tượng của bạn được tham chiếu trong nội bộ
phiên bản và thương hiệu cơ sở dữ liệu nào đứng sau front-end của bạn

... danh sách đi và về. Về cơ bản mọi quyết định thiết kế trong một ứng dụng lớn có thể liên quan đến bảo mật và hầu hết tất cả chúng có thể được đưa ra thông qua tên phương thức hoặc mô-đun. Xin lưu ý bạn, điều đó không có nghĩa là nó vẫn không có ý nghĩa để hiển thị dấu vết ngăn xếp nếu môi trường mà nó gửi đến là an toàn (ví dụ: mạng nội bộ thay vì trang web truy cập internet), nhưng chi phí bảo mật chắc chắn không phải là không .

— Kilian Foth
nguồn

6

Tôi đồng ý phần lớn, nhưng một số trong những điều này không quan trọng. Ví dụ, thuật toán mã hóa nào bạn đang sử dụng không cần phải bí mật để bảo mật hệ thống của bạn.

— Oleksi

3

Nó không quan trọng, nhưng thế giới là không hoàn hảo, và nó thường như vậy. Đó là lý do tại sao phòng thủ theo chiều sâu (làm nhiều việc cùng một lúc mà nên là đủ nếu họ đã hoàn hảo) các vấn đề.

— Kilian Foth

3

Thẳng thắn mà nói, nếu một dấu vết ngăn xếp tiết lộ bất cứ điều gì có thể giúp đỡ kẻ tấn công, thì bạn đang làm sai !

— Đánh dấu gian hàng

3

@MarkBooth nói theo thống kê, có lẽ bạn đang làm sai. Không, cào nó - chắc chắn thống kê rằng bạn đang nhận được một số sai. Bạn có thực sự muốn để những kẻ tấn công tìm thấy lỗi bảo mật của bạn trước khi bạn làm không?

— AviD

1

@AviD - Không, tôi đồng ý, lý do thuyết phục nhất để không hiển thị dấu vết ngăn xếp cho người dùng là họ không biết phải làm gì với họ và hệ thống ghi nhật ký của bạn phải an toàn và có thể chụp được nhiều trạng thái hơn so với chụp màn hình của một trang web bao giờ có thể.

— Đánh dấu gian hàng

15

Vấn đề là, đây không phải là công việc chính của chúng tôi để làm mọi thứ dễ dàng hơn với chính chúng tôi. Đó là công việc của chúng tôi để làm cho mọi thứ dễ dàng hơn đối với người dùng cuối. Đối với chúng tôi, một dấu vết ngăn xếp trông giống như một thông tin cực kỳ hữu ích để cung cấp cho nhà phát triển. Đối với một người dùng, nó trông giống như hoàn toàn vô nghĩa mà không có ích gì. Ngay cả khi bạn nói với họ khác, họ không nội tâm hóa nó. Nếu bạn nghĩ rằng việc lấy thông tin đó từ quản trị viên hệ thống thì việc lấy thông tin từ người dùng cuối thậm chí còn tệ hơn.

Về bảo mật, bạn có thể có một điểm nếu đó là một ứng dụng máy tính để bàn. Trong trường hợp đó, in dấu vết ngăn xếp không cung cấp bất cứ điều gì kẻ tấn công chưa biết. Trên một ứng dụng web, thông tin đó không có sẵn cho kẻ tấn công. Bạn thực sự đang phơi bày các chi tiết nội bộ sẽ làm cho một cuộc tấn công dễ dàng hơn rất nhiều .

Tại sao không bỏ qua cả hai nguồn quan tâm và nhận báo cáo ngoại lệ tự động gửi cho bạn? Bằng cách đó, bạn thậm chí không cần phải lo lắng về việc mọi người không báo cáo lỗi.

— Karl Bielefeldt
nguồn

2

Người dùng được hưởng lợi từ việc khắc phục nhanh sự cố của mình nhờ thông tin được cung cấp bởi theo dõi ngăn xếp. Nhưng tôi nhận được quan điểm của bạn.

— Tulains Córdova

11

Hãy xem câu hỏi này của IT Security SE . Nói tóm lại, một dấu vết ngăn xếp có thể cung cấp cho kẻ tấn công nhiều thông tin hơn để làm việc. Kẻ tấn công càng có nhiều thông tin, chúng càng có khả năng xâm nhập hệ thống của bạn. Tôi sẽ không bảo mật cho sự thật rằng các dấu vết ngăn xếp luôn bị ẩn, nhưng điều đó cũng không có nghĩa là bạn nên cung cấp thông tin đó cho những kẻ tấn công.

Bạn vẫn có thể nhận được hầu hết các lợi ích từ việc ghi nhật ký phụ trợ thích hợp. Nó hơi kém kiên nhẫn, nhưng có lẽ không đáng để mạo hiểm tính bảo mật của hệ thống và làm phiền khách hàng của bạn.

— Oleksi
nguồn

8

Bạn có thể cân nhắc việc không hiển thị dấu vết ngăn xếp vì những lý do sau.

Bảo vệ

Hiển thị dấu vết ngăn xếp cho thấy các bề mặt tấn công có thể sẽ là tin tặc. Mạng nội bộ không tránh khỏi hack. Nó sẽ phản ánh xấu về bạn nếu mạng của bạn bị hack vì một ứng dụng mà bạn chịu trách nhiệm

Kinh nghiệm người dùng

Đối với trải nghiệm tốt nhất của người dùng, dấu vết strack là quá nhiều thông tin. Có, thông tin thích hợp về tình trạng lỗi phải được ghi lại và được chú ý bởi một kỹ sư. Tuy nhiên, việc yêu cầu người dùng thực hiện những gì bạn có thể tự động hóa sẽ không phải là điều tốt nhất cho người dùng.

Danh tiếng của bạn

Bất cứ khi nào một dấu vết ngăn xếp được hiển thị trên một trang web, nó trông xấu. Hầu hết mọi người không có ý tưởng gì về nó và điều đó khiến họ cảm thấy trang web không thân thiện với họ. Đối với những người biết nó là gì, nó có thể là một dấu hiệu cho thấy ứng dụng không được suy nghĩ kỹ. Nhiều ứng dụng được viết xấu hiển thị dấu vết ngăn xếp quá thường xuyên vì nó là mặc định trong một số khung như ASP.Net.

— Tom định cư
nguồn

6

Là một nhà phát triển phần mềm, khi tôi nhìn thấy dấu vết ngăn xếp trên màn hình, ngay lập tức tôi là "Đây là một bozo không biết gì về xử lý lỗi, ít quan tâm đến chúng và thậm chí có thể ít hơn về người dùng". Những người khác xoay quanh "đây là phần mềm nhảm nhí, không hoạt động, xử lý lỗi không hoạt động" và "WTF .... Tôi không làm việc này cho anh ta" Những gì người dùng của bạn muốn biết là gì anh ta cần phải làm gì để sửa nó. Làm thế nào để theo dõi ngăn xếp làm điều đó.

— mattnz

6

Câu trả lời ngắn: Trong một trang web extranet hoặc internet, sẽ không có nghĩa là không hiển thị stacktrace. Trong mạng nội bộ, lợi ích của việc hiển thị stacktrace vượt qua những người ẩn nó.

Câu trả lời dài:

Điều tương tự cũng xảy ra với tôi tại nơi làm việc. Tôi đã từng nghĩ rằng nếu một ứng dụng thất bại, nó sẽ thất bại một cách ồn ào.

Nhưng sau đó họ giải thích cho tôi rằng một hacker có thể gây ra rất nhiều thứ từ một stacktrace.

Tôi nghĩ rằng không cần bằng chứng. Rõ ràng là càng có nhiều hacker biết về nền tảng của bạn thì càng tốt cho anh ta và rằng càng ít hacker biết về nền tảng của bạn thì càng tốt cho bạn .

Ngoài ra các công ty không muốn tiết lộ làm thế nào một hacker đột nhập vào hệ thống của họ.

Mặt khác, đó là một mạng nội bộ và tôi nghĩ rằng những lợi thế của việc biết một cách không chính xác những gì đã sai khi tìm kiếm một tệp nhật ký là một lợi thế lớn và rủi ro bảo mật của việc hiển thị một ngăn xếp bên trong ranh giới của công ty bạn không cao bằng họ đang nói

— Tulains Córdova
nguồn

1

một số "lợi ích của việc biết rõ những gì đã sai" và tại sao chúng không thể được truy xuất từ một tệp nhật ký? Dường như với Intranet, bạn có thể truy cập tệp nhật ký dễ dàng hơn so với từ trang web của khách hàng.

— Wonko the Sane

Trong kịch bản của tôi, có những ứng dụng quan trọng có mức độ ưu tiên "7/24". Bàn trợ giúp người dùng gọi, nếu sự cố là lỗi ứng dụng hoặc ngoại lệ, bàn trợ giúp sẽ gọi cho người bảo trì có thể ở ngoài cơ sở. Với thông tin lỗi, chuyên gia có thể hướng dẫn một người tại chỗ giải quyết ... Thông thường thời gian lưu là quý giá nếu ứng dụng quan trọng trong kinh doanh. nếu chuyên gia rằng nếu các thành viên đầu tiên có kết nối với công ty, hãy tìm kiếm nhật ký, v.v., một chức năng kinh doanh quan trọng có thể phải chờ đợi một cách không cần thiết.

— Tulains Córdova

3

@ user1598390 vì vậy hãy xây dựng cơ chế xem nhật ký. Một trang web đơn giản, nhập id sự cố và bộ phận trợ giúp có thể xem toàn bộ nhật ký liên quan. Tất nhiên giới hạn quyền truy cập vào tính năng này, v.v ...

— AviD

Chỉ vì một ứng dụng trên mạng nội bộ của công ty bạn không có nghĩa là không có người dùng độc hại trên đó. Có rất nhiều nhân viên bất mãn ngoài kia, những người rất có thể lạm dụng một hệ thống nội bộ vì lợi ích của chính họ. Vì những nhân viên này biết rất nhiều về công ty và các chính sách của họ, họ thực sự có thể nguy hiểm hơn một hacker nội bộ. Xem qua các tệp nhật ký là một nhiệm vụ khá nhỏ, đặc biệt nếu bạn đang thực hiện tốt và cũng ghi nhật ký lỗi vào một tệp nhật ký lỗi cụ thể.

— cliff.meyers

5

Trong bất kỳ sản phẩm được giao nào, số lượng lỗi dự kiến của loại lỗi này sẽ bằng không. Tiện ích của thông tin này cho khách hàng là bằng không. Trên cả hai tổng số, không có lý do để trình bày một dấu vết ngăn xếp. Nếu có một số bối cảnh hữu ích, nó nên được trình bày theo cách thân thiện với khách hàng, không phải là một dấu vết ngăn xếp.

Mặt khác, nếu số lần xuất hiện thực tế không bằng 0, bạn rất cần thông tin này và không nên dựa vào khách hàng để gửi cho bạn. 99,99% thời gian họ sẽ không. Bạn nên cài đặt một hệ thống sửa lỗi để gửi thông tin một cách tự động, chỉ với một "ok" từ khách hàng.

— người ngu
nguồn

Tôi sẽ chỉ đưa ra câu trả lời này cho dòng sau: "Tiện ích của thông tin này cho khách hàng là bằng không." . Bất kỳ chi tiết kỹ thuật nào về phần bên trong của sản phẩm nên được ẩn đi trừ khi có lý do chính đáng để không làm điều đó vì lý do đơn giản là đơn giản và khả năng sử dụng cho người dùng cuối của sản phẩm.

— Kjartan