HTTP Only cookie - (LUẬN văn THẠC sĩ) xây dựng các- 123docz.net

Mô tả: Yêu cầu thiết lập thuộc tính ”HTTP Only” cho session cookiẹ 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 cookiẹ 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.

Ví dụ: http://www.examplẹ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àỵ 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 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

- F3. Chức năng Tìm kiếm

- F4. Chức năng Thêm mới

- F5. Chức năng Sửa

- F6. Chức năng Xóa

- F7. Chức năng Xem thông tin chi tiết

- F8. Chức năng Download

- F9. Chức năng Upload

- F10. Chức năng Import

- 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ảị 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.

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 Nhóm chức năng BẢNG TỔNG HỢP Nhóm các ca kiểm thử

Nguy cơ mất ATTT

tƣơng ứng Số ca

F1 Ca kiểm thử mức chung R5, R12, R10 6 F2 F2

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

Đăng xuất R1, R5, R6, R9, R8 10

F3 Ca kiểm thử cho chức năng Tìm kiếm R1, R2, R4, R12 13 F4 Ca kiểm thử cho chức năng Thêm mới R1, R2, R3, R4, R12 15 F4 Ca kiểm thử cho chức năng Thêm mới R1, R2, R3, R4, R12 15 F5 Ca kiểm thử cho chức năng Sửa R1, R2, R3, R4, R12 22 F6 Ca kiểm thử cho chức năng Xóa R1, R3, R4, R12 6 F7 Ca kiểm thử cho chức năng Xem thông tin R1, R4 4 F8 Ca kiểm thử cho chức năng Download R4, R7 9 F9 Ca kiểm thử cho chức năng Upload R3, R4, R7 12 F10 Ca kiểm thử cho chức năng Import R1, R2, R3, R4, R7 7 F11

Ca kiểm thử cho chức năng Trang có

chuyển hƣớng R11 1

F12

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

cảm R8 4

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

Tổng: 115

Dựa trên bảng phân tích này, chúng tôi thiết kế các ca kiểm thử tƣơng ứng với từng nguy cơ và từng chức năng tƣơng ứng. Mỗi ca kiểm thử sẽ đƣợc thiết kế gồm các nội dung sau (tƣơng ứng với từng cột trong các bảng từ 2.3 đến 2.15):

- 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ệ

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 onlỵ 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

Mỗi case phải check 1 lần duy nhất 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 B

3. Trên Firefox: Dùng tiện ích để lấy cookie của tài khoản A: Firebug/ Net/ Click Link/ cookies

4. Trên Chrome:

+ Delete cookies cũ (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 (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 Ạ - 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 ađress 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

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 Chromẹ

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

- 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 ađress

3. Trên máy 2:

+ Paste link vừa copy trên máy 1

+ Delete cookies hiện tại (Chrome/ 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 (Console/ gõ lệnh: document.cookie = "JSESSIONID = <cookie của tài khoản A>")

+ Refresh URL vừa thay đổi cookie mới

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

F1_R10_ 6

Kiểm tra HttpOnly Cookie

Pre: Cài và chạy Ađ-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

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

Login/ logout

F2_R1_1 SQL injection

Kiểm tra đăng nhập hệ thống: 1.Nhập username = test' or '1'='1 2.Nhập Password = <bất kỳ giá trị nào>

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