Bên cạnh đó c n một điểm cần quan tâm đó là sự an toàn không chỉ phụ thuộc vào những giải thuật, những tiêu chuẩn, và những cơ chế mà WS security mang lại, mà nó c n tùy vào thái độ của
Trang 1BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
-
Phạm Minh Tuyến
PHÂN TÍCH VÀ ĐÁNH GIÁ ĐỘ AN TOÀN CỦA CÁC DỊCH VỤ WEB
Chuyên ngành: Công nghệ thông tin
LUẬN VĂN THẠC SĨ KHOA HỌC
Công nghệ thông tin
NGƯỜI HƯỚNG DẪN KHOA HỌC:
TS Vũ Thị Hương Giang
Trang 2LỜI CÁM ƠN
Lời đầu tiên cho em xin được gửi lời cảm ơn sâu sắc đến cô giáo TS Vũ Thị Hương Giang – Viện Công nghệ thông tin & Truyền thông – Đại học Bách khoa Hà Nội, đã tận tình hướng dẫn trong suốt quá trình thực hiện luận văn
Em xin chân thành cảm ơn quý thầy cô ở Viện Công nghệ thông tin & Truyền thông nói riêng và Đại học Bách khoa Hà Nội nói chung, đã giúp đỡ chúng em trong suốt khóa học
Cuối cùng tôi xin cảm ơn quý bạn bè và đồng nghiệp, những người đã tạo điều kiện cũng như giúp đỡ để tôi có thể hoàn thành khóa học
Trang 3LỜI CAM ĐOAN
Tôi là Phạm Minh Tuyến, học viên lớp Cao học khóa 2009 – trường Đại học Bách khoa Hà Nội Tôi xin cam kết Luận văn này là công trình nghiên cứu của bản thân dưới sự hướng dẫn khoa học của TS Vũ Thị Hương Giang – Viện Công nghệ thông tin & Truyền thông – Đại học Bách khoa Hà Nội
Kết quả trong Luận văn là trung thực và không sao chép nguyên bản từ bất kỳ một công trình nào khác
Hà Nội, ngày 25 tháng 3 năm 2012
Học viên: Phạm Minh Tuyến
Trang 4SOAP Simple Object Access Protocol
WS-BPEL Web Services Business Process Execution Language
WSDL Web Services Description Language
XML Extensible Markup Language
UDDI Universal Description, Discovery and Intergration
HTTP HyperText Transfer Protocol
COBIT Control OBjectives for Information and related Technology
PO Planning & Organisation
DS Delivery & Support
AI Acquisition & Implementation
ME Monitoring & Evaluate
Trang 5DANH MỤC HÌNH
Hình 1: Mô hình hoạt động dịch vụ Web 13
Hình 2: Chồng giao thức dịch vụ Web 16
Hình 3: Các actor tham gia vào WS 18
Hình 4: Cấu trúc WS L 20
Hình 5: Mô hình UDDI 21
Hình 6: Các yêu cầu của thuộc t nh xác thực 26
Hình 7: Các yêu cầu của thuộc t nh phân quyền 27
Hình 8: Các yêu cầu của thuộc t nh không thể phủ nhận 28
Hình 9: Các yêu cầu của thuộc t nh b mật 29
Hình 10: Các yêu cầu của thuộc t nh toàn v n 30
Hình 11: Sơ đồ mô tả cách tấn công bằng cách sử dụng local proxy để thay đổi tham số 33 Hình 12: Sơ đồ mô tả cách tấn công dựa vào lỗi tràn vùng đệm 36
Hình 13: Sơ đồ mô tả ví dụ về cách tấn công dựa vào lỗi cross site scripting 37
Hình 14: hiện thị thông báo lỗi SQL Injection 39
Hình 15: Sơ đồ mô tả cách tấn công DoS 41
Hình 16: Áp dụng các cơ chế an toàn cho web services 42
Hình 17: Mô hình an toàn cho web service 43
Hình 18: Quy trình mô hình hóa của Microsoft 48
Hình 19: Khối lập phương CO IT 54
Hình 20: Quy trình quản lý CNTT của CO IT 4.1 58
Hình 21: Mô hình quy trình tổng thể đánh giá WS 61
Hình 22: Mô hình quy trình chi tiết đánh giá các tiêu chuẩn an toàn trong xây dựng WS 63 Hình 23: Mô hình chi tiết quy trình đánh giá an toàn WS 65
Hình 24: Mô hình quy trình đánh giá độ an toàn khi triển khai và hỗ trợ các WS 66
Hình 25: Mô hình quy trình đánh giá an toàn khi lập kế hoạch và tổ chức các WS 74 Hình 26: Mô hình chi tiết quy trình đánh giá an toàn WS 75
Hình 27: Biểu đồ phân cấp chức năng 80
Hình 28: iểu đồ luồng dữ liệu mức ngữ cảnh 81
Hình 29: iểu đồ luồng dữ liệu mức đỉnh 81
Hình 30: Biểu đồ luồng dữ liệu mức dưới đỉnh, chức năng quản lý người dùng 82
Hình 31: iểu đồ luồng dữ liệu mức dưới đỉnh Chat 82
Hình 32: Biểu đồ luồng dữ liệu mức dưới đỉnh hiển thị 83
Hình 33: Giao diện chính của chương trình 85
Hình 34: Giao diện form đăng nhập 86
Hình 35: Giao diện form tạo tài khoản mới 87
Hình 36: Giao diện form thêm người dùng 88
Hình 37: Giao diện form chat 89
Hình 38: Giao diện form tin nhắn offline 90
Trang 6MỤC LỤC
GIỚI THIỆU ĐỀ TÀI 10
CHƯƠNG 1: TỔNG QUAN VỀ DỊCH VỤ WEB (WEB SERVICE) 13
Giới thiệu: 13
1.1 KHÁI NIỆM 13
1.2 ĐẶC ĐIỂM 14
1.3 KIẾN TRÚC 15
1.3.1 Tầng vận chuyển (Transport) 16
1.3.2 Tầng giao thức tương tác dịch vụ (Service Communication Protocol) 16
1.3.3 Tầng mô tả dịch vụ (Service escription) 17
1.3.4 Tầng dịch vụ (Service) 17
1.3.5 Tầng đăng lý dịch vụ (Service Registry) 17
1.3.6 Các tầng còn lại 17
1.4 CẤU TRÚC WS 17
1.5 CÁC C NG CỤ X Y ỰNG WS 18
1.5.1 XML (Extensible Markup Language) 18
1.5.2 WSDL (Web Services Description Language) 19
1.5.3 UDDI (Universal Description , Discovery and Intergration) 20
1.5.4 SOAP (Simple Object Accesss Protocol) 21
1.6 QUI TRÌNH X Y ỰNG WS 22
1.6.1 Giai đoạn xây dựng 23
1.6.2 Giai đoạn triển khai 23
1.6.3 Giai đoạn tiến hành 23
1.6.4 Giai đoạn quản lý 23
Tổng kết chương: 24
CHƯƠNG 2: ĐẢM BẢO AN TOÀN CHO CÁC DỊCH VỤ WEB 25
Giới thiệu: 25
2.1 CÁC TI U CH AN TO N ỊCH VỤ W .25
2.1.1 T nh xác thực (Authentication) 25
2.1.2 T nh phần quyền (Authorization) 26
2.1.3 T nh không thể phủ nhận (chống chối b - Non-Repudiation) 27
2.1.4 T nh b mật (Confidentiality) 29
2.1.5 T nh toàn v n (Integrity) 30
Trang 72.2.1 ữ liệu đầu vào không được kiểm tra t nh hợp lệ 32
2.2.2 Lỗi kiểm soát truy cập nguồn tài nguyên 33
2.2.3 Lỗi liên quan đến quá trình quản lý xác thực và phiên truy cập 34
2.2.4 Lỗi tràn bộ đệm 35
2.2.5 Lỗi liên trang (Cross Site Scripting - XSS) 36
2.2.6 Tiêm mã độc (Injection) 38
2.2.7 Quy trình quản lý báo lỗi 38
2.2.8 Lưu trữ thiếu an toàn 39
2.2.9 Từ chối dịch vụ 40
2.2.10 Quản lý cấu hình thiếu an toàn 41
2.3 ĐẢM ẢO AN TO N WS NG W S RVIC S CURITY 42
Tổng kết chương: 45
CHƯƠNG 3: CÁC PHƯƠNG PHÁP ĐÁNH GIÁ ĐỘ AN TOÀN PHẦN MỀM 46
Giới thiệu: 46
3.1 PHƯƠNG PHÁP M HÌNH HÓA Đ ỌA 46
3.1.1 Khái niệm mô hình hóa đe dọa 46
3.1.2 Phương pháp mô hình hóa đe dọa của Microsoft 47
3.1.2.1 Mục đ ch 47
3.1.2.2 Quy trình thực hiện 48
3.1.2.3 Đánh giá phương pháp mô hình hóa đe dọa của Microsoft 49
3.2 PHƯƠNG PHÁP THỬ NGHIỆM TH M NHẬP 49
3.2.1 Tổng quan 49
3.2.2 Lập kế hoạch thử nghiệm thâm nhập 50
3.3 PHƯƠNG PHÁP X M LẠI MÃ NGUỒN 51
3.3.1 Tổng quan 51
3.3.2 Quy trình thực hiện 52
3.3.3 Đánh giá 53
3.4 PHƯƠNG PHÁP CO IT 53
3.4.1 Tổng quan 53
3.4.2 Các thành phần của CO IT 54
3.4.2.1 Yêu cầu nghiệp vụ ( usiness Requirements) 55
3.4.2.2 Tài nguyên công nghệ (IT Resources) 56
3.4.2.3 Quy trình CNTT (IT Process) 56
Trang 83.4.4 Đánh giá phương pháp CO IT 58
Tổng kết chương: 59
CHƯƠNG 4: QUY TRÌNH ĐÁNH GIÁ ĐỘ AN TOÀN CỦA DỊCH VỤ WEBTRÊN GÓC ĐỘ QUẢN TRỊ CÔNG NGHỆ THÔNG TIN 60
Giới thiệu: 60
4.1 CÁCH TIẾP CẬN 60
4.1.1 Mục tiêu đánh giá 62
4.1.2 Thông tin về WS 63
4.1.3 Thông tin về môi trường triển khai phần mềm 64
4.2 M HÌNH CHI TIẾT QUY TRÌNH ĐÁNH GIÁ AN TO N WS 65
4.3 ĐỀ XUẤT QUY TRÌNH ĐÁNH GIÁ ĐỘ AN TO N KHI CHUYỂN GIAO V HỖ TRỢ CÁC ỊCH VỤ W .65
4.3.1 Mô hình quy trình đánh giá 65
4.3.2 Quản lý các dịch vụ do đối tác thứ 3 cung cấp (Manage Third-Party Services) – DS2 67 4.3.2.1 Nhà cung cấp giao diện (Supplier Interfaces) 67
4.3.2.2 Chủ sở hữu các quan hệ (Owner relationships) 67
4.3.2.3 ảo mật các mối quan hệ (Security Relationships) 68
4.3.3 Đảm bảo t nh liên tục dịch vụ ( nsure continuous service) – DS4 69
4.3.3.1 Nguồn tài nguyên CNTT quan trọng (Critical IT Resources) 69
4.3.3.2 Lưu trữ sao lưu ngoại vi (Off-site Back-up Storage) 70
4.3.4 ảo đảm an ninh hệ thống ( nsure Systems Security) – DS5 70
4.3.4.1 Định danh, xác thực và truy cập (Identification, Authentication and Access) 70
4.3.4.2 Đảm bảo an toàn trong việc truy cập trực tuyến tới dữ liệu (Security of Online Access to Data) 71 4.3.4.3 Quản lý tài khoản người dùng (User Account Management) 71
4.3.4.4 Đánh giá việc quản lý tài khoản người dùng (Management Review of User Accounts) 72 4.3.4.5 Kiểm soát người dùng đối với các tài khoản người dùng (User Control of User Accounts) 72
4.3.4.6 Giám sát an ninh (Security Surveillance) 72
4.3.4.7 Quản lý tập trung việc định danh và quyền truy cập (Central Identification and Access Rights Management) 72
4.3.4.8 Độ tin cậy của đối tác (Counterparty Trust) 72
4.3.4.9 Cấp phép giao dịch (Transaction Authorisation) 73
Trang 94.3.4.12 Quản lý khóa mã hóa (Cryptographic Key Management) 73
4.4 ĐỀ XUẤT QUY TRÌNH ĐÁNH GIÁ ĐỘ AN TO N KHI LẬP KẾ HOẠCH V TỔ CHỨC ỊCH VỤ W B 74
4.4.1 Mô hình quy trình đánh giá 74
4.4.2 Định nghĩa kiến trúc thông tin ( efine The Information Architecture) – PO2 74
4.4.2.1 Sơ đồ phân loại dữ liệu 74
4.4.2.2 Các cấp độ bảo mật 74
4.4.3 M HÌNH CHI TIẾT QUY TRÌNH ĐÁNH GIÁ TO N WS 75
Tổng kết chương: 76
CHƯƠNG 5: ỨNG ỤNG X Y ỰNG WS ỰA TR N QUY TRÌNH ĐÁNH GIÁ AN TO N ĐÃ ĐỀ XUẤT 77
Giới thiệu: 77
5.1 L O VIỆC CHỌN X Y ỰNG ỨNG ỤNG ỊCH VỤ CHAT 77
5.2 PH N T CH HỆ TH NG 77
5.2.1 Phân t ch chức năng và vẽ biểu đồ phân cấp chức năng 77
5.2.1.1 Chức năng Quản lý người dùng 78
5.2.1.2 Chức năng Chat 79
5.2.1.3 Chức năng Hiển thị 79
5.2.1.4 iểu đồ phân cấp chức năng 79
5.2.2 Phân t ch dữ liệu và biểu đồ luồng dữ liệu 80
5.2.2.1 iểu đồ luồng dữ liệu mức ngữ cảnh 81
5.2.2.2 iểu đồ luồng dữ liệu mức đỉnh 81
5.2.2.3 iểu đồ luồng dữ liệu mức dưới đỉnh 81
5.3 THIẾT KẾ CƠ SỞ Ữ LIỆU 83
5.3.1 ảng tblAccounts 83
5.3.2 ảng tblAddFriends 84
5.3.3 ảng tblMessages 84
5.4 THIẾT KẾ GIAO IỆN 85
5.4.1 Giao diện ch nh của chương trình 85
5.4.2 Giao diện form đăng nhập 86
5.4.3 Giao diện form tạo tài khoản mới 87
5.4.4 Giao diện form thêm người dùng(bạn bè) vào danh bạ 88
5.4.5 Giao diện form chat 89
5.4.6 GIAO diện form nhận tin nhắn offline 90
Trang 10KẾT LUẬN 91
T I LIỆU THAM KHẢO 93
Trang 11GIỚI THIỆU ĐỀ TÀI
T h ấ hiế ủ ề i
Trong những năm gần đây Internet đã phát triển nhanh cả về số lượng (băng thông, số kết nối, ) và cả các dịch vụ (giao dịch trực tuyến, thương mại điện tử, ) Với nhu đó, bắt buộc các cơ quan, tổ chức phải hoà mình vào và sử dụng các dịch vụ của Internet o đó việc đảm bảo an toàn và bảo mật thông tin là một trong những vấn
đề quan trọng hàng đầu khi thực hiện kết nối và sử dụng các dịch vụ trong mạng
H a cùng sự phát triển của Internet, ngày nay công nghệ web services cũng đã được phát triển, ứng dụng trong rất nhiều lĩnh vực khác nhau bao gồm cả những lĩnh vực nhạy cảm, đ i h i t nh an toàn cao như tài ch nh, ngân hàng, thương mại điện tử,… Ngoài những thành công mà công nghệ Web services mang lại thì việc đảm bảo
an toàn, tin cậy, toàn v n thông tin trao đổi trên các dịch vụ web cũng là một điều rất quan trọng trong quá trình xây dựng Web services V dụ, người dùng khó mà an tâm
để sử dụng một một dịch vụ giao dịch trực tuyến như mua bán chứng khoán hay chuyển tiền trực tuyến mà lại không có một sự an toàn cần thiết Nắm bắt được yêu cầu đó, công nghệ web service đã phát triển về k thuật, đó là cung cấp một mức an toàn bằng việc sử dụng WS security và các thành phần của nó giúp cho thông tin trao đổi trên web services trở nên an toàn hơn Tuy nhiên việc chọn cơ chế an toàn nào trong WS security thì phụ thuộc nhiều vào loại dịch vụ và những t nh năng mà dịch vụ này cung cấp Bên cạnh đó c n một điểm cần quan tâm đó là sự an toàn không chỉ phụ thuộc vào những giải thuật, những tiêu chuẩn, và những cơ chế mà WS security mang lại, mà nó c n tùy vào thái độ của các công ty có hiểu rõ tầm quan trọng của an toàn thông tin khi triển khai các ứng dụng, giao dịch trên mạng hay không cũng là điều rất cần quan tâm Vì vậy làm thế nào để giúp các nhà quản lý thấy được tầm quan trọng cũng như có một quy trình cụ thể nhằm đánh giá độ an toàn của dịch vụ Web trên góc
độ quản lý CNTT Từ những nhu cầu đó và cũng mong muốn góp một phần nh vào công cuộc nghiên cứu đảm bảo an toàn thông tin các dịch vụ Web nên tôi đã chọn đề
tài “Phâ h v á h giá ộ an toàn của các dịch vụ Web” đứng từ góc độ quản
trị công nghệ thông tin làm vấn đề để nghiên ch nh của luận văn
Trang 12Mụ h ghi ứ
Tìm hiểu và phân t ch các phương pháp đánh giá độ an toàn cho phần mềm hiện nay; nhận biết các ưu nhược điểm của các phương pháp để từ đó đề xuất những cải tiến nhằm có một quy trình đánh giá độ an toàn cho các dịch vụ Web tối ưu
Áp dụng quy trình đánh giá đã được cải tiến đó để ứng dụng đánh giá một WS
cụ thể
Đ i g ghi ứ
ịch vụ Web
Các phương pháp đánh giá an toàn bảo mật phần mềm
Các chuẩn qui trình quản lý rủi ro an toàn thông tin
Cấ v
Nội dung luận văn gồm 5 chương:
o Chương 1: Tìm hiểu tổng quan về an toàn dịch vụ Web (Web service – WS); Kiến trúc của dịch vụ Web; Quy trình xây dựng một WS,…
o Chương 2: Tìm hiểu các khái niệm: An toàn thông tin; An toàn dịch vụ
Trang 13để làm cơ sở cho các chương sau,…Và nêu lên các lỗ h ng bảo mật ứng dụng Web đang tồn tại
o Chương 3: Sẽ làm rõ nội dung cơ sở lý thuyết của các phương đánh giá phần mềm tiêu biểu hiện này (mô hình hóa đe dọa, thử thâm nhập, xem lại mã nguồn, phương quản lý CNTT theo CO IT)
o Chương 4: Từ các phân t ch ưu nhược điểm của các phương pháp đánh giá độ an toàn phần mềm nói chung ở chương 3 sẽ đề xuất cải tiến mô hình phương pháp đánh giá theo COBIT để áp dụng nhằm đánh giá độ
an toàn của dịch vụ Web theo 5 tiêu ch an toàn cho WS
o Chương 5: Thử nghiệm áp dụng mô hình đã đề xuất để ứng dụng đánh giá độ an toàn một dịch vụ Web cụ thể
Cuối cùng là kết luận: nêu những vấn đề c n tồn tại và hướng phát triển của đề tài
Trang 14CHƯƠNG : TỔNG QUAN VỀ DỊCH VỤ WEB (WEB SERVICE)
Giới thiệu:
Trong chương này ta lần lược tìm hiểu các khái niệm cơ bản về dịch vụ Web nhằm giúp cho người dùng bước đầu hình dung thế nào là Web service (WS)? Ứng dụng nó để làm gì? Xây dựng một dịch vụ Web có thật sự khó hay không? Nội dung chương này sẽ trả lời phần nào các thắc mắt đó của các bạn
1.1 KHÁI NIỆM
Dịch vụ Web là một tài nguyên phần mềm được thiết kế để hỗ trợ khả năng tương tác giữa các ứng dụng trên các máy tính khác nhau thông qua mạng Internet, giao diện chung và sự gắn kết của nó được mô tả bằng XML Như vậy Web Services
là một chuẩn mới để xây dựng và phát triển ứng dụng phân tán, có khả năng làm việc trên mọi hệ điều hành, mở rộng khả năng phối hợp giữa các ứng dụng, có thể tái sử dụng, tăng cường sự giao tiếp giữa Client và Server thông qua môi trường Web
Dịch vụ Web được coi là một công nghệ mang đến cuộc cách mạng trong cách thức hoạt động của các dịch vụ B2B (Business to Business) và B2C (Business to
Trang 15theo chuẩn trong việc truy nhập đối với hệ thống đóng gói và hệ thống kế thừa Các phần mềm được viết bởi những ngôn ngữ lập trình khác nhau và chạy trên những nền tảng khác nhau có thể sử dụng dịch vụ Web để chuyển đổi dữ liệu thông qua mạng Internet theo cách giao tiếp tương tự bên trong một máy tính Tuy nhiên, công nghệ xây dựng dịch vụ Web không nhất thiết phải là các công nghệ mới, nó có thể kết hợp với các công nghệ đã có như XML, SOAP, WS L, U I… Với sự phát triển và lớn mạnh của Internet, dịch vụ Web thật sự là một công nghệ đáng được quan tâm để giảm chi ph và độ phức tạp trong tích hợp và phát triển hệ thống
Trước hết, có thể nói rằng ứng dụng cơ bản của Dịch vụ Web là tích hợp các hệ thống và là một trong những hoạt động chính khi phát triển hệ thống Trong hệ thống này, các ứng dụng cần được tích hợp với cơ sở dữ liệu (CSDL) và các ứng dụng khác, người sử dụng sẽ giao tiếp với CS L để tiến hành phân tích và lấy dữ liệu Trong thời gian gần đây, việc phát triển mạnh mẽ của thương mại điện tử và 2 cũng đ i h i các hệ thống phải có khả năng t ch hợp với CSDL của các đối tác kinh doanh (nghĩa là tương tác với hệ thống bên ngoài - bên cạnh tương tác với các thành phần bên trong của hệ thống trong doanh nghiệp)
1.2 ĐẶC ĐIỂM
Web service độc lập vì nó không đ i h i các tiến trình ở phía client phải cài đặt bất cứ một thành phần nào Vì vậy WS cho phép client và server tương tác được với nhau ngay cả trong những môi trường khác nhau
Phần lớn k thuật của dịch vụ Web được xây dựng dựa trên nền tảng những công nghệ đã được chấp nhận và mã nguồn mở (Những chuẩn này là XML, SOAP, WS L và U I), vì vậy chúng độc lập và vận hành được với nhau
Một Dịch vụ Web bao gồm có nhiều module Các module này có thể được công
bố chia sẻ và tích hợp vào khi sử dụng
Dịch vụ Web cung cấp khả năng hoạt động rộng lớn với các ứng dụng phần mềm khác nhau, chạy trên những nền tảng khác nhau Sử dụng các giao thức và chuẩn mở, giao thức và định dạng dữ liệu dựa trên văn bản (text), giúp các lập trình viên dễ dàng hiểu được
Trang 16 Nâng cao khả năng tái sử dụng, thúc đẩy đầu tư các hệ thống phần mềm đã tồn tại bằng cách cho phép các tiến trình chức năng nghiệp vụ đóng gói trong giao diện dịch vụ Web Tạo mối quan hệ tương tác lẫn nhau và mềm dẻo giữa các thành phần trong hệ thống, dễ dàng cho việc phát triển các ứng dụng phân tán Với những đặc điểm đã phân t ch trên, có thể nói rằng ngày nay dịch vụ Web đang rất phát triển Những lĩnh vực trong cuộc sống có thể áp dụng và tích hợp dịch vụ Web là khá rộng lớn, như: dịch vụ chọn lọc và phân loại tin tức (hệ thống thư viện có kết nối đến web portal để tìm kiếm các thông tin cần thiết); ứng dụng cho các dịch vụ
du lịch (cung cấp giá vé, thông tin về địa điểm…), các đại lý bán hàng qua mạng, thông tin thương mại như giá cả, tỷ giá hối đoái, đấu giá qua mạng hay dịch vụ giao dịch trực tuyến…
Ngoài những ưu điểm vừa nêu thì WS c n có nhược điểm lớn đó là độ an toàn bảo mật Sẽ có những thiệt hại lớn xảy ra vào khoản thời gian chết của dịch vụ Web, hoặc có thể lỗi nếu một máy khách không được nâng cấp dịch vụ hoặc thiếu các giao thức cho việc vận hành Và một nhược điểm lớn nữa đó là có quá nhiều chuẩn cho dịch vụ Web khiến người dùng khó nắm bắt
1.3 KIẾN TRÚC
Web services là một tập các chuẩn đặc tả mở rộng khả năng của các chuẩn có sẵn như XML, URL và HTTP nhằm cung cấp chuẩn truyền thông giữa các hệ thống với nhau Web services là những thành phần thực thi một số xử lý nghiệp vụ thông qua những dịch vụ và cung cấp những dịch vụ qua mạng, những dịch vụ này có thể được triệu gọi bởi các dịch vụ client bằng cách sử dụng giao thức SOAP trên HTTP Web services sử dụng XML, một ngôn ngữ độc lập trong việc biểu diễn dữ liệu, làm ngôn ngữ trao đổi thông tin Bởi vậy khi được kết hợp với nhau, khả năng t ch hợp phần mềm và đa kết nối giữa những mô hình WS sẽ đảm bảo hoạt động tốt Thêm vào đó, các chuẩn Web services mới còn hỗ trợ các t nh năng cao cấp như hỗ trợ giao dịch, bảo mật, quy trình nghiệp vụ…
Mô hình web services dạng đơn giản định nghĩa cách thức tương tác giữa
Trang 17vụ tìm kiếm các dịch vụ trong một UDDI Service Directory Chúng sẽ lấy thông tin
mô tả WSDL của các Web services cung cấp bởi Service Providers từ trước thông qua Service Directory Sau khi lấy được mô tả WSDL, bên yêu cầu dịch vụ kết nối đến nhà cung cấp dịch vụ bằng cách triệu gọi các dịch vụ thông qua giao thức SOAP Web services cơ bản bao gồm các khái niệm SOAP, WSDL và UDDI Chúng ta sẽ lần lượt phân tích trong các phần sau Cần lưu ý là các chuẩn trên có thể được kết hợp với nhau hoặc dùng độc lập tùy trường hợp cụ thể
Hình 2: Chồng giao thức dịch vụ Web
1.3.1 Tầ g v h yể (T s o )
Được dùng truyền thông điệp giữa các ứng dụng mạng giữa Máy cung cấp dịch
vụ (Web server) và máy sử dụng dịch vụ (Web client), như: dịch vụ World Wide WWW, E-mail, Bao gồm những giao thức như HTTP, SMTP, FTP, JSM và gần đây nhất là giao thức thay đổi khối mở rộng (Blocks Extensible Exchange Protocol- BEEP)
Web-1.3.2 Tầng giao thứ g á dịch vụ (Service Communication Protocol)
Với công nghệ chuẩn là SOAP SOAP là giao thức nằm giữa tầng vận chuyển
Trang 18từ xa thông qua một thông điệp XML Có thể ứng dụng yêu cầu thực thi method trên máy tính ở xa mà không cần quan tâm đến chi tiết về platform cũng như các phần
mềm trên máy t nh đó
1.3.3 Tầ g ô ả dị h vụ (Service Description)
Được sử dụng để miêu tả các giao diện chung cho một dịch vụ Web cụ thể
WS L thường được sử dụng cho mục đ ch này, nó là một ngôn ngữ mô tả giao tiếp và thực thi dựa trên XML Dịch vụ Web sẽ sử dụng ngôn ngữ này để truyền tham số và các loại dữ liệu cho các thao tác và chức năng mà dịch vụ Web cung cấp
được đối tượng nào cung cấp dịch vụ Hiện tại, UDDI (Universal Description, Discovery, and Integration) thường được sử dụng để thực hiện công việc này UDDI
định nghĩa một số thành phần cho biết các thông tin cho phép các client truy tìm và nhận những thông tin được yêu cầu khi sử dụng dịch vụ Web Ngoài ra nó c n có chức năng cho phép đăng ký dịch vụ để người dùng có thể gọi thực thi các hàm, các chức năng của web service hay nói cách khác một service cần phải được đăng ký để cho phép các client có thể gọi thực hiện
1.3.6 Các tầng còn lại
Ngoài ra, để các dịch vụ có tính an toàn, toàn v n và bảo mật thông tin, trong kiến trúc dịch vụ Web, còn có thêm các tầng Policy, Security, Transaction, Management
1.4 CẤU TRÚC WS
Trang 19 Service Provider: ùng WS L để mô tả dịch vụ mà mình có thể cung cấp cho Service Broker
Service roker: Lưu trữ thông tin về các service được cung cấp bởi các Service Provider Cung cấp chức năng tìm kiếm hỗ trợ Service Requester trong việc xác định Service Provider phù hợp Thành phần chính của Service Broker là UDDI
Service Requester: ùng WS L để đặc tả nhu cầu sử dụng (loại service, thời gian sử dụng, resource cần thiết, mức giá, ) và gởi cho Service Broker Bằng việc sử dụng UDDI và chức năng tìm kiếm của Service Broker, Service Requester có thể tìm thấy Service Provider thích hợp Ngay sau đó, giữa Service Requester và Service Provider thiết lập kênh giao tiếp sử dụng SOAP để thương lượng giá cả và các yếu tố khác trong việc sử dụng service
Hình 3: ác actor tham gia vào W
1.5 CÁC C NG CỤ XÂY DỰNG WS
1.5.1 XML (Extensible Markup Language)
XML do W3C phát triển, XML là một ngôn ngữ mô tả văn bản với cấu trúc do người sử dụng định nghĩa Về hình thức XML có ký pháp tựa như HTML nhưng không tuân theo một đặc tả quy ước như HTML Người sử dụng hay các chương trình
có thể quy ước định dạng các tag XML để giao tiếp với nhau Thông tin cần truyền tải
Trang 20được chứa trong các tag XML, ngoài ra không chứa bất cứ thông tin nào khác về cách
sử dụng hay hiển thị những thông tin ấy
Do WS là sự kết hợp của nhiều thành phần khác nhau, do đó web services sử dụng các t nh năng và đặc trưng của các thành phần này để giao tiếp với nhau Vì vậy XML là một công cụ chính yếu để giải quyết vấn đề này Từ kết quả này, các ứng dụng tích hợp vĩ mô tăng cường sử dụng XML Nhờ có khả năng tổng hợp này mà XML đã trở thành kiến trúc nền tảng cho việc xây dựng web service
1.5.2 WSDL (Web Services Description Language)
WS L định nghĩa một tài liệu XML mô tả giao diện của các dịch vụ web Tài liệu WS L này được sử dụng cho bên yêu cầu dich vụ (service requester) Bên yêu cầu dịch vụ sẽ sử dụng các thông tin về giao diện định nghĩa trong lược đồ WS L để triệu gọi (invoke) dịch vụ web
Một tài liệu WSDL mô tả một Web Service như một tập các đối tượng trừu tượng gọi là các “ports” và “endpoint” Một tài liệu WS L cũng định nghĩa bên trong
nó các phương thức của web service Các phương thức tương ứng với “operation” và
dữ liệu trao đổi tương ứng với “message” Một tập các phương thức liên quan được nhóm lại vào trong một “portType” Một ràng buộc kết nối (binding) chỉ định một giao thức mạng và đặc tả định dạng dữ liệu cho một portType cụ thể Kế đến một port được định nghĩa bằng cách kết hợp một địa chỉ mạng với một binding Nếu một client có được một tài liệu WSDL và tìm thấy binding và địa chỉ cho mỗi port, nó có thể gọi các phương thức của dịch vụ theo đúng giao thức và định dạng dữ liệu đã đặc tả
Một WS L hợp lệ gồm có hai phần :
1 Phần giao diện mô tả giao diện và giao thức kết nối
2 Phần thi hành mô tả thông tin để truy xuất service
Cả 2 phần trên sẽ được lưu trong 2 tập tin XML, bao gồm:
- Tập tin giao diện service (cho phần 1)
- Tập tin thi hành service (cho phần 2)
Trang 21Hình 4: u trúc W
1.5.3 UDDI (Universal Description , Discovery and Intergration)
Về cơ bản Universal Description, Discovery, and Intergration (UDDI) là một tập các quy tắc đăng ký và tìm kiếm thông tin các Web Service Nó đóng vai tr như service broker cho phép người sử dụng dịch vụ tìm đúng nhà cung cấp dịch vụ cần tìm
Muốn sử dụng đến các dịch vụ của UDDI, bản thân UDDI cung cấp một tập hàm API dưới dạng SOAP Web Service Tập API được chia làm hai phần: Inquiry API dùng truy vấn và Publisher’s API dùng đăng ký Phần API dùng để truy vấn bao gồm hai phần con: Một phần dùng để tạo ra các chương trình cho phép tìm kiếm và duyệt thông tin trên một UDDI registry, phần còn lại dùng để xử lý lỗi triệu gọi
Trang 22Thành phần xử lý chính là bộ đăng ký U I, đó là một file XML dùng để mô
tả một thực thể kinh doanh (business entity) kèm theo các Web service đi cùng Sử dụng các dịch vụ của UDDI, các doanh nghiệp đăng ký thông tin về những Web service mà họ định cung cấp Thông tin này đuợc thêm vào UDDI registry thông qua Web site hoặc sử dụng các công cụ lập trình sử dụng các dịch vụ theo đúng đặc tả
U I programmer’s API
Lược đồ XML U I định nghĩa bốn loại thông tin cơ bản để kết nối đến Web service
Hình 5: Mô hình UDDI
1.5.4 SOAP (Simple Object Accesss Protocol)
Đến đây chúng ta đã hiểu được web services là như thế nào, nó được công bố
và truy xuất ở đâu Nhưng vẫn còn một vấn đề khá quan trọng đó là: Làm thế nào chúng ta truy xuất dịch vụ khi tìm thấy? Câu trả lời là web servicves có thể truy xuất bằng một giao thức là Simple Object Access Protocol – SOAP Nói cách khác chúng ta
có thể truy xuất đến UDDI registry bằng các lệnh gọi hoàn toàn theo kiểu SOAP
SOAP là một giao thức giao tiếp có cấu trúc như XML và mã hóa thành định dạng chung cho các ứng dụng trao đổi với nhau tưởng bắt đầu từ Microsoft và phần
Trang 23ưu điểm vuợt trội hơn bản SOAP 1.1 SOAP được xem như là cấu trúc xương sống của các ứng dụng phân tán xây dựng từ nhiều ngôn ngữ, hệ điều hành khác nhau
SOAP là một đặc tả việc sử dụng các tài liệu XML theo dạng các thông điệp Bản thân SOAP không định ra các ngữ nghĩa ứng dụng hoặc cách cài đặt chi tiết SOAP cung cấp một cơ chế đơn giản và gọn nh cho việc trao đổi thông tin có cấu trúc
và định dạng giữa các thành phần trong một môi trường phân tán sử dụng XML SOAP được thiết kế dựa trên những chuẩn nhằm giảm chi phí tích hợp các hệ thống phân tán xây dựng trên nhiều nền tảng khác nhau ở mức càng thấp càng tốt Đặc tả về SOAP định nghĩa một mô hình trao đổi dữ liệu dựa trên 3 khái niệm cơ bản: Các thông điệp là các tài liệu XML, chúng được truyền đi từ bên gửi đến bên nhận, bên nhận có thể chuyển tiếp dữ liệu đến nơi khác
Khái niệm cơ bản nhất của mô hình SOAP là việc sử dụng các tài liệu XML như những thông điệp trao đổi Điều này có nhiều ưu điểm hơn các giao thức truyền
dữ liệu khác Các thông điệp XML có thể được tổng hợp và đọc với một bộ soạn thảo text đơn giản, ta có thể làm việc với XML trên hầu hết mọi nền tảng
Tóm lại SOAP, WSDL và UDDI có thể kết hợp với nhau như sau :
i Nhà cung c p Web Service mô tả Web Service trong một tài liệu WSDL
và đăng ký nó lên một UDDI bằng cách sử dụng Publisher’s API
ii Một người sử dụng dịch vụ U I Inquiry API để tìm thông tin về nhà cung c p dịch vụ thích hợp Nếu có, nó sẽ tìm kiếm tiếp tModel rồi từ đó
l y ra tài liệu mô tả WSDL
iii Một yêu cầu dạng OAP được tạo ra dựa trên tài liệu mô tả WSDL
iv Yêu cầu SOAP trên sẽ được gửi đến nhà cung c p dịch vụ và được xử lý
1.6 QUI TRÌNH XÂY DỰNG WS
Để xây dựng một dịch vụ Web, ta cần hiểu được những việc phải làm và nên bắt đầu từ đâu Có 3 cách tiếp cận chủ yếu để xây dựng nên một dịch vụ Web, có thể từ một ứng dụng đã có (bottom-up); từ một định nghĩa dịch vụ, WS L để phát sinh một ứng dụng mới (top-down) hoặc có thể từ một nhóm các dịch vụ Web hiện có, kết hợp lại với nhau để tạo nên các chức năng mới hoặc mở rộng thêm chức năng Những
Trang 24hướng tiếp cận này dựa trên những gì mà chúng ta đã có, tùy thuộc vào yêu cầu của hệ thống, trong đó tối đa việc sử dụng lại các chức năng, các thành phần, môđun đã được xây dựng
Có 4 giai đoạn ch nh để xây dựng một dịch vụ Web là: xây dựng, triển khai, tiến hành và quản lý
1.6.1 Gi i oạ xây dự g
Bao gồm phát triển và chạy thử ứng dụng dịch vụ Web, xây dựng các chức năng và định nghĩa dịch vụ (WS L) Thường sử dụng 2 phương pháp Red-path-solod
và Blue-path-dashed Với Red-path-solod chúng ta sẽ xây dựng một dịch vụ Web mới
từ trạng thái ban đầu hoặc với một dịch vụ đã có sẵn Từ đó, xây dựng định nghĩa service (WS L) với các đối tượng, hàm chức năng mà chúng ta mong muốn Nếu theo cách Blue-path-dashed, dịch vụ Web sẽ được xây dựng từ đầu hoặc từ một định nghĩa dịch vụ WS L Sử dụng WS L này, xây dựng hoặc sửa đổi lại mã để thực hiện các yêu cầu mong muốn trong dịch vụ Web
1.6.2 Gi i oạ iể kh i
Công bố định nghĩa dịch vụ, xây dựng WS L và triển khai mã thực thi của dịch
vụ Web Triển khai dịch vụ Web tới một ứng dụng ph a server (SOAP server), sau đó
sẽ công bố dịch vụ Web trên mạng Internet để các client có thể nhìn thấy Sử dụng
U I registry để công bố lên mạng
1.6.3 Gi i oạ iế h h
Tìm kiếm và gọi thực thi dịch vụ Web bởi những người dùng muốn sử dụng dịch vụ Client nhận file WS L và từ đó xây dựng SOAP client để có thể kết nối với SOAP server
Trang 251 Định nghĩa và xây dựng các chức năng, các dịch vụ mà dịch vụ sẽ cung cấp
2 Tạo WS L cho dịch vụ
3 Xây dựng SOAP server
4 Đăng ký WS L với U I registry để cho phép các client có thể tìm thấy và truy xuất
5 Client nhận file WS L và từ đó xây dựng SOAP client để có thể kết nối với SOAP server
6 Xây dựng ứng dụng ph a client (chẳng hạn sử dụng Java) và sau đó gọi thực hiện dịch vụ thông qua việc kết nối tới SOAP server
Lựa chọn một ngôn ngữ, xây dựng các tiến trình nghiệp vụ và ta bắt đầu tạo nên một dịch vụ Web như ý muốn Sau đó là cung cấp dịch vụ Web này trên Internet
Tổng kết chương:
Như vậy ta th y rằng sự phát triển và ứng dụng của Web service hiện nay và cả trong tương lai là một xu thế t t yếu Và để xây dựng một dịch vụ Web cũng thật sự không khó khăn như ban đầu chúng ta nghĩ Tuy nhiên, có phải chỉ cần xây dựng xong một Web service và đóng gói thì có thể đưa ra sử dụng được hay chưa? Câu trả lời là
có, tuy nhiên như vậy là chưa đủ, còn một v n đề lơn hơn nữa đó là làm sao cho dịch
vụ Web mà chúng ta đưa ra sử dụng là an toàn?Vậy thế nào là an toàn dịch vụ Web, ta
sẽ tìm hiểu ở chương tiếp theo
Trang 26CHƯƠNG : ĐẢM BẢO AN TOÀN CHO CÁC DỊCH VỤ WEB
Giới thiệu:
Như ở chương 1 ta đã biết dịch vụ Web liên kết và tương tác với các ứng dụng qua Internet, chính v vậy bảo mật là một v n đề được quan tâm khi các c ng ty tiến tới kết hợp ứng dụng với một dịch vụ Web Việc đảm bảo an toàn cho dịch vụ Web là một v n
đề quan trọng, đặc biệt đối với những dịch vụ liên quan đến trao đổi tiền tệ, th ng tin
từ thị trường chứng khoán hay dịch vụ bán hàng qua mạng (liên quan đến trả tiền bằng tài khoản và có yêu cầu th ng tin cá nhân của người dùng) Vậy thế nào là m t
an toàn dịch vụ Web, chúng ta sẽ tìm hiểu qua các khái niệm sau:
Trong hệ thống thông tin truyền thống, vấn đề an toàn được xem xét trên 4 kh a sau: Tin cậy (Confidentiality), Toàn v n (Integrity), Sẵn dùng (Avaibility) và Khả năng xác thực (Authentication) Tuy nhiên, với phần mềm hướng dịch vụ nói chung và dịch vụ web nói riêng yêu cầu về tính sẵn dùng là một yêu cầu rất quan trọng o đó người ta đã tách yêu cầu về tính sẵn dùng ra làm 1 tính chất độc lập và bổ sung yêu cầu Không thể phủ nhận (Non-Repudiation) vào khía cạnh an toàn của phần mềm hướng dịch vụ Đồng thời tách Đảm bảo t nh tin cậy ra thành 2 kh a cạnh độc lập là
T nh xác thực (Authentication) và T nh phân quyền (Authorization) Vậy khi xây dựng một WS đảm bảo yếu tố an toàn thì phải bảo vệ các thông tin và tài nguyên theo các thuộc t nh an toàn đã nêu:
2.1.1 T h xá hự (Authentication)
T nh xác thực là thuộc t nh dùng để chứng thực quyền truy cập của người dùng tham gia hệ thống và xác thực tài sản do người dùng sử dụng hệ thống Hệ thống chỉ cho phép chương trình thực hiện nếu đã xác thực người dùng là tin cậy Để xác minh
t nh xác thực người ta xem xét những tác động trên dữ liệu kiểm soát, như: xác minh
dữ liệu để đưa ra bằng chứng cho thấy các ràng buộc đã xảy ra, xác minh dữ liệu không thay đổi trước khi kết thúc bất kỳ hoạt động nào liên quan đến yêu cầu xác thực
Trang 27Hình 6: ác yêu cầu của thuộc tính ác thực
Hình 6 mô tả minh họa về yêu cầu của t nh xác thực, trong đó:
Cơ chế truyền dữ liệu tin cậy: sử dụng cơ chế truyền dữ liệu tin cậy cho
dữ liệu truyền đi
Cơ chế xác thực người dùng tin cậy: để xác minh đối tượng (con người, chương trình,…) tin cậy
Cơ chế ràng buộc người dùng tin cậy: để ràng buộc dữ liệu người dùng (xác nhận người dùng, mật khẩu hay các thông tin khác để xác nhận việc nhận dạng và các thông tin làm bằng chứng mà hệ thống cung cấp) cho môi trường thực hiện
ữ liệu kiểm soát: thiết lập giá trị tin cậy của dữ liệu kiểm soát để xác định cơ chế tin cậy có được thực hiện đúng hay không và cho thấy tình trạng dữ liệu bị ràng buộc
Việc xác thực được xem là không thành công nếu bất kỳ cơ chế nào trong các yêu cầu trên bị thất bại
Cơ chế ràng buộc người dùng tin cậy
ữ liệu kiểm soát (chỉ
bị thay đổi bởi các thành phần tin cậy)
T nh xác thực th a mãn
Trang 28Cơ chế xác thực tin cậy
Cơ chế tra cứu tin cậy
ữ liệu kiểm soát (chỉ
bị thay đổi bởi các thành phần tin cậy)
T nh phân quyền th a mãn
nào Như vậy thuộc t nh này đảm bảo sẽ có phát hiện khi thông tin bị thay đổi T nh phân quyền sẽ xác định người dùng nào có quyền tác động lên dữ liệu kiểm soát
Hình 7: ác yêu cầu của thuộc tính phân quyền
Các yêu cầu về t nh phân quyền được minh họa ở hình 7, trong đó:
Cơ chế xác thực tin cậy: Một cơ chế xác thực tin cậy luôn được sử dụng
để xác thực người dùng (bao gồm cả cơ chế truyền dữ liệu và xác thực tin cậy)
Cơ chế tra cứu tin cậy: Một cơ chế tra cứu tin cậy luôn được sử dụng để xác định người dùng được phân quyền để hoàn thành các yêu cầu quy định
ữ liệu kiểm soát: thiết lập giá trị tin cậy của dữ liệu kiểm soát để xác định cơ chế tin cậy có được thực hiện đúng hay không và xác định người dùng được phân quyền và phạm vi phân quyền
Nếu bất kỳ yêu cầu hoặc cơ chế nào thất bại thì t nh phần quyền sẽ không thành công
2.1.3 T h khô g hể hủ h ( h g h i b - Non-Repudiation)
Là thuộc t nh cam kết hệ thống phải có biện pháp giám sát, đảm bảo một đối tượng khi tham gia sử dụng tài sản thì không thể phủ nhận việc mình đã làm hoặc thay
Trang 29tham gia của mình trong giao dịch (thông thường để thực hiện thuộc t nh này ta sử dụng chữ ký điện tử) Để xác minh t nh không thể phủ nhận phải xem xét những tác động trên dữ liệu kiểm soát liên quan đến t nh không thể phủ nhận
Hình 8: ác yêu cầu của thuộc tính kh ng thể phủ nhận
Hình 8 mô tả minh họa về yêu cầu của t nh không thể phụ nhận trong mỗi dữ liệu truyền đi, trong đó:
Cơ chế phân quyền tin cậy luôn được dùng cho người gửi, người nhận và việc thay đổi hoặc truyền dữ liệu Yêu cầu này bao gồm yêu cầu truyền
dữ liệu tin cậy, xác thực người dùng tin cậy và phân quyền người dùng tin cậy
Cơ chế ràng buộc tin cậy được sử dụng để ràng buộc người gửi với dữ liệu được gửi và ràng buộc người nhận với dữ liệu được nhận
Cơ chế kiểm tra và truy tìm tin cậy dùng để truy xuất xứ nguồn gốc và kiểm tra dữ liệu Hay nói cách khác là việc xác thực việc truyền dữ liệu
là không thể bác b sau này (mỗi dữ liệu truyền đi được xác thực và nhận dạng người gửi và tương tự đối với dữ liệu nhận)
Cơ chế phân
quyền tin cậy
Cơ chế ràng buộc tin cậy
Cơ chế kiểm tra và truy tìm tin cậy
ữ liệu kiểm soát (chỉ
bị thay đổi bởi các thành phần tin cậy)
T nh không thể phủ nhận th a mãn
Trang 30Cơ chế chống chối b tin cậy
Cơ chế truy cập
dữ liệu tin cậy
ữ liệu kiểm soát (chỉ
bị thay đổi bởi các thành phần tin cậy)
T nh b mật th a mãn
ữ liệu kiểm soát: thiết lập giá trị tin cậy của dữ liệu kiểm soát để xác định cơ chế tin cậy có được thực hiện một cách ch nh xác hay không Việc t nh không thể phủ nhận xem là không thành công nếu bất kỳ yêu cầu nào nêu trên bị thất bại
Hình 9: ác yêu cầu của thuộc tính bí mật
Hình 9 mô tả minh họa về yêu cầu của t nh không thể phụ nhận trong mỗi dữ liệu truyền đi, trong đó:
Cơ chế chống chối b tin cậy luôn được sử dụng để xử lý các yêu cầu truy cập dữ liệu và truyền dữ liệu b mật Yêu cầu này bao gồm yêu cầu truyền dữ liệu tin cậy, xác thực người dùng và các quy trình tin cậy, phân quyền người dùng và quy trình tin cậy cho các phạm vi dữ liệu cụ thể
Cơ chế truy cập dữ liệu tin cậy luôn được sử dụng để đảm bảo dữ liệu không thể bị truy cập từ bên ngoài hệ thống
Trang 31 ữ liệu kiểm soát: thiết lập giá trị tin cậy của dữ liệu kiểm soát để xác định cơ chế tin cậy có được thực hiện ch nh xác hay không
Nếu bất kỳ yêu cầu hoặc cơ chế nào thất bại thì yêu cầu truy cập dữ liệu b mật hoặc truyền dữ liệu b mật xem như không thành công
2.1.5 T h o vẹ (Integrity)
Tài sản chỉ bị thay đổi nếu người dùng có đủ quyền, các thay đổi này phải được phát hiện, theo gi i và phải được giới hạn trong phạm vi cụ thể T nh toàn v n không phải là một nhiệm vụ mà nó là thuộc t nh của đối tượng Để xác minh t nh toàn v n phải xem xét hiệu ứng trên dữ liệu kiểm soát liên quan đến t nh toàn v n, đó là: phát hiện tất cả các thay đổi trên dữ liệu và đảm bảo tất cả các thay đổi đó phải được xác định trước
Hình 10: ác yêu cầu của thuộc tính toàn v n
Hình 10 mô tả minh họa về yêu cầu của t nh toàn v n, trong đó:
Cơ chế chống chối b tin cậy: tồn tại một ch nh sách bảo mật để mô tả phạm vi các thay đổi cho phép Nếu ch nh sách bảo mật dữ liệu phải thay đổi để loại b bất kỳ một phần tử từ tập hợp cho phép thì t nh toàn v n của dữ liệu thất bại
Cơ chế thay đổi dữ liệu tin cậy: được sử dụng cho các thay đổi dữ liệu và thay đổi ch nh sách để đảm bảo rằng tất cả những thay đổi trong ch nh
Cơ chế chống chối b tin cậy
Cơ chế thay đổi
dữ liệu tincậy
ữ liệu kiểm soát (chỉ
bị thay đổi bởi các thành phần tin cậy)
T nh toàn v n th a mãn
Trang 32sách an ninh và dữ liệu được thực hiện bằng cách sử dụng cơ chế chống không thể phủ nhận Yêu cầu này bao gồm truyền dữ liệu tin cậy, xác thực người dùng và các quy trình tin cậy, ủy quyền người dùng và quy trình tin cậy cho các phạm vi dữ liệu cụ thể, không thể phủ nhận tin cậy cho các thay đổi dữ liệu
ữ liệu kiểm soát: thiết lập giá trị tin cậy của dữ liệu kiểm soát để xác định cơ chế tin cậy có được thực hiện ch nh xác hay giá trị của dữ liệu kiểm soát được thiết lập bởi bất kỳ cơ chế tin cậy
Việc t nh toàn v n của dữ liệu được xem là không thành công nếu bất kỳ cơ chế nào trong các yêu cầu trên bị thất bại
2.2 MỘT S LỖ HỔNG ỨNG DỤNG WEB PHỔ BIẾN
Gần đây, các dịch vụ web đã thu hút được ngày càng nhiều mối quan tâm chung
từ ph a cộng đồng Sự xuất hiện của cách thức xây dựng các ứng dụng web kiểu mới hứa h n khả năng cho phép các tổ chức trao đổi thông tin với các đối tác và khách hàng ngay trong các hệ thống của ch nh họ Nhưng trên thực tế, người dùng thường hiểu sai về bảo mật và nhầm tưởng rằng, họ sẽ được an toàn trước các cuộc tấn công
“tiêm mã độc” nếu các ứng dụng của họ sử dụng giao thức SSL (Secure Sockets Layer)
Chuyên gia phân t ch cao cấp của hãng nghiên cứu thị trường Zap Think, Jason loomberg đã trả lời trên tờ -Commerce Times: “Các dịch vụ web sẽ tạo ra các lổ hổng trên các phương pháp bảo mật truyền thống” Vậy các lổ h ng đó là gì và xuất phát từ đâu
Với các dịch vụ web, dữ liệu sẽ tới từ rất nhiều điểm ra vào khác nhau Kết quả
là rất nhiều ứng dụng thường đi men theo các checkpoint (điểm kiểm tra) khác nhau V dụ, các dữ liệu HTTP thường được truyền thông qua một cổng 80 của thiết bị mạng, nhờ đó tránh được sự kiểm tra của tường lửa Vì thế, các hacker
có thể lợi dụng điểm vào đó để qua mặt các phương tiện bảo mật và truy cập được vào mạng của một công ty
Trang 33 o thiết kế của các ứng dụng có những điểm khác biệt nên những kiểu tấn công mới hoàn toàn có thể xảy ra đối với các dịch vụ web, v dụ như kiểu tấn công
“tiêm mã độc” (Injection) Những kiểu tấn công như vậy có rất nhiều, nhưng chúng đều hoạt động theo một nguyên tắc chung: hacker ký sinh mã độc lên mã tốt thông qua một trường đầu vào trong ứng dụng Kiểu hack này đã trở nên phổ biến đối với các ứng dụng hệ thống quản lý cơ sở dữ liệu dựa vào ngôn ngữ truy vấn cấu trúc (SQL - Structured Query Language) Ngoài ra, ngôn ngữ đánh dấu mở rộng (XML - Extensible Markup Language) và Giao thức truy cập thư mục đơn giản (L AP - Lightweight Directory Access Protocol) [ref], thường được sử dụng với các ứng dụng dịch vụ Web, có thể dễ dàng bị tiêm mã độc V
dụ, nếu một ứng dụng XML dành cho thương mại điện tử không thể xác nhận điểm đến của thông tin nó gửi đi, một hacker có thể lấy được các thông tin cá nhân của khách hàng, như số tài khoản hay thông tin thẻ t n dụng Với một
“phát” tiêm mã độc L AP, kẻ tấn công có thể truy cập vào một thư mục của công ty và truy cập thông tin địa chỉ khách hàng, như mail và địa chỉ nhà riêng, khi đó mọi việc sẽ trở nên tồi tệ với những thông tin cá nhân mà hacker
đã có được
Theo thống kê gần đây của tổ chức uy t n Gartner Group, đến 75% các cuộc tấn công thành công hiện nay dựa trên các lỗ hổng trong ứng dụng web Đa số ứng dụng web có thể bị những lỗi mà các phương cách ph ng chống mạng thông thường không bảo vệ được Lỗi và lỗ hổng trong mã nguồn của ứng dụng web có thể gây ra những hậu quả nghiêm trọng như lộ dữ liệu nhạy cảm, gây tổn thương đến toàn hệ thống hạ tầng CNTT Vì vậy việc xác định các lỗ h ng trong các ứng dụng web để có thể đưa ra các biện pháp bảo mật kịp thời là công việc cấp thiết hiện nay
ưới đây xin giới thiệu sơ lược về các điểm yếu trong các ứng dụng web hiện nay:
2.2.1 Dữ iệ ầ v o khô g kiể tính h ệ
Thông tin và dữ liệu từ các truy cập HTTP không được kiểm tra trước khi được
sử dụng bởi ứng dụng web Tin tặc có thể tận dụng những lỗi này nhằm tấn công các
Trang 34lớp ứng dụng ph a sau thông qua ứng dụng web: Ứng dụng Web sử dụng dữ liệu đầu vào trong các truy cập HTTP (hoặc trong các tập tin) nhằm xác định kết quả phản hồi Tin tặc có thể sửa đổi bất kỳ phần nào của một truy xuất HTTP, bao gồm URL, querystring, headers, cookies, form fields, và thậm ch field ẩn (hidden fields), nhằm vượt qua các cơ chế bảo mật Các tấn công phổ biến dạng này bao gồm: Chạy lệnh hệ thống tùy chọn; Cross site scripting; Lỗi tràn bộ đệm; Tấn công Format string; SQL injection; Cookie poisoning; Sửa đổi field ẩn
V dụ theo hình 11 mô tả sơ đồ cách thức phổ biến của hacker hiện nay sử dụng
để tấn công ứng dụng web Trước tiên, hacker thiết lập một proxy đứng giữa trình duyệt và máy chủ ứng dụng web Proxy này có khả năng chặn các gói dữ liệu trước khi chuyển đến máy chủ, do đó cho phép hacker sửa đổi dữ liệu truy cập và chèn các
mã tấn công trước khi gửi đến ứng dụng web
Hình 11: ơ đồ mô tả cách t n công bằng cách sử dụng local pro y để thay đổi
tham số
2.2.2 Lỗi kiể soá y g ồ i g y
Những giới hạn về quyền truy cập tài nguyên của người sử dụng không được thi hành đúng Tin tặc có thể tận dụng những lỗi này nhằm truy cập vào tài khoản của người khác, xem các tập tin nhạy cảm, hoặc thi hành những chức năng không cho phép: Kiểm soát truy cập tài nguyên (authorization), là cơ chế mà ứng dụng web cho phép truy cập đến nội dung, t nh năng ứng dụng cho một số người sử dụng và từ chối truy cập cho một số người sử dụng khác Những kiểm tra này được thực hiện sau quá trình xác thực, và quản lý các quyền truy cập mà người sử dụng được phép Kiểm soát
Trang 35khó được thi hành đầy đủ Một mô hình quản lý truy cập tài nguyên cho ứng dụng web cần được thiết kế theo sát các nội dung và hàm chức năng của một web site cung cấp
Ví dụ về cách tấn cộng dạng này là tấn công vào trang web portal của một công
ty cung cấp dịch vụ trực tuyến cho các thuê bao điện thoại di động Thường thì loại web portal này cung cấp cho người sở hữu thuê bao một tài khoản trên trang web và cung cấp các dịch vụ sau:
Cho phép mỗi người sử dụng được phép gửi 5 tin nhắn không tốn tiền đến các thuê bao cùng mạng
Cho phép người sử dụng được upload sổ địa chỉ cá nhân lên trang web và download khi có nhu cầu
Cho phép người sử dụng được xem lịch sử cuộc gọi của máy thuê bao
Nếu cơ chế kiểm soát quyền sử dụng dịch vụ trên bị lỗi, hacker có thể có các tấn công sau:
Sửa đổi các tham số về số lượng giới hạn tin nhắn và có thể gửi hơn 5 tin nhắn cho phép không tốn tiền mỗi ngày
Truy cập vào sổ địa chỉ của thuê bao khác
Xem được lịch sử cuộc gọi của các thuê bao khác
2.2.3 Lỗi i q ế q á ì h q ả ý xá hực v hi y
Quá trình xác thực và quản lý phiên truy cập không được bảo vệ tốt có thể dẫn đến việc thông tin tài khoản bị mất cắp: Quản lý xác thực và phiên truy cập bao gồm tất cả các yếu tố quản lý xác thực người sử dụng và các phiên truy cập Xác thực người dùng là một yếu tố quan trọng trong quy trình này, nhưng ngay cả những cơ chế xác thực mạnh nhất vẫn có thể bị mắc những lỗi liên quan đến các chức năng quản lý xác thực, bao gồm thay đổi password, quên password, nhớ password ở trình duyệt, cập nhật tài khoản và những hàm chức năng khác
Xác thực người dùng trên ứng dụng web thường bao gồm sử dụng một username và password Những phương pháp xác thực khác mạnh hơn bao gồm các giải pháp phần cứng hoặc mềm dựa trên các token mã hóa hoặc dùng phương pháp sinh trắc học (biometrics) Tuy nhiên những phương pháp này có phần hạn chế do giá
Trang 36thành cao Một số lượng lớn lỗi ứng dụng trong các hàm quản lý tài khoản và phiên truy cập có thể dẫn đến mối nguy cơ lộ tài kh an người sử dụng và thậm chí tài kh an của người quản trị
Ứng dụng web thường phải theo dõi và duy trì phiên truy cập của người dùng nhằm phân biệt các truy cập từ người dùng khác nhau Giao thức HTTP không cung cấp khả năng này và do đó ứng dụng web phải tự tạo cơ chế này Thường thì, môi trường phát triển ứng dụng cung cấp cơ chế quản lý phiên truy cập (thường là dưới hình thức cookie token), tuy nhiên, đa số các nhà lập trình nghiêng về phát triển cơ chế riêng của họ Trong cả hai trường hợp, nếu token quản lý phiên truy cập không được bảo vệ, tin tặc có thể ăn cắp token truy cập tài khoản của người khác
2.2.4 Lỗi bộ ệ
Tin tặc sử dụng lỗi tràn bộ đệm nhằm ảnh hưởng đến dòng lệnh thực thi của ứng dụng web: Bằng cách gửi một đoạn mã được thiết kế đặc biệt đến ứng dụng, tin tặc có thể làm cho ứng dụng web thi hành bất kỳ đoạn mã nào, điều này tương đương với việc chiếm quyền làm chủ máy server Mặc dù là một lỗi phổ biến, lỗi tràn bộ đệm
là loại lỗi rất khó được phát hiện và ngay cả khi đã được phát hiện, lỗi này rất khó được lợi dụng do tin tặc cần một trình độ rất cao để có thể viết đoạn mã khai thác
Hình 12 là sơ đồ mô tả một cuộc tấn công tràn bộ đệm, hacker gửi đến ứng dụng web một truy cập với gói dữ liệu có độ dài vượt mức cho phép mà hàm xử lý của ứng dụng có thể xử lý Thông thường, dữ liệu đầu vào được lưu trữ trên bộ nhớ đệm trước khi xử lý, dữ liệu vượt quá độ dài đăng ký sẽ được chèn lên các dữ liệu quan trọng khác trong bộ đệm, dẫn đến khả năng thi hành mã tùy ý theo yêu cầu của hacker
Trang 37Hình 12: ơ đồ mô tả cách t n công dựa vào lỗi tràn vùng đệm
2.2.5 Lỗi liên trang (Cross Site Scripting - XSS)
Lỗi XSS xảy ra khi một ứng dụng web bị lợi dụng để gửi dữ liệu xấu (thường là đoạn mã script) đến trình duyệt của người sử dụng Những lỗ hổng này rất phổ biến và xảy ra trong bất cứ phần nào của ứng dụng web có sử dụng dữ liệu từ người dùng trong các giá trị phản hồi mà không kiểm tra tính hợp lệ Một tin tặc có thể sử dụng lỗ hổng này để gửi các đoạn mã đến người dùng Trình duyệt trong máy người dùng không thể biết được nên tin hay không tin đoạn mã nào, và sẽ thi hành đoạn script này Bởi vì trình duyệt tin rằng đoạn mã đến từ một nguồn tin tưởng, đoạn mã script có thể truy cập đến cookies, session tokens, hoặc bất kỳ thông tin nhạy cảm nào được lưu lại trong trình duyệt có liên quan đến trang web đang truy cập Những đoạn mã này còn
có thể sửa đổi nội dung trang web
Hậu quả của tấn công dạng XSS có thể rất nguy hiểm, bao gồm lộ session cookie, cho phép tin tặc chiếm quyền sở hữa tài khoản Những hậu quả khác bao gồm:
lộ các tập tin của người dùng, cài đặt các chương trình trojan, di chuyển người sử dụng đến trang web khác, sửa đổi nội dung trang web nhằm đánh lừa người dùng
Hình 13 là sơ đồ mô tả một ví dụ tấn công dạng cross site scripting với hậu quả
là khách hàng bị lừa truy cập vào trang web giả mạo nhằm ăn cắp tài khoản khách hàng:
Hacker phát hiện lỗ hổng cross-site-scripting trên trang web của một ngân hàng thật
Trang 38http://www.bank-that.com Hacker tạo một trang web trông giống ngân hàng thật tại địa chỉ http://www.bank-gia.com Sau đó tin tặc soạn một email giả từ nhân viên của ngân hàng gửi đến cho một khách hàng Trong email, hacker soạn một nội dung yêu cầu khách hàng bấm vào một link trông giống như một link truy cập vào ngân hàng thật http://www.bank-that.com/dichvu.asp?url=http://www.bank-gia.com Khách hàng nhận được email, tưởng là email từ phía ngân hàng thật, nên bấm vào link Khi bấm vào link, thay vì truy cập vào ngân hàng thật, trình duyệt của khách hàng được chuyển
tự động đến trang web ngân hàng giả do hacker tạo sẵn trông giống như ngân hàng thật
http://bank-gia.com Khách hàng nhập thông tin đăng ký vào trang ngân hàng giả và thông tin này được chuyển đến hacker
Trang 392.2.6 Ti ộ (Injection)
Ứng dụng web có thể sử dụng các dữ liệu đầu vào làm tham số cho các hàm gọi vào hệ thống Nếu tin tặc nhúng các mã nguy hiểm trong dữ liệu đầu vào, hệ thống có thể chạy các đoạn mã nguy hiểm này Những cuộc tấn công dạng này bao gồm các mã gọi hàm đến hệ điều hành, gọi các ứng dụng qua lệnh shell, và các hàm gọi đến cơ sở
dữ liệu (SQL injection) Những đoạn mã nguy hiểm được viết bằng perl, python và ngôn ngữ khác có thể được chuyển đến và thực thi bởi ứng dụng web, hệ điều hành hoặc các ứng dụng khác
Rất nhiều ứng dụng web sử dụng các hàm của hệ điều hành và các chương trình ngoài để thi hành các chức năng Sendmail là một trong những chương trình ngoài được sử dụng nhiều nhất Khi ứng dụng web sử dụng dữ liệu từ người dùng để tạo ra đoạn mã thực thi, dữ liệu từ người dùng cần được lọc k lưỡng Nếu không, tin tặc có thể kèm vào các ký tự đặc biệt, đoạn lệnh, và những thông tin xấu này có thể được chuyển đến hệ thống và các chương trình ngoài
Một trong những dạng phổ biến nhất của lỗi injection là lỗi “sql injection” Lỗi này xảy ra khi ứng dụng sử dụng những dữ liệu đầu vào không được kiểm tra làm tham số để xây dựng chuỗi lệnh SQL Bằng cách sử dụng những đoạn mã SQL đặc biệt, hacker có thể gây ra những hậu quả nghiêm trọng như: Vượt qua hệ thống xác thực login mà không cần sử dụng password hoặc username; Truy cập vào một phần hoặc tất cả các thông tin trong CSDL; Lấy được thông tin về cấu trúc của cơ sở dữ liệu; Sửa đổi hoặc xóa thông tin trong CSDL; Chạy các lệnh trong hệ điều hành trên máy chủ CSDL
2.2.7 Q y ì h q ả ý báo ỗi
Quy trình xử lý báo lỗi có thể gây ra nhiều vấn đề bảo mật cho một trang web Vấn đề thông thường nhất là khi các thông báo lỗi có chứa các thông tin nhạy cảm như stack traces, thông tin cơ sở dữ liệu, và các mã lỗi được thông báo cho người dùng Những lỗi này cung cấp các thông tin về hệ thống, ứng dụng ở mức độ thấp và thông tin này phải được bảo mật Sử dụng những thông tin này, hacker có thể dò tìm ra những lỗi khác của ứng dụng
Trang 40 Tên và phiên bản phầm mềm cơ sở dữ liệu
Tên cơ sở dữ liệu
vệ những thông tin này Mặc dù sử dụng các hàm mã hóa không khó cho các lập trình viên, tuy nhiên, lập trình viên vẫn thường mắc những lỗi cơ bản khi áp dụng vào ứng dụng web do không hiểu rõ hết các đặc điểm mã hóa Những lỗi thông thường bao gồm:
Không mã hóa dữ liệu quan trọng như khóa, certificates và mật khẩu