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

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ả <script>alert(document.cookie)</script>.

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