-
09/04/2020
-
93
-
610 bài viết
Lỗ hổng path traversal trong thư viện kiểm soát an ninh doanh nghiệp OWASP
Ứng dụng an ninh Open Web (OWASP) đã sửa một lỗi trong Enterprise Security API (ESAPI) có thể bị lạm dụng để thực hiện các cuộc tấn công path traversal.
Lỗ hổng liên quan đến giao diện trình xác thực ESAPI và xếp hạng mức điểm CVSS 7.5/10, hiện đã có bản vá được phát hành trong phiên bản 2.3.0.0.
OWASP ESAPI cung cấp một thư viện kiểm soát an ninh, giúp các nhà phát triển phần mềm doanh nghiệp code an toàn hơn. Công nghệ này được thiết kế để nhúng vào các ứng dụng (chủ yếu là web) như một giải pháp an ninh chủ động. Dù đây là lỗ hổng khó khai thác, OWASP vẫn khuyến cáo việc cập nhật vì sợ mức độ rủi ro cao sau này.
Validator.getValidDirectoryPath được triển khai mặc định có thể kiểm chuỗi đầu vào không chính xác giống như một mục con trong thư mục lớn. Điều này khiến vượt qua sự kiểm soát, nếu cuộc tấn công có thể xác định toàn bộ chuỗi đường dẫn đầu vào.
Wall nói thêm: “Ngay cả khi Validator.getValidDirectoryPath () được sử dụng trong một ứng dụng không có nghĩa là nó có thể khai thác trong chính ứng dụng của bạn. Cần phải phân tích trong từng trường hợp cụ thể”.
Theo Wall, trong hầu hết các trường hợp sử dụng, ESAPI dễ bị tấn công sẽ sử dụng cùng với tường lửa ứng dụng web (WAF) hoặc phần mềm phát hiện xâm nhập. Đối với câu hỏi về mức độ, nhà phát triển phần mềm kết luận: “Tôi không nghĩ đây là một lỗ hổng nghiêm trọng, nhưng CVSS v3.1 vẫn được đánh giá".
Wall cho biết: “Nếu không vá, người dùng cần phải thực hiện phân tích sâu để xem chính xác lỗ hổng trong một số thư viện ảnh hưởng đến ứng dụng như thế nào và đưa ra những giải pháp giảm thiểu rủi ro (ví dụ như 'vá ảo' thông qua WAF)”.
Lỗ hổng cũng có thể mang tính hướng dẫn cho các nhà phát triển thư viện vì nó minh họa tiện ích của các công cụ kiểm tra an ninh ứng dụng tĩnh (SAST). Cần có phạm vi kiểm tra thích hợp và ít nhất thực hiện đánh giá mã thủ công về 'git diffs' khi PRs được gửi trước khi chúng hợp nhất.
Wall kết luận: “Tôi nghĩ việc ESAPI có lỗi là do không được kiểm tra cụ thể, trách nhiệm thuộc về chúng tôi. Mặc dù vẫn bảo vệ nhưng chúng tôi chưa ý thức được việc tác động vào mã File.getCanonicalPath () khi giá trị cho một thư mục không kết thúc bằng ‘/’.
Lỗ hổng liên quan đến giao diện trình xác thực ESAPI và xếp hạng mức điểm CVSS 7.5/10, hiện đã có bản vá được phát hành trong phiên bản 2.3.0.0.
OWASP ESAPI cung cấp một thư viện kiểm soát an ninh, giúp các nhà phát triển phần mềm doanh nghiệp code an toàn hơn. Công nghệ này được thiết kế để nhúng vào các ứng dụng (chủ yếu là web) như một giải pháp an ninh chủ động. Dù đây là lỗ hổng khó khai thác, OWASP vẫn khuyến cáo việc cập nhật vì sợ mức độ rủi ro cao sau này.
Validator.getValidDirectoryPath được triển khai mặc định có thể kiểm chuỗi đầu vào không chính xác giống như một mục con trong thư mục lớn. Điều này khiến vượt qua sự kiểm soát, nếu cuộc tấn công có thể xác định toàn bộ chuỗi đường dẫn đầu vào.
Hạn chế tác động
Kevin Wall, đồng lãnh đạo dự án OWASP ESAPI cho biết “hầu hết các ứng dụng sử dụng ESAPI có thể không sử dụng phương pháp bị ảnh hưởng”, vì vậy tác động tiềm ẩn của lỗ hổng là dành riêng cho từng ứng dụng. “Khó để đánh giá mức độ tiếp xúc của một ứng dụng chung để khai thác lỗ hổng trong thư viện.”Wall nói thêm: “Ngay cả khi Validator.getValidDirectoryPath () được sử dụng trong một ứng dụng không có nghĩa là nó có thể khai thác trong chính ứng dụng của bạn. Cần phải phân tích trong từng trường hợp cụ thể”.
Theo Wall, trong hầu hết các trường hợp sử dụng, ESAPI dễ bị tấn công sẽ sử dụng cùng với tường lửa ứng dụng web (WAF) hoặc phần mềm phát hiện xâm nhập. Đối với câu hỏi về mức độ, nhà phát triển phần mềm kết luận: “Tôi không nghĩ đây là một lỗ hổng nghiêm trọng, nhưng CVSS v3.1 vẫn được đánh giá".
Bài học kinh nghiệm
Mặc dù lỗ hổng khó bị khai thác và ít khả năng gây ra hậu quả, nhưng nó mang lại bài học sâu sắc cho các nhà phát triển phần mềm nên sử dụng công cụ phân tích thành phần phần mềm (SCA) và nắm được các giới hạn. Một số công cụ SCA chỉ tìm thấy các lỗ hổng được báo cáo phụ thuộc trực tiếp (direct dependencies), nhưng không phải phụ thuộc bắc cầu (transitive dependencies).Wall cho biết: “Nếu không vá, người dùng cần phải thực hiện phân tích sâu để xem chính xác lỗ hổng trong một số thư viện ảnh hưởng đến ứng dụng như thế nào và đưa ra những giải pháp giảm thiểu rủi ro (ví dụ như 'vá ảo' thông qua WAF)”.
Lỗ hổng cũng có thể mang tính hướng dẫn cho các nhà phát triển thư viện vì nó minh họa tiện ích của các công cụ kiểm tra an ninh ứng dụng tĩnh (SAST). Cần có phạm vi kiểm tra thích hợp và ít nhất thực hiện đánh giá mã thủ công về 'git diffs' khi PRs được gửi trước khi chúng hợp nhất.
Wall kết luận: “Tôi nghĩ việc ESAPI có lỗi là do không được kiểm tra cụ thể, trách nhiệm thuộc về chúng tôi. Mặc dù vẫn bảo vệ nhưng chúng tôi chưa ý thức được việc tác động vào mã File.getCanonicalPath () khi giá trị cho một thư mục không kết thúc bằng ‘/’.
Theo Portswigger
Chỉnh sửa lần cuối: