Bảo mật ứng dụng Web: kiểm tra thâm nhập thủ công hay quét tự động

GIỚI THIỆU

Với hơn 90% các ứng dụng Web có mắc các lỗi bảo mật và hơn 70% các tấn công là vào các giao thức HTTP/S. Chính vì vậy, các tổ chức cần phải bổ sung các công cụ mạng để bảo đảm cho các ứng dụng Web của họ. Tỷ lệ phần trăm của các tấn công xuất hiện trên cổng 80 và 443 dường như rất lớn, mặt khác ở đây là các cổng này gần như là cửa trước để tổ chức truyền thông online.

Ngày nay, khi các ứng dụng Web ngày càng trở nên phức tạp thì một số lượng lớn các dữ liệu nhạy cảm trong đó có thông tin cá nhân, tài chính, y tế được trao đổi và lưu trữ. Các khách hàng không chỉ mong đợi mà chính bản thân họ còn yêu cầu cần được bảo mật các thông tin này. Nhưng việc đánh giá một ứng dụng Web sẽ đi đến đâu bằng việc kiểm tra ứng dụng theo phương pháp thủ công hay bằng các công cụ và hệ thống tự động. Nó cho ta thấy từ các khái niệm, bằng việc mô hình hóa rủi ro bảo mật được giới thiệu trong các ứng dụng cũng như các biện pháp đối phó khác được thêm vào bổ sung. Sự bảo mật cần phải được xem như là các thành phần quan trọng khác trong mỗi ứng dụng, phải được phân tích, xem xét qua từng bước trong mỗi chu kỳ sử dụng của ứng dụng. Việc tìm ra các lỗ hổng trong các ứng dụng Web có thể được thực hiện bằng nhiều cách:

Tự động

• Bằng các công cụ quét
• Sự phân tích tĩnh

Thủ công

• Kiểm tra sự thâm nhập
• Xem xét lại code

Mục đích chính của bài viết này là để kiểm tra các phương pháp phát hiện lỗ hổng đặc biệt là việc so sánh giữa phương pháp tự động và phương pháp kiểm tra sự thâm nhập thủ công.

LỊCH SỬ

Việc kiểm tra sự thâm nhập bảo mật thủ công là phương pháp đã có từ lâu. Các nhà phát triển kiểm tra các lỗ hổng ứng dụng của họ và các vấn đề trong suốt thời gian tồn tại của ứng dụng. Tuy nhiên, khi mà các tấn công ngày càng tinh vi và các ứng dụng phức tạp ngày một tăng thì mục tiêu của các chuyên gia là tìm ra và khai thác các vấn đề bảo mật như vậy càng thể hiện rõ. Những người này được biết đến như là các “cây kiểm tra”. Việc kiểm tra tự động các ứng dụng Web được đưa ra năm 1992. Khi đó các web còn khá sơ sài và các trình duyệt web chỉ đủ để có thể quản lý sự phức tạp của các ứng dụng động. Mục tiêu chính của các công cụ này là tự động quá trình kiểm tra ứng dụng web và các lỗi liên quan với mục đích tìm ra các lỗ hổng.

CÁC LOẠI LỖ HỔNG

Nhìn chung, hầu hết các ứng dụng web đều có thể nhóm thành một trong hai loại: kỹ thuật và logic. Các lỗ hổng kỹ thuật được biết đến như là: Cross-Site Scripting (XSS), Injection Flaws(các khe hở dễ bị xâm nhập) và Buffer Overflows (tràn bộ đệm). Còn các lỗ hổng logic thì khó khăn hơn trong việc phân loại ra. Các lỗ hổng này liên quan đến tính logic của ứng dụng mà nó chưa hề được dự định từ trước. Ví dụ: vào đầu năm 2002, một người đã cố ý sử dụng lỗ hổng logic để vòng tránh được sự kiểm tra tính hợp lệ của các thông tin cá nhân cần thiết trong ứng dụng Microsoft Hotmail - cho phép người dùng thiết lập lại mật khẩu bằng việc đoán câu trả lời với mỗi câu hỏi bảo mật đơn lẻ.

CÁC LỖ HỔNG KỸ THUẬT

Các công cụ và các hệ thống tự động cho việc kiểm tra các lỗ hổng kỹ thuật phải bao gồm cả tính phương pháp và tính toàn diện. Xem xét qua ứng dụng đăng ký cho Microsoft Hotmail. Biểu mẫu này bao gồm xấp xỉ 30 thành phần cần thiết: một số bị ẩn, một số được trưng bày. Mỗi thành phần của biểu mẫu này là tiềm ẩn nguy cơ Cross-Site Scripting, Injection Flaws, Buffer Overflows hay Improper Error Handling. Bạn có biết rằng có tới hơn 70 kỹ thuật khác nhau có thể được sử dụng để khám phá Cross-Site Scripting. Điều này cho thấy rằng biểu mẫu đăng ký cần phải có hơn 2000 lần test mới có thể test thấu đáo. Các hệ thống cũng như công cụ như crawl hay phân tích và kiểm tra ứng dụng web tốt hơn so với cách kiểm tra thủ công các ứng dụng. Tuy nhiên các công cụ đang kiểm tra và đang quét thường không phát hiện hết được 100% các lỗ hổng kỹ thuật, không có lý do nào có thể tin tưởng rằng điều này sẽ xảy ra trong tương lai gần. Cuộc chạy đua ban đầu tồn tại với các công cụ quét đang có nhiều vấn đề trong cụ thể như:

- Trình khách sinh các URL

- Các hàm JavaScript

- Ứng dụng logout

- Các hệ thống dựa trên phiên liên lạc yêu cầu chỉ rõ các đường dẫn người dùng

- Đệ trình form tự động

- Các password

- Các website “vô tận” với các session ID dựa trên URL ngẫu nhiên

Các công cụ bảo mật ứng dụng web tự động đang ngày càng được hoàn thiện, các cuộc chạy đua giữa hai phương pháp thủ công và tự động này đều cần có điểm chung và cần được làm sáng tỏ. Thứ nhất, đánh giá tự động sẽ giảm bất kỳ sự không chắc chắn nào (hướng tích cực). Ngược lại, thời gian sẽ là nguyên nhân không khả thi của kiểm tra thủ công với các lỗ hổng kỹ thuật để tăng từ khó khăn nhỏ đến không thể khi kích thước và phạm vị ứng dụng tăng. Trong nhiều tổ chức kinh doanh, nó sẽ không đơn giản để giảm thời gian, sự cố gắng và tiền cần để truy cập hàng nghìn các ứng dụng web đang tồn tại. Thứ hai, vai trò của con người ảnh hưởng đến việc kiểm tra hàng nghìn đến hàng triệu các lỗ hổng kỹ thuật là chủ đề đáng nói và không thể tin tưởng một cách tuyệt đối. Quan điểm của các nhà nghiên cứu của công ty IDC là “Vấn đề là sự thời gian và giá thành. Việc làm thủ công là tốn thời gian và giá thành. Nhưng nếu bạn có những người làm việc tốt thực sự thì nó sẽ rất an toàn, còn nếu không, họ sẽ chỉ nhìn vào các dòng code mỗi ngày. Với phần mềm quét, bạn có thể làm các công việc này nhanh hơn, rẻ hơn và có thể bao phủ nhiều vùng lãnh thổ địa lý.”

CÁC LỖ HỔNG LOGIC

Các lỗ hổng logic có thể được khám phá bằng việc hiểu một ứng dụng làm việc như thế nào và bằng việc tìm ra các yếu điểm của nó. Khi cả công cụ tự động và kỹ năng kiểm tra đều không tích cực thông qua một ứng dụng web, thì chính khi đó bạn sẽ phải cần đến hiểu ứng dụng làm việc như thế nào và quá trình logic nằm dưới nó ra sao. Việc hiểu sự logic của một ứng dụng sẽ cho phép kiểm tra sự thâm nhập thủ công để phá vỡ logic kinh doanh và phơi bày ra các lỗ hổng bảo mật. Ví dụ: một ứng dụng có thể hướng vào người dùng từ điểm A đến điểm B rồi đến điểm C, trong đó, điểm B tồn tại một kiểm tra bảo mật hợp lệ. Sự xem xét thủ công tại A của ứng dụng có thể cho thấy rằng nó là hoàn toàn có thể đi trực tiếp từ điểm A đến điểm C bằng việc thông qua việc hợp lệ từ điểm B.

THỐNG KÊ

Dựa vào phân tích gần đây của 100 website, các con số thống kê dưới đây đã được đưa ra:

- 36% các website có kiểm tra thủ công phát hiện kém hơn số lỗ hổng so với phương pháp tự động.

- 17% kiểm tra thủ công phát hiện các lỗ hổng trong khi đó quét tự động không thể thấy một lỗ hổng nào.

- 46% việc tìm kiếm của các kiểm tra viên thủ công và công cụ quét tự động đã được bổ sung.

Các thống kê có thể sai lạc, và công thức 80-20 không cần thiết để áp dụng. Vì việc tìm được 80% các lỗ hổng là không đủ nếu một lỗ hổng lớn bị bỏ qua.

KẾT LUẬN

Ở phần trên chúng ta đã được nghe giới thiệu về các phương pháp khác nhau được sử dụng để khám phá các lỗ hổng trong bảo mật ứng dụng web. Cả hai phương pháp kiểm tra thủ công và bằng các công cụ tự động đều có thể được sử dụng để khám phá các lỗ hổng trong các ứng dụng. Các công cụ tự động có hạn chế của nó, tuy nhiên nếu sử dụng đúng, các công cụ tự động có thể được sử dụng trong các tổ chức để tìm ra một dãy các lỗ hổng, việc này làm cho chúng ta có thể tiết kiệm được tiền và thời gian. Với cách kiểm tra thủ công được sử dụng để tăng kết quả cho các lỗ hổng logic. Các tổ chức từ đó sẽ quyết định sự trộn lẫn của việc quét tự động với quét thủ công để đưa ra ứng dụng web có bảo mật tốt nhất.