Aspect-Oriented Programming và bảo mật

Chia sẻ: Bi Bo | Ngày: | Loại File: PDF | Số trang:3

Thêm vào BST

Báo xấu

66
lượt xem 9
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

AOP là gì? Nhiều người không thực sự hiểu AOP là gì và cho rằng AOP là sự thay thế cho ngôn ngữ lập trình hướng đối tượng (OOP), chính vì vậy mà chúng tôi cần giải thích sâu. Khái niệm này rõ ràng hoàn toàn sai: AOP dựa trên OOP. Nó tập trung vào các khái niệm cross-cutting hoặc các khía cạnh –phần mã chung cho các đối tượng khác nhau. Sử dụng một ngôn ngữ AOP (như AspectJ) hoặc các thư viện (như Spring), những người lập trình có thể viết mã cho chức năng này, sau đó định...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Aspect-Oriented Programming và bảo mật

Aspect-Oriented Programming và bảo mật AOP là gì? Nhiều người không thực sự hiểu AOP là gì và cho rằng AOP là sự thay thế cho ngôn ngữ lập trình hướng đối tượng (OOP), chính vì vậy mà chúng tôi cần giải thích sâu. Khái niệm này rõ ràng hoàn toàn sai: AOP dựa trên OOP. Nó tập trung vào các khái niệm cross-cutting hoặc các khía cạnh –phần mã chung cho các đối tượng khác nhau. Sử dụng một ngôn ngữ AOP (như AspectJ) hoặc các thư viện (như Spring), những người lập trình có thể viết mã cho chức năng này, sau đó định nghĩa vị trí đan kết nó vào trong các đối tượng đang tồn tại. Một ví dụ cần phải được đưa ra để làm sáng tỏ cho các bạn về vấn đề này. Giả dụ chung ta có các lớp Java dưới đây: Ở đây chúng ta có thể thấy hàm ghi (logging) được nhân đôi thành hai lớp khác nhau. Với AOP, chúng ta cũng thực hiện như vậy (lưu ý cú pháp ở đây đã được đơn giản hóa để tạo sự rõ ràng rễ hiểu): Lúc này chúng ta tạo một khía cạnh LogInterceptor để có thể xen trước và sau bất kỳ một lời gọi nào đến class (bỏ qua những chi tiết về cách xen xảy ra như thế nào). Chúng ta cần phải tạo một proxy cho các lời gọi. Thứ quan trọng cần lưu ý về ví dụ này là cả MyFirstClass và MySecondClass đều không biết và không phụ thuộc vào LogInterceptor. Trong ứng dụng thực mà mã logging có thể được sao chép thành hàng trăm file class khác nhau, chính vì vậy việc tập trung nó giống như vậy sẽ làm giảm số lượng mã nguồn một cách đáng kể. Ở đây có thể thực hiện rẽ nhánh vì chúng ta có thể bổ sung các khía cạnh bảo mật cho các ứng dụng mà không cần thay đổi mã đã tồn tại từ trước.
Những gợi ý bảo mật Một vài khái niệm cross-cutting có liên quan đến bảo mật được tìm thấy rải rác thông qua logic ứng dụng:  Logging  Access control  Error handling  Transaction management  Session management (trong một số trường hợp)  Input/output validation Sử dụng AOP, chúng ta có thể tách riêng một đoạn lớn các khái niệm ra khỏi cả mảng mã lớn và tập hợp chúng lại. Có một số trường hợp bạn sẽ không thể tập hợp (ví dụ như việc quản lý lỗi), nhưng lớn hơn, AOP cho phép các chuyên gia phát triển có thể tập hợp trên Plain Old Java Object (hoặc bất cứ ngôn ngữ gì mà bạn đang sử dụng). POJO về bản chất là mã các chuyên gia phát triển đã được học để viết ngay từ những ngày ban đầu; mã này chỉ tập trung vào sự logic và không có các khái niệm khác như sự hợp lệ hóa đầu vào, bản ghi, điều khiển truy cập và vấn đề quản lý lỗi. Mã càng rõ ràng hơn thì càng ít bị lỗi hơn (trong đó có cả các lỗi bảo mật). Một ngụ ý khác về vấn đề này là các chuyên gia lão luyện có thể chịu trách nhiệm cho việc viết mã các khía cạnh bảo mật. Đây chính là những người đã được đào tạo một cách đặc biệt và có kinh nghiệm trong lĩnh vực như quản lý session hoặc điều khiển truy cập, có thể quản lý phần lớn nhất của mã đó trong toàn bộ một dự
án hoặc một thành phần của dự án. Ví dụ thực: Bổ sung sự hợp lệ hóa đầu vào cho ứng dụng có trước Rõ ràng, việc sử dụng AOP với toàn bộ tiềm lực của nó trên các ứng dụng đang tồn tại trước sẽ cần phải gần như viết lại ứng dụng – thứ thường không mấy khả thi. Những điều thú vị đối với cộng đồng bảo mật là cách sử dụng AOP trong một cơ sở mã đã tồn tại trước đó cho các chức năng bảo mật không được bổ sung. Chúng ta hãy xem xét một chút vào ứng dụng Customer Relationship Management (CRM) đang tồn tại, ứng dụng này có một số lỗ hổng XSS (Cross-site Scripting). Khi nhập một đầu vào các hàng hóa mới một trong các biểu mẫu web với mô tả alert(document.cookie). Chúng ta nhận được: Biểu mẫu này là một lỗ hổng XSS. Chúng tôi biết có một số phần mã dính líu đến lỗ hổng này. Chính vì vậy chúng tôi quyết định bảo vệ đối tượng NewLead trong lớp doanh nghiệp bằng cách thêm sự hợp lệ hóa đầu vào ở bất cứ thời điểm nào mà phương pháp setter trên thuộc tính String bị gọi. Đây là một mảng cắt nhỏ của lớp NewLead có một số phương pháp sette