Xây dựng các ca kiểm thử an toàn thông tin cho ứng dụng web

6 Explorer, Netscap Navigator, Firefox… Trình chủ thường được dùng như Apache, IIS… Hệ quản trị cơ sở dữ liệu phổ biến như SQL Server, MySQL, DB2, Access … Một giải pháp dùng để bảo vệ m

AN TOÀN THÔNG TIN CHO ỨNG DỤNG WEB

LUẬN VĂN THẠC SỸ CÔNG NGHỆ THÔNG TIN

Hà Nội - 2014

AN TOÀN THÔNG TIN CHO ỨNG DỤNG WEB

Ngành: Công nghệ thông tin

i

LỜI CẢM ƠN

Trước hết, tôi xin gửi lời cảm ơn đặc biệt đến TS Đặng Đức Hạnh, Bộ môn Công nghệ phần mềm, Khoa Công nghệ Thông tin, Trường Đại học Công nghệ, Đại học Quốc Gia Hà Nội, người đã định hướng đề tài, cung cấp tài liệu và tận tình hướng dẫn chỉ bảo tôi trong suốt quá trình thực hiện luận văn cao học này

Tôi xin được gửi lời cảm ơn sâu sắc tới các thầy cô giáo trong khoa Công nghệ Thông tin, Trường Đại học Công nghệ, Đại học Quốc Gia Hà Nội đã tận tình giảng dạy và truyền đạt những kiến thức, những kinh nghiệm quý báu cũng như những tình cảm tốt đẹp cho tôi trong suốt thời gian tôi học Cao học

Cuối cùng, tôi xin dành tình cảm biết ơn chân thành đến gia đình, bạn bè và đồng nghiệp, những người đã luôn ở bên cạnh tôi, động viên, chia sẻ cùng tôi trong suốt thời gian học Cao học cũng như quá trình thực hiện luận văn Cao học

Hà Nội, tháng 05 năm 2014

Nguyễn Thị Thu Hiền

ii

LỜI CAM ĐOAN

Tôi xin cam đoan: bản luận văn “Xây dựng các ca kiểm thử an toàn thông tin cho ứng dụng web” là do chính tôi viết dưới sự hướng dẫn khoa học của TS Đặng Đức Hạnh Nội dung của luận văn có tham khảo nhưng không sao chép từ bất kỳ tài liệu nào đã được công bố

Hà Nội, tháng 05 năm 2014

Học viên Nguyễn Thị Thu Hiền

iii

MỤC LỤC

LỜI CẢM ƠN i

LỜI CAM ĐOAN ii

MỤC LỤC iii

DANH MỤC KÝ HIỆU, TỪ VIẾT TẮT vi

DANH MỤC BẢNG vii

DANH MỤC HÌNH VẼ viii

MỞ ĐẦU 1

CHƯƠNG 1 KHÁI NIỆM CƠ BẢN 2

1.1 Các khái niệm cơ bản trong kiểm thử phần mềm 2

1.1.1 Khái niệm về kiểm thử phần mềm 2

1.1.2 Các phương pháp kiểm thử 2

1.1.3 Các chiến lược kiểm thử 3

1.2 Kiểm thử an toàn thông tin cho ứng dụng web 4

1.2.1 Khái niệm ứng dụng web 4

1.2.2 Hoạt động của một ứng dụng Web 6

1.2.3 Kiểm thử ATTT cho ứng dụng web 7

1.2.4 Quy trình kiểm thử an toàn thông tin 7

CHƯƠNG 2 THIẾT KẾ CA KIỂM THỬ ATTT CHO ỨNG DỤNG WEB 8

2.1 Phương pháp thiết kế ca kiểm thử ATTT 9

2.2 Tổng hợp nguy cơ về ATTT cho ứng dụng web 10

R1 Tương tác với cơ sở dữ liệu tránh lỗ hổng SQL Injection 10

R2 Xử lý dữ liệu đầu vào tránh lỗ hổng XSS 10

iv

R3 Sử dụng Token trong phương thức GET và POST tránh lỗ hổng CSRF 11

R4 Kiểm tra quyền truy cập của người dùng 12

R5 Session Hijacking 12

R6 Session fixation 12

R7 Kiểm soát các thao tác với file 13

R8 Mã hóa dữ liệu nhạy cảm 14

R9 User enumeration 15

R10 HTTP Only cookie 15

R11 Chuyển hướng và chuyển tiếp thiếu thẩm tra 15

R12 Thất thoát thông tin và xử lý lỗi không đúng cách 16

R13 Sử dụng captcha an toàn 16

R14 Mật khẩu mạnh 16

2.3 Các ca kiểm thử ATTT 17

F1 Ca kiểm thử mức chung 19

F2 Ca kiểm thử cho chức năng Đăng nhập – Đăng xuất 24

F3 Ca kiểm thử cho chức năng Tìm kiếm 28

F4 Ca kiểm thử cho chức năng Thêm mới 35

F5 Ca kiểm thử cho chức năng Sửa 44

F6 Ca kiểm thử cho chức năng Xóa 60

F7 Ca kiểm thử cho chức năng Xem thông tin 66

F8 Ca kiểm thử cho chức năng Download 71

F9 Ca kiểm thử cho chức năng Upload 78

F10 Ca kiểm thử cho chức năng Import 84

F11 Ca kiểm thử cho chức năng Trang có chuyển hướng 93

v

F12 Ca kiểm thử liên quan đến dữ liệu nhạy cảm 94

F13 Ca kiểm thử cho chức năng liên quan đến mật khẩu 96

CHƯƠNG 3 VẬN DỤNG VÀ CÔNG CỤ HỖ TRỢ 98

3.1 Minh họa phương pháp kiểm thử 98

3.2 Công cụ hỗ trợ 100

3.2.1 Quản lý các ca kiểm thử an toàn thông tin 100

3.2.2 Sinh các ca kiểm thử với từng chức năng của hệ thống website 101

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 102

TÀI LIỆU THAM KHẢO 103

vi

DANH MỤC KÝ HIỆU, TỪ VIẾT TẮT

CSRF Cross-site request forgery Lỗ hổng CSRF

URL Uniform Resource Locator Định vị Tài nguyên thống nhất ATTT Information security An toàn thông tin

HTTP HyperText Transfer Protocol Giao thức truyền tải siêu văn bản HTTPS Hypertext Transfer Protocol

Secure

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

an toàn HTML HyperText Markup Language Ngôn ngữ Đánh dấu Siêu văn bản

SQL Structured Query Language ngôn ngữ truy vấn mang tính cấu

trúc HQL Hibernate Query Language Ngôn ngữ truy vấn hướng đối

vii

DANH MỤC BẢNG

Bảng 2.1 Các ký tự đặc biệt có nguy cơ gây lỗ hổng XSS 11

Bảng 2.2 Bảng tổng hợp các nguy cơ mất ATTT tương ứng với từng chức năng của một ứng dụng web 18

Bảng 2.3 Các ca kiểm thử chỉ cần kiểm tra một lần trên toàn bộ hệ thống 19

Bảng 2.4 Các ca kiểm thử với màn hình có chức năng Đăng nhập – Đăng xuất 24

Bảng 2.5 Các ca kiểm thử với màn hình có chức năng Tìm kiếm 28

Bảng 2.6 Các ca kiểm thử với màn hình có chức năng Thêm mới 35

Bảng 2.7 Các ca kiểm thử với màn hình có chức năng Sửa 44

Bảng 2.8 Các ca kiểm thử với màn hình có chức năng Xóa 60

Bảng 2.9 Các ca kiểm thử với màn hình có chức năng Xem thông tin chi tiết 1 bản ghi 66

Bảng 2.10 Các ca kiểm thử với màn hình có chức năng Download 71

Bảng 2.11 Các ca kiểm thử với màn hình có chức năng Upload 78

Bảng 2.12 Các ca kiểm thử với màn hình có chức năng Import 84

Bảng 2.13 Các ca kiểm thử với màn hình có chức năng Chuyển hướng 93

Bảng 2.14 Các ca kiểm thử với chức năng có dữ liệu nhạy cảm 94

Bảng 2.15 Các ca kiểm thử với màn hình có chức năng liên quan đến mật khẩu 96

viii

DANH MỤC HÌNH VẼ

Hình 1.1 : Kiến trúc ứng dụng Web và Database 5

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

Hình 1.3 Quy trình kiểm thử ATTT 8

Hình 3.1 Chức năng quản lý sự kiện 98

Hình 3.2 Chức năng quản lý các ca kiểm thử ATTT trên ứng dụng web 100

Hình 3.3 Chức năng sinh tập các ca kiểm thử cho từng chức năng trên ứng dụng web 101

1

MỞ ĐẦU

Trong thời đại bùng nổ công nghệ thông tin hiện nay, phần mềm đã đi vào mọi ngõ ngách của cuộc sống và đã có những ảnh hưởng to lớn đến đời sống của con người Bởi vậy mà hơn bao giờ hết, việc kiểm thử và đảm bảo chất lượng phần mềm càng trở lên quan trọng Giờ đây, việc kiểm thử phần mềm cũng không chỉ đơn thuần

là kiểm thử cho các chức năng hoạt động tốt, mà còn phải đảm bảo bảo mật phần mềm Bởi những nỗ hổng về bảo mật là những nguy cơ rất nguy hiểm có thể dẫn đến những hậu quả nghiêm trọng

Các loại tội phạm công nghệ cao, an ninh mạng là những vấn đề thuộc an ninh phi truyền thống đang ngày càng phổ biến và tác động, ảnh hưởng đến an ninh quốc gia Theo tờ USA Today, năm 2012, tội phạm công nghệ cao gây thiệt hại cho nước

Mỹ khoảng 67,2 tỷ USD, trên toàn cầu khoảng 400 tỷ USD, chỉ đứng sau tội phạm ma túy (460 tỷ USD) [1]

Thực trạng an toàn thông tin tại Việt Nam đang tiềm ẩn nhiều nguy cơ An ninh mạng vẫn chưa thực sự được quan tâm tại các cơ quan, doanh nghiệp Theo nhận định của các chuyên gia Công ty Bkav [2], hầu hết cơ quan doanh nghiệp của Việt Nam chưa bố trí được nhân sự phụ trách an ninh mạng hoặc năng lực và nhận thức của đội ngũ này chưa tương xứng với tình hình thực tế Vấn đề an ninh mang đang trở lên hiện hữu, ảnh hưởng sâu rộng, tác động đến các vấn đề chính trị, kinh tế và an ninh quốc gia Việc đảm bảo bảo mật phần mềm đã trở thành yêu cầu cấp thiết và bắt buộc đối với bất kỳ phần mềm nào Vì vậy, việc kiểm thử bảo mật cũng trở thành 1 yêu cầu bắt buộc trong quy trình kiểm thử phần mềm của rất nhiều công ty Xuất phát từ nhu cầu thực tế này, chúng tôi đã nghiên cứu và tìm hiểu về an toàn thông tin đối với các ứng dụng web và các phương pháp kiểm thử để tìm ra các nỗ hổng về bảo mật của ứng dụng web Sau một quá trình nghiên cứu dưới sự hướng dẫn của TS Đặng Đức Hạnh, tôi đã hoàn thành luận văn “XÂY DỰNG CÁC CA KIỂM THỬ AN TOÀN THÔNG TIN CHO ỨNG DỤNG WEB” Luận văn được cấu trúc thành 3 chương như sau:

- Chương 1: Khái niệm cơ bản

- Chương 2: Thiết kế các ca kiểm thử ATTT cho ứng dụng web

- Chương 3: Vận dụng và công cụ hỗ trợ

2

CHƯƠNG 1 KHÁI NIỆM CƠ BẢN

Trong Chương 1 chúng tôi trình bày về những khái niệm cơ bản trong kiểm thử phần mềm và kiểm thử an toàn thông tin

1.1 Các khái niệm cơ bản trong kiểm thử phần mềm

Chúng tôi xin tóm lược lại những khái niệm cơ bản về kiểm thử phần mềm, các phương pháp và chiến lược kiểm thử

1.1.1 Khái niệm về kiểm thử phần mềm

Kiểm thử phần mềm [5] là quá trình khảo sát một hệ thống hay thành phần

dưới những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh nào đó của hệ thống hay thành phần đó

Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần

mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều điều kiện khác nhau

Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm [6] là một

tiến trình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã máy tính thực hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gì không mong muốn Đây là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa

1.1.2 Các phương pháp kiểm thử

Trong thực tế, có 2 phương pháp kiểm thử phần mềm [6] thường được sử dụng

là phương pháp kiểm thử tĩnh (static testing) và kiểm thử động (dynamic testing)

Kiểm thử tĩnh (static testing): Là phương pháp kiểm thử phần mềm đòi hỏi

phải duyệt lại các yêu cầu và các đặc tả bằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà không cần chạy chương trình Phương pháp này chủ yếu dùng để kiểm tra tính đúng đắn của mã lệnh, thuật toán và các tài liệu đặc tả Ngoài ra, phương pháp này có thể dùng để xem xét các yêu cầu và thông số kỹ thuật Kiểm thử tĩnh cũng có thể được thực hiện một cách tự động Trong các môi trường lập trình, thường có sẵn một trình thông dịch hay biên dịch kiểm tra tính đúng đắn của cú pháp chương trình, đó cũng là một cách kiểm thử tĩnh nhưng được thực hiện tự động

3

Kiểm thử động (dynamic testing): Là phương pháp kiểm thử thông qua việc

dùng máy chạy chương trình để điều tra trạng thái tác động của chương trình Đó là kiểm thử dựa trên các ca kiểm thử xác định bằng sự thực hiện của đối tượng kiểm thử hay chạy chương trình Kiểm thử động là kiểm tra cách thức hoạt động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy Kiểm thử động bao gồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra

có như mong muốn hay không

1.1.3 Các chiến lược kiểm thử

Trong chiến lược kiểm thử, chúng ta có ba chiến lược kiểm thử [6] hay dùng

nhất là: kiểm thử hộp đen, kiểm thử hộp trắng, và kiểm thử hộp xám Chi tiết các phương pháp này như mô tả phần dưới

1.1.3.1 Kiểm thử hộp đen – Black box

Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng

dữ liệu, hay hướng vào ra Kiểm thử hộp đen xem chương trình như là một “hộp đen” Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử và cấu trúc bên trong của chương trình Thay vào đó, tập trung vào tìm các trường hợp mà chương trình không thực hiện theo các đặc tả của nó Ở mức kiểm thử này, kiểm thử viên chỉ xem xét dữ liệu đầu vào và giá trị đầu ra có giống với mong muốn không, mà không cần phải quan tâm hệ thống làm thế nào để đưa được giá trị đầu ra như mong muốn Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để ngăn chặn những rủi ro chắc chắn

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh và kiểm thử viên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi Sử dụng nguyên tắc “Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên không tìm ra Nhưng, người ta nói kiểm thử hộp đen “giống như là đi trong bóng tối

mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào Đó là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất Trong khi đó, một số phần của chương trình lại không được kiểm tra chút nào Do vậy, kiểm thử hộp đen có ưu điểm

là đánh giá khách quan, nhưng lại có nhược điểm là một kiểu thăm dò mù

1.1.3.2 Kiểm thử hộp trắng – White box

Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bên trong của chương trình Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính

4

logic của chương trình Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng) Phương pháp kiểm thử hộp trắng cũng có thể được kết hợp với phương pháp kiểm thử hộp đen để tạo ra bộ các ca kiểm thử đầy đủ nhằm giảm thiểu rủi ro

1.1.3.3 Kiểm thử hộp xám – Gray box testing

Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức người sử dụng hay mức hộp đen Việc thao tác tới dữ liệu đầu vào và định dạng dữ

liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầu ra

rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp – Intergartion testing

giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là được đưa ra để kiểm thử Kiểm thử hộp xám có thể cũng bao gồm cả thiết

kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi

1.2 Kiểm thử an toàn thông tin cho ứng dụng web

Bên cạnh kiểm thử chức năng cho phần mềm, việc kiểm thử an toàn thông tin cho mỗi ứng dụng cũng là một vấn đề rất quan trọng Đặc biệt là với các ứng dụng web, loại ứng dụng có đối tượng người dùng rất đa dạng và phức tạp Ứng dụng web hiện cũng là mục tiêu tấn công của nhiều hacker Bởi vậy, việc đảm bảo an toàn thông tin cho các ứng dụng web là một yêu cầu cấp thiết Để nghiên cứu kỹ hơn về vấn đề này, chúng ta sẽ đi tìm hiểu từng khái niệm để hiểu rõ hơn thế nào là kiểm thử an toàn thông tin cho ứng dụng web

1.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 Firefox 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

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

5

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

Hình 1.1 : Kiến trúc ứng dụng Web và Database

- Lớp trình bày: Lớp này có nhiệm vụ hiển thị dữ liệu cho người dùng, 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 gồm trình khách, trình chủ, hệ quản trị cơ sở dữ liệu:

Hình 1.2 : Mô hình hoạt động của một ứng dụng Web Trình khách (hay còn gọi là trình duyệt) thường được sử dụng là Internet

6

Explorer, Netscap Navigator, Firefox… Trình chủ thường được dùng như Apache, IIS… Hệ quản trị cơ sở dữ liệu phổ biến như SQL Server, MySQL, DB2, Access … 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 (firewall), 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

Trong kỹ thuật phần mềm, một Ứng dụng web [7] là một trình ứng dụng mà có

thể tiếp cận qua web thông qua mạng như Internet hay intranet Ứng dụng web phổ biến nhờ vào sự có mặt vào bất cứ nơi đâu của một chương trình Khả năng cập nhật

và bảo trì ứng dụng Web mà không phải phân phối và cài đặt phần mềm trên hàng ngàn máy tính là lý do chính cho sự phổ biến của nó Ứng dụng web được dùng để hiện thực webmail, bán hàng trực tuyến, đấu giá trực tuyến, wiki, diễn đàn thảo luận, weblog, MMORPG, hệ quản trị nội dung, phần mềm quản lý nguồn nhân lực và nhiều chức năng khác

Các ứng dụng web có thể được viết bởi 1 ngôn ngữ bất kỳ, chạy trên rất nhiều loại hệ điều hành, nhiều loại trình duyệt khác nhau, và người dùng cuối có thể hành xử theo mọi cách mà bạn có thể tưởng tượng Cốt lõi của một ứng dụng web là sử dụng các giao thức HTTP để truyền dữ liệu Dữ liệu từ server gửi về client thường định dạng HTML và javascript Dữ liệu đầu vào thường sử dụng phương thức GET, POST

và các phương thức tương tự

1.2.2 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

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

1.2.3 Kiểm thử ATTT cho ứng dụng web

Kiểm thử bảo mật web [3] là kiểm tra sự đảm bảo an toàn dữ liệu và bảo vệ tài

nguyên của hệ thống trước sự tấn công nhằm phá vỡ hệ thống hoặc sử dụng trái phép các tài nguyên của một số đối tượng có mục đích xấu Để làm được điều này cần có kiến thức về công nghệ bảo mật, kinh nghiệm thực tế về cách thức thâm nhập các phần không được phép trên hệ thống website

Việc thiết lập bảo mật cho một hệ thống website phụ thuộc vào nhiều yếu tố: bảo mật về thiết kế, bảo mật về xây dựng mã nguồn, bảo mật về các thiết lập của trình duyệt, bảo mật tường lửa

Tuy nhiên, trong khuôn khổ luận văn này, chúng tôi chỉ để cập đến vấn đề bảo mật khi xây dựng mã nguồn Phương pháp kiểm tra độ bảo mật của ứng dụng thông qua mã nguồn chủ yếu dùng để xác định sự an toàn của thuật toán được dùng trong ứng dụng Dựa trên các đặc trưng của ứng dụng web, việc kiểm thử có thể xác định nguy cơ rò rỉ thông tin hoặc bị tấn công chiếm quyền kiểm soát hệ thống Phương pháp này thường ứng dụng kỹ thuật kiểm thử hộp trắng

1.2.4 Quy trình kiểm thử an toàn thông tin

Quy trình kiểm thử chức năng có đầu vào là tài liệu mô tả yêu cầu hệ thống và tài liệu thiết kế hệ thống Cũng tương tự như vậy, nhưng quy trình kiểm thử an toàn thông tin còn cần thêm tài liệu phân tích các nguy cơ mất an toàn thông tin đối với hệ thống Từ đó, đưa ra các ca kiểm thử trên hệ thống và thực hiện kiểm thử để tìm ra lỗi

8

Quy trình kiểm thử an toàn thông tin đƣợc mô tả nhƣ hình 1.3 [3]:

Hình 1.3 Quy trình kiểm thử ATTT

Bắt đầu

Kết thúc

Phân tích các nguy cơ mất ATTT đối với hệ thống

Xây dựng các ca kiểm thử ATTT

Thực hiện kiểm thử ATTT

Nếu có lỗi Sai

Đúng Tài liệu giải pháp

9

CHƯƠNG 2 THIẾT KẾ CA KIỂM THỬ ATTT

CHO ỨNG DỤNG WEB

Các ứng dụng web đứng trước rất nhiều nguy cơ về việc mất an toàn thông tin

Để giảm thiểu những nguy cơ này, quy trình sản xuất phần mềm cần tuân thủ những nguyên tắc về lập trình an toàn Cũng giống như việc đảm bảo các chức năng hoạt động đúng, các quy trình phát triển phần mềm đều phải qua 2 bước: lập trình và kiểm thử Việc đảm bảo các chức năng không bị lỗ hổng về an toàn thông tin cũng cần trải qua 2 bước như vậy Để đảm bảo thực hiện được điều này, chúng ta sẽ cùng tìm hiểu cách thức kiểm tra mức độ ATTT của một hệ thống web

2.1 Phương pháp thiết kế ca kiểm thử ATTT

Để thiết kế các ca kiểm thử ATTT cho các ứng dụng Web, chúng tôi thực hiện theo các bước sau

Bước 1: Chương này xác định các nguy cơ về lỗi ATTT Dựa trên công bố của thế giới

về các lỗ hổng bảo mâ ̣t của mô ̣t ứng du ̣ng web , chương 2 tâ ̣p hợp những mô tả cu ̣ thể về từng lỗ hổng bảo mâ ̣t , phân tích từng lỗ hổng có thể dẫn đến những nguy về mất ATTT của hê ̣ thống

Mô ̣t ví du ̣ điển hình là l ỗi "SQL Injection" Lỗi này xuất hiê ̣n khi lâ ̣p trình viên sử du ̣ng phương pháp cô ̣ng xâu đối với các dữ liê ̣u đầu vào Những kẻ tấn công có thể

lơ ̣i du ̣ng đă ̣c điểm này để truyền vào những đoa ̣n mã làm sai lê ̣ch mu ̣c đích truy v ấn

Bước 2: Mỗi l ỗ hổng bảo mật này có thể xuất hiện ở nhiều ph ần khác

nhau của một hệ thống Bởi vậy, chúng tôi sẽ phân một ứng dụng web thành các chức năng và phân tích từng chức năng và các nguy cơ về mất ATTT mà ch ức năng đó có khả năng mắc phải

Ví dụ, qua phân tích đă ̣c điểm dữ liê ̣u đầu vào của từng chức năng , chúng tôi nhâ ̣n thấy , lỗi "SQL Injection" có nguy cơ mắc phải tại các chức năng : Đăng nhâ ̣p , Tìm kiếm, Thêm mới, Sửa, Xoá, Xem thông tin, Import

Bước 3: Bước này mô tả chi ti ết cách thiết kế các ca ki ểm thử tương ứng với cặp

"nguy cơ ATTT" và "chức năng"

Ví dụ, với lỗi “SQL injection” và chức năng “Đăng nhâ ̣p” Chức năng Đăng nhâ ̣p bi ̣ lỗi SQL injection khi lâ ̣p trình không tham số hoá dữ liê ̣u truyền vào Tên đăng nhâ ̣p và Mâ ̣t khẩu , mà sử dụng phương pháp cộng xâu Kẻ tấn công có thể lợi dụng

đă ̣c điểm này để truyền vào các xâu dữ liê ̣u nhằm phá vỡ cấu trúc câu SQL kiểm tra

10

tính hợp của Tên đăng nhập và Mật khẩu Cụ thể câu truy vấn kiểm tra tính hợp lê ̣ của

Tên đăng nhâ ̣p và Mâ ̣t khẩu là select * from user where user = „Tên đăng nhập người dùng nhập‟ and pass = „Mật khẩu người dùng nhập‟ Trường hợp người dùng nhâ ̣p Tên đăng nhập = abc‟ or „a‟=‟a có thể dẫn đến việc phá vỡ cấu trúc ban đầu của câu truy vấn Câu truy vấn mới là select * from user where user = „abc‟ or „a‟ =‟a‟ and pass = „Mật khẩu người dùng nhập‟ , lúc này biểu thức điều kiện luôn đúng Bởi vâ ̣y,

dù người dùng không biết Tên đăng nhập và Mật khẩu vào hệ thống vẫn có thể truy

câ ̣p được Dựa vào những phân tích trên , chúng tôi thiết kế ca kiểm thử tương ứng nhằm mu ̣c đích kiểm tra hê ̣ thống có mắc lỗi SQL injection ở chức n ăng đăng nhâ ̣p không Phương pháp được áp du ̣ng để xây dựng lên ca kiểm thư trên là phương pháp kiểm thử hô ̣p trắng

Tính đúng đắn của ca kiểm thử được phân tích và đảm bảo ở bước 3 Trong phạm vi luận văn, chúng tôi không đi sâu chứng minh tính đúng đắn của các ca sử kiểm thử Điểm nhấn mạnh ở đây là phương pháp đề xuất cho viê ̣c thiết kế các ca kiểm thử ATTT cho ứng dụng Web

Trong phần tiếp theo của chương, mục 2.2 sẽ tổng hợp các nguy cơ về lỗi ATTT, mục 2.3 trình bày các ca kiểm thử được xây dựng theo phương pháp này

2.2 Tổng hợp nguy cơ về ATTT cho ứng dụng web

Phần này tổng hợp những vấn đề có thể dẫn đến mất ATTT đối với ứng dụng web Mỗi vấn đề được trình bày gồm 3 phần: mô tả vấn đề, nguy cơ mất ATTT của vấn đề và cách phòng chống

R1 Tương tác với cơ sở dữ liệu tránh lỗ hổng SQL Injection

Mô tả: Dữ liệu đầu vào từ người dùng phải được truyền dưới dạng tham số,

không được sử dụng cách cộng xâu trong các truy vấn tới cơ sở dữ liệu

Nguy cơ: Khi truy vấn tới cơ sở dữ liệu, lập trình viên thường sử dụng cách

cộng xâu dữ liệu đầu vào từ người dùng, các câu truy vấn này có thể bị mắc lỗi SQL Injection hoặc HQL Injection (nếu sử dụng Hibernate) Bằng việc lợi dụng các lỗi này,

kẻ tấn công có thể xem, thêm, sửa, xóa dữ liệu trong database từ đó chiếm được tài khoản admin, lấy cắp thông tin người dùng

Phòng chống: Để phòng chống các nguy cơ này, truy vấn SQL phải dùng

PrepareStatement, tất cả tham số phải được add bằng hàm (setParam), không được xử dụng cách cộng xâu trong truy vấn Với truy vấn HQL, tất cả tham số phải được add bằng hàm (setParam), không được xử dụng cách cộng xâu trong truy vấn [8]

R2 Xử lý dữ liệu đầu vào tránh lỗ hổng XSS

11

Mô tả: Xử lý dữ liệu đầu vào tránh lỗ hổng XSS có nghĩa là mã hóa dưới dạng

HTML các ký tự đặc biệt do người dùng gửi lên máy chủ và các ký tự đặc biệt trong

cơ sở dữ liệu trước khi gửi tới người dùng

Nguy cơ: Kết quả server trả về cho người dùng chủ yếu là dưới dạng HTML

Nội dung trả về thường bao gồm cả những giá trị mà người dùng nhập vào Hệ thống

có thể bị mắc lỗi XSS nếu không kiểm soát dữ liệu đầu vào XSS (Cross-Site Scripting) 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

Phòng chống: Để tránh lỗ hổng XSS thì cần mã hóa dưới dạng HTML các ký

tự đặc biệt do client gửi đến Các ký tự này bao gồm: <,>,&,’,”,/ Việc mã hóa cần thực hiện trong trường hợp: dữ liệu lấy ra từ database khi trả về cho client Bản chất của việc mã hóa là thay thế các kí tự trên bằng chuỗi tương ứng trong bảng 2.1 Cách mã hóa này sẽ ngăn chặn được nguy cơ hệ thống thực thi các đoạn mã nguy hiểm [4]

Bảng 2.1 Các ký tự đặc biệt có nguy cơ gây lỗ hổng XSS

R3 Sử dụng Token trong phương thức GET và POST tránh lỗ hổng CSRF

Mô tả: Trong các tương tác của người dùng với cơ sở dữ liệu thông qua các

form, liên kết, sử dụng thêm biến token (được tạo ra mỗi đầu phiên truy cập của người dùng) như một tham số trong phương thức GET hoặc POST và kiểm tra giá trị token này tại máy chủ để xác nhận hành vi của người dùng

Nguy cơ: CSRF (Cross-site request forgery) là phương pháp mượn quyền của

người dùng khác để thực hiện một hành động không cho phép Ví dụ: Để có thể xóa một bài viết trên diễn đàn một member có thể mượn tay của một admin để làm việc đó

vì member không đủ chủ quyền nhưng admin lại đủ chủ quyền để thực hiện hành động này Kẻ tấn công lừa admin truy cập vào trang web có chứa đoạn mã xóa bài viết trên diễn đàn (Admin đang đăng nhập vào diễn đàn) như vậy admin đã gửi yêu cầu xóa bài viết trên diễn đàn mà không hề biết Một ví dụ nữa, ta có 1 link chuyển tiền vào tài khoản có dạng:

12

http://www.tek.eten.vn/bank/sendfund.php?sender=A&receiver=B&amount=1000000

000 Trong đó sender là người gửi tiền, receiver là người nhận tiền và amount là số tiền chuyển Hiển nhiên là đường link này chỉ được người A thực thi, vì thế nên phải

có một thao tác kiểm tra sender chính là người thực thi đường link Tuy vậy, bằng

một cách nào đó, hacker lừa được A chạy đường link trên (có thể là chèn một iframe tới đường link này, tại bài viết trong một forum và lừa cho A đọc bài viết), thao tác xác thực được vượt qua và hacker có thể chuyển tiền từ A đến bất kỳ tài khoản nào

Phòng chống: Đối với các yêu cầu quan trọng, sử dụng thêm biến token Trên

server sẽ kiểm tra token trong yêu cầu gửi lên từ client, nếu token không hợp lệ thì yêu cầu sẽ không được thực hiện [9]

R4 Kiểm tra quyền truy cập của người dùng

Mô tả: Kiểm soát quyền của người dùng trong mỗi request lên máy chủ

Nguy cơ: Trong các hệ thống có phân quyền, mỗi người dùng chỉ được phép

truy cập các dữ liệu mà mình được phép Tuy nhiên, nếu việc kiểm tra quyền không được kiểm soát tốt thì người dùng có thể truy cập được các dữ liệu không được quyền (leo quyền)

Phòng chống: Kiểm tra quyền trong từng request gửi lên server [10]

R5 Session Hijacking

Mô tả: Để đảm bảo ATTT, hệ thống không cho phép 2 phiên truy cập đồng

thời Thông tin session được xây dựng hướng người dùng Nghĩa là dựa trên các thông tin người dung như: IP, User-Agent hoặc địa chỉ MAC

Nguy cơ: Kỹ thuật tấn công cho phép hacker mạo danh người dùng hợp lệ sau

khi nạn nhân đã đăng nhập vào hệ thống bằng cách giải mã session ID của họ được lưu trữ trong cookie hay tham số URL, biến ẩn của form [11]

Phòng chống: Giới hạn phạm vi ứng dụng của session ID

o Kết hợp Session ID với địa chỉ của trình duyệt

o Kết hợp session ID với thông tin chứng thực được mã hóa SSL của người dùng

o Xóa bỏ session khi người dùng thoát khỏi hệ thống hay hết hiệu lực, có thể thực hiện trên trình chủ hoặc trình duyệt (cookie)

o Người sử dụng phải dùng chế độ thoát khỏi hệ thống để xóa bỏ session hiện thời và có thể những session ID còn lưu lại trên hệ thống khi họ quên thoát ra ngoài những lần trước

o Thiết lập thời gian hết hiệu lực cho session, tránh trường hợp hacker có thể duy trì session và sử dụng nó lâu dài

R6 Session fixation

13

Mô tả: Để đảm bảo ATTT, khi phát triển phần mềm cần tạo session mới sau

khi đăng nhập và xóa session cũ (trên Server) sau khi đăng xuất khỏi hệ thống Tránh trường hợp session của ứng dụng trước và sau khi đăng nhập không thay đổi Hacker

có thể sử dụng lỗ hổng này để đăng nhập mà không cần biết Tài khoản/ Mật khẩu

Nguy cơ: Kỹ thuật tấn công cho phép hacker mạo danh người dùng hợp lệ

bằng cách gửi một sesion ID hợp lệ đến người dùng, sau khi người dùng đăng nhập vào hệ thống thành công, hacker sẽ dùng lại sesion ID đó và nghiễm nhiêm trở thành người dùng hợp lệ [12]

Phòng chống:

- Biện pháp 1: Phần mềm cần tránh đăng nhập với một session ID có sẵn

Theo kiểu tấn công này, người dùng đăng nhập vào hệ thống thông qua một session ID do hacker tạo sẵn thay vì cho trình chủ tạo mới, do đó để

có phòng chống, ứng dụng phải hủy bỏ session ID được cung cấp bởi trình duyệt của người dùng khi đăng nhập và luôn tạo một session ID mới khi người dùng đăng nhập thành công

- Biện pháp 2: Phòng chống những hacker bên ngoài hệ thống Việc tạo

ứng dụng trên hệ thống theo hướng giới hạn (chỉ tạo một session ID mới cho người dùng sau khi họ thành công) sẽ khiến cho những hacker không phải là người dùng hợp lệ của hệ thống không thể sử dụng phương pháp tấn công này [12]

- Biện pháp 3: Giới hạn phạm vi ứng dụng của session ID

o Kết hợp session ID với địa chỉ của trình duyệt

o Kết hợp session ID với thông tin chứng thực được mã hóa SSL của người dùng

o Xóa bỏ session khi người dùng thoát khỏi hệ thống hay hết hiệu lực, có thể thực hiện trên trình chủ hoặc trình duyệt (cookie)

o Người sử dụng phải dùng chế độ thoát khỏi hệ thống để xóa bỏ session hiện thời và có thể những session ID có lưu lại trên hệ thống khi họ quên thoát ra ngoài những lần trước

o Thiết lập thời gian hết hiệu lực cho session, tránh trường hợp hacker có thể duy trì session và sử dụng nó lâu dài

R7 Kiểm soát các thao tác với file

Mỗi ứng dụng web có 2 loại file cần chú ý đến vấn đề bảo mật Thứ nhất, file upload lên hệ thống cần đảm bảo là file an toàn, hợp lệ và upload vào thư mục được phép Thứ hai, với file download, người dùng chỉ download được các file được phép Với mỗi loại file chúng tôi trình bày các vấn đề, nguy cơ và cách phòng chống như dưới dây [10]

File upload:

14

Mô tả: Giới hạn chỉ cho phép các định dạng file theo yêu cầu của ứng dụng

được phép upload lên máy chủ Kiểm soát file upload ở phía máy chủ Lưu trữ các file upload tại một thư mục riêng nằm ngoài thư mục web hoặc không cho phép truy cập, thực thi trên các thư mục đó Chặn các kí tự \, /, null và kiểm tra phần mở rộng của file khi xử lý với tên file trên máy chủ

Nguy cơ: Các thao tác với file thường sử dụng tên file, đường dẫn file được

gửi lên từ client, nếu ứng dụng không kiểm soát tốt các giá trị này (việc kiểm soát phải được thực hiện phía server) có thể dẫn đến việc download hoặc upload các file không hợp lệ

Phòng chống: Để đảm bảo không phát sinh các vấn đề mất an toàn thông tin

với file upload, phía server cần kiểm soát các file upload:

- Kiểm soát phần mở rộng của file, chỉ cho phép thực hiện với các file có định dạng theo yêu cầu

- Kiểm soát các vấn đè liên quan đến đọc ghi file, biến đường dẫn file phải được lọc các ký tự /, \ và kí tự null

File download:

Mô tả: Yêu cầu tất cả dữ liệu, tài nguyên hệ thống (báo cáo, file lưu trữ khi

xuất hệ thống xuất ra hoặc tải lên) không được lưu trong thư mục chia sẻ (share) việc thực hiện tải (download) dữ liệu này phải qua bước xác thực và tham số trong URI request phải được mã hóa Đối với các hệ thống đang triển khai yêu cầu các dữ liệu nhạy cảm này phải được lưu trong thư mục bên ngoài thư mục cài đặt web server

Nguy cơ: Trên hệ thống tồn tại các chức năng cho phép kết xuất dữ liệu truy

vấn, kết quả làm việc ra dưới dạng các file excel Tuy nhiên, chức năng này có các lỗ hổng sau có thể làm lộ dữ liệu của hệ thống:

o File exel được lưu trữ trong thư mục con của thư mục webapp

o File exel sau khi được người dùng tải về không được xóa

o Cho phép truy cập trực tiếp vào các file excel này mà không qua xác thực

o Ví dụ: Những đường link sau sẽ cho phép tải một file excel mà hệ thống đã xuất ra trước đó về mà không cần qua các bước xác thực:

o http://abc.com:8080/ams/share/report_out/exportDMHangHoa20121022090909.xls

Phòng chống: Các dữ liệu này lưu trong thư mục bên ngoài thư mục cài đặt

web server và không được đặt ở thư mục share Việc thực hiện download các dữ liệu này phải qua bước xác thực và tham số phải mã hóa

R8 Mã hóa dữ liệu nhạy cảm

Mô tả: Cần ngăn chặn việc thất thoát thông tin với các dữ liệu nhạy cảm trong

cơ sở dữ liệu hoặc trên đường truyền

15

Nguy cơ: Khi hệ thống bị tấn công và kẻ tấn công lấy được thông tin trong cơ

sở dữ liệu hoặc trên đường truyền, các dữ liệu nhạy cảm sẽ bị lộ nếu không được mã hóa hoặc mã hóa không an toàn

Phòng chống: Để giảm thiểu nguy cơ mất ATTT với dữ liệu trong DB và trên

đường truyền, quá trình phát triển ứng dụng cần mã hóa các dữ liệu nhạy cảm trong cơ

sở dữ liệu và sử dụng giao thức HTTPS với các chức năng quan trọng (như các hệ thống giao dịch trực tuyến, các chức năng đăng nhập) [10,13]

R9 User enumeration

Mô tả: Sử dụng chung thông báo lỗi cho cả 2 trường hợp nhập sai tên đăng

nhập và mật khẩu trên trang đăng nhập vào hệ thống Nhằm tránh trường hợp thông báo lỗi trên trang đăng nhập phân biệt giữa nhập sai tên đăng nhập và sai mật khẩu Dựa vào đó hacker có thể thử và tìm ra các user có trên hệ thống

Nguy cơ: Trường hợp thông báo lỗi trên trang đăng nhập phân biệt giữa nhập

sai tên đăng nhập và sai mật khẩu Dựa vào đó hacker có thể thử và tìm ra các user có trên hệ thống

Phòng chống: Sử dụng chung thông báo lỗi cho cả 2 trường hợp nhập sai tên

đăng nhập và mật khẩu trên trang đăng nhập vào hệ thống [14]

R10 HTTP Only cookie

Mô tả: Yêu cầu thiết lập thuộc tính ”HTTP Only” cho session cookie Vì nếu

Session cookie không được set thuộc tính ”HTTP Only”, hacker có thể sử dụng mã javascript để ăn cắp cookie của người dùng

Nguy cơ: Hacker có thể sử dụng mã javascript để ăn cắp cookie của người

dùng

Phòng chống: Yêu cầu thiết lập thuộc tính "HTTP Only" cho session cookie

Vì nếu Session cookie không được set thuộc tính "HTTP Only" Ta có thể cấu hình bên phía Webserver [15]

R11 Chuyển hướng và chuyển tiếp thiếu thẩm tra

Mô tả: Không cho phép người dùng cuối có thể can thiệp vào quá trình redirect

từ ứng dụng này sang ứng dụng khác Nếu cần sử dụng thì URL phải được kiểm tra, đảm bảo URL được redirect đến nằm trong danh sách cho phép của ứng dụng Nếu không được kiểm tra, kẻ tấn công có thể redirect đến URL có nhiễm mã độc để cài đặt phần mềm độc hại, hoặc lừa nạn nhân khai báo mật khẩu, hoặc những thông tin nhạy cảm khác

Nguy cơ: Hacker có thể redirect đến URI có nhiễm mã độc để cài phần mềm

độc hại, hoặc lừa nạn nhân khai báo mật khẩu, hoặc những thông tin nhạy cảm khác

16

Ví dụ: http://www.example.com/redirect.jsp?url=evil.com ở đây evil.com chính là trang hacker muốn chuyển đến

Phòng chống: Hạn chế sử dụng việc chuyển hướng và chuyển tiếp đến URI

khác Nếu sử dụng thì nên hạn chế truyền tham số là trang sẽ chuyển hướng đến, hoặc tham số này phải được mã hóa và được kiểm tra tính hợp lệ của nó [16]

R12 Thất thoát thông tin và xử lý lỗi không đúng cách

Mô tả: Yêu cầu không hiển thị chi tiết lỗi cho người dùng cuối, hạn chế thông

tin hiển thị nhất có thể Đồng thời các thông tin lỗi này phải được log lại bên server để phục vụ bảo trì

Nguy cơ: Việc hiển thị chi tiết và quá nhiều thông tin lỗi khi xử lý, các thông

tin này rất có ích cho hacker Hacker có thể dựa vào các thông tin này để đoán biết hệ thống cũng như tiếp cận, khai thác lỗ hổng ứng dụng

Phòng chống: Yêu cầu tất cả các ngoại lệ đều phải được xử lý, và được lưu vào trong hệ thống log để được xử lý sau này Hạn chế hiển thị chi tiết lỗi ra phía người

dùng cuối chỉ nên thông báo lỗi đơn giản nhất có thể [17]

R13 Sử dụng captcha an toàn

Mô tả: Nhằm mục đích chủ động bảo vệ các ứng dụng web, phòng tránh các

nguy cơ từ việc dò quyét mật khẩu người dùng, đăng ký tài khoản, gửi thư rác hàng loạt, gửi bình luận, nhận xét trên các website với số lượng lớn bằng các Chương trình

tự động [18]

Nguy cơ: Hacker sử dụng các phần mềm tự động nhằm thực hiện hàng loạt các

tác vụ của hệ thống gây ảnh hưởng đến hoạt động và chất lượng phục vụ của hệ thống

Phòng chống: Sử dụng captcha trong các trường hợp có nguy cơ tấn công bằng

các phần mềm tự động VD: với các chức năng đăng ký tài khoản, gửi bình luận…

R14 Mật khẩu mạnh

Mô tả: Nhằm mục đích chủ động bảo vệ thông tin tài khoản và mật khẩu của

người dùng, hệ thống cần có tính năng yêu cầu người dùng sử dụng mật khẩu mạnh [19]

Nguy cơ: Việc sử dụng mật khẩu không đảm bảo độ phức tạp có thể dẫn đến

việc: hacker sử dụng phần mềm tự động đề dò ra mật khẩu của người dùng

Phòng chống: Hệ thống cần thiết đặt tính năng yêu cầu người dùng sử dụng

mật khẩu mạnh, đảm bảo các tiêu chí:

- Mật khẩu có độ dài tối thiểu là 8 ký tự

17

- Mật khẩu phải bao gồm chữ số, chữ cái hoa, chữ cái thường và ký tự đặc biệt

- Thời gian hiệu lực của mật khẩu là 90 ngày

- Khi đổi mật khẩu: mật khẩu mới không được trùng với mật khẩu cũ

2.3 Các ca kiểm thử ATTT

Với các nguy cơ mất an toàn thông tin đã mô tả ở mục 2.2, kiểm thử viên có trách nhiệm phân tích với từng chức năng của hệ thống sẽ có nguy cơ mắc những lỗi

an toàn thông tin nào để từ đó đưa ra các ca kiểm thử tương ứng

Mỗi lỗ hổng bảo mật này có thể xuất hiện ở nhiều phần khác nhau của một hệ thống Bởi vậy, chúng tôi sẽ phân một ứng dụng web thành 12 chức năng, được đánh dấu từ F2 đến F13 Các chức năng này gồm:

- F2 Chức năng Đăng nhập – Đăng xuất

- F11 Chức năng Trang có chuyển hướng

- F12 Chức năng liên quan đến dữ liệu nhạy cảm

- F13 Chức năng liên quan đến mật khẩu

Phần này phân tích từng chức năng và các nguy cơ về ATTT mà chức năng đó có khả năng mắc phải Riêng có một số nguy cơ, một ứng dụng web chỉ có khả năng mắc phải

ở một điểm duy nhất của hệ thống Các trường hợp này được nhóm thành một tập các

ca kiểm thử mức chung (đánh dấu là F1) Các ca kiểm thử mức chung là các ca kiểm thử ATTT chỉ cần thực hiện 1 lần là có khả năng kiểm tra cho toàn bộ hệ thống Từ những phân tích trên, chúng tôi tổng hợp thành bảng 2.1

Nguy cơ mất ATTT tương ứng Số ca

F2

Ca kiểm thử cho chức năng Đăng nhập –

- Mã ca kiểm thử: mỗi ca kiểm thử có 1 mã riêng được hình thành theo quy tắc

Nhóm chức năng (F)_Rủi ro (R)_số thứ tự

- Mục đích kiểm thử: mô tả tóm tắt mục địch cụ thể của từng ca kiểm thử

- Các bước thực hiện: mô tả chi tiết từng bước thực hiện để phát hiện ra lỗ hổng

về ATTT Để thực hiện được các ca kiểm thử này, chúng tôi dùng thêm các công cụ hỗ trợ trong quá trình kiểm thử như firebug (để xem mã nguồn phía trình duyệt) và tamper data (để bắt gọi tin gửi lên server)

- Kết quả mong muốn: mô tả kết quả đầu ra của hệ thống khi hệ thống không có

lỗi

- Ghi chú: mô tả lại phạm vi áp dụng với từng ca kiểm thử, biểu hiện của hệ

thống khi mắc lỗi và giải thích cụ thể từng lỗi

19

F1 Ca kiểm thử mức chung

Dựa vào công cụ hỗ trợ như firebug, chúng tôi có thể thay đổi dữ liệu cookies của hệ thống, từ đó chiếm quyền điều khiển, nhằm mục đích kiểm tra xem hệ thống có bị các lỗi Session Hijacking hay không Ngoài ra, firebug cũng hỗ trợ chúng tôi kiểm tra việc hệ thống thiết lập thuộc tính HTTP only Các trường hợp này được chúng tôi thiết kế thành các ca kiểm thử như bảng 2.3

Bảng 2.3 Các ca kiểm thử chỉ cần kiểm tra một lần trên toàn bộ hệ thống

Mã ca

kiểm thử Mục đích kiểm thử Các bước thực hiện mong muốn Kết quả Ghi chú

CHỨC NĂNG: Các case chỉ kiểm tra 1 lần trên cả hệ thống

F1_R5_1

Session Hijacking (Kiểm tra lỗi

2 tài khoản,

2 trình duyệt, trên cùng 1 máy)

1 Trên Firefox: Đăng nhập vào hệ thống với Tài khoản A

có quyền cao hơn tài khoản B

2 Trên Chrome: Đăng nhập vào hệ thống với Tài khoản

+ Thay cookie của tài khoản B bằng cookie của tài khoản

A và lưu lại (document.cookie = "JSESSIONID =

<cookie của tài khoản A>") + Refresh URL trên trình duyệt của B với cookie mới

Tài khoản B không tấn công được vào tài khoản A (không thực hiện được tháo tác thuộc tài khoản A hoặc view được thông tin thuộc tài khoản A hoặc cả

2 bị hết session)

- Phạm vi kiểm thử: 1 lần

- Biểu hiện lỗi: Tài khoản

B thực hiện được các quyền của tài khoản A

- Giải thích lỗi: Lỗi session hijacking không cho phép 2 phiên truy cập đồng thời, session được xây dựng từ các thông tin người dùng: IP, trình duyệt, địa chỉ mac

20

F1_R5_2

Session Hijacking (Kiểm tra lỗi

1 user có tài khoản, 1 user không

có tài khoản,

2 trình duyệt, trên cùng 1 máy)

1 Trên Firefox:

+ Đăng nhập vào hệ thống với Tài khoản A có quyền vào

hệ thống + Dùng tiện ích để lấy cookie của tài khoản A: Firebug/

Net/ Click Link/ cookies + Copy link trên thanh address

2 Trên Chrome:

+ Paste link vừa copy trên Firefox + Delete cookies cũ (F12/ resources/ cookies/ địa chỉ hệ thống đang test/ Chuột phải vào cookies/ delete)

+ Sửa cookie hiện tại bằng cookie của tài khoản A và lưu lại (gõ lệnh: document.cookie = "JSESSIONID = <cookie của tài khoản A>")

3 Refresh URL trên Chrome vừa thay đổi cookie mới

Trên Chrome không vào được tài khoản A (không thực hiện được thao tác thuộc tài khoản

A hoặc view được thông tin thuộc tài khoản

A hoặc cả 2 bị hết session)

- Phạm vi kiểm thử: 1 lần

- Biểu hiện lỗi: Trên Chrome chiếm được các quyền của tài khoản A

21

F1_R5_3

Session Hijacking (Kiểm tra lỗi

2 tài khoản,

1 trình duyệt, trên 2 máy)

1 Máy 1: Đăng nhập vào hệ thống với Tài khoản A có quyền cao hơn tài khoản B bằng trình duyệt Chrome

2 Máy 2: Đăng nhập vào hệ thống với Tài khoản B bằng trình duyệt Chrome

3 Máy 1: Dùng tiện ích để lấy cookie của tài khoản A (Chrome/ F12/ resources/ cookies/ địa chỉ hệ thống đang test)

4 Máy 2:

+ Xóa cookie hiện tại (Chrome/ F12/ resources/ cookies/

địa chỉ hệ thống đang test/ Chuột phải vào cookies/

delete) + Thay cookie của tài khoản B bằng cookie của tài khoản

A và lưu lại (Console/ gõ lệnh: document.cookie =

"JSESSIONID = <cookie của tài khoản A>") + Refresh URL trên trình duyệt của B vừa thay đổi cookie mới

+ Thực hiện cùng thao tác tài khoản A có quyền, nhưng tài khoản B không có quyền

Tài khoản B không tấn công được vào tài khoản A (không thực hiện được tháo tác thuộc tài khoản A hoặc view được thông tin thuộc tài khoản A hoặc cả

2 bị hết session)

- Phạm vi kiểm thử: 1 lần

- Biểu hiện lỗi: Tài khoản

B thực hiện được các quyền của tài khoản A

22

F1_R5_4

Session Hijacking (Kiểm tra lỗi

1 user có tài khoản, 1 user không

có tài khoản,

1 trình duyệt, trên 2 máy)

1 Trên máy 1:

+ Đăng nhập vào hệ thống với Tài khoản A có quyền vào

hệ thống + Dùng tiện ích để lấy cookie của tài khoản A (Chrome/

F12/ resources/ cookies/ địa chỉ hệ thống đang test) + Copy link trên thanh address

A hoặc view được thông tin thuộc tài khoản

A hoặc cả 2 bị hết session)

- Phạm vi kiểm thử: 1 lần

- Biểu hiện lỗi: Trên Chrome chiếm được các quyền của tài khoản A

F1_R12_

5

Kiểm tra việc cố tình tạo trang lỗi

để khai thác thông tin nhạy cảm của hệ thống

1 Đăng nhập vào hệ thống

2 Sửa 1 thông tin trên đường link rồi enter VD:

+ Link gốc:

http://tuyendung.viettel.com.vn/RMSPortal/Index.do + Link sau sửa:

http://tuyendung.viettel.com.vn/RMSPortal/abc123

5 Kiểm tra thông tin hiển thị lên có chứa các thông tin nhạy cảm không (VD: sessionid, CMND, số tài khoản, phiên bản tomcat )

- Hiển thị trang trắng hoặc thông báo Có lỗi xảy ra (Nhưng không hiển thị các thông tin của hệ thống)

- Phạm vi kiểm thử: 1 lần

- Biểu hiện lỗi: Trình duyệt hiển thị kết quả lỗi, bao gồm các thông tin: phiên bản tomcat,version

dự án, full ra trang lỗi do không bắt ngoại lệ làm thất thoát thông tin

23

F1_R10_

6

Kiểm tra HttpOnly Cookie

Pre: Cài và chạy Add-ons cookie và FireBug cho FireFox

1 Đăng nhập vào ứng dụng

2 Dùng firebug kiểm tra trường HttpOnly của Jsession

- Firefox: Firebug -> Cookies -> SID/ JSessionID/ ->

kiểm tra HttpOnly

- Chrome: F12/ resources/ cookies/ ip server/ xem thuộc tính HTTP

- Nếu xem thuộc tính only bằng cách view, đôi lúc view trên firebug thì không có thuộc tính only => nên tốt nhất

là xem bằng cách gõ lệnh document.cookie hoặc xem trên trình duyệt Chrome

SID/

JSessionID/ có giá trị http only

- Phạm vi kiểm thử: 1 lần

- Biểu hiện lỗi: SID/ JSessionID/ không có giá trị HttpOnly

- Giải thích lỗi: Hacker

có thể sử dụng javascript

để đánh cắp cookies của người dùng

24

F2 Ca kiểm thử cho chức năng Đăng nhập – Đăng xuất

Với chức năng Đăng nhập – Đăng xuất cũng thường mắc các lỗi SQL injection, Session fixation, Session Hijacking Để kiểm tra lỗi SQL injection thì chúng tôi chỉ cần tiếp cận hệ thống thông qua việc nhập dữ liệu đầu vào trên giao diện Một số trường hợp có thể sử dụng công cụ firebug để hỗ trợ nếu hệ thống có điều kiện ngăn chặn phía client gây ảnh hưởng đến việc nhập liệụ Để kiểm tra các lỗi liên quan đến session, chúng tôi dùng các công cụ hỗ trợ như firebug hoặc tamper data để sửa hoặc xem dữ liệụ Việc thiết kê từng trường hợp để kiểm tra được chúng tôi mô tả trong bảng 2.4

Bảng 2.4 Các ca kiểm thử với màn hình có chức năng Đăng nhập – Đăng xuất

Mã ca

kiểm thử Mục đích kiểm thử Các bước thực hiện mong muốn Kết quả Ghi chú

CHỨC NĂNG: Đăng nhập/ Đăng xuất

3.Click Đăng nhập

Hệ thống thông báo tài khoản không tồn tại

- Phạm vi kiểm thử: 1 lần

- Biểu hiện lỗi: Ứng dụng có thể bắn lỗi 500, hoặc trên trình duyệt in ra câu truy vấn SQL lỗi hay đăng nhập thành công, khi đó có thể xác định ứng dụng

đã bị mắc lỗi SQL Injection

- Giải thích lỗi: Câu SQL đc thành lập: select * from user where username='test' or '1'='1' and password= functionMahoắpass')

=> nếu thay username như case thì sẽ select được toàn bộ bảng user (do thứ

tự ưu tiên các toán tử là: not, and, or)

25

F2_R6_2

Session fixation (login)

1 Mở tool hỗ trợ để lấy link của các action (firebug hoặc tamper data)

2 Gõ link vào hệ thống (đ/c ứng dụng)

3 Thực hiện thao tác login

4 Xem SessionID khi chưa login và sau khi login vào hệ thống

<Chú ý: phải kiểm tra cookies trước và sau khi đăng nhập của cùng địa chỉ server của ứng dụng>

SessionID trước và sau khi đăng nhập là khác nhau

có thể đăng nhập vào hệ thống thông qua 1 session id do hacker tạo sẵn thay vì do trình chủ tự sinh Do đó phải hủy bỏ SessionId (SID/

JSessionID/…) đc cung cấp bởi trình duyệt của người dùng khi đăng nhập

và luôn tạo SID mới sau khi đăng nhập thành công

3 Thực hiện thao tác logout

4 Xem SessionID khi chưa logout và sau khi logout khỏi hệ thống

<Chú ý: phải kiểm tra cookies trước và sau khi đăng nhập của cùng địa chỉ server của ứng dụng >

SessionID trong khi login và sau khi logout là khác nhau

- Phạm vi kiểm thử: 1 lần

- Biểu hiện lỗi: SessionID trong khi login và sau khi logout là giống nhau nhau

- Giải thích lỗi: Hacker có thể lợi dụng lỗ hổng này để lấy Session ID

và đăng nhập vào hệ thống

F2_R9_5

User enumeration (thông báo lỗi khi đăng nhập)

Thực hiện đăng nhập với 3 trường hợp sau:

1 Thực hiện đăng nhập với username không tồn tại

2 Thực hiện đăng nhập với password sai, username đúng

3 Thực hiện đăng nhập với password sai, username sai

Chỉ thông báo chung sai account đăng nhập

- Máy 2 đăng nhập không thành công

3 Logout Tài khoản A trên máy 1

4 Login vào Tài khoản A trên máy 2

Máy 2 đăng nhập thành công

- Phạm vi kiểm thử: 1 lần

- Biểu hiện lỗi: Máy 2 vẫn không đăng nhập được

27

F2_R5_8

Session Hijacking (Kiểm tra lỗi 1 tài khoản, trên

2 trình duyệt)

1 Đăng nhập vào hệ thống với Tài khoản A trên trình duyệt 1

2 Đăng nhập vào hệ thống với Tài khoản A trên trình duyệt 2

- Máy 1 đăng nhập thành công

- Máy 2 đăng nhập không thành công

2 trình duyệt)

1 Login vào hệ thống với Tài khoản A trên trình duyệt 1

2 Login vào hệ thống với Tài khoản A trên trình duyệt 2 => không thành công

3 Logout Tài khoản A trên trình duyệt

1

4 Login vào Tài khoản A trên trình duyệt 2

Máy 2 đăng nhập thành công

1 Thực hiện đăng nhập vào hệ thống

2 Kiểm tra giao thức:

Vào firebug/ Net/ Xem link

Sử dụng giao thức HTTPS

- Phạm vi kiểm thử: 1 lần

- Biểu hiện lỗi: Không sử dụng giao thức https

28

F3 Ca kiểm thử cho chức năng Tìm kiếm

Chức năng Tìm kiếm thường gặp các lỗi XSS và SQL Injection hoặc các lỗi liên quan đến việc xác thực phân quyền (lỗi leo quyền) Phương pháp tiếp cận hệ thống để kiểm tra các lỗi này là dựa vào việc nhập dữ liệu đầu vào trên giao diện có sử dụng thêm các công cụ hỗ trợ như firebug Chúng tôi thiết kế các trường hợp kiểm tra cho chức năng Tìm kiếm như trong bảng 2.5

Bảng 2.5 Các ca kiểm thử với màn hình có chức năng Tìm kiếm

Đối với trang tìm kiếm:

1 Mở firebug/ Click element lên control

2 Sửa value của item dùng làm tiêu chí tìm kiếm như sau: <tiêu chí tìm kiếm> or 1=1

3 Tìm kiếm

Hệ thống:

+ Thông báo không tìm thấy

dữ liệu + Hoặc thông báo có lỗi xảy ra (Do có ngoại lệ khi server ép kiểu xâu nhập vào về kiểu số)

- Phạm vi kiểm thử: Mỗi tiêu chí tìm kiếm tương ứng 1 case (chỉ cần test khi tiêu chí này là tiêu chí tìm kiếm tuyệt đối)

- Biểu hiện lỗi: Hệ thống hiển thị tất cả dữ liệu (mà không lọc theo tiêu chí đã nhập)

- Giải thích lỗi: Câu truy vấn tìm kiếm: select * <TableName> where

<FieldName> = '<tiêu chí tìm kiếm>' or '1'='1'

2 Check hiển thị dữ liệu trong Combobox/

Data picker/ Popup A

Dữ liệu được hiển thị lên không bị lỗi, hiển thị đúng định dạng đã nhập ở danh mục B

- Phạm vi kiểm thử: Mỗi trường tương ứng 1 case (chỉ cần test với combo/ datapicker/ popup lấy dữ liệu từ DB, được nhập từ danh mục hoặc 1 phần khác của hệ thống)

- Biểu hiện lỗi: chỉ hiển thị số 1

1 Trong danh mục B, tạo dữ liệu nhập NAME

là chuỗi script mã HEXA dạng URL:

%3cb%3e1%3c%2fb%3e

2 Check hiển thị dữ liệu trong Combobox/

Data picker/ Popup A

Dữ liệu được hiển thị lên không bị lỗi, hiển thị đúng định dạng đã nhập ở danh mục B

- Phạm vi kiểm thử: Mỗi trường tương ứng 1 case (chỉ cần test với combo/ datapicker/ popup lấy dữ liệu từ DB, được nhập từ danh mục hoặc 1 phần khác của hệ thống)

- Biểu hiện lỗi: chỉ hiển thị số 1

1 Trong danh mục B, tạo dữ liệu nhập NAME

là chuỗi script mã HEXA dạng HTML:

&lt;b&gt;1&lt;/b&gt;

2 Check hiển thị dữ liệu trong Combobox/

Data picker/ Popup A

Dữ liệu được hiển thị lên không bị lỗi, hiển thị đúng định dạng đã nhập ở danh mục B

- Phạm vi kiểm thử: Mỗi trường tương ứng 1 case (chỉ cần test với combo/ datapicker/ popup lấy dữ liệu từ DB, được nhập từ danh mục hoặc 1 phần khác của hệ thống)

- Biểu hiện lỗi: chỉ hiển thị số 1 Textbox/ Textarea (trường lưu trong DB là trường số)

dữ liệu + Hoặc thông

- Phạm vi kiểm thử: Mỗi tiêu chí tìm kiếm tương ứng 1 ca (kiểm tra khi tiêu chí này là tiêu chí tìm kiếm tuyệt đối)

- Biểu hiện lỗi: Hệ thống hiển thị

30

báo Có lỗi xảy ra (Do có ngoại lệ khi server ép kiểu xâu nhập vào về kiểu số)

tất cả dl (không lọc theo tiêu chí nhập)

- Giải thích lỗi: Câu truy vấn tìm kiếm: select * <TableName> where

<FieldName> = '<tiêu chí tìm kiếm>' or '1'='1'

2 Các tiêu chí khác để trống

3 Tìm kiếm

Hệ thống thông báo: không tìm thấy dữ liệu

- Phạm vi kiểm thử: Mỗi tiêu chí tìm kiếm tương ứng 1 ca

- Biểu hiện lỗi: Hệ thống hiển thị tất cả dữ liệu (mà không lọc theo tiêu chí đã nhập)

- Giải thích lỗi: Câu truy vấn tìm kiếm: select * <TableName> where

<FieldName> like '%<tiêu chí tìm kiếm>' or '1%'='1%'

Textbox/ Textarea/ các control nhập DL mà Hệ thống có hiển thị DL nhập đó trên Hệ thống (trường lưu trong DB là xâu)

- Phạm vi kiểm thử:

+ Chỉ cần test với trường hợp trong

KQ tìm kiếm có hiển thị Script nhập vào VD: hiện thông báo "KQ tìm kiếm theo tiêu chí … Là: " + Mỗi tiêu chí tìm kiếm tương ứng

1 case

- Biểu hiện lỗi: Full ra alert hoặc hiển thị trang lỗi