Haruskah jejak stack berada di pesan kesalahan yang disajikan kepada pengguna?

Saya punya sedikit argumen di tempat kerja saya dan saya mencoba mencari tahu siapa yang benar, dan apa hal yang benar untuk dilakukan.

Konteks: aplikasi web intranet yang digunakan pelanggan kami untuk akuntansi dan hal-hal ERP lainnya.

Saya berpendapat bahwa pesan kesalahan yang disajikan kepada pengguna (ketika terjadi crash) harus memasukkan informasi sebanyak mungkin, termasuk jejak stack. Tentu saja, ini harus dimulai dengan "Kesalahan telah terjadi, silakan kirimkan informasi di bawah ini kepada pengembang" dalam huruf besar dan ramah.

Alasan saya adalah tangkapan layar dari aplikasi yang mogok sering kali menjadi satu-satunya sumber informasi yang mudah tersedia. Tentu, Anda dapat mencoba menghubungi administrator sistem klien, berusaha menjelaskan di mana file log Anda, dll, tetapi itu mungkin akan lambat dan menyakitkan (kebanyakan berbicara dengan perwakilan klien).

Juga, memiliki informasi langsung dan lengkap sangat berguna dalam pengembangan, di mana Anda tidak perlu mencari file log untuk menemukan apa yang Anda butuhkan pada setiap pengecualian. (Tapi itu bisa diselesaikan dengan sakelar konfigurasi.)

Sayangnya ada semacam "audit keamanan" (tidak tahu bagaimana mereka melakukannya tanpa sumber ... tapi apa pun), dan mereka mengeluh tentang pesan pengecualian penuh yang menyebut mereka sebagai ancaman keamanan. Tentu saja, klien (setidaknya satu yang saya tahu) telah mengambil ini pada nilai nominal dan sekarang menuntut agar pesan dibersihkan.

Saya gagal melihat bagaimana seorang penyerang potensial dapat menggunakan jejak stack untuk mencari tahu apa yang dia tidak tahu sebelumnya. Apakah ada contoh, bukti terdokumentasi dari siapa pun yang pernah melakukan itu? Saya pikir kita harus melawan ide bodoh ini, tapi mungkin aku yang bodoh di sini, jadi ...

Siapa yang benar

Saya cenderung membuat log aplikasi, baik dalam DB atau dalam file, dan mencatat semua informasi seperti itu. Anda kemudian dapat memberikan nomor kesalahan kepada pengguna, yang mengidentifikasi item log mana yang terkait dengan kesalahan, sehingga Anda bisa mendapatkannya kembali. Pola ini juga berguna karena Anda dapat mengikuti kesalahan bahkan jika pengguna tidak repot-repot mengangkatnya bersama Anda, sehingga Anda bisa mendapatkan ide yang lebih baik tentang di mana masalahnya.

Jika situs Anda dipasang di lingkungan klien dan Anda tidak dapat mencapainya, Anda bisa mendapatkan departemen TI di tempat untuk mengirimkan Anda beberapa ekstrak berdasarkan kesalahan no.

Hal lain yang dapat Anda pertimbangkan adalah memiliki rincian kesalahan sistem email ke kotak surat yang Anda lihat, sehingga Anda tahu ketika ada masalah.

Pada dasarnya memiliki sistem yang menumpahkan nyali ketika ada sesuatu yang tidak benar tidak menginspirasi kepercayaan pada pengguna non-teknis - cenderung menakut-nakuti mereka untuk berpikir ada sesuatu yang sangat salah (misalnya berapa banyak BSOD yang Anda pahami, dan bagaimana melakukan Anda rasakan ketika seseorang muncul)?

Pada stacktrace:

Di .Net, jejak tumpukan akan menampilkan jejak penuh langsung ke kumpulan sumber inti MS, dan akan mengungkapkan detail tentang teknologi apa yang Anda gunakan, dan kemungkinan versi juga. Ini memberikan informasi berharga kepada penyusup tentang kemungkinan kelemahan yang dapat dieksploitasi.

Ya, ada banyak.

Jejak tumpukan dapat mengungkapkan

• algoritma enkripsi apa yang Anda gunakan
• apa beberapa jalur yang ada di server aplikasi Anda
• apakah Anda benar membersihkan input atau tidak
• bagaimana objek Anda dirujuk secara internal
• versi dan merek basis data apa di belakang front-end Anda

... daftarnya terus berlanjut. Pada dasarnya setiap keputusan desain dalam aplikasi besar mungkin relevan dengan keamanan, dan hampir semuanya dapat diberikan melalui metode atau nama modul. Pikiran Anda, itu tidak berarti masih tidak masuk akal untuk menampilkan jejak tumpukan jika lingkungan itu diserahkan aman (misalnya intranet daripada situs web yang menghadap internet), tetapi biaya dalam keamanan pasti bukan nol .

Masalahnya, itu bukan tugas utama kita untuk membuat segalanya lebih mudah pada diri kita sendiri. Adalah tugas kami untuk membuat segalanya lebih mudah bagi pengguna akhir. Bagi kami, jejak tumpukan tampak seperti sepotong informasi yang sangat berguna untuk disediakan pengembang. Untuk pengguna, sepertinya omong kosong lengkap yang tidak berguna sama sekali. Bahkan jika Anda memberi tahu mereka sebaliknya, mereka tidak menginternalisasi itu. Jika Anda merasa sulit mendapatkan informasi itu dari administrator sistem, mendapatkannya dari pengguna akhir bahkan lebih buruk.

Sejauh keamanan berjalan, Anda mungkin ada benarnya jika itu adalah aplikasi desktop. Dalam hal itu, mencetak jejak tumpukan tidak memberikan apa pun yang belum diketahui oleh penyerang. Pada aplikasi web, informasi itu belum tersedia untuk penyerang. Anda memang mengekspos detail internal yang akan membuat serangan jauh lebih mudah.

Mengapa tidak melewati kedua sumber yang menjadi perhatian dan mendapatkan laporan pengecualian secara otomatis dikirimkan kepada Anda? Dengan begitu Anda bahkan tidak perlu khawatir tentang orang yang tidak melaporkan kesalahan.

Lihatlah pertanyaan IT Security SE ini . Singkatnya, tumpukan jejak dapat memberi penyerang lebih banyak informasi untuk dikerjakan. Semakin banyak informasi yang dimiliki penyerang, semakin besar kemungkinan mereka untuk menembus sistem Anda. Saya tidak akan mendasarkan keamanan saya pada kenyataan bahwa tumpukan jejak selalu disembunyikan, tetapi itu juga tidak berarti bahwa Anda harus memberikan informasi itu kepada penyerang.

Anda bisa mendapatkan sebagian besar manfaat dari pencatatan backend yang tepat. Ini sedikit kurang nyaman, tetapi mungkin tidak layak mempertaruhkan keamanan sistem Anda dan mengganggu pelanggan Anda.

Anda mungkin mempertimbangkan untuk tidak menunjukkan jejak tumpukan karena alasan berikut

Keamanan

Menampilkan jejak tumpukan mengungkapkan kemungkinan permukaan serangan adalah peretas. Intranet tidak kebal dari peretasan. Ini akan berdampak buruk pada Anda jika jaringan Anda diretas karena aplikasi yang Anda bertanggung jawab

Pengalaman pengguna

Untuk pengalaman terbaik pengguna, jejak strack terlalu banyak informasi. Ya, informasi yang tepat tentang kondisi kesalahan harus dicatat dan diperhatikan oleh seorang insinyur. Namun, meminta pengguna untuk melakukan apa yang dapat Anda lakukan secara otomatis tidak akan menjadi yang terbaik bagi pengguna.

Reputasi Anda

Setiap kali jejak tumpukan ditampilkan di situs web, itu terlihat buruk. Kebanyakan orang tidak tahu apa itu dan yang membuat mereka merasa seperti situs web tidak ramah kepada mereka. Bagi mereka yang tahu apa itu, mungkin itu indikasi bahwa aplikasi itu tidak dipikirkan dengan baik. Banyak aplikasi yang ditulis dengan buruk menunjukkan jejak stack terlalu sering karena itu adalah default dalam beberapa kerangka kerja seperti ASP.Net.

Jawaban singkat: Di situs ekstranet atau internet, masuk akal untuk tidak menampilkan stacktrace. Dalam intranet, manfaat menunjukkan stacktrace melampaui yang menyembunyikannya.

Jawaban panjang:

Hal yang sama terjadi pada saya di tempat kerja. Dulu saya berpikir bahwa jika suatu aplikasi gagal, itu harus gagal dengan berisik.

Tetapi kemudian mereka menjelaskan kepada saya bahwa seorang hacker potensial dapat melakukan banyak hal dari stacktrace.

Saya pikir tidak perlu bukti. Jelas bahwa semakin banyak peretas yang tahu tentang platform Anda, semakin baik baginya dan semakin sedikit peretas yang tahu tentang platform Anda, semakin baik bagi Anda .

Juga perusahaan tidak ingin mengungkapkan bagaimana seorang hacker membobol sistem mereka.

Di sisi lain, ini adalah intranet , dan saya pikir keuntungan mengetahui secara tidak langsung apa yang salah tanpa harus mencari file log adalah keuntungan besar dan risiko keamanan menunjukkan stacktrace di dalam batas-batas perusahaan Anda tidak setinggi kata mereka.

Dalam setiap produk yang dikirim, jumlah yang diharapkan dari jenis kesalahan ini harus nol. Utilitas informasi ini kepada pelanggan adalah nol. Dalam kedua hal tersebut, tidak ada alasan untuk menyajikan jejak tumpukan. Jika ada beberapa konteks yang bermanfaat, itu harus disajikan dengan cara yang ramah pelanggan, bukan sebagai tumpukan jejak.

Di sisi lain, jika jumlah kejadian sebenarnya tidak nol, Anda sangat membutuhkan informasi ini, dan tidak boleh bergantung pada pelanggan untuk mengirimkannya kepada Anda. 99,99% dari waktu mereka tidak mau. Anda harus menginstal sistem pelaporan bug yang mengirimkan informasi secara otomatis, dengan hanya "ok" dari pelanggan.