Cơ bản về bảo mật trong Ajax (<i>Phần cuối</i>)

Xem phần trước

Ajax làm phức tạp các phương pháp kiểm tra bảo mật hiện nay như thế nào

Trong khi kiểm tra một ứng dụng web thông thường, một kiểm tra viên phải bắt đầu từ footprinting của ứng dụng. Mục đích của giai đoạn footprint là bắt giữ các yêu cầu và các đáp ứng để các kiểm tra viên hiểu các ứng dụng truyền thông như thế nào với máy chủ và các đáp ứng những thu nhận của nó. Thông tin được ghi qua các proxi cục bộ như là Burp hay Paros. Giai đoạn footprint là rất quan trọng để các kiểm tra viên ghi các yêu cầu đến tất cả các trang được sử dụng bởi ứng dụng.

Sau bước này, các kiểm tra viên sẽ bắt đầu quá trình sửa lỗi, sử dụng cả công cụ bằng tay và tự động, để kiểm tra các thông số mà đã đến và đi từ web server.

Ajax làm phức tạp phương pháp này bởi vì đặc tính không đồng bộ của nó. Việc này đã làm nó khó hơn so với các ứng dụng web thông thường khác. Một ứng dụng có thể tạo ra nhiều yêu cầu trong background thậm chí khi nó xuất hiện tĩnh đến người dùng. Một kiểm tra viên phải có kiến thức về các giải pháp có thể gây khó khăn với quá trình kiểm tra ứng dụng. Điều này bao gồm:

* Vấn đề của “state”

Trong các ứng dụng web thông thường trên thế giới, trạng thái của ứng dụng đã được định nghĩa khá tốt. Mọi thứ đang cư trú trong DOM của các trang có thể được xem xét như trạng thái hiện hành của trang. Nếu trạng thái này cần thiết thay đổi thì một yêu cầu được gửi đến server và đáp ứng sẽ định nghĩa trạng thái thay đổi như thế nào.

Trong Ajax, nhiều thứ có thể thay đổi tinh vi hơn nhiều. Ứng dụng có thể phát sinh các loại yêu cầu khác nhau phụ thuộc vào trạng thái hiện tại của trang. Yêu cầu được tạo ra bằng việc click trên list box nếu người dùng có lựa chọn nút radio đầu tiên trên trang web. Thông thường, đáp ứng có thể cập nhật một phần của trang để người dùng có thể có các link mới hoặc các điều khiển mới để tương tác với các trang đó.

* Các Request được khởi tạo thông qua các sự kiện timer.

Khởi tạo này được tao ra để update đến giao diện người dùng không có bất kỳ sự tương tác người dùng nào thông qua các sự kiện timer-based. Các ứng dụng có thể gửi các yêu cầu một cách định kỳ đến server để update thông tin trên web. Ví dụ một ứng dụng tài chính có thể sử dụng đối tượng XHR để update các phần của trang web để hiển thị thông tin cổ phiếu hiện hành. Các tester có thể không biết về quá trình này trong background nếu chúng không yêu cầu đúng thời điểm, khi không thể nhìn thấy các link hay các button, để gây chú ý đến các tester các request được tạo ra bên trong background.

* Nâng cấp DOM động

Các đáp ứng của Ajax có thể bao gồm các đoạn nhỏ Javascript, các đoạn nhỏ này có thể được đánh giá ở các ứng dụng web và thể hiện ở giao diện người dùng. Điều này có thể là các link mới, truy cập mới đến các tài liệu mới trên server và tương tự như vậy. Để thực hiện điều này là thực hiện tuyên bố eval(). Tuyên bố này cần có một tham số đơn, một chuỗi và thực thi nó như thể nó là một phần của chương trình.

Một ví dụ như Google Suggest, khi ứng dụng này nhận được một mẩu Javascript được thực thi và thực hiện như sự đề xuất để hoàn thành việc chất vấn. Thói quen này có thể khó hiểu cho các tester thủ công cũng như tự động. Cả hai sẽ phải hiểu nội dung xung quanh việc Javascript đang được sử dụng trong các ứng dụng web như thế nào. Cần phải chú ý khi một tham số đầu vào được gửi được đánh giá trên trình khách. Điều này nghe có vẻ giống XSS nhưng nó khó khai thác hơn. Các ứng dụng thực hiện hiệu lực blacklist thậm chí dễ bị ảnh hưởng bởi vì các kẻ tấn công không cần điều chỉng ở các tag. Trong quá khứ đã có vài phương pháp sử dụng XSS mà không có tag script.

* XML Fuzzing

Ajax có thể được sử dụng để gửi các yêu cầu và nhận các đáp ứng trong định dạng XML. Đơn giản, các công cụ hiểu các phương thức GET và POST nhưng có thể không hiểu phải giải quyết thông tin có sử dụng định dạng XML như thế nào.

Tester phải bảo đảm rằng các chuyên gia phát triển ứng dụng không đi chệch hướng cấu trúc. Trong một hệ thống, các điều kiện bẩo mật được bổ sung trong môi trường người dùng. Anh ta phải nhìn qua các mã trình khách để xác định xem nó có làm thay đổi trạng thái biến cố (cookies, tham sô From, tham số GET) hay không trước khi đệ trình chúng lên server. Điều này xảy ra ở bất kỳ thời điểm nào, mã Javascript cần phải được xác định rõ lý do cho vấn đề này.

Giống như các ứng dụng web điển hình, tất cả các yêu cầu nên được kiểm tra cấp phép. Các chuyên gia có thể trở thành nạn nhân nếu tin rằng chỉ có trang được gọi là ẩn dưới kịch bản thông qua người dùng của trình khách mà việc cấp phép này là không cần thiết.

Kết luận

Các ứng dụng Ajax đã cung cấp khả năng mới thông qua đặc tính tương tác cao của nó. Chính vì vậy các chuyên gia nên quan tâm đến sự không bảo đảm việc bảo mật trên. Các chuyên gia bảo mật cần phải cải thiện các phương pháp và thiết lập các công cụ hữu ích cho các ứng dụng Ajax. Trong bài viết này, chúng tôi chỉ cung cấp những vấn đề chung về các lỗ hổng được phát hiện trong Ajax.