Tại sao chúng ta cần bảo mật mức phương thức?

Trong thế giới thực, tại sao chúng ta cần thực hiện bảo mật mức phương thức?

Chúng tôi có ứng dụng web hoặc ứng dụng máy tính để bàn, nơi người dùng truy cập vào giao diện người dùng (và do đó trực tiếp không thể truy cập phương thức).

Vì vậy, nơi phương pháp truy cập trực tiếp đi vào hình ảnh ở đây?

chỉnh sửa: Tôi hỏi câu hỏi này vì tôi đang thử nghiệm bảo mật mùa xuân và tôi thấy ủy quyền cho người dùng truy cập các phương thức.

cái gì đó như :

 @ROLE_ADMIN
public void update() {
      //update
}

Trong một ứng dụng được thiết kế đúng, phần phụ trợ và frontend bị ngắt kết nối. Hệ thống bảo mật phụ trợ không thể cho rằng bất kỳ giao diện cụ thể nào sẽ xử lý chính xác bảo mật, do đó, nó phải tự xử lý.

Tôi giả sử bạn đang nói về quyền truy cập dựa trên vai trò đối với các hành động trong bộ điều khiển. Tức là trong một kiến ​​trúc MVC mỗi phương thức trên một Controllerlớp là một hành động riêng biệt. Hầu hết các khung MVC mà tôi đã sử dụng cho phép tôi gán các đặc quyền ở cả cấp độ phương thức và cấp độ lớp. Điều đó có nghĩa là tôi có thể áp dụng một thuộc tính / chú thích ở cấp lớp và vai trò tương ứng sẽ được yêu cầu cho mọi hành động trong bộ điều khiển đó.

Đối với việc kiểm soát chi tiết hơn đối với quyền truy cập dựa trên vai trò, hãy xem xét điều này:

• Thật thuận tiện để nhóm tất cả các hành động xung quanh một tài nguyên với nhau. Tức là các hành động Tạo / Đọc / Cập nhật / Xóa (CRUD) của bạn cho các bài viết, tài khoản, v.v ... Điều này làm cho API kiểu REST dễ viết và duy trì hơn.
• Nhiều hệ thống có các thông tin / vai trò khác nhau cần thiết cho các hành động Tạo / Cập nhật / Xóa so với các hành động Đọc.
• Nếu tất cả các hành động tài khoản người dùng nằm trong một bộ điều khiển, bạn muốn cho phép mọi người đăng nhập, nhưng chỉ một số người nhất định tạo tài khoản mới hoặc gán vai trò.

Dù muốn hay không, khi Ruby on Rails lên sóng vài năm trước, cứ gần như mọi khung MVC đều sao chép phương pháp thiết kế cơ bản của nó. Trước đây, các hành động là các lớp riêng biệt, nhưng logic hành động có xu hướng nhỏ và tập trung nên toàn bộ chi phí lớp là quá mức cần thiết. Ánh xạ một phương thức trên bộ điều khiển thành hành động cho một trang thực sự có ý nghĩa rất lớn. Chỉ cần biết rằng nhiều người cần kiểm soát chi tiết về vai trò nào có thể thực hiện chức năng nào.

Phương thức bảo mật mức hữu ích vì hai lý do chính:

• như một lớp bảo mật khác (ngoài các lớp khác)

• trong trường hợp thuận tiện hoặc hợp lý hơn khi có quyền ở cấp phương thức, hãy xem xét trường hợp người dùng khác có thể thực hiện cùng một hành động "trực tiếp" (vì vậy bảo mật máy khách không liên quan). nhưng trong một số trường hợp, hành động của họ có thể kích hoạt một hành vi mà bạn muốn hạn chế - trong trường hợp này bảo mật mức phương thức có thể là một giải pháp phù hợp.

Mike Wiesner đã nhắc nhở trong bài trình bày SpringSource này, Giới thiệu về Bảo mật mùa xuân 3 / 3.1 , đã đưa ra ví dụ rằng Tomcat và nhiều bộ chứa Servlets khác có lỗi không nhận dạng đúng "../", khi được mã hóa thành unicode, theo cách mà một thử nghiệm bằng đơn giản sẽ thất bại trong Java, nhưng sẽ dịch sang thư mục trên trong hệ thống tệp.

Bảo mật là khó, nhiều cấp độ bảo mật, sẽ cải thiện cơ hội chặn các nỗ lực lách luật. Vì bảo mật cấp phương thức được mã hóa trực tiếp bên trong lớp, sau khi tăng cường AOP, khi bạn gọi phương thức, bạn sẽ luôn gọi kiểm tra bảo mật trước đó.

Tôi đoán rằng bạn đang nói về các phương pháp công cộng, riêng tư và được bảo vệ ở đây?

Nếu vậy, thì chúng không tồn tại cho mục đích bảo mật. Chúng tồn tại với mục đích làm cho nó dễ dàng hơn o đảm bảo rằng phần mềm được mô đun hóa đúng. (Cho dù họ thành công trong đó là một cuộc tranh luận tôi sẽ để lại cho người khác. Tuy nhiên, đó là tầm nhìn về những gì họ đang làm.)

Giả sử rằng tôi cung cấp một thư viện, sau đó tôi có thể tự do cung cấp một phiên bản khác của thư viện và thay đổi những thứ được đánh dấu là riêng tư nhiều như tôi muốn. Ngược lại, nếu tôi không đánh dấu những thứ đó là riêng tư, thì tôi sẽ không thể thay đổi bất kỳ phần bên trong nào của phần mềm của mình vì ai đó, ở đâu đó, có thể đang truy cập trực tiếp vào phần mềm. Chắc chắn, về lý thuyết, đó là lỗi của họ khi không sử dụng API tài liệu. Nhưng khách hàng sẽ nhận thấy đó là lỗi của tôi khi nâng cấp phần mềm của tôi đã phá vỡ phần mềm của họ. Họ không muốn bào chữa, họ muốn sửa nó. Nhưng nếu tôi không cho phép họ có quyền truy cập để bắt đầu, thì API của tôi chính xác là các phương thức công khai mà tôi dự định là API của tôi và vấn đề được tránh.

Điều có khả năng thứ hai mà bạn có thể nói đến là mô hình bảo mật của Java. Nếu bạn đang nói về điều đó, thì lý do tồn tại là tầm nhìn ban đầu cho Java liên quan đến việc những người gửi các applet không đáng tin cậy có thể hoạt động tương tác bên trong các chương trình của bên thứ ba (ví dụ: trình duyệt). Do đó, mô hình bảo mật nhằm cung cấp cho người dùng một số bảo vệ chống lại các applet độc hại. Do đó, mối đe dọa bảo mật để lo lắng và bảo vệ chống lại là các applet không đáng tin cậy đang cố gắng tương tác với các phần mềm khác có thể được tải.