Đây có phải là một lỗ hổng bảo mật để ghi nhật ký tên lớp và phương thức khi có ngoại lệ xảy ra không?

8

Tôi có những điều sau đây:

public class doCheck(){

    public void performCheck(){
        try {
            perform all checks......
        }
        catch(Exception e){
            logger.error("Exception occured in class doCheck in method performCheck");
            thrown new MyNewException(e.getMessage());
        }
    }
}

Có an toàn để đăng nhập tên lớp và phương thức?

java security exception-handling

— trời xanh
nguồn

8

Điều đó phụ thuộc vào việc cơ sở mã của bạn có bị ẩn hay không. Nếu bạn gửi sản phẩm cho khách hàng thì anh ta có thể kiểm tra mã byte Java một cách tầm thường, vì vậy tên lớp ghi nhật ký không tiết lộ bất kỳ thông tin nào mà người dùng không thể nhận được.

Đối với một ứng dụng phía máy chủ, điều này vẫn đúng. Tuy nhiên, nó có thể là một lỗ hổng bảo mật để hiển thị các bản ghi như vậy cho khách hàng. Đó là lý do tại sao hầu hết các khung ứng dụng web phân biệt giữa cấu hình phát triển và sản xuất: trong quá trình phát triển, thông tin gỡ lỗi được hiển thị cho người dùng trong trường hợp có lỗi. Trong sản xuất, thông tin này được ghi lại trên máy chủ, nhưng không còn hiển thị trong trình duyệt web / tới máy khách.

— Konrad Rudolph
nguồn

Có, và điều quan trọng là đảm bảo rằng bản thân các bản ghi được bảo mật - người dùng bên ngoài không thể truy cập và hoàn toàn không thể sửa đổi.

— Donald.McLean

2

Tóm lại, đăng nhập lớp / phương thức là một điều tốt . Cho phép nhật ký (hoặc stacktrace) thoát là một điều xấu .

— Qwerky

6

@Konrad đã trả lời câu hỏi trực tiếp, tuy nhiên việc xử lý ngoại lệ của bạn có một vấn đề nhỏ và hai vấn đề nghiêm trọng. Vì ban đầu bạn đã đăng lên codereview.SE, nên đây là:

Ghi nhật ký một ngoại lệ trước khi ném là vô nghĩa. Đăng nhập nó ở nơi bạn xử lý nó và đừng bận tâm đến việc nắm bắt nó nếu bạn không có kế hoạch xử lý ti.
Nếu bạn định đăng nhập một ngoại lệ, hãy ghi lại ngoại lệ đó; đừng chỉ đơn giản nói "một ngoại lệ đã xảy ra" và mong mọi người đoán xem ngoại lệ đó là gì. Tất cả các khung ghi nhật ký phổ biến cung cấp một phương thức hai đối số: đầu tiên là thông báo, thứ hai là có thể ném được.
Lấy lại một ngoại lệ chỉ với một tin nhắn là cùng một vấn đề nhưng là một trường hợp tồi tệ hơn. Tôi có thể hiểu (hầu như) tại sao bạn có thể không muốn một dấu vết ngăn xếp ngoại lệ hiển thị trong nhật ký của bạn. Nhưng một khi bạn ném ngoại lệ mới, bạn hoàn toàn không có cách nào để nói vấn đề thực sự là gì . Đặc biệt nếu bạn giữ thói quen bắt và nghĩ lại.

OK, tôi sẽ thêm một vấn đề thứ tư: bạn đăng nhập nơi xảy ra ngoại lệ, nhưng bạn không nói bạn đang làm gì khi nó xảy ra, hoặc đưa ra bất kỳ thông tin theo ngữ cảnh nào. Nếu bạn đăng nhập ngoại lệ thực tế (điểm # 1), bạn sẽ biết nó đã xảy ra ở đâu. Quan trọng hơn là nói một cái gì đó như "không thể mở tệp foo.txt".

— phân tích
nguồn

1

Nó không đặc biệt không an toàn, vì vậy trừ khi có bất kỳ điều gì quan trọng mà bạn muốn ẩn trong lớp này hoặc nếu lớp đó là một phần của đường dẫn quan trọng (như tính năng bắt tay an toàn hoặc tính năng "ẩn"), tôi sẽ không coi đây là vấn đề ở tất cả.

Hơn nữa, chúng ta đang nói về Java ở đây. Vì vậy, nếu chúng ta đang nói về một ứng dụng phía máy khách chạy Java trên máy khách, họ luôn có thể sửa đổi JRE của họ để sử dụng thêm các thói quen gỡ lỗi của riêng họ và / hoặc sử dụng trình nạp lớp tùy chỉnh và truy cập các lớp của bạn theo bất kỳ cách nào họ muốn. Làm cho họ khó khăn hơn (bằng cách giấu công cụ sâu hơn, hoặc thậm chí làm xáo trộn mã) luôn là một khả năng, nhưng nó thường không hiệu quả về mặt chi phí khi bạn xem xét thời gian và nỗ lực cần thiết để đạt được điều này chống lại sự mất mát do không thể thống kê được người dùng độc hại.

Nếu chúng ta đang nói về một phần mềm phía máy chủ có thể xuất nhật ký cho khách hàng (giả sử trình duyệt của người dùng), thì có lẽ đó không phải là vấn đề quá lớn, nhưng nó đã đơn giản hơn để khắc phục: định cấu hình bộ chứa của bạn theo đó, và sử dụng khung ghi nhật ký hoặc bộ ghép kênh để xuất ra các tệp thích hợp trên máy chủ cho mục đích gỡ lỗi. Bằng cách này, bạn giữ lại các bản ghi hữu ích để gỡ lỗi nhưng không thỏa hiệp thông tin có thể hữu ích.

Nhưng nói chung, điều này có lẽ sẽ không phải là một vấn đề. đó là nhiều hơn những gì bạn đưa vào thông báo gỡ lỗi có thể là một vấn đề, vì chúng ta thường có xu hướng là nhà phát triển sản xuất những thứ chúng ta làm việc (bạn không muốn để các đầu ra gỡ lỗi này cho tên người dùng, mật khẩu, muối và mã thông báo bảo mật ).

— haylem
nguồn