CHƯƠNG 4 THỰC NGHIỆM VÀ PHÂN TÍCH KẾT QUẢ
4.2.2. Phân tích thực nghiệm
Khi đã cấu hình xong, mọi yêu cầu gửi từ trình duyệt đến server đều bị chặn bởi burpsuite và chúng ta tiến hành chỉnh sửa các yêu cầu đó và thực thi tấn công nhờ chức năng Intruder nhƣ sau:
Hình 4.5: Kết quả quét trên phần mềm Trường Nhà
Danh sách hiện thị ra các giá trị đầu vào cùng với kết quả phản hồi, giúp chúng ta biết đƣợc REQUEST chúng ta gửi đi là gì, và những phản hồi nhận lại đƣợc là gì và từ đó biết đƣợc có khả năng lỗi ở đâu.
Request và response tương ứng với các đầu vào
Giá trị đầu vào
Hình 4.6: Thƣ̣c nghiệm công cụ Netsparker 4.3.2. Phân tích thực nghiệm
Netsperker tìm ra một loạt các vấn đề trong trang web này, những khả năng mà kẻ
tấn công có thể lợi dụng nhƣ: mật khẩu đƣợc truyền ngang qua HTTP, hoặc khả năng tự động hiển thị một vài trường quan trọng như trường mật khẩu, hay trường Credit Card, Django Stack Trace Disclosure …Hình trên là giao diện của công cụ trong khi quét. Nó hiển thị toàn bộ thông tin về “site map”- tức thông tin bố cục trang web của bạn, “Scan information” – thông tin về tốc độ quét, các yêu cầu lỗi…, “Issues”- là tất cả các vấn đề về bảo mật mà Netsperker phát hiện ra, nó đƣợc hiển thị rõ về lỗi, mức độ quan trọng khi bạn nhấn vào nó.
Lỗ hổng xảy ra tại: http://truongnha.com/admin/
Lỗi mật khẩu đƣợc truyền ngang qua HTTP: Khi tồn tại lỗi này xảy ra, kẻ tấn công có thể lợi dụng và làm chặn lại giao thông mạng và ăn trộm chứng thực của người sử dụng hợp pháp. Để tránh được lỗ hổng này xảy ra, các dữ liệu nhảy cảm, hay các form hoặc trang nên đƣợc truyền ngang qua HTTPs thay thì truyền qua HTTP không an toàn.
Lỗ hổng Django Stack Trace Disclosure: là khả năng hiển thị chi tiết trang web lỗi tại những ứng dụng web mục tiêu.
Xảy ra tại: http://truongnha.com/register/. Ảnh hưởng khi tồn tại lỗ hổng này, kẻ
tấn công có thể:
Lấy đƣợc thông tin về phiên bản của Django và Python
Sử dụng kiểu cơ sở dữ liệu, tên của người sử dụng cơ sở dữ liệu đó, và tên cơ sở dữ liệu hiện thời
Thông tin chi tiết về cấu hình của dự án Django
Biết được đường dẫn tới các tệp bên trong hệ thống
Các ngoại lệ từ mã nguồn, biến địa phương và các giá trị của biến.
Những thông tin này giúp cho kẻ tấn công có thể chống lại hệ thống, khai thác các lỗ hổng của hệ thống dựa trên các thông tin đã biết, từ đó thực thi khai thác chúng, có thể dẫn đến phá hủy hệ thống. Để khắc phục lỗi này, nhà phát triển phần mềm nên thay đổi cấu hình của Django là: thay đổi lựa chọn DEBUG tới false.
Bên cạnh đó có rất nhiều nhƣ̃ng lỗi với mƣ́c độ thấp hơn nhƣ:
Lỗi bên trong máy chủ : Máy chủ đáp trả lại về một HTTP với trạng thái 500, điều đó chỉ ra lỗi về phía m áy chủ. Thông tin này sau đó sẽ được phân tích một cách cẩn thận . Sự ảnh hưởng của lỗ hổng này phụ thuộc vào nhiều điều kiện nhưng nó có khả năng sẽ gây ra tấn công dưới dạng SQL Injection . Để ngăn chặn lỗ hổng này xảy ra, nhà phát triển phần mềm nên xem xét lại mã chương trình để ngăn chặn những lỗi không mong đợi , để không làm lộ những thông tin ra ngoài , các lỗi nên đƣợc xử lý ở phía máy chủ . Lỗ hổng này xảy ra tại : http://truongnha.com/static/bootstrap/
Cookie không được đánh dấu như HTTPOnly : HTTPOnly là một cơ chế bảo mật cookie . Nếu một khi cookie được đánh dấu như HTTPOnly thì cookie không có khả năng truy cập được từ máy khách . Do đó nó có khả năng tạo thêm một tầng bảo vệ chống lại tấn công XSS . Trang web này sẽ có khả năng bị kẻ
tấn công truy cập cookie một cách dễ dàng . Để ngăn chặn các lỗi này , nhà phát triển phần mềm nên đánh dấu cookie với cờ HTTPOnly để tạo một tầng bảo mật chống lại XSS cho các trang Web của mình.
4.4. Skipfish
4.4.1. Thực nghiệm
Skipfish là một công cụ dò tìm bảo mật cho các ứng dụng Web một cách hiệu quả.
Nó chuẩn bị một tập các trang tương tác với nhau cho trang đích đến bởi việc thực hiện quét đệ quy và dò tìm dựa trên các thƣ mục. Việc sắp xếp kết quả sau đó đƣợc
o Tốc độ cao: Sử dụng code C, xử lý tối ƣu HTTP cao, dấu vết CPU thấp – đạt đƣợc 2000 yêu cầu trên mỗi giây một cách dễ dàng với sự phản hồi của đích đến trong mạng LAN/WAN, trên 500 yêu cầu cho mỗi giây trên mạng Internet, hơn 7000 yêu cầu chống lại các thực thể địa phương, với một CPU đơn giản nhất. Kết hợp các luồng đơn lẻ, không đồng bộ mạng I/O và mô hình xử lý dữ liệu, loại bỏ ra quản lý về bộ nhớ, kế hoạch và những đại diện không hiệu quả trong một số đa luồng máy khách.
o Dễ học và dễ sử dụng: Skipfish mang tính thích nghi và mức độ tin tưởng cao.
Chuẩn đóan để hỗ trợ rất nhiều những nền tảng Web và những trang có áp dụng nhiều công nghệ, với khả năng tự học...
o Logic bảo mật tiên tiến: chất lƣợng cao, khả năng lỗi thấp, kiểm tra đƣợc các kiểu bảo mật khác nhau, khả năng phát hiện ra một miền lỗi tinh vi, bao gồm cả lỗi Blind injection.
o Tạo ra kết quả dưới dạng HTML rất tốt.
o Phát hiện đƣợc lỗ hổng dạng XSRF (Cross-Site Request Forgery)
Nhƣợc điểm:
o Không hỗ trợ các Plugin
o Không phát hiện đƣợc lỗ hổng dạng: reflected và stored XSS
Tóm lại: Công cụ này tiện ích cho những người quen sử dụng dòng lệnh và nó hỗ trợ việc tạo ra báo cáo dưới dạng HTML rất hữu ích. Tuy nhiên nó không thể nắm bắt đƣợc các tham số yêu cầu trong ứng dụng.
Công cụ này được dùng trên các môi trường: Linux, FreeBSD, MacOS X và Windows (Cygwin)
Dưới đây là thực nghiệm chương trình chạy trên trang http://truongnha.com và Hình 4.7 là kết quả của việc chạy công cụ Skipfish , nó thể hiện nhƣ̃ng cảnh báo , thông tin về mƣ́c độ nguy hiểm nhiều , ít của công cụ này tới hệ thống web . Tuy nhiên kết quả ở đây chỉ tìm ra đƣợc một cảnh báo.
Để xem chi tiết của cảnh báo này , người dùng có thể mở kết quả dưới dạng tệp html nhƣ Hình 4.8 sau:
Hình 4.8: Chi tiết về thông tin cảnh báo của công cụ Skipfish 4.4.2. Phân tích thực nghiệm
Hình 4.7: Kết quả chạy công cụ Skipfish
Thƣ̣c hiện việc tìm kiếm lỗ hổng an ninh cho ƣ́ng dụng Web : http://truongnha.com, và thu đƣợc kết quả nhƣ sau:
Hình 4.9: Công cụ W3af bật các plugin 4.5.2. Phân tích thực nghiệm
Kết quả của công cụ đƣợc hiển thị trong bản “Log”
Hình 4.10: Thông tin các lỗ hổng và các lỗi trên công cụ W3af
Bên cạnh đó , công cụ này còn thể hiện được biểu đồ xuất hiện các điểm yếu . Kết quả của việc tìm kiếm ra các lỗ hổng này phụ thuộc vào việc chọn các plugin trong phần “scan config”. Và chúng ta có thể nhìn thấy kết quả bên cột “Result” nhƣ sau:
Hình 4.11: Kết quả các lỗ hổng được tìm thấy bởi W3af Chúng ta cùng đi phân tích các lỗ hổng sau đây:
collectCookies: công cụ tìm ra rất nhiều cookies, điều đó đồng nghĩa với việc kẻ
tấn công cũng có thể dùng công cụ này vào việc tìm ra cookies và đăng nhập được vào hệ thống để chỉnh sửa điểm hay thao tác tùy theo ý của họ.
serverHeader: thông số của máy chủ đã bị lộ , cung cấp thêm thông tin cho kẻ
tấn công. Nó đƣợc tìm thấy tại yêu cầu ID 2.
Xsrf (get_xsrf): Phát hiện ra lỗi Cross Site Request Forgery của ứng dụng.
Error500: một lỗi của ứng dụng này không được xác nhận đ ã được tìm thấy t ại:
http://truongnha.com/_vti_inf.html".
4.6. Websecurify 4.6.1. Thực nghiệm
Chúng ta thực thi quét trang web với công cụ Websecurify và có kết quả nhƣ sau:
Hình 4.12: Kết quả chạy công cụ Websecurify 4.6.2. Phân tích thực nghiệm
Dưới đây là các lỗ hổng được tìm thấy bởi công cụ này
Error Disclosure: khi lộ thông tin này, kẻ tấn công biết thêm về ứng dụng , phiên bản và cấu hình hiện tại của ứng dụng giúp ích cho vi ệc khai thác các điểm yếu đó.
Autocomplete Enable: khi những trường thông tin nhạy cảm được hiển thị , kẻ
tấn công có thể truy cập vào bộ đệm có thể lấy được các thông tin đó và tấn công bởi các thông tin nhƣ mật khẩu, cookies…
Email Disclosure: Máy chủ hoặc ứng dụng bị lộ địa chỉ email . Điều này sẽ gây ra một cuộc spam thư, hay lộ thông tin của người dùng nào đó.
Banner Disclosure: Máy chủ và ứng dụng bị lộ các thông tin về phiên bản và kiểu.
4.7. Tổng hợp đánh giá
Chương này thực hiện việc kiểm thử an ninh cho ứng dụng quản lý trường học phổ thông mang tên “Trường Nhà” (http://truongnha.com) và phát hiện ra các lỗ hổng bảo mật giúp ứng dụng này có thể giảm thiểu phần nào các thiệt hại gây ra . Dưới đây là
danh sách các công cụ thực thi trên ứng dụng “Trường Nhà”, và các lỗ hổng đã đư ợc miêu tả chi tiết trong khi thực thi từng công cụ trong các phần thực nghiệm trên:
XSS X
DOS/DDOS X
Lộ đường dẫn X X
Lộ ngôn ngữ ứng
dụng X X
Tấn công liên
trang giả mạo X
Mật khẩu truyền
qua HTTP X
Mật khẩu tự động
hiển thị X
Lộ thông tin máy
chủ X X X
Hiển thị cookies X X X
Khả năng tự động
hiện thị các trường X X X
Ngoài các công cụ đƣợc liệt kê với các lỗ hổng trên, luận văn cũng thực thi áp dụng các công cụ khác nhƣ: Skipfish và Burp suite ở giai đoạn sau khi những lỗ hổng trên đã đƣợc nhà phát triển vá thì những lỗ hổng này đã không còn.
Dưới đây là một vài kh uyến cáo đối với các nhà phát triển phần mềm trong quá
trình tôi làm luận văn, hi vọng có thể giúp các ứng dụng Web giảm thiểu được lỗ hổng bảo mật anh ninh cho trang Web của mình:
o Đảm bảo rằng bất kỳ nhƣ̃ng lỗ i ứng dụng đều đƣợc xử lý ở phía máy chủ và không bao giờ hiện thị tới người dùng . Nếu khi hiển thị lỗi để thông báo lỗi do người dùng nhập vào, thì không nên để lộ những thông tin nhạy cảm như : ngôn
ngƣ̃, phiên bản…
o Đối với các trường có thông tin nhạy cảm như : trường mật khẩu, cookies… nên sửa thuộc tính: autocomplete="off" để tránh trường hợp chúng được lưu vào bộ nhớ đệm, kẻ tấn công có thể truy nhập vào và khai thác chúng.
o Để tránh lỗ hổng mật khẩu được truyền đi không an toàn , chúng ta nên sử dụng HTTPs khi truyền nhƣ̃ng dƣ̃ liệu nhạy cảm.
o Tất cả những thông tin được nhập vào từ người dùng phải được kiểm tra trước khi xử lý.
o Các máy chủ nên sƣ̉ dụng apache httpd 2.2.15 (trở đi) có thêm module mod_reqtimeout – tƣ̀ đó các request mà quá thời gian thì nó sẽ hủy đi kết nối đó
và giải phóng cho các request khác. Điều này tránh được việc nắm giữ hệ thống quá lâu gây nên nghẽn mạng.
o Để ngăn chặn các lỗi về cookies nhà phát triển phần mềm nên đánh dấu cookie với cờ HTTPOnly để tạo một tầng bảo mật chống lại XSS cho các trang Web của mình.
Toàn bộ chương này tập trung đi sâu vào quét lỗ hổng bảo mật bởi các công c ụ hiện đại được sử dụng nhiều hiện nay trên ứng dụng quản lý trường học tại
http://truongnha.com. Thêm vào đó , chương này đưa ra một vài khuyến cáo để giúp ứng dụng có thể giảm thiểu các lỗ hổng an ninh nhằm ngăn chặn tấn công của kẻ tấn công vào ƣ́ng dụng . Nhƣ̃ng khuyến cáo này cũng có thể áp dụng với những ứng dụng Web khác. Dựa vào việc thực nghiệm trên, luận văn cũng đƣa ra một qui trình áp dụng cho việc sử dụng các công cụ một cách hiệu quả nhƣ sau:
o Đầu tiên, chúng ta nên sử dụng công cụ Websecurify vì công cụ cài đặt rất đơn giản, không mất thời gian và có khả năng tìm đƣợc những lỗ hổng cơ bản và quan trọng nhƣ: SQL Injection, XSS, các thông số bị lộ.
o Sau đó, khi đã phát hiện được những lỗ hổng cơ bản, người dùng muốn phát hiện rộng thêm các lỗ hổng khác, chúng ta có thể áp dụng các công cụ nhƣ Acunetix và Netsparker vì chúng có nhiều lựa chọn và nhiều cấu hình hơn cho người dùng để quét toàn bộ cấu trúc trang Web, từ đó có khả năng phát hiện ra các lỗ hổng nhƣ DOS, các cổng thông tin mở và mật khẩu đƣợc truyền một cách không an toàn.
o Cuối cùng, đối với người dùng quen dùng chế độ dòng lệnh có thể sử dụng thêm các công cụ nhƣ W3af và Skipfish để quét lại một lƣợt để phát hiện thêm một vài lỗ hổng nhƣ dạng tấn công liên trang giả mạo.
Với việc áp dụng một quy trình nhƣ vậy, ứng dụng Web cũng sẽ phần nào giảm