Quy trình đánh giá an toàn và bảo mật website

MỤC LỤC TrangDANH MỤC CÁC KÝ HIỆU VÀ CHỨ VIẾT TẮT3DANH MỤC CÁC BẢNG, SƠ ĐỒ, HÌNH4CHƯƠNG I : TỔNG QUAN VỀ AN NINH MẠNG VÀ ỨNG DỤNG WEB7I.1. TỔNG QUAN VỀ AN NINH MẠNG7I.2 TỔNG QUAN VỀ ỨNG DỤNG WEB8I.2.1 KHÁI NIỆM ỨNG DỤNG WEB8I.2.2 MÔ TẢ HOẠT ĐỘNG CỦA MỘT ỨNG DỤNG WEB10I.2.3 CÁC NGUYÊN NHẬN VÀ MỐI ĐE DỌA WEBSITE :11I.3 CÁC KHÁI NIỆM VÀ THUẬT NGỮ:12I.3.1 HACKER:12I.3.2 HTTP HEADER:12I.3.3 SESSION:12I.3.4 COOKIE:13I.3.5 PROXY:15CHƯƠNG II: GIỚI THIỆU SƠ LƯỢC VỀ CÁC KĨ THUẬT ĐÁNH GIÁ MỨC DỘ BẢO MẬT VÀ AN TOÀN ỨNG DỤNG WEB16II.1 KHÁI NIỆM AN NINH WEBSITE :16II.2.GIỚI THIỆU VỀ PENTEST16II.2.1 KHÁI NIỆM PENTEST16II.2.2 PHƯƠNG PHÁP SỬ DỤNG TRONG PENTEST.17II.2.3 TIÊU CHUẨN ĐÁNH GIÁ WEB – OWASP TOP 10 201318II.3 CÁC CÔNG CỤ ĐÁNH GIÁ ĐỘ AN TOÀN VÀ BẢO MẬT CỦA MỘT WEBSITE22II.3.1 CÔNG CỤ KIỂM TRA THỦ CÔNG22II.3.2 CÔNG CỤ KIỂM TRA TỰ ĐỘNG24II.4 QUY TRÌNH ĐÁNH GIÁ ĐỘ AN TOÀN VÀ BẢO MẬT CỦA MỘT WEBSITE27II.4.1 THU THẬP THÔNG TIN.27I.4.2 QUY TRÌNH KIỂM TRA CÁC VẤN ĐỀ CẤU HÌNH, QUẢN TRỊ CỦA ỨNG DỤNG WEB.30II.4.3 QUY TRÌNH KIỂM TRA QUẢN LÝ DANH TÍNH CỦA ỨNG DỤNG WEB.33II.4.5 QUY TRÌNH KIỂM TRA CÁC VẤN ĐỀ PHÂN QUYỀN CỦA ỨNG DỤNG WEB.37II.4.6 QUY TRÌNH KIỂM TRA CÁC VẤN ĐỀ QUẢN LÝ PHIÊN CỦA ỨNG DỤNG WEB.39II.4.7 QUY TRÌNH KIỂM TRA CÁC VẤN ĐỀ KIỂM SOÁT DỮ LIỆU CỦA ỨNG DỤNG WEB.42II.4.8 QUY TRÌNH KIỂM TRA CÁC VẤN ĐỀ VỀ LỖI CỦA ỨNG DỤNG WEB.44CHƯƠNG III: THỰC HIỆN ĐÁNH GIÁ AN TOÀN VÀ BẢO MẬT HCM.PTIT.EDU.VN46III.1 GIỚI THIỆU HCM.PTIT.EDU.VN46III.2 THỰC HIỆN ĐÁNH GIÁ AN TOÀN VÀ BẢO MẬT WEBSITE HCM.PTIT.EDU.VN47III.2.1 Thu Thập Thông Tin47III.2.2 Kiểm tra các vấn đề về cấu hình50III.2.3 Kiểm tra các vấn đề về Phân quyền52III.2.4 Kiểm tra các vấn đề về Session53III.2.5 Kiểm tra các vấn đề đầu vào54III.2.6 Kiểm tra các vấn đề lỗi55III.3 Tổng Kết56CHƯƠNG IV: THỰC HIỆN ĐÁNH GIÁ AN TOÀN VÀ BẢO MẬT UIS.PTITHCM.EDU.VN64IV.1 GIỚI THIỆU UIS.PTITHCM.EDU.VN64IV.2 THỰC HIỆN ĐÁNH GIÁ AN TOÀN VÀ BẢO MẬT WEBSITE UIS.PTITHCM.EDU.VN65IV.2.1 Thu Thập Thông Tin65IV.2.2 Kiểm tra các vấn đề về cấu hình67IV.2.3 Kiểm tra các vấn đề về danh tính70IV.2.4 Kiểm tra các vấn đề về xác thực71IV.2.5 Kiểm tra các vấn đề về Phân quyền75IV.2.6 Kiểm tra các vấn đề về Session76IV.2.7 Kiểm tra các vấn đề kiểm soát dữ liệu đầu vào78IV.2.8 Kiểm tra các vấn dề lỗi79IV.3 TỔNG KẾT79KẾT LUẬN86DANH MỤC TÀI LIỆU THAM KHẢO87

MỤC LỤC

Trang

Từ viết tắt Tên tiếng Anh Tên tiếng Việt

HTTP HypertextProtocol Transfer Giao thức truyền tải siêu văn bản

Management System Hệ quản trị cơ sở dữ liệu

Locator

Định vị Tài nguyên thống nhất

Application Security Project

Dự án mở về bảo mật ứng dụng Web

Security Consortium

Bào mật ứng dụng web thông dụng

XSS Cross Site Scripting thực thi script độc hại

CSRF Cross Site Request

Hình I.2.1.2-Mô hình hoạt động của một ứng dụng Web

Hình I.3.4.: Các thành phần của một cookie

Hình I.3.4.2: Cookie

Chương II

BÁNG II.2.3.1 Đánh giá các lỗi bảo mật Owasp Top Ten 2013 (Trích Owasp Top Ten 2013)

Hình II.3.1.1-Giao diện WebScarab

Hình II.3.1.2-Giao diện BurpSuite

Hình II.3.2.1-Giao diện OWASP Zed Attack Proxy (ZAP)

Hình II.3.2.2-Giao diện Acunetix WVS (Web Vulnerability Scanner)

Bảng II.4.1.b.1 HTTP Request-Response:

Bảng II.4.6.a.1 Ví dụ CSRF

Bảng II.4.7.b.1 Ví dụ Command injection

Chương III

Bảng III.1.1 Chức năng hcm.ptit.edu.vn

Hình III.2.1.1 : Truy cập tập tin robots.txt

Hình III.2.1.2:Duyệt cấu trúc site với Burp Suite

Hình III.2.1.3: Fingerprint Web Server với Burp Suite

Hình III.2.1.4: Fingerprint Web Server với httprint

Hình III.2.1.5:Mã nguồn trang

Hình III.2.2.1:Xác định các cổng và dịch vụ website với nmap

Hình III.2.2.2:Xác định HTTP Method bằng netcat

Hình III.2.2.3:Xác định các HTTP header trong HTTP response

Hình III.2.2.5:Kiểm tra giao thức ssl thông qua bên thứ ba.

Hình III.2.3.1:Sử dụng DotDotPwn trong backtrack 5 để khai thác Directory Traversal

Hình III.2.3.2:Kiểm tra Directory Listing

Hình III.2.4.1:Kiểm tra thuộc tính cookie

Hình III.2.5.1:Kiểm tra SQL Injection với SQL Injection Me

Hình III.2.5.2 :Kiểm tra XSS với XSS Me

Hình III.2.5.3 :Kiểm tra XSS thủ công

Hình III.2.6.1 Thông báo lỗi

Hình III.2.6.2 :Kiểm tra link báo lỗi

Bảng III.3.1 Kết quả đánh giá bảo mật và an toàn hcm.ptit.edu.vn

Chương IV

Bảng IV.1.1 Chức năng uis.ptithcm.edu.vn

Hình IV.2.1.1 : Truy cập tập tin robots.txt

Hình IV.2.1.2:Duyệt cấu trúc site với Burp Suite

Hình IV.2.1.3: Fingerprint Web Server với Burp Suite

Hình IV.2.1.4: Fingerprint Web Server với httprint

Hình IV.2.1.5:Mã nguồn trang

Hình IV.2.2.1:Xác định các cổng và dịch vụ website với nmap

Hình IV.2.2.2:Xác định HTTP Method bằng netcat

Hình IV.2.2.3:Xác định các HTTP header trong HTTP response

Hình IV.2.2.4:Kiểm tra giao thức https của website

Hình IV.2.2.5:Kiểm tra giao thức ssl thông qua bên thứ ba

Hình IV.2.3.1:Đăng nhập với username và mật khẩu hợp lệ

Hình IV.2.3.2:Đăng nhập với username đúng và mật khẩu sai

Hình IV.2.3.3:Đăng nhập với username không tồn tại

Hình IV.2.4.1: Bỏ qua xác thực với SQL Injection

trong trình duyệt

Hình IV.2.4.3: Kiểm tra thông tin đăng nhập trong cookie

Hình IV.2.4.4: Kiểm tra thuộc tính autocomplete form password

Bảng IV.4.5 Kiểm tra cơ chế khóa tài khoản

Hình IV.2.4.6:Kiểm tra Brute Force bằng Burp Suite

Hình IV.2.4.7:Kiểm tra Cache-control

Hình IV.2.4.8:Sử dụng nút Back sau khi thoát đăng nhập

Hình IV.2.5.1:Sử dụng DotDotPwn trong backtrack 5 để khai thác Directory Traversal

Hình IV.2.5.2:Kiểm tra Directory Listing

Hình IV.2.6.1:Cookie của hacker

Hình IV.2.6.2:Set Cookie của victim giống cookie hacker

Hình IV.2.6.3:Duyệt web bằng tài khoản victim

Hình IV.2.6.4:Kiểm tra thuộc tính cookie

Hình IV.2.7.1:Kiểm tra sql injection bằng sql injection me

Hình III.2.7.2 :Kiểm tra XSS với XSS Me

Hình IV.2.8.1: Thông báo lỗi

Bảng IV.3.1 Kết quả đánh giá bảo mật và an toàn uis.ptithcm.edu.vn

CHƯƠNG I : TỔNG QUAN VỀ AN NINH MẠNG VÀ ỨNG DỤNG WEB

TỔNG QUAN VỀ AN NINH MẠNG

Tình hình an ninh mạng trên toàn cầu đang diễn biến ngày càng phức tạp với tần suất các cuộc tấn công nghiêm trọng diễn ra thường xuyên hơn Tại Việt Nam, chỉ tính từ đầu năm 2015 đến nay, đã có 2.460 website của các cơ quan,

doanh nghiệp bị xâm nhập Trong năm 2014 cho thấy có tới 40% website

thuộc các đơn vị trọng yếu, doanh nghiệp lớn của Việt Nam tồn tại lỗ hổng Một trong những nguyên nhân của tình trạng này là thiếu quy trình kiểm tra đánh giá cũng như kinh nghiệm về lập trình an toàn

Khả năng có thể truy cập 24/7 từ bất cứ nơi nào trên thế giới hay các ứng dụng web không an toàn thường cung cấp truy cập dễ dàng đến cơ sở dữ liệu

là một sơ hở lớn cho phép tin tặc có thể thực hiện các hoạt động bất hợp pháp bằng cách sử dụng các trang web đã tấn công Hầu hết nguyên nhân của các

vụ tấn công này là do website tồn tại nhiều lỗ hổng bảo mật

Một điều đáng lo ngại nữa là đối với các cá nhân, tổ chức và doanh nghiệp, CNTT nói chung và các ứng dụng web nói riêng đang trở thành một trong các nhân tố, công cụ đắc lực hỗ trợ tăng hiệu suất làm việc và lợi nhuận, hiểu quả kinh tế cao cho họ, nhưng sự quan tâm, và chi phí bỏ ra cho lĩnh vực bảo trì, bảo mật lại không đáng kể

Đồng thời các mói nguy hiểm đe dọa ngày càng mới và phát triển phức tạp hơn, khả năng tấn công và khai thác của các kẻ xấu đã tăng lên rõ rệt, các

mã độc, phần mềm độc hại, virut trở nên khó phát hiện và tiêu diệt hơn

Vì vậy vấn đề an ninh mạng nói chung và bảo mật Web Application nói riêng đang là một vấn đề quan trọng và cấp bách cần phải được nghiên cứu, tìm hiểu và đưa ra các giải pháp và kỹ thuật mới để phòng tránh, đồng thời cá nhân, tổ chức và doanh nghiệp cũng cần dành nhiều thời gian, kinh phí, nhân lực kỹ thuật để đảm bảo cho hệ thống mạng cũng như Web Application của mình hoạt động tốt, có khả năng chống chọi và ngăn chặn trước các mối nguy hiểm và các cuộc tấn công

I.2 TỔNG QUAN VỀ ỨNG DỤNG WEB

I.2.1 KHÁI NIỆM ỨNG DỤNG WEB

Ứng dụng Web là một ứng dụng chủ/khách sử dụng giao thức HTTP để tương tác với người dùng hay hệ thống khác

Trình khách dành cho người sử dụng thường là một trình duyệt Web như Internet Explorer hay Netscape Navigator Cũng có thể là một chương trình đóng vai trò đại lý người dùng hoạt động như một trình duyệt tự động Người dùng gửi và nhận các thông tin từ trình chủ thông qua việc tác động vào các trang Web Các chương trình có thể là các trang trao đổi mua bán, các diễn đàn, gửi nhận e-mail…

Tốc độ phát triển các kỹ thuật xây dựng ứng dụng Web cũng phát triển rất nhanh Trước đây những ứng dụng Web thường được xây dựng bằng CGI (Common Gateway Interface) được chạy trên các trình chủ Web và có thể kết nối vào các cơ sở dữ liệu đơn giản trên cùng máy chủ Ngày nay ứng dụng Web thường được viết bằng Java (hay các ngôn ngữ tương tự) và chạy trên máy chủ phân tán, kết nối đến nhiều nguồn dữ liệu

Một ứng dụng web thường có kiến trúc gồm:

Hình I.2.1.1-Kiến trúc một ứng dụng web

ngoài ra còn có thể có thêm các ứng dụng tạo bố cục cho trang web.

• Lớp ứng dụng: là nơi xử lý của ứng dụng Web Nó sẽ xử lý thông tin

người dùng yêu cầu, đưa ra quyết định, gửi kết quả đến “lớp trình bày”

Lớp này thường được cài đặt bằng các kỹ thuật lập trình như CGI, Java, NET , PHP hay ColdFusion, được triển khai trên các trình chủ như IBM WebSphere, WebLogic, Apache, IIS…

• Lớp dữ liệu: thường là các hệ quản trị dữ liệu (DBMS) chịu trách nhiệm quản lý các file dữ liệu và quyền sử dụng

Mô hình hóa hoạt động của một ứng dụng Web:

Hình I.2.1.2-Mô hình hoạt động của một ứng dụng Web

Trong đó:

• Trình khách ( hay còn gọi là trình duyệt): Internet Explorer, Netscap Navigator

• Trình chủ: Apache, IIS, …

• Hệ quản trị cơ sở dữ liệu: SQL Server, MySQL, DB2, Access…

Bên cạnh đó, một giải pháp dùng để bảo vệ một hệ thống mạng thường được

sử dụng là bức tường lửa, nó có vai trò như là lớp rào chắn bên ngoài một

hệ thống mạng, vì chức năng chính của firewall là kiểm soát luồng thông tin giữa các máy tính Có thể xem firewall như một bộ lọc thông tin, nó xác định và cho phép một máy tính này có được truy xuất đến một máy tính khác hay không, hay một mạng này có được truy xuất đến mạng kia hay không

Người ta thường dùng firewall vào mục đích:

• Cho phép hoặc cấm những dịch vụ truy xuất ra ngoài

• Cho phép hoặc cấm những dịch vụ từ bên ngoài truy nhập vào trong

• Kiểm soát địa chỉ truy nhập, cấm địa chỉ truy nhập

Firewall hoạt động dựa trên gói IP do đó kiểm soát việc truy nhập của máy người sử dụng

I.2.2 MÔ TẢ HOẠT ĐỘNG CỦA MỘT ỨNG DỤNG WEB

Đầu tiên trình duyệt sẽ gửi một yêu cầu (request) đến trình chủ Web thông qua các lệnh cơ bản GET, POST… của giao thức HTTP, trình chủ lúc này có thể cho thực thi một chương trình được xây dựng từ nhiều ngôn ngữ như Perl, C/C++… hoặc trình chủ yêu cầu bộ diễn dịch thực thi các trang ASP, JSP… theo yêu cầu của trình khách

Tùy theo các tác vụ của chương trình được cài đặt mà nó xử lý, tính toán, kết nối đến cơ sở dữ liệu, lưu các thông tin do trình khách gửi đến…và từ đó trả về cho trình khách 1 luồng dữ liệu có định dạng theo giao thức HTTP, nó gồm 2 phần:

• Header mô tả các thông tin về gói dữ liệu và các thuộc tính, trạng thái

trao đổi giữa trình duyệt và WebServer.

• Body là phần nội dung dữ liệu mà Server gửi về Client, nó có thể là một file HTML, một hình ảnh, một đoạn phim hay một văn bản bất kì

Theo mô hình ở Hình I.2.1.2, với firewall, luồng thông tin giữa trình chủ và trình khách là luồng thông tin hợp lệ Vì thế, nếu hacker tìm thấy vài lỗ hổng trong ứng dụng Web thì firewall không còn hữu dụng trong việc ngăn chặn hacker này Do đó, các kĩ thuật tấn công vào một hệ thống mạng ngày nay đang dần tập trung vào những sơ suất (hay lỗ hổng) trong quá trình tạo ứng dụng của những nhà phát triển Web hơn là tấn công trực tiếp vào hệ thống mạng, hệ điều hành Tuy nhiên, hacker cũng có thể lợi dụng các lỗ hổng Web để mở rộng sự tấn công của mình vào các hệ thống không liên quan khác

I.2.3 CÁC NGUYÊN NHẬN VÀ MỐI ĐE DỌA WEBSITE :

Trong quá trình hoạt động, ứng dụng web thường được phép truy xuất đến các tài nguyên quan trọng của hệ thống đó là máy chủ web và máy chủ cơ sở dữ liệu

Thông thường khi phát triển ứng dụng, các lập trình viên thường dành nhiều thời gian cho các chức năng, giao diện mà bỏ qua vấn đề bảo mật Điều đó không có nghĩa là lập trình viên không quan tâm đến vấn đề bảo mật mà vấn

đề ở chỗ họ thường thiếu kiến thức về bảo mật và vấn đề bảo mật thường bị bỏ qua trong giai đoạn thiết kế và xây dựng ứng dụng

Ứng dụng có lỗ hỗng bảo mật thường bị tin tặc khai thác để chiếm quyền điều khiển máy chủ web và máy chủ cơ sở dữ liệu Từ đó tin tặc có thể triển khai các kiểu tấn công khác như:

• Thay đổi giao diện trang web

• Chèn các mã độc được cài đặt tự động vào máy người dùng khi họ truy cập vào ứng dụng

• Chèn các mã độc để lấy cắp các thông tin về phiên làm việc (session ID)

• Lấy cắp thông tin về được lưu trữ trên cơ sở dữ liệu

• Truy cập tự do vào những vùng cấm

•

I CÁC KHÁI NIỆM VÀ THUẬT NGỮ:

I.3 HACKER:

Hacker là một thuật ngữ dùng để chuyên chỉ những kẻ phá hoại các hệ thống mạng…Hacker thường là những chuyên gia về máy tính Hacker không tạo ra các kẽ hở chohệ thống, nhưng hacker lại là những người am hiểu về hệ điều hành, hệ quản trị dữ liệu, các ngôn ngữ lập trình…

Họ sử dụng kiến thức của mình trong việc tìm tòi và khai thác các lỗ hổng của hệ thống mạng Một số hacker chỉ dừng lại việc phát hiện và thông báo lỗi tìm được cho những nhà bảo mật hay người phát triển chương trình, họ được xem như là WhiteHat (Hacker mũ trắng) Một số hacker dựa vào những

lỗ hổng thực hiện việc khai thác trái phép nhằm mục đích phá hoại hay mưu lợi riêng, những người này bị xem như là BlackHat (Hacker mũ đen)

I.3 HTTP HEADER:

HTTP header là phần đầu (header) của thông tin mà trình khách và trình chủ gửi cho nhau Những thông tin trình khách gửi cho trình chủ được gọi là HTTP requests (yêu cầu) còn trình chủ gửi cho trình khách là HTTP responses (trả lời) Thông thường, một HTTP header gồm nhiều dòng, mỗi dòng chứa tên tham số và giá trị Một số tham số có thể được dùng trong cả header yêu cầu và header trả lời, còn số khác thì chỉ đuợc dùng riêng trong từng loại

I.3 SESSION:

HTTP là giao thức hướng đối tượng tổng quát, phi trạng thái, nghĩa là HTTP không lưu trữ trạng thái làm việc giữa trình duyệt với trình chủ Sự thiếu sót này gây khó khăn cho một số ứng dụng Web, bởi vì trình chủ không biết được trước đó trình duyệt đã có những trạng thái nào Vì thế, để giải quyết vấn đề này, ứng dụng Web đưa ra một khái niệm phiên làm việc (Session) Còn SessionID là một chuỗi để chứng thực phiên làm việc Một số trình chủ sẽ cung cấp một SessionID cho người dùng khi họ xem trang web trên trình chủ

Để duy trì phiên làm việc thì sessionID thường được lưu vào :

 Biến trên URL

 Biến ẩn form

Phiên làm việc chỉ tồn tại trong một khoảng thời gian cho phép, thời gian này được cấu hình qui định tại trình chủ hoặc bởi ứng dụng thực thi Trình chủ sẽ tự động giải phóng phiên làm việc để khôi phục lại tài nguyên của hệ thống

mà còn tùy thuộc vào người dùng có chấp nhận chuyện lưu trữ đó hay không.

Ở những lần truy cập sau đến trang Web đó, ứng dụng có thể dùng lại những thông tin trong cookie (như thông tin liên quan đến việc đăng nhập vào Yahoo Messenger! ) mà người dùng không phải làm lại thao tác đăng nhập hay phải cung cấp lại các thông tin khác

Cookie được phân làm 2 loại secure/non-secure và persistent do đó ta sẽ có 4 kiểu cookie là:

Non-persistent cookie thì được lưu trữ trên bộ nhớ RAM của máy khách và sẽ bị hủy khi đóng trang web hay nhận được lệnh hủy từ trang web.Secure cookies chỉ có thể được gửi thông qua HTTPS (SSL)

Non-Secure cookie có thể được gửi bằng cả hai giao thức HTTPS hay HTTP Thực chất là đối với secure cookie thì trình chủ sẽ cung cấp chế độ truyền bảo mật

Domain Flag Path Secure Expiratio

n Name Value

1154029490

Apache

64.3.40.151.16018996349247480

Hình I.3.4.: Các thành phần của một cookie

 Domain: tên miền của trang Web đã tạo cookie (trong ví dụ trên là www.redhat.com)

 Flag: mang giá trị TRUE/FALSE xác định các máy khác với cùng tên miền có được truy xuất đến cookie hay không

 Path: Phạm vi các địa chỉ có thể truy xuất cookie

 Sercure: Mang giá trị TRUE/FALSE xác định đây là một secure cookie hay không nghĩa là kết nối có sử dụng SSL hay không

 Expiration: Thời gian hết hạn của cookie, được tính bằng giây kể từ 00:00:00 giờ GMT ngày 01/01/1970 Nếu giá trị này không được thiết lập thì trình duyệt sẽ hiểu đây là non-persistent cookie và chỉ lưu trong bộ nhớ RAM

và sẽ xóa nó khi trình duyệt bị đóng

 Name: tên biến (trong trường hợp này là Apache)

 Value: Với cookie được tạo ở trên thì giá trị của Apache 54.3.40.151.16018996349247480 và hết hạn là 27/07/2006, của tên miền

Kích thước tối đa của cookie là 4kb Số cookie tối đa cho một tên miền

là 20 cookie.Cookie bị hủy ngay khi đóng trình duyệt gọi là “session cookie”

I.3 PROXY:

Proxy cung cấp cho người sử dụng truy xuất Internet những nghi thức đặt biệt hoặc một tập những nghi thức thực thi trên dual_homed host hoặc

basion host Những chương trình client của người sử dụng sẽ qua trung gian proxy server thay thế cho server thật sự mà người sử dụng cần giao tiếp.

Proxy server xác định những yêu cầu từ client và quyết định đáp ứng hay không đáp ứng, nếu yêu cầu được đáp ứng, proxy server sẽ kết nối với server thật thay cho client và tiếp tục chuyển tiếp những yêu cầu từ client đến server, cũng như trả lời của server đến client Vì vậy proxy server giống cầu nối trung gian giữa server và client

CHƯƠNG II: GIỚI THIỆU SƠ LƯỢC VỀ CÁC KĨ THUẬT ĐÁNH GIÁ MỨC DỘ BẢO MẬT VÀ AN TOÀN ỨNG DỤNG WEB

II.1 KHÁI NIỆM AN NINH WEBSITE :

An ninh Website là bằng các phương pháp khoa học và kỹ thuật đánh giá một cách tổng thể và chi tiết về an tòan bảo mật website Các phương pháp đánh giá và phân tích được dựa trên cơ sở sử dụng các công cụ kỹ thuật chuyên dụng và kỹ thuật tấn công phân tích Kết quả của việc đánh giá sẽ cho biết về mức độ an tòan của hệ thống, khả năng phòng chống trước những tấn công ngày càng nhiều và nguy hiểm trên mạng Internet Kết quả cung sẽ chỉ ra các thiếu sót cần khắc phục trong việc triển khai và vận hành hệ thống

II.2.GIỚI THIỆU VỀ PENTEST

II.2.1 KHÁI NIỆM PENTEST

Là hình thức kiểm tra hệ thống CNTT của bạn có thể bị tấn công hay không, bằng cách giả lập các vụ tấn công thử nghiệm tạo ra Có thể hiểu một cách đơn giản Penetration Testing ( Pentest ) chính là đánh giá độ an toàn bằng cách tấn công vào hệ thống

Pentest khác với Vulnerability Assessment Vulnerability Assessment là quá trình xem xét lại các dịch vụ và hệ thống để tìm ra các vấn đề an ninh tiềm tàng hoặc dò tìm các dấu vết khi hệ thống bị tổn thương Người thực hiện một thử nghiệm xâm nhập được gọi là kiểm tra xâm nhập hoặc pentester

Khi thâm nhập thử nghiệm cần phải có sự cho phép của người sở hữu hệ thống Nếu không, sẽ là hacking hệ thống, và đó là bất hợp pháp Nói cách khác: Sự khác biệt giữa thử nghiệm thâm nhập và hack là có sự cho phép của chủ sở hữu hệ thống

Pentest cần được thực hiện trên cơ sở tuân thủ các tiêu chuẩn quốc tế về đánh giá an ninh bảo mật cho hệ thống như sau:

• Đánh giá ứng dụng Web – OWASP (Open-source Web Application Security Project): OWASP là một chuẩn mở cho phép tổ chức/DN tiến hành xây dựng, phát triển, duy trì hoạt động của các ứng dụng trên nền tảng web một cách bảo mật nhất Quá trình đánh giá dựa trên các tiêu chí đã được cộng đồng bảo mật xác nhận OWASP bao gồm 10 lỗ hổng được đánh giá một cách

chi tiết và cập nhật thường xuyên với thực tế các nguy cơ mà một ứng dụng web thường gặp.

• Đánh giá mạng và hệ thống – OSSTMM (Open Source Security Testing Methodology Manual): OSSTMM là một chuẩn mở cung cấp phương pháp kiểm tra bảo mật một hệ thống đang hoạt động của doanh nghiệp Từ phiên bản 3.0, OSSTMM đưa ra phương pháp kiểm định cho hầu hết các thành tố trong hệ thống như: con người, hạ tầng vật lý, mạng không dây, truyền thông

và các mạng sử dụng truyền dữ liệu

II.2.2 PHƯƠNG PHÁP SỬ DỤNG TRONG PENTEST.

• Hộp đen (Black box) :

Tấn công từ ngoài vào (black box Pen Test): các cuộc tấn công được thực hiện

mà không có bất kỳ thông tin nào, pentester sẽ đặt mình vào vị trí của những tin tặc mũ đen và cố gắng bằng mọi cách để thâm nhập vào được mạng nội, ngoại của khách hàng

Pentester sẽ mô phỏng một cuộc tấn công thực sự vào ứng dụng ,quá trình thử nghiệm bao gồm một loạt các lỗ hổng bảo mật ở cấp ứng dụng được xác định bởi OWASP và WASC (Web Application Security Consortium), nhắm mục tiêu các lỗ hổng bảo mật nguy hiểm tiềm tàng trong ứng dụng của khách hàng Quá trình thử nghiệm sẽ tiết lộ các lỗ hổng, thiệt hại khai thác tiềm năng và mức độ nghiêm trọng

• Hộp trắng (White box)

Tấn công từ trong ra (white box Pen Test): là các thông tin về mạng nội bộ và ngoại sẽ được cung cấp bởi khách hàng và Pentester sẽ đánh giá an ninh mạng dựa trên đó

Điều quan trọng là cho các tổ chức để xác định rủi ro và mối đe dọa của họ xuất phát từ đâu Nếu doanh nghiệp cảm nhận được nó đến từ các nhân viên, khách hàng hoặc đối tác thương mại, nó có thể có lợi để tiến hành một thử nghiệm hộp Penetration trắng Nhân viên, khách hàng và các đối tác thương mại có kiến thức về thông tin của doanh nghiệp Họ có thể biết rằng Doanh Nghiệp có một Intranet hoặc Extranet, trang web, và họ cũng có thể có các thông tin cho phép họ để đăng nhập vào hệ thống Họ có thể biết nhân viên làm việc trong tổ chức, cơ cấu quản lý, các ứng dụng chạy trong môi trường Tất cả các thông tin này có thể được sử dụng để khởi động các cuộc tấn công

nhắm mục tiêu nhiều hơn đối với một cơ sở hạ tầng, mà có thể không được xác định là một phần của một sự tham gia thử nghiệm Black Box.

• Hộp xám (Gray box)

Kiểm định hộp xám (Gray-box hay Crystal-box): Giả định như tin tặc được cung cấp tài khoản một người dùng thông thường và tiến hành tấn công vào hệ thống như một nhân viên của doanh nghiệp

II.2.3 TIÊU CHUẨN ĐÁNH GIÁ WEB – OWASP TOP 10 2013

OWASP (Open Web Application Security Project) là 1 dự án mở về bảo mật ứng dụng web, dự án là sự cố gắng chung của cộng đồng với mục đích giúp các doanh nghiệp có thể phát triển, mua và bảo trì các ứng dụng web một cách

an toàn

OWASP cung cấp cho cộng đồng nhiều nguồn “tài nguyên” khác nhau:

• Công cụ và tiêu chuẩn về an toàn thông tin

• Các bộ chuẩn về kiểm tra bảo mật ứng dụng, lập trình an toàn và kiểm định mã nguồn

• Các thư viện và tiêu chuẩn điều khiển an toàn thông tin

• Các nghiên cứu mới nhất về bảo mật ứng dụng web

• Các maillist uy tín về thông tin bảo mật

để bảo vệ chống lại các rủi ro và hướng dẫn để xử lý

OWASP Top 10 2013 :

 A1 – Injection ( Lỗi mã nhúng ) : Xảy ra trong các ứng dụng như SQL, LDAP khi những dữ liệu không xác thực được gửi tới hệ thống biên dịch như một phần của mã lệnh Những dữ liệu này của kẻ tấn công có thể lừa hệ thống biên dịch thực hiện những mã lệnh độc hại hoặc giúp kẻ tấn công xâm nhập đến những dữ liệu quan trọng một cách trái phép

 A2 – Broken Authentication and Session Management ( Sai lầm trong

l{ phiên làm việc của người sử dụng thường hay được làm qua loa không đúng cách Điều này giúp kẻ thâm nhập có thể ăn cắp mật mã, khóa, mã của các phiên làm việc {session token} hoặc tận dụng những lỗi khác để giả mạo danh tính các người dùng khác.

 A3 – Cross Site Scripting ( XSS – thực thi script độc hại ) : Xảy ra khi một ứng dụng tiếp nhận những dữ liệu không đáng tin cậy và gửi chúngđến cho trình duyệt web mà không qua xử l{ và kiểm duyệt XSS cho phép kẻ tấn công thực hiện mã độc trên trình duyệt của người bị tấn công và lợi dụng ăn cắp phiên truy cập để mạo danh hoặc hủy hoại trang web hoặc lừa người sử dụng đến những trang web chứa mã độc khác

 A4 – Insecure Direct Object References ( Đối tượng tham chiếu thiếu

an toàn ) :Xảy ra khi người phát triển để lộ một tham chiếu đến những đối tượng trong hệ thống như các tập tin, thư mục hay chìa khóa dữ liệu Nếu chúng ta không có một hệ thống kiểm tra truy cập, kẻ tấn công có thể lợi dụng những tham chiếu này để truy cập dữ liệu một cách trái phép

 A5 – Security Misconfiguration ( Sai sót cấu hình an ninh ) : Một cơ chế an ninh tốt cần phải định nghĩa những hiệu chỉnh về an ninh và triển khai

nó cho các ứng dụng, khuôn mẫu, máy chủ ứng dụng, máy chủ web, máy chủ

dữ liệu và các ứng dụng nền tảng Tất cả những thiệt lập nên được định nghĩa, thực hiện và bảo trì bởi vì rất nhiều thứ không được triển khai với thiết lập an toàn mặc định Các hiệu chỉnh cũng bao gồm cập nhật phần mềm và những thư viện được sử dụng bởi ứng dụng

 A6 - Sensitive Data Exposure ( Tiếp xúc với dữ liệu nhạy cảm ) : Các

dữ liệu nhạy cảm được lưu trữ không an toàn có thể gây ra những ảnh hưởng to lớn cho hệ thống máy chủ, cũng như cho khách hàng

 A7 – Missing Function Level Access Control ( Sai sót hạn chế truy cập ) : Nhiều ứng dụng web kiểm tra quyền thực thi địa chỉ truy cập (URL) trước khi dựng các liên kết và nút nhấn được bảo vệ Tuy nhiên ứng dụng cũng phải thực hiện những kiểm tra tương tự mỗi khi những trang thông tin được truy cập trực tiếp nếu không kẻ tấn công có thể giả mạo URL để truy cập vào những trang thông tin ẩn này

 A8 – Cross Site Request Forgery ( CSRF – Giả mạo yêu cầu ) : Kiểu tấn công này ép buộc trình duyệt web của một người dùng đã đăng nhập gửi những yêu cầu giao thức web (HTTP) tới một trang web bị lỗi, bao gồm cookie của phiên truy cập và những thông tin tự động khác như thông tin đăng nhập

Cách thức này cho phép kẻ tấn công buộc trình duyệt web tạo ra những yêu cầu cho ứng dụng lỗi mà ứng dụng này không thể biết đây là những yêu cầu giả mạo của kẻ tấn công

 A9 – Using Know Vulnerable Components (Sử dụng thành phần đã tồn tại lỗ hổng ) : Các lổ hỏng có thể có trong các thành phần (thành phần phát triển ứng dụng) như các thư viện, các framework, và mô-đun phần mềm khác Các thành phần này gần như luôn luôn chạy với quyền cao nhất trong hệ thống Vì vậy, nếu bị khai thác, các thành phần này có thể gây mất dữ liệu nghiêm trọng.Các ứng dụng sử dụng các thành phần tồn tại lổ hỏng có thể làm suy yếu phòng thủ của hệ thống, cho phép một loạt các cuộc tấn công và ảnh hưởng đến hệ thống

 A10 – Unvalidated Redirects and Forwards ( Thiếu thẩm tra chuyển hướng và chuyển tiếp ) : Ứng dụng web thường xuyên đưa người dùng đến những liên kết qua các website khác, và sử dụng những thông tin thiếu tin cậy

để xác định đích đến Nếu không được kiểm tra một cách cẩn thận, kẻ tấn công

có thể lợi dụng để chuyển nạn nhân đến các trang web lừa đảo hay phần mềm độc hại, hoặc chuyển tiếp để truy cập các trang trái phép

Bảng sau đây trình bày tóm tắt của năm 2013 Top 10 rủi ro về bảo mật ứng dụng,và các yếu tố cấu thành chúng ta đã gán cho mỗi rủi ro Những yếu tố này được xác định dựa trên các số liệu thống kê sẵn có và kinh nghiệm của đội OWASP

Còn tùy vào từng ứng dụng cụ thể mà từng lỗ hổng có những tác nhân gây hại

và ảnh hưởng kinh doanh khác nhau

năng khai thác

Mức dộ phổ biến Khả năng

phát hiện

BÁNG II.2.3.1 Đánh giá các lỗi bảo mật Owasp Top Ten 2013

II.3 CÁC CÔNG CỤ ĐÁNH GIÁ ĐỘ AN TOÀN VÀ BẢO MẬT CỦA MỘT WEBSITE

II.3.1 CÔNG CỤ KIỂM TRA THỦ CÔNG

Kiểm tra thủ công là quá trình kiểm tra mà người kiểm tra phải xác định vị trị

dữ liệu cần được đệ trình đến ứng dụng bằng cách sử dụng các intercepting proxy (là một ứng dụng nằm giữa ứng dụng và trình duyệt, cho phép người kiểm tra thay đổi giá trị một cách tùy biến trước khi đệ trình đến ứng dụng) và tập dữ liệu cần đệ trình đến ứng dụng tương ứng với các vị trí đệ trình đã xác định trước đó Một số công cụ tiêu biểu:

• WebScarab (http://www.owasp.org/software/webscarab.html) là một framework được viết bằng Java phục vụ cho việc phân tích những ứng dụng web với hai giao thức hỗ trợ HTTP và HTTPS WebScarab có khả năng ghi lại hoặc thay đổi tham số ứng dụng trước khi đi trình những yêu cầu, phản hồi giữa trình duyệt và ứng dụng web Ngoài ra, công cụ còn cho phép thực hiện một số chức năng hữu ích khác như:

– Spider (duyệt toàn bộ cấu trúc của website): Sẽ thực hiện quét toàn bộ thư mục và tập tin của ứng dụng web

– SessionID Analysis (phân tích chỉ số phiên làm việc): Cho phép phân tích phiên làm việc giữa trình duyệt và ứng dụng

– Fuzzer: Một chức năng tự động truyền dữ liệu đối với các tham số đã được người kiểm tra chỉ định trước đó.

Hình II.3.1.1-Giao diện WebScarab

• BurpSuite (http://portswigger.net/suite/) cũng là một framework được viết bằng Java cũng có chức tương tự như webScarab như intercepting proxy, spider, fuzzer, … BurpSuite hiện tại có hai phiên bản, một phiên bản miễn phí

và một phiên bản thương mại Phiên bản thương mại thì có thêm phần tự động quét các lỗi ứng dụng web và cho phép người sử dụng có thể tìm kiếm hoặc lưu lại trạng thái trong quá trình kiểm tra các ứng dụng web Một số điểm nổi bật của BurpSuite có thể điểm qua đó là:

– Chức năng spider trong BurpSuite thông minh hơn WebScarab ở chỗ khi nó nhận diện các dữ liệu cần đệ trình thì nó sẽ thông báo cho người kiểm tra biết Người kiểm tra sẽ xem xét và đệ trình dữ liệu phù hợp để BurpSuite có thể quét toàn bộ thư mục và tập tin của ứng dụng web một cách hiệu quả nhất

– Quá trình intercepting proxy có nhiều tùy chọn chọn lọc hơn so với webscarab, cho phép người kiểm tra ứng dụng có thể tùy biến trong việc theo dõi việc trao đổi dữ liệu giữa trình duyệt và ứng dụng web

– Chức năng Intruder trong BurpSuite giống như chức năng Fuzzer của WebScarab nhưng lại cho tùy biến các vị trí dữ liệu cần đệ trình đến ứng dụng uyển chuyển và linh hoạt hơn

– Một số chức năng phụ mạnh như: so sánh kết quả từ sự phản hồi của ứng dụng, cung cấp một số phương thức giải mã thông dụng base64, htmlencode,

…

– Chức năng thực hiện tự động kiểm tra các lỗi SQLi, XSS, Path Traversal, … Chức năng này chỉ có trong phiên bản có thu phí Quá trình kiểm tra tự động các lỗi bảo mật cũng thực hiện trên việc đệ trình các dữ liệu gây ra lỗi SQLi, XSS, … trên những tham số mà BurpSuite thu thập được.

– Chức năng lưu phiên làm việc (chỉ có tác dụng trong bản thu phí) cho phép người kiểm tra có thể lưu phiên làm việc của mình với BurpSuite

Hình II.3.1.2-Giao diện BurpSuite

II.3.2 CÔNG CỤ KIỂM TRA TỰ ĐỘNG

Phương pháp kiểm tra lỗi tự động là quá trình các công cụ sẽ thực hiện tự

động quét thư mục, tập tin của ứng dụng web và tự động xác định các điểm

mà cần đệ trình dữ liệu Trên cơ sở đã xác định các điểm cần đệ trình tự động tiếp đến công cụ sẽ thực hiện đệ trình các tập dữ liệu được định nghĩa sẵn và chờ sự phản hồi từ phía ứng dụng web để kiểm tra xem liệu ứng dụng đó có bị các lỗi bảo mật hay không? Một số công cụ tiêu biểu:

• OWASP Zed Attack Proxy (ZAP): là công cụ tích hợp của tập hợp

nhiều công cụ pentest có chức năng khác nhau ZAP cho phép người sử dụng

có thể thực hiện nhiều tác vụ nhằm dò tìm điểm yếu trên ứng dụng web

Những tiện ích nổi bật của ZAP

 Intercepting Proxy : Bản chất ZAP là một proxy chặn giữa người dùng

và ứng dụng web

 Automated scanner

 Passive scanner

 Brute Force scanner : Cho phép tìm cây thư mục,tính năng này là sự tích hợp của công cụ Dir Buster mà mình đã giới thiệu trước đó

 Spider : Tìm kiếm các url trong website

 Fuzzer : Tích hợp tiện ích JbroFuz

Hình II.3.2.1-Giao diện OWASP Zed Attack Proxy (ZAP)

• Acunetix WVS (Web Vulnerability Scanner) là chương trình tự động

kiểm tra các ứng dụng Web để tìm kiếm các lỗ hổng bảo mật như SQL Injection, hay Cross-Site Scripting,… và tìm kiếm những chính sách đối với mật khẩu đăng nhập cũng như các phương thức xác thực vào Web Site

Acunetix WVS là một công cụ quét lỗi cho ứng dụng Web dựa trên một cơ sở

dữ liệu rộng lớn được cập nhật thường xuyên, với các thuật toán heuristic đáp ứng được các cơ chế họat động phức tạp của môi trường Web Acunetix WVS

có thể tự động kiểm tra các lổ hỗng thông dụng như cross site scripting, sql injection và các mối nhạy cảm khác của những web site có thể truy cập bằng trình duyệt, hay những ứng dụng được xây dụng trên các kỹ thuật tiên tiến như AJAX để thực hiện được điều này Acunetix WVS dựa trên nhiều phương pháp và công cụ tích hợp để:

• Crawling (lấy về) toàn bộ website gồm tất cả các liên kết trên site và cả trong tập tin robots.txt sau đó hiển thị tòan bộ cấu trúc này một cách chi tiết

• Sau tiến trình cwarling và khám phá tình trạng của ứng dụng web, Acunetix WVS tự động phát động các đợt tấn công đã được lập trình sẳn dựa trên các lổ hổng, giống như khi web site bị 1 hacker tấn công thực sự, phân tích các trang và những vị trí có thể nhập liệu cùng với các sự kết hợp khác nhau của dữ liệu đầu vào có thể làm cho website hiển thị những thông tin nhạy cảm

• Sau khi tìm ra được các lổ hổng, Acunetix WVS thông báo trên các

“Alerts Node”, mỗi alert gồm các thông tin về lỗi cũng như các mối nguy hiểm có thể gặp phải và “dĩ nhiên” là kèm theo các khuyến nghị

về cách thức khắc phục

• Sau khi tiến trình kiểm tra hòan tất, chúng ta có thể lưu lại thành một tập tin để phân tích sau này, với công cụ báo cáo chuyên nghiệp sẽ giúp cho các web master dễ dàng tổng hợp các kết quả kiểm tra khác nhau trên ứng dụng Web của mình

• Sau khi quét, Acunetix WVS sẽ liệt kê cấu trúc của site, phiên bản webserver đang sử dụng, URL không tồn tại, các lỗi phát hiện được cũng như mức độ Security của site đang quét Mức độ bảo mật của website được AWV đánh giá từ low, medium, high Nếu website được liệt kê ở mức low, hãy nhanh chóng fix lỗi mà AWV liệt kê

Download : http://www.acunetix.com/vulnerability-scanner/download/

Giao diện sao khi cài đặt :

Hình II.3.2.2-Giao diện Acunetix WVS (Web Vulnerability Scanner)

II.4 QUY TRÌNH ĐÁNH GIÁ ĐỘ AN TOÀN VÀ BẢO MẬT CỦA MỘT WEBSITE

Owasp đã đưa ra một số quy trình đánh giá độ an toàn và bảo mật của môt ứng dụng website

II.4.1 THU THẬP THÔNG TIN.

a) Tiến hành khám phá công cụ tìm kiếm / trinh sát để tìm thông tin rò rỉ

Mục tiêu kiểm tra để biết những thiết kế nhạy cảm và thông tin cấu hình của ứng dụng web thông qua tiếp xúc trực tiếp (trên chính website đó ) hay gián tiếp (thông qua một trang web bên thứ ba )

• Robots.txt

File robots.txt ở dạng văn bản đặt ở mực mục gốc của trang web , để nói cho những công cụ tìm kiếm như Google những gì cần quét và những gì không cần quét trên trang web của bạn

Tuy nhiên một số nhà quản trị trang web đưa thêm vị trí của Control Panel của trang webvào danh sách file để những công cụ tìm kiếm không quét tới đó Như vậy nếu như bất kì ai ở được file robots.txt có thể xem được những thư mục không dùng tới trong phần “Disallow”

• Spider

Sử dụng các công cụ kiểm thử thủ công duyệt toàn bộ cấu trúc của website để

tự động phát hiện ra các URL của một trang web Lập danh sách URL ,biết được các liên kết gãy ,các tập tin mở rộng …

• Sử dụng các toán tử tìm kiếm

Chắc hẳn rằng, ai trong chúng ta cũng từ quen thuộc với những cú pháp tìm kiếm thông dụng của Google Áp dụng những cú pháp đó, có thể giúp mình ra kết quả nhanh hơn, chính xác hơn Tuy nhiên, vài cú pháp sau đây thì thích hợp cho hacker hơn

• Site :Là toán tử dùng để tìm kiếm thông tin trong một site Điều này giúp chúng ta giới hạn phạm vi tìm kiếm lại Ví dụ cú pháp site: uit.edu.vn sẽ giới hạn phạm vi tìm kiếm trong trang webuit.edu.vn

• Intitle:index of :Cú pháp này đã có dịp chúng ta sử dụng để tìm kiếm thư mục Nó cũng được xem là cú pháp lợi hại dành cho hacker

• Error | Warning :Đây là hai cú pháp dùng để tìm kiếm thông tin lỗi Một vài thông báo lỗi khi lập trình sẽ tạo một lỗ hổng cho hacker thừa cơ đột nhật

• Login | Logon :Cú pháp dùng để tìm trang logon Nó có thể chỉ là trang đâp nhập website bình thường, nhưng cũng có thể là trang đăng nhập vào một hệ thống đặc biệt hơn Đứng trước cửa rồi, việc tấn công vào trong thế nào còn tùy thuộc vào nhiều thứ

• Username | Userid | employerID | “your user name” :Đây là một loạt các

cú pháp tìm kiếm user name để đăng nhật hệ thống Tại sao chúng ta tìm được Đó là do vài lỗi không để ý của người lập trình Ví dụ anh ta vô tinh

cho hiển thị thông báo “Tài khoản tranvanteo vẫn chưa kích hoạt”

• Password | Passcode | “Your password is” :cũng tương tự như cú pháp về username Chúng ta dễ dàng tìm thấy nhưng câu thông báo đại loại như

là “Your password is AHTlkYu”

• Admin | Administrator :Chúng ta có khoanh vùng tìm kiếm những thông tin có liên quan đến admin với từ khóa này Những trang quản trị dành cho admin, những thông tin của admin, và nhiều thứ khác có liên quan đến admin Kết hợp với chức năng cache của Google, hiệu quả công việc sẽ tăng lên

• –ext:html –ext:htm –ext:shtml –ext:asp –ext:php :Và còn nhiều hơn nữa những cú pháp có liên quan đến –ext Cú pháp này giúp chúng ta tìm thấy những file mà chúng ta muốn Với hacker nhưng file đó có thể kể đến như php, html, bak, conf, sys…

• inurl:temp | inurl:tmp | inurl:backup | inurl:bak :Cũng giống như với ext, nhưng không tìm theo file nữa mà tìm theo thư mục Những thư mục mà hacker quan tâm như temp, backup, admin, conf…

• intranet | help.desk :Thông tin có liên quan đến bộ phận helpdesk của công

ty cũng không thể bỏ qua trong cuộc tấn công Cú pháp này giúp chúng ta

tìm thấy nhiều thông tin có liên quan đến bộ phận helpdesk

b) Fingerprint Web Server

Phương thức mà xác định phiên bản và loại của một web server được gọi là Fingerprint Web Server.Phương thức xác định các lỗ hổng được biết đến và sử dụng cách khai thác thích hợp trong quá trình kiểm thử

Hình thức đơn giản và cơ bản nhất để xác định một web server là nhìn vào các trường Server trong HTTP response header

Bảng II.4.1.b.1 HTTP Request-Response:

$ nc 202.41.76.251 80

HEAD / HTTP/1.0

HTTP/1.1 200 OK

Date: Mon, 16 Jun 2003 02:53:29 GMT

Server: Apache/1.3.3 (Unix) (Red Hat/Linux)

Last-Modified: Wed, 07 Oct 1998 11:18:14 GMT

ETag: "1813-49b-361b4df6" Accept-Ranges: bytes

Content-Length: 1179 Connection: close

Content-Type: text/html

Từ đây ta biết được web server là Apache ,phiên bản 1.3.3 ,Hệ điều hành Linux

c) Phân tích mã nguồn trang

Trong một ứng dụng web có thể chứa hàng trăm ,hàng ngàn dòng mã lệnh Và trong hầu hết các trường hợp ,thời gian để xem xét các dòng mã lệnh đó là có hạn nên ta chỉ tập trung chú ý đến các Title Tags ,thẻ meta , comment html

Comment HTML rất phổ biến đối với các lập trình viên để chú thích các chi tiết và dữ liệu trên mã nguồn của họ Tuy nhiên những ý kiến đó có thể tiết lộ thông tin không cần thiết cho hacker để cho họ có thể hiểu rõ về ứng dụng hơn

I.4.2 QUY TRÌNH KIỂM TRA CÁC VẤN ĐỀ CẤU HÌNH, QUẢN TRỊ CỦA ỨNG DỤNG WEB.

a) Kiểm tra quản lý cấu hình cơ sở hạ tầng

Để kiểm tra cơ sở hạ tầng quản lý cấu hình, những bước sau cần được thực hiện:

• Các thành phần khác nhau tạo nên cơ sở hạ tầng cần được xác định để hiểu cách chúng tương tác với một ứng dụng Web và cách chúng ảnh hưởng đến an ninh

• Các thành phần của cơ sở hạ tầng cần phải được xem xét để đảm bảo không có bất kỳ lỗ hổng nào

• Cần đánh giá lại bằng các công cụ quản trị để duy trì, bảo dưỡng các thành phần khác nhau

• Các hệ thống xác thực, nếu có, cần phải xem xét để đảm bảo rằng chỉ phục vụ nhu cầu của các ứng dụng và không bị thao tác bởi người dùng bên ngoài để leo thang truy cập

• Danh sách các cổng xác định cho các ứng dụng cần được duy trì và tuân thủ dưới sự kiểm soát sử dụng một tool quét tự động các cổng truy cập để đảm bảo tất cả các host trong mạng lưới có được đảm bảo an toàn trong mạng nội bộ và không bị truy cập bất hợp pháp từ một mạng ngoài không

• Tool quét thường dùng cho trường hợp này là NMap

b)Kiểm tra phương thức HTTP

HTTP cung cấp một số phương thức có thể được sử dụng để thực hiện hành động trên máy chủ web.Nhiều trong số các phương thức đó được thiết kế để

hỗ trợ các nhà phát triển trong việc triển khai và thử nghiệm các ứng dụng HTTP

Trong khi GET và POST là bởi đến nay các phương thức phổ biến nhất được

sử dụng để truy cập thông tin được cung cấp bởi một máy chủ web, Hypertext Transfer Protocol (HTTP) cho phép một số phương thức khác (và phần nào ít được biết đến) RFC 2616 (trong đó mô tả HTTP phiên bản 1.1 là tiêu chuẩn hiện nay) định nghĩa một số phương thức sau đây:

- GET: Phương thức lấy một đối tượng hoặc tài nguyên nào đó trên Server

- POST: Phương thức mà Client sử dụng để gửi thông tin đến các Server

- PUT: Phương thức dùng để Client upload dữ liệu lên Server

- DELETE: Phương thức giúp Client xoá các đối tượng, tài nguyên từ các Server

- HEAD: Phương thức xác minh rằng một đối tượng có tồn tại hay không

- TRACE: Phương thức được sử dụng để gọi từ xa một lớp ứng dụng trở lại ví dụ như cookie, tiêu đề ủy quyền, …

- CONNECT : Phương pháp này có thể cho phép khách hàng sử dụng các máy chủ web như là một proxy

- OPTION: Kiểm tra các phương thức HTTP được cho phép

Một số trong những phương thức đó khả năng có thể gây ra một nguy cơ bảo mật cho một ứng dụng web, vì chúng cho phép kẻ tấn công để sửa đổi các tập tin được lưu trữ trên các máy chủ web và ăn cắp các thông tin của người sử dụng hợp pháp Ví dụ:

• DELETE: Phương pháp này cho phép một khách hàng xóa một tập tin trên máy chủ web Một kẻ tấn công có thể khai thác nó một cách đơn giản và trực tiếp từ đó thay đổi một trang web hoặc để gắn nó với một cuộc tấn công DoS

Phương pháp kiểm tra rất đơn giản là sử dụng netcat (hoặc telnet)

c) Kiểm tra HSTS và HTTPS và các HTTP header hữu ích

HTTPS – giao thức truyền tiếp văn bản an toàn, đảm bảo tất cả thông tin liên lạc giữa người dùng và một trang web nhất định đi qua kênh được mã hóa

HSTS, hay còn gọi là HTTP Strict Transport Security là một header của trình duyệt bắt buộc các kết nối sau nó phải được gửi thông qua giao thức HTTPS,

về cơ bản là một chính sách bảo mật được máy chủ uỷ quyền cho website khi phát sinh giao tiếp thường xuyên với người dùng HTTP

Mỗi khi sử dụng giao thức HTTPS, thanh địa chỉ của trình duyệt sẽ xuất hiện biểu tượng hình khóa Bằng cách nhấp vào ổ khóa xuất hiện trong cửa sổ trình duyệt khi truy cập vào một trang Web https, có thể xem thông tin liên quan đến chứng nhận

Các website dùng cơ chế HSTS để đảm bảo rằng người dùng chỉ giao tiếp với máy chủ thông qua kết nối HTTPS an toàn Bằng cách thêm một cờ vào phần header mà một trình duyệt web nhận được khi gửi yêu cầu tới máy chủ, HSTS đảm bảo rằng tất cả kết nối sau đó tới một website được mã hóa bằng giao thức HTTPS Nhờ việc yêu cầu tất cả kết nối kế tiếp được mã hóa, HSTS bảo

vệ người dùng khỏi các thủ đoạn chuyển kết nối về dạng HTTP trần ngăn chặn tin tặc sử dụng chứng chỉ số không hợp lệ HSTS cũng bảo vệ người dùng với những trang HTTPS nhưng có đường dẫn HTTP hay nội dung không

mã hóa

Các HTTP header nghiêm ngặt an toàn lưu lượng sử dụng hai chỉ thị:

• max-age: để chỉ ra số giây mà trình duyệt sẽ tự động chuyển đổi tất cả các yêu cầu HTTP tới HTTPS

• includeSubDomains: để chỉ ra rằng các tên miền phụ tất cả ứng dụng web của phải sử dụng HTTPS

Strict-Transport-Security: max-age=60000; includeSubDomains

Kiểm tra HSTS header bằng cách kiểm tra sự tồn tại của tiêu đề HSTS trong server response trong một intercepting proxy

Ngoài HSTS header còn có một số HTTP header hữu ích khác cho việc bảo mật :

• X-Frame-Options, Frame-Options:Cung cấp bảo vệ Clickjacking , Header này cho biết trang web có thể được tải vào trong một frame hay không Header X- FRAME-OPTIONS có hai chế đô:DENY – cấm hoàn toàn việc tải trang web vào trong frame; SAMEORIGIN – cho phép tải trang web vào trong frame nếu trang chứa frame thuộc cùng domain với trang web được tải vào trong frame

• X-XSS-Protection :Cung cấp bộ lọc chống XSS được xây dựng vào hầu hết các trình duyệt web gần đây Nó thường được kích hoạt theo mặc định anyway, nên vai trò của header này là để tái kích hoạt bộ lọc cho trang web cụ thể

• X-Content-Type- Options nếu không được thiết lập để 'nosniff' Điều này cho phép các phiên bản cũ của Internet Explorer và Chrome để thực hiện MIME-sniffing từ các tuyên bố content-type

Trong hầu hết các kiến trúc các header có thể được thiết lập trong cấu hình máy chủ web ( Apache , IIS , nginx ), mà không thay đổi code thực tế của ứng dụng Điều này cung cấp phương pháp nhanh hơn và rẻ hơn đáng kể ít nhất giảm thiểu một phần các vấn đề tồn tại, và thêm một lớp bảo vệ cho các ứng dụng mới

II.4.3 QUY TRÌNH KIỂM TRA QUẢN LÝ DANH TÍNH CỦA ỨNG DỤNG WEB.

a) Kiểm tra quy trình đăng ký user

Cách kiểm tra:

Xác minh rằng các yêu cầu nhận dạng cho đăng ký sử dụng phải phù hợp với yêu cầu kinh doanh và bảo mật:

• Bất cứ ai có thể đăng ký để truy cập?

• Đăng kí bởi con người hay robot tự động?

• Cùng một người hoặc danh tính có thể đăng ký nhiều lần?

• Người dùng có thể đăng ký cho vai trò hoặc quyền hạn khác nhau?

• Có gì chứng minh danh tính là cần thiết cho một đăng ký để có thể thành công?

• Được đăng ký bản sắc xác minh?

Xác nhận quá trình đăng ký:

• Có thể nhận dạng thông tin được dễ dàng giả mạo hoặc làm giả?

• Việc trao đổi thông tin nhận dạng có thể được thao tác trong quá trình đăng ký?

Một proxy HTTP có thể là một công cụ hữu ích để kiểm tra quy trình đăng ký user

b) Kiểm tra liệt kê tài khoản và đoán tài khoản user

Phạm vi của thử nghiệm này là để xác minh có thể thu thập một tập hợp các tên người dùng hợp lệ bằng cách tương tác với các cơ chế xác thực của ứng dụng

Một vài ứng dụng cho phép bạn đoán, hay lấy được usernames từ các ứng dụng web của bạn Nếu một kẻ tấn công có thể tổng hợp được danh sách của usernames, anh ta có thể sử dụng tấn công brute-force để tìm kiếm mật khẩu Việc dễ dàng bị phát hiện ra usernames cũng là một vấn đề Ví dụ, một forums tại trang web msn.com mà có thể sử dụng một phần mềm lấy được toàn bộ các username của nó Có nghĩa khi đó người dùng sẽ phải gánh chịu những bức thư quảng cáo, các bức thư chứa virus Với số user được quản lý lên tới hàng triệu, việc khai thác được số user này cũng là mục tiêu của các kẻ tấn công

Cách kiểm tra :

• Xác định cấu trúc của tên tài khoản

• Đánh giá sự đáp ứng của ứng dụng với tên tài khoản hợp lệ và không hợp lệ

• Sử dụng phản ứng khác nhau đối với tên tài khoản hợp lệ và không hợp

lệ để liệt kê tên tài khoản hợp lệ

• Sử dụng từ điển tên tài khoản để liệt kê danh sách tài khoản hợp lệ

Ví dụ :Sử dụng HTTP Response message

• Kiểm tra với tài khoản đúng/mật khẩu đúng

• Kiểm tra với tài khoản đúng/mật khẩu sai

• Kiểm tra với tài khoản không tồn tại

Ghi lại các thông báo từ ứng dụng

Sử dụng Burp Suite ,Lấy các thông tin (HTTP 200 Response, chiều dài của phản ứng)

II.4.4 QUY TRÌNH KIỂM TRA CÁC VẤN ĐỀ XÁC THỰC CỦA ỨNG DỤNG WEB.

a) Kiểm tra trường hợp bỏ qua xác thực

Trong khi hầu hết các ứng dụng yêu cầu xác thực để đạt được quyền truy cập vào thông tin cá nhân hoặc để thực hiện các nhiệm vụ, không phải mọi phương pháp xác thực là có thể cung cấp bảo mật đầy đủ Sơ suất, thiếu hiểu biết, hoặc cách nói đơn giản của các mối đe dọa an ninh thường dẫn đến việc xác thực có thể được bỏ qua

Một số phương pháp đơn giản bỏ qua xác thực :

• Thay đổi tham số

• Dự đoán Session ID

• Trực tiếp yêu cầu một trang được bảo vệ thông qua address bar trong trình duyệt

• Sql injection

b) Kiểm tra lỗ hổng ghi nhớ mật khẩu

Trình duyệt đôi khi sẽ yêu cầu người dùng rằng họ có thể ghi nhớ mật khẩu nếu muốn Sau đó trình duyệt sẽ lưu mật khẩu ,và tự động nhập nó vào bất cứ khi nào các hình thức xác thực giống nhau được truy cập

Đây không chỉ là một tiện nghi cho người sử dụng mà còn cho kẻ tấn công Nếu kẻ tấn công có thể được truy cập vào trình duyệt của nạn nhân (ví dụ như thông qua một cuộc tấn công Cross Site Scripting, hoặc thông qua một máy tính dùng chung), thì họ có thể lấy được mật khẩu lưu trữ

Cách kiểm tra :

• Tìm mật khẩu được lưu trữ trong một cookie Kiểm tra các tập tin cookie được lưu trữ bởi các ứng dụng Xác minh rằng các thông tin không được lưu trữ rõ ràng trong văn bản, có sử dụng hàm băm

• Kiểm tra các cơ chế băm

• Xác minh rằng các chứng chỉ được gửi trong giai đoạn login, và không được gửi kèm với mỗi yêu cầu đến ứng dụng

• Hãy xem xét các trường hợp nhạy cảm khác (ví dụ như một câu trả lời cho một câu hỏi bí mật mà phải được nhập vào một khôi phục mật khẩu hoặc tài khoản mở khóa theo mẫu).

• Kiểm tra thuộc tính autocomplete : autocomplete là chức năng của trình

duyệt cho phép ghi nhớ các ký tự hay password vào biểu mẫu (form) trên trang web và tự động điền lại vào những lần sau Thuộc tính này có hai giá trị “on”

và “off” tương đương có cho phép sử dụng autocomplete không.Nếu form password không có giá trị hay giá trị là “on” thì password có thể lưu trữ trong trình duyệt và truy xuất Kiểm tra thuộc tính này trong mã nguồn html trang đăng nhập cho form password

c) Kiểm tra cơ chế khóa tài khoản

Cơ chế khóa tài khoản được sử dụng để giảm thiểu các cuộc tấn công brute force mật khẩu Tài khoản thường được khóa sau 3-5 lần đăng nhập không thành công và chỉ có thể được mở khóa sau một thời gian nhất định , thông qua một cơ chế mở khóa tự phục vụ, hoặc can thiệp của quản trị viên Cơ chế khóa tài khoản đòi hỏi một sự cân bằng giữa bảo vệ tài khoản khỏi những truy cập trái phép và bảo vệ người dùng khỏi bị từ chối truy cập được ủy quyền

Để đánh giá năng lực của cơ chế khóa tài khoản để giảm thiểu tấn công brute force mật khẩu, cố gắng login không hợp lệ bằng cách sử dụng mật khẩu không chính xác một số lần, trước khi sử dụng mật khẩu đúng để xác minh rằng tài khoản đã bị khóa ra Một ví dụ có thể kiểm tra như sau:

• Cố gắng để đăng nhập với một mật khẩu sai 3 lần

• Thành công đăng nhập với mật khẩu chính xác, qua đó cho thấy rằng cơ chế khóa không kích hoạt sau khi 3 lần chứng nhận không chính xác

• Cố gắng đăng nhập bằng mật khẩu không chính xác 4 lần

• Thành công đăng nhập với mật khẩu chính xác, qua đó cho thấy rằng cơ chế khóa không kích hoạt sau khi 4 lần chứng nhận không chính xác

• Cố gắng để đăng nhập với một mật khẩu sai 5 lần

• Cố gắng để đăng nhập với mật khẩu chính xác Các ứng dụng trả về

"Tài khoản của bạn đã bị khóa.", Qua đó xác nhận rằng tài khoản bị khóa ra sau 5 lần xác thực không đúng

• Cố gắng đăng nhập bằng mật khẩu đúng 5 phút sau đó Các báo ứng dụng "Tài khoản của bạn đã bị khóa.", Qua đó cho thấy rằng cơ chế khóa không tự động mở khóa sau 5 phút

• Cố gắng đăng nhập bằng mật khẩu đúng 10 phút sau đó Các báo ứng dụng "Tài khoản của bạn đã bị khóa.", Qua đó cho thấy rằng cơ chế khóa không tự động mở khóa sau 10 phút

• Thành công đăng nhập với mật khẩu chính xác 15 phút sau đó, qua đó cho thấy rằng cơ chế khóa tự động mở khóa sau một khoảng thời gian 10-15 phút.

d) Kiểm tra việc quản lý bộ nhớ cache của trình duyệt

Kiểm tra rằng trình duyệt không nhớ dữ liệu nhạy cảm của ứng dụng web

Trình duyệt có thể lưu trữ thông tin cho các mục đích của bộ nhớ đệm và lịch

sử, có thể phục hồi được thông qua kiểm tra bộ nhớ cache của trình duyệt hoặc bằng cách đơn giản nhấn nút "Back" của trình duyệt

Các thử nghiệm đầu tiên và đơn giản nhất bao gồm nhập thông tin nhạy cảm vào ứng dụng và đăng xuất Sau đó, các thử nhấp chuột vào nút "Back" của trình duyệt để kiểm tra xem trước hiển thị thông tin nhạy cảm có thể được truy cập trong khi thẩm định

Ở đây để kiểm tra xem các ứng dụng có bị rò rỉ bất kỳ dữ liệu nhạy cảm vào

bộ nhớ cache của trình duyệt họ có thể sử dụng một proxy (như WebScarab)

và tìm kiếm thông qua các phản ứng server response thuộc về phiên, kiểm tra rằng đối với mỗi trang có chứa thông tin nhạy cảm của máy chủ chỉ thị cho các trình duyệt không nhớ bất kỳ dữ liệu Một chỉ thị như vậy có thể được ban hành trong các HTTP response headers

• Cache-Control: no-cache, no-store

• Expires: 0

• Pragma: no-cache

II.4.5 QUY TRÌNH KIỂM TRA CÁC VẤN ĐỀ PHÂN QUYỀN CỦA ỨNG DỤNG WEB.

a) Kiểm tra Directory traversal

Kiểm soát hợp lí truy cập nội dung trang web là yếu tố quyết định trong việc điều hành một máy chủ bảo mật Directory traversal là một khai thác HTTP cho phép tin tặc truy cập đến những chỉ mục bị giới hạn, thực thi lệnh bên ngoài chỉ mục gốc của máy chủ web

Máy chủ web cung cấp hai mức cơ chế bảo mật chính:

• Access Control List được sử dụng trong quá trình xác thực Đây là

danh sách quản trị viên máy chủ sử dụng để xác định người dùng hay nhóm

nào đó có thể truy cập, thay đổi hoặc thực thi những file cụ thể trên máy chủ cũng như những quyền truy cập khác.

• Root Directory là chỉ mục đặc biệt trên file hệ thống máy chủ mà

người dùng bị hạn chế trong đó Người dùng không thể truy cập bất cứ thứ gì trong chỉ mục này Ví dụ chỉ mục gốc mặc định của IIS trên Windows làC:\Inetpub\wwwroot và với cài đặt này, người dùng không thể truy cập vào C:\Windows nhưng có thể truy cập vào C:\Inetpub\wwwroot\news, bất kì chỉ mục nào khác và file nằm dưới chỉ mục gốc (giả thiết rằng người dùng hợp

lệ trong ACL)

• Chỉ mục gốc ngăn người dùng truy cập những file nhạy cảm trên máy

chủ như cmd.exe trên Windows haypasswd trên Linux/UNIX Để thực hiện

một cuộc tấn công Directory Traversal, tất cả những gì tin tặc cần là một trình duyệt web và một số kiến thức tìm ra nơi chứa file và chỉ mục trên hệ thống

Những gì tin tặc có thể làm nếu website của bạn có lỗ hổng

Với một hệ thống tồn tại lỗ hổng directory traversal, tin tặc có thể lợi dụng nó

để tìm ra chỉ mục gốc và truy cập một phần của file hệ thống Điều này cho phép tin tặc xem những file bị giới hạn hay nguy hiểm hơn là tin tặc có thể thực thi những lệnh mạnh trên máy chủ, dẫn đến xâm hại hoàn toàn hệ thống Tin tặc sẽ thực thi những lệnh giả mạo thành thành viên của trang web Do đó kiểu tấn công hoàn toàn phụ thuộc vào cách thiết đặt người dùng trang web được phép truy cập những gì trong hệ thống

Ví dụ về tấn công Directory Traversal thông qua Code ứng dụng web :

Trong ứng dụng web với những trang động, đầu vào luôn nhận từ trình duyệt thông qua phương thức request GET và POST Đây là ví dụ về HTTP GET request URL

GET http://test.webarticles.com/show.asp?view=oldarchive.html HTTP/1.1Host: test.webarticles.com

Với URL này, trình duyệt yêu cầu một trang động show.asp từ máy chủ và kèm theo một thông số view với giá trị từ oldarchive.htm từ file hệ thống của máy chủ, sau đó gửi quay trở lại trình duyệt hiển thị với người dùng Tin tặc cho rằng show.asp có thể dẫn được đến file từ file hệ thống và gửi một URL sau:

view= / / / / /Windows/system.ini HTTP/1.1

Host: test.webarticles.com

Lệnh trên khiến trang web động nhận file system.ini từ hệ thống và hiển thị nó đến người dùng Dấu / định hướng hệ thống tiến lên một chỉ mục Tin tặc có thể đoán cần vượt qua bao nhiêu chỉ mục để tìm được thư mục Windows trên

hệ thống thông qua nhiều lần thử và thông báo lỗi

Khi tiếp cận với một ứng dụng Web, việc kiểm tra nó có khả năng bị lỗi Path traversal có thể được thực hiện bằng hai loại:

• Nếu kẻ tấn công không thể có source thì chúng sẽ dùng spider, crawler để thực hiện kiểm tra Website và từ những kết quả mà spider mang lại chúng sẽ lần lượt kiểm tra các biến đối với các phương thức GET, POST hoặc COOKIE mà có khả năng bị lỗi

• Nếu kẻ tấn công có source code thì có thể tìm kiếm những hàm của những ngôn ngữ lập trình Web mà có khả năng gây ra lỗi Path Traversal PHP: include(), include_once(), require(), require_once(), fopen(), readfile(), JSP/Servlet: java.io.File(), java.io.FileReader(), ASP: include file, include virtual,

b) Kiểm tra vượt qua lược đồ ủy quyền

Đối với mỗi vai trò cụ thể các tester nắm giữ trong việc đánh giá, cho tất cả các chức năng và yêu cầu rằng việc áp dụng thực hiện trong giai đoạn hậu xác thực, nó là cần thiết để xác minh:

• Có thể truy cập vào tài nguyên mà ngay cả khi người dùng không xác thực?

• Có thể truy cập vào tài nguyên sau khi log-out?

• Có thể truy cập các chức năng và các nguồn với một người sử dụng giữ một vai trò hoặc đặc quyền khác nhau?

Sử dụng một proxy (WebScarab) sửa đổi các tham số (userID, groupID,…) để

có thể truy cập vào các chức năng không được phép

Directory Listing không quá nguy hiểm, nhưng sẽ gây hậu quả khó lường khi thư mục bị lộ có chứa các file bí mật mà quản trị không muốn người dùng bình thường nhìn thấy, chẳng hạn các file log, file cấu hình hoặc các file chứa những thông tin nhạy cảm

II.4.6 QUY TRÌNH KIỂM TRA CÁC VẤN ĐỀ QUẢN LÝ PHIÊN CỦA ỨNG DỤNG WEB.

a) Kiểm thử Session Fixation

Session Fixation là một kỹ thuật cho phép hacker có thể chiếm đoạt session của người dùng Kỹ thuật này lợi dụng việc server không thay đổi giá trị của session ID mỗi khi người dùng đăng nhập, thay vào đó nó sử dụng session ID sẵn có trước đó Quá trình tấn công bao gồm việc lấy một session ID hợp lệ (có thể bằng cách truy cập vào website), sau đó tìm cách để nạn nhân đăng nhập vào website với session ID này, cuối cùng, khi nạn nhân đăng nhập thành công, hacker sẽ duyệt website với tài khoản của anh ta

Các cách sau để hacker set cookie cho victim :

• Gửi kèm theo một đoạn script để set cookie

• Gửi gói tin HTTP Response kèm theo giá trị cookie của hacker

• Sử dụng thẻ meta của HTML: <meta http-equiv=Set-Cookie content

Hacker sử dụng phương pháp CSRF để lừa trình duyệt của người dùng gửi đi các câu lệnh http đến các ứng dụng web Trong trường hợp phiên làm việc của người dùng chưa hết hiệu lực thì các câu lệnh trên sẽ dc thực hiện với quyền chứng thực của người sử dụng

eBank vừa công bố lãi xuất mới….<img height=0″ width=”0″

sử Alie vừa mới truy cập vào tài khoản ngân hàng của mình và chưa thực hiện logout để kết thúc Trình duyệt của Alie sẽ gửi câu lệnh HTTP GET đến địa chỉ lưu trong thẻ “<img” trong đoạn mã trên và nó sẽ dc thực hiện bằng quyền chứng thực của Alie

• Cách kiểm tra :

Lỗi này nằm ở chỗ các request sẽ insert,delete và update vào CSDL (VD: Xóa bài viết)

Cần Kiểm tra kĩ các action này xem có lỗi không

Có thể sử dụng một action đó , xây dựng một html có chứa thông tin yêu cầu http của action

Đảm bảo cho người dùng hợp lệ đăng nhập ,và liên kết tới url thử nghiệm

Quan sát kết quả ,tức là kiểm tra xem các máy chủ web thực hiện yêu cầu

c) Kiểm thử các thuộc tính cookie

Tấn công Cookie luôn là một hướng tấn công quan trọng đến người dung Phần này sẽ kiểm tra các thuộc tính của cookie đã được cấu hình đúng hay không

 Domain: Domain không được đặt quá lỏng lẻo nếu không các máy chủ khác có thể nhận được cookie

 Path: Phạm vi các địa chỉ có thể truy xuất cookie phải thiết lập chặt chẽ ví dụ các đường dẫn được chỉ tới thư mục gốc ,nó có thể gây tổn thương tới các ứng dụng kém an toàn hơn trên cùng một server

 Sercure: Khi một cookie được thiết lập với cờ Secure, nó chỉ thị các trình duyệt cookie chỉ có thể được truy cập qua các kênh SSL an toàn Đây là một bảo vệ an ninh quan trọng cho cookie session

 Expiration: Thời gian hết hạn của cookie,hacker có thể lợi dụng cookie tấn công cho đến khi cookie hết hạn

 Thuộc tính HttpOnly chỉ thị cho trình duyệt không để lộ cookie thông qua một kết nối khác ngoài HTTP (hoặc HTTPS), chẳng hạn Javascript, và do

đó khó có thể lấy cookie bằng việc khai thác lỗ hổng Cross-Site Scripting (XSS)

Dùng cookies manager kiềm tra.

II.4.7 QUY TRÌNH KIỂM TRA CÁC VẤN ĐỀ KIỂM SOÁT DỮ LIỆU CỦA ỨNG DỤNG WEB.

a) Kiểm tra lỗ hổng SQL Injection

SQL Injection là dạng kỹ thuật được sử dụng để tận dụng lợi thế của các lỗ hổng đầu vào không xác nhận ,để vượt qua các lệnh SQL ,thông qua một ứng dụng web với một CSDL phụ trợ SQL Injection có thể sử dụng để truy xuất CSDL lấy thông tin hoặc vượt qua xác thực

b) Kiểm tra lỗ hổng XSS(Cross Site Scripting )

Cross-Site Scripting hay còn được gọi tắt là XSS (thay vì gọi tắt là CSS để tránh nhầm lẫn với CSS-Cascading Style Sheet của HTML) là một kĩ thuật tấn công bằng cách chèn vào các website động (ASP, PHP, CGI, JSP ) những thẻ HTML hay những đoạn mã script nguy hiểm có thể gây nguy hại cho những người sử dụng khác Trong đó, những đoạn mã nguy hiểm đựơc chèn vào hầu hết được viết bằng các Client-Site Script như JavaScript, JScript, DHTML và cũng có thể là cả các thẻ HTML

Có 3 loại XSS :

• Stored-XSS : Là lỗi XSS mà đoạn mã chèn thêm vào được lưu trữ trên

server, như trong CSDL dưới dạng các comment trong blog, message trong forum

• Reflected-XSS : Khác với Stored-XSS, Reflected-XSS đoạn mã khai

thác sẽ không được lưu trữ trên server

• DOM Based XSS là kỹ thuật khai thác XSS dựa trên việc thay đổi cấu

trúc DOM của tài liệu, cụ thể là HTML

Bất kì một website nào cho phép người dùng đăng thông tin mà không có sự

Cũng như sql injection việc kiểm tra xss cũng cần một lượng lớn truy vấn ,tester có thể sử dụng một số công cụ tự động kết hợp với thao tác thủ công Kiểm tra hộp đen đối với DOM based XSS thường không thực hiện được vì truy cập vào mã nguồn luôn được dùng

b) Kiểm tra lỗ hổng Command Injection

Khả năng thực thi được những câu lệnh hệ thống hay những đoạn mã được thêm vào trong những tham số mà không có sự kiểm tra chặt chẽ như tham số của form, cookies, yêu cầu HTTP Header, và những dữ liệu nguy hiểm trong những tập tin được đưa lên trình chủ

Thành công trong kĩ thuật này giúp hacker có thể thực thi được những câu lệnh hệ thống với cùng quyền của trình chủ

Lợi dụng lỗ hổng không kiểm soát giá trị các đối số khi thực thi kịch bản (servlet) trên web server

Không phân biệt các ký hiệu điều khiển (ký hiệu phép toán, dấu ; “ ‘ ) trong giá trị của đối số và trong câu lệnh

Bảng II.4.7.b.1 Ví dụ Command injection

• Nội dung biểu thức được truyền qua đối số exp Ví dụ: