Luận văn Nghiên cứu bảo mật web services

phần giao tiếp với phần thực hiện dịch vụ. Điều này có thể làm bạn liên tưởng đến một công nghệ được đề cập nhiều gần đây: Dịch vụ web. Dịch vụ web cho phép truy cập thông qua định nghĩa giao thức-và-giao tiếp. SOA và dịch vụ web thoạt trông có vẻ giống nhau nhưng chúng không phải là một. Về cơ bản, SOA là kiến trúc phần mềm phát xuất từ định nghĩa giao tiếp và xây dựng toàn bộ mô hình ứng dụng như là mô hình các giao tiếp, hiện thực giao tiếp và phương thức gọi giao tiếp. Giao tiếp là trung tâm của toàn bộ triết lý kiến trúc này; thực ra, tên gọi ‘kiến trúc định hướng giao tiếp’ thích hợp hơn cho SOA. Dịch vụ và module phần mềm nghiệp vụ được truy cập thông qua giao tiếp, thường theo cách thức yêu cầu - đáp trả. Ngay cả với yêu cầu dịch vụ 1 chiều thì nó vẫn là yêu cầu trực tiếp có chủ đích từ một phần mềm này đến một phần mềm khác. Một tương tác định hướng dịch vụ luôn bao hàm một cặp đối tác: nguồn cung cấp dịch vụ và khách hàng sử dụng dịch vụ. [36] Định nghĩa cơ bản của dịch vụ web dựa trên một nền tảng khác: Tập hợp các công nghệ WSDL (Web Services Description Language), SOAP (Simple Object Access Protocol) và UDDI (Universal Description, Discovery ang Integration) [21], cho phép xây dựng các giải pháp lập trình cho vấn đề tích hợp ứng dụng và truyền thông điệp. Theo thời gian, các công nghệ này có thể hoàn thiện hay có thể được thay bằng công nghệ khác tốt hơn, hiệu quả hơn hay ổn định hơn. Rõ ràng, theo định nghĩa thì dịch vụ web là đặc tả công nghệ còn SOA là triết lý thiết kế phần mềm. Dịch vụ web đưa ra giải pháp kỹ thuật để thực hiện SOA, nhưng SOA cũng có thể thực hiện với các giải pháp kỹ thuật khác không phải dịch vụ web (và không phải tất cả dịch vụ web đều có kiến trúc SOA). Tuy vậy, SOA và dịch vụ web có mối quan hệ tương hỗ: sự phổ biến của dịch vụ web giúp thúc đẩy sự phát triển của SOA, và kiến trúc tốt của SOA sẽ giúp dịch vụ web thành công. SOA là một phương pháp thiết kế, trong khi dịch vụ Web chỉ là một công nghệ. SOA có thể được thực hiện qua công nghệ dịch vụ Web nhưng cũng có thể thực hiện thông qua các công nghệ khác. Kiến trúc SOA sử dụng dịch vụ Web như là một giải pháp chính để giải quyết vấn đề tích hợp nghiệp vụ giữa các hệ thống (bên cạnh giải pháp dùng công nghệ thông báo). Và đặc biêt trong quá trình internet hóa mọi dịch vụ hiên nay, thì triển khai dịch vụ bằng dịch vụ Web là điều “tất nhiên”. 3.4. Kết luận Công nghệ Web Service đã và đang được triển khai, ứ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, quân sự…và nó đã mang lại nhiều thành quả to lớn cho các tổ chức, doanh nghiệp, tập thể. Trong chương này, tôi đã đưa ra những kiến thức cơ bản về Web Service, các thành phần cấu thành nên một web service. Các đặc điểm của web service và mối quan hệ giữa kiến trúc hướng dịch vụ vào xây dựng web service. [37] CHƯƠNG 4 Các kỹ thuật đảm bảo an ninh Web Service Cùng với sự phát triển không ngừng của Web Service tạo nên những ảnh hưởng nhất định trong việc xây dựng các mô hình phân tán. Các công nghệ kiến trúc hướng đối tượng như DOA hay Java RMIT đang dần chuyển sang các kiến trúc hướng dịch vụ SOA với những công nghệ như SOAP, HTTP và XML. 4.1. Các vấn đề bảo mật cần quan tâm 4.1.1. Những hạn chế của tường lửa Các hệ thống tưởng lửa đều không giám sát chặt chẽ các gói tin được truyền tải dựa trên giao thức HTTP, nghĩa là, các yêu cầu truy cập đến Web Service thông qua nghi thức HTTP đều được các hệ thống tường lửa cho phép qua. Sự thiếu sót này có thể khiến cho máy chủ có nguy cơ bị những cuộc tấn công mà không thể biết trước. Trong thực tế, đã có những cuộc tấn công bằng cách thiết kế các gói tin SOAP qua mặt được hệ thống tường lửa và máy chủ để gây nên lỗi “Tràn vùng đệm” cho các ứng dụng bên trong. Thời gian gần đây, rất nhiều những sản phẩm tường lửa giám sát những gói tin chứa những dữ liệu dạn XML được xây dựng nhằm bảo vệ các web service trong việc kiểm soát các yêu cầu dạng SOAP. Tuy nhiên, tính hiệu quả của những sản phẩm này chưa đủ sức thuyết phục để các nhà quản trị chấp nhận sử dụng nó như một phần của thiết kế an ninh hệ thống. 4.1.2. Cơ chế bảo mật chưa được định nghĩa một các đầy đủ Hầu hết những chuẩn về bảo mật hiện nay đều chỉ tập trung vào việc đưa ra các định dạng bảo vệ dữ liệu trong quá trình trao đổi, mà không quan tâm đến việc xác định các nghi thức mà các bên cần thực hiện khi tương tác, như là việc chứng thực và kiểm tra quyền. 4.1.3. Các giải pháp bảo mật khó tích hợp với nhau Vì thiếu những chuẩn chung về việc chỉ ra nghi thức giao tiếp giữa những web service khiến cho các sản phẩm hỗ trợ cho vấn đề bảo mật của web service trên thị trường ngày nay không thể [38] hoàn toàn tích hợp với nhau, mặc dù các sản phẩm này đều được thiết kế dựa trên các chuẩn về bảo mật cho web service. 4.1.4. Bảo mật trong qui trình phối hợp hoạt động của các WS Khi số lượng các web ngày càng gia tăng, nhu cầu tái sử dụng lại các dịch vụ này, kết hợp chúng theo những qui trình xử lý khác nhau để đạt được những kết quả khác nhau đang giành được rất nhiều sự quan tâm. Và lúc này, rõ rang là ta phải giải quyết được vấn đề bảo mật trong mối quan hệ tương tác giữa các web service. 4.1.5. Bảo mật và vấn đề hiệu suất hoạt động Một hệ thống sử dụng cơ chế bảo mật khóa công cộng đòi hỏi phải thực hiện rất nhiều phép tính như là chứng nhận thông điệp, mã hóa và kiểm tra các giấy chứng nhận. Việc truyền gửi một thông điệp đã được chứng nhận sẽ chậm hơn rất nhiều lần so với việc truyền gửi một thông điệp thông thường. Và chắc chắn rằng, sẽ luôn luôn có một sự ràng buộc giữa mức độ bảo mật và hiệu suất hoạt động của hệ thống. Vấn đề đặt ra đó là, cần phải lên phương án, hoạch định kế hoạch chi tiết, kỹ càng, thận trọng những công nghệ tối ưu về hiệu quả nhằm đảm bảo rằng hệ thống SOA được an toàn, trong khi vẫn có hiệu suất hoạt động ở mức chấp nhận được. 4.2. Giao thức bảo mật SSL 4.2.1. Cấu trúc giao thức bảo mật SSL SSL là giao thức đa mục đích được thiết kế để tạo ra các giao tiếp giữa hai chương trình ứng dụng trên một cổng định trước (thông thường là socket 443) nhằm mã hoá toàn bộ thông tin đi/đến, mà ngày nay được sử dụng rộng rãi cho giao dịch điện tử như truyền số hiệu thẻ tín dụng, mật khẩu, số bí mật cá nhân (PIN) trên Internet. Giao thức SSL được hình thành và phát triển đầu tiên năm 1994 bởi nhóm nghiên cứu Netscape dẫn dắt bởi Elgammal và ngày nay đã trở thành chuẩn bảo mật thực hành trên mạng Internet. Phiên bản SSL hiện nay là 3.0 và vẫn đang tiếp tục được bổ sung và hoàn thiện. Chức năng chính là bảo vệ bằng mật mã lưu lượng dữ liệu HTTP. Giao thức SSL dựa trên hai nhóm con giao thức là giao thức “bắt tay” (handshake protocol) và giao thức “bản ghi” (record protocol). Giao thức bắt tay xác định các tham số giao dịch giữa hai [39] đối tượng có nhu cầu trao đổi thông tin hoặc dữ liệu, còn giao thức bản ghi xác định khuôn dạng cho tiến hành mã hoá và truyền tin hai chiều giữa hai đối tượng đó. Khi hai ứng dụng máy tính, thí dụ giữa một trình duyệt web và máy chủ web, làm việc với nhau, máy chủ và máy khách sẽ trao đổi “lời chào” (hellos) dưới dạng các thông điệp cho nhau với xuất phát đầu tiên chủ động từ máy chủ, đồng thời xác định các chuẩn về thuật toán mã hoá và nén số liệu có thể được áp dụng giữa hai ứng dụng. Ngoài ra, các ứng dụng còn trao đổi “số nhận dạng/khoá theo phiên” (session ID, session key) duy nhất cho lần làm việc đó. Sau đó ứng dụng khách (trình duyệt) yêu cầu có chứng thực điện tử (digital certificate) xác thực của ứng dụng chủ (web server). Cấu trúc của một giao thức bảo mật SSL như hình sau: Hình 4.1: Cấu trúc của giao thức bảo mật SSL Hình trên mô tả giao thức bảo mật SSL. Trong đó, SSL chỉ một lớp bảo mật trung gian giữa tầng transport và tầng application. SSL được xếp lớn lên trên một dịch vụ vận chuyển định hướng kết nổi và đáng tin cậy. Chẳng hạn như được cung cấp bở TCP. Về khả năng, nó có thể cung cấp các dịch vụ bảo mật cho các giao thức ứng dụng tùy ý dựa vào TCP chứ không chỉ HTTP. Thực tế, một ưu điểm chính của các giao thức bảo mật tầng vận chuyển (transport layer) nói chung và giao thức SSL nói riêng là chúng độc lập với ứng dụng theo nghĩa là chúng có thể được sử dụng [40] để bảo vệ bất kỳ giao thức ứng dụng được xếp lớp lên trên TCP một cách trong suốt. Hình minh họa một số giao thức ứng dụng điển hình bao gồm NSIIOP, HTTP, FTP, Telnet, IMAP, IRC, và POP3. Tất cả chúng có thể được bảo vệ bằng cách xếp lớn chúng lên trên SSL (mẫu tự S được thêm vào trong các từ ghép giao thức tương ứng chỉ định việc sử dụng SSL). Tuy nhiên, chú ý rằng SSL có một định hướng client-server mạnh mẽ và thật sự không đáp ứng các yêu cầu của các giao thức ứng dụng ngang hàng. Tóm lại, giao thức SSL cung cấp sự bảo mật truyền thông vốn có ba đặc tính cơ bản: 1. Các bên giao tiếp (nghĩa là client và server) có thể xác thực nhau bằng cách sử dụng mật mã khóa chung. 2. Sự bí mật của lưu lượng dữ liệu được bảo vệ vì nối kết được mã hóa trong suốt sau khi một sự thiết lập quan hệ ban đầu và sự thương lượng khóa session đã xảy ra. 3. Tính xác thực và tính toàn vẹn của lưu lượng dữ liệu cũng được bảo vệ vì các thông báo được xác thực và được kiểm tra tính toàn vẹn một cách trong suốt bằng cách sử dụng MAC. Tuy nhiên, điều quan trọng cần lưu ý là SSL không ngăn các cuộc tấn công phân tích lưu lượng. Ví dụ, bằng cách xem xét các địa chỉ IP nguồn và đích không được mã hóa và các sô cổng TCP, hoặc xem xét lượng dữ liệu được truyền, một người phân tích lưu lượng vẫn có thể xác định các bên nào đang tương tác, các loại dịch vụ đang được sử dụng, và đôi khi ngay cả dành được thông tin về các mối quan hệ doanh nghiệp hoặc cá nhân. Hơn nữa, SSL không ngăn các cuộc tấn công có định hướng dựa vào phần thực thi TCP, chẳng hạn như các cuộc tấn công làm tràn ngập TCP SYN hoặc cưỡng đoạt session. Để sử dụng sự bảo vệ SSL, cả client lẫn server phải biết rằng phía bên kia đang sử dụng SSL. Nói chung, có ba khả năng để giải quyết vấn đề này: 1. Sử dụng các số cổng chuyên dụng được dành riêng bởi Internet Asigned Numbers Authority (IANA). Trong trường hợp này, một số cổng riêng biệt phải được gán cho mọi giao thức ứng dụng vốn sử dụng SSL. 2. Sử dụng số cổng chuẩn cho mọi giao thức ứng dụng và để thương lượng các tùy chọn bảo mật như là một phần của giao thức ứng dụng (bây giờ được chỉnh sửa đôi chút). [41] 3. Sử dụng một tùy chọn TCP để thương lượng việc sử dụng một giao thức bảo mật, chẳng hạn như SSL trong suốt giai đoạn thiết lập nối kết TCP thông thường. Sự thương lượng dành riêng cho ứng dụng của các tùy chọn bảo mật (nghĩa là khả năng thứ hai) có khuyết điểm là đòi hỏi mọi giao thức ứng dụng được chỉnh sửa để hiểu tiến trình thương lượng. Ngoài ra, việc xác định một tùy chọn TCP (nghĩa là khả năng thứ ba) là một giải pháp tốt, nhưng đó không được thảo luận nghiêm túc cho đến bây giờ. Thực tế, các số cổng riêng biệt đã được dành riêng và được gán bởi IANA cho mọi giao thức ứng dụng vốn có thể chạy trên SSL hoặc TLS (nghĩa là khả năng thứ nhất). Tuy nhiên, hãy chú ý việc sử dụng các số cổng riêng biệt cũng có khuyết điểm là đòi hỏi hai nối kết TCP nếu client không biết những gì mà server hỗ trợ. Trước tiên, client phải nối kết với cổng an toàn và sau đó với cổng không an toàn hay ngược lại. Rất có thể các giao thức sau này sẽ hủy bỏ phương pháp này và tìm khả năng thứ hai. Ví dụ, SALS (Simple Authentication và Security Layer) xác định một phù hợp để thêm sự hỗ trợ xác thực vào các giao thức ứng dụng dựa vào kết nối. Theo thông số kỹ thuật SALS, việc sử dụng các cơ chế xác thực có thể thương lượng giữa client và server của một giao thức ứng dụng đã cho. Các số cổng được gán bởi IANA cho các giao thức ứng dụng vốn chạy trên SSL/TLS được tóm tắt trong bảng 1.2 và được minh họa một phần trong hình 1.1. Ngày nay, "S" chỉ định việc sử dụng SSL được thêm (hậu tố) nhất quán vào các từ ghép của các giao thức ứng dụng tương ứng (trong một số thuật ngữ ban đầu, S được sử dụng và được thêm tiền tố một cách không nhất quán và một số từ ghép). Bảng 4.1: Các số cổng được gán cho các giao thức ứng dụng chạy trên TLS/SSL. Từ khóa Cổng Mô tả Nsiiop 261 Dịch vụ tên IIOP trên TLS/SSL https 443 HTTP trên TLS/SSl Smtps 465 SMTP trên TLS/SSL [42] Nntps 563 NNTP trên TLS/SSL Ldaps 636 LDAP trên TLS/SSL Ftps-data 989 FTP (dữ liệu) trên TLS/SSL Ftps 990 FTP (Điều khiển) trên TLS/SSL Tenets 992 TELNET trên TLS/SSL Imaps 994 IRC trên TLS/SSL Pop3s 995 POP3 trên TLS/SSL Nói chung, một session SSL có trạng thái và giao thức SSL phải khởi tạo và duy trì thông tin trạng thái ở một trong hai phía của session. Các phần tử thông tin trạng thái session tương ứng bao gồm một session ID, một chứng nhận ngang hàng, một phương pháp nén, một thông số mật mã, một khóa mật chính và một cờ vốn chỉ định việc session có thể tiếp tục lại hay không, được tóm tắt trong bảng 1.3. Một session SSL có thể được sử dụng trong một số kết nối và các thành phần thông tin trạng thái nối kết tương ứng được tóm tắt trong bảng 1.4. Chúng bao gồm các tham số mật mã, chẳng hạn như các chuỗi byte ngẫu nhiên server và client, các khóa mật MAC ghi server và client, các khóa ghi server và client, một vector khởi tạo và một số chuỗi. Ở trong hai trường hợp, điều quan trọng cần lưu ý là các phía giao tiếp phải sử dụng nhiều session SSL đồng thời và các session có nhiều nối kết đồng thời. Bảng 4.2. Các thành phần thông tin trạng thái Session SSL Thành Phần Mô tả Session ID Định danh được chọn bởi server để nhận dạng một trạng thái session hoạt động hoặc có thể tiếp tục lại. [43] Peer certificate Chứng nhân X.509 phiên bản 3 của thực thể ngang hàng. Compression method Thuật toán dừng để nén dữ liệu trước khi mã hóa Cipher spec Thông số của các thuật toán mã hóa dữ liệu và MAC Master secret Khóa mật 48-byte được chia sẻ giữa client và server. Is resumable Cờ vốn biểu thị session có thể được sử dụng để bắt đầu các nối kết mới hay không. Bảng 4.3. Các thành phần thông tin trạng thái nối kết SSL Thành Phần Mô tả Ngẫu nhiên server và client Các chuỗi byte được chọn bởi server và client cho mỗi nối kết. Khóa mật MAC ghi server Khóa mật được sử dụng cho các hoạt động MAC trên dữ liệu được ghi bởi server. Khóa mật MAC ghi client Khóa mật được sử dụng cho các hoạt động MAC trên dữ liệu được ghi bởi client. Khóa ghi server Khóa được sử dụng cho việc mã hóa dữ liệu bởi server và giải mã bởi client [44] Khóa ghi client Khóa được sử dụng để mã khóa dữ liệu bởi client và giải mã bởi server. Initialization vector Trạng thái khởi tạo cho một mật mã khối trong chế độ CBC. Trường này được khởi tạo đầu tiên bởi SSL Handshake Player. Sau đó, khối text mật mã sau cùng từ mỗi bản ghi được dành riêng để sử dụng vởi bản ghi sau đó. Số chuỗi Mỗi phía duy trì các số chuỗi riêng biệt cho các thông báo được truyền và được nhận cho mỗi nối kết. Như được minh họa trong hình 1.1, giao thức SSL gồm hai phần chính, SSL Record Protocol và một số giao thức con SSL được xếp lớp trên nó: - Record OK được xếp lớp trên một dịch vụ lớp vận chuyển định hướng nối kết và đáng tin cậy, chẳng hạn như được cung cấp bởi TCP và cung cấp sự xác thực nguồn gốc thông báo, sự bí mật dữ liệu và dữ liệu. - Các dịch vụ toàn vẹn (bao gồm nhưng thứ như chống xem lại). - Các giao thức con SSL được xếp lớp trên SSL Record Protocol để cung cấp sự hỗ trợ cho việc quản lý session SSL và thiết lập nối kết. - Giao thức con SSL quan trọng nhất là SSL Handshake Protocol. Lần lượt giao thức này là một giao thức xác thực và trao đổi khóa vốn có thể được sử dụng để thương lượng, khởi tạo và đồng bộ hóa các tham số bảo mật và thông tin trạng thái tương ứng được đặt ở một trong hai điểm cuối của một session hoặc nối kết SSL. - Sau khi SSL Handshake Protocol đa hoàn tất, dữ liệu ứng dụng có thể được gửi và được nhận bằng cách sử dụng SSL Record Protocol và các tham số bảo mật được thương lượng và các thành phần thông tin trạng thái. SSL Record và Handshake Protocol được trình bày tổng quan ở phần tiếp theo. [45] 4.2.2. SSL Record Protocol SSL Record Protocol nhận dữ liệu từ các giao thức con SSL lớp cao hơn và xử lý việc phân đoạn, nén, xác thực và mã hóa dữ liệu. Chính xác hơn, giao thức này lấy một khối dữ liệu có kích cỡ tùy ý làm dữ liệu nhập và tọa một loạt các đoạn dữ liệu SSL làm dữ liệu xuất (hoặc còn được gọi là các bản ghi) nhỏ hơn hoặc bằng 16,383 byte. hình 4.2: Các bước SSL Record Protocol. Các bước khác nhau của SSL Record Protocol vốn đi từ một đoạn dữ liệu thô đến một bản ghi SSL Plaintext (bước phân đoạn), SSL Compressed (bước nén) và SSL Ciphertext (bước mã hóa) được minh họa trong hình 1.5. Sau cùng, mỗi bản ghi SSL chứa các trường thông tin sau đây: - Loại nội dung; - Số phiên bản của giao thức; - Chiều dài; - Tải trọng dữ liệu (được nén và được mã hóa tùy ý); - MAC. [46] Loại nội dung xác định giao thức lớp cao hơn vốn phải được sử dụng để sau đó xử lý tải trọng dữ liệu bản ghi SSL (sau khi giải nén và giải mã hóa thích hợp). Số phiên bản của giao thức xác định phiên bản SSL đang sử dụng (thường là version 3.0) Mỗi tải trọng dữ liệu bản ghi SSL được nén và được mã hóa theo phương thức nén hiện hành và thông số mật mã được xác định cho session SSL. Lúc bắt đầu mỗi session SSL, phương pháp nén và thông số mật mã thường được xác định là rỗng. Cả hai được xác lập trong suốt quá trình thực thi ban đầu SSL Handshake Protocol. Sau cùng, MAC được thêm vào mỗi bản ghi SSL. Nó cung cấp các dịch vụ xác thực nguồn gốc thông báo và tính toàn vẹn dữ liệu. Tương tự như thuật toán mã hóa, thuật toán vốn được sử dụng để tính và xác nhận MAC được xác định trong thông số mật mã của trạng thái session hiện hành. Theo mặc định, SSL Record Protocol sử dụng một cấu trúc MAC vốn tương tự nhưng vẫn khác với cấu trúc HMAC hơn. Có ba điểm khác biệt chính giữa cấu trúc SSL MAC và cấu trúc HMAC: 1. Cấu trúc SSL MAC có một số chuỗi trong thông báo trước khi hash để ngăn các hình thức tấn công xem lại riêng biệt. 2. Cấu trúc SSL MAC có chiều dài bản ghi. 3. Cấu trúc SSL MAC sử dụng các toán tử ghép, trong khi cấu trúc MAC sử dụng moduloe cộng Tất cả những điểm khác biệt này hiện hữu chủ yếu vì cấu trúc SSL MAC được sử dụng trước cấu trúc HMAC trong hầu như tất cả thông số kỹ thuật giao thức bảo mật Internet. Cấu trúc HMAC cũng được sử dụng cho thông số kỹ thuật giao thức TLS gần đây hơn. Như được minh họa trong hình 1.5, một số giao thức con SSL được xếp lớp trên SSL Record Protocol. Mỗi giao thức con có thể tham chiếu đến các loại thông báo cụ thể vốn được gửi bằng cách sử dụng SSL Record Protocol. Thông số kỹ thuật SSL 3.0 xác định ba giao thức SSL sau đây: Alert Protocol; - Handshake Protocol; - ChangeCipherSpec Protocol; Tóm lại, SSL Alert Protocol được sử dụng để chuyển các cảnh báo thông qua SSL Record Protocol. Mỗi cảnh báo gồm 2 phần, một mức cảnh báo và một mô tả cảnh báo. SSL Handshake Protocol là giao thức con SSL chính được sử dụng để hỗ trợ xác thực client và server và để trao đổi một khóa session. Do đó SSL Handshake Protocol trình bày tổng quan và [47] được thảo luận trong phần tiếp theo. Sau cùng, SSL ChangeCipherSpec Protocol được sử dụng để thay đổi giữa một thông số mật mã này và một thông số mật mã khác. Mặc dù thông số mật mã thường được thay đổi ở cuối một sự thiết lập quan hệ SSL, nhưng nó cũng có thể được thay đổi vào bất kỳ thời điểm sau đó. Ngoài những giao thức con SSL này, một SSL Application Data Protocol được sử dụng để chuyển trực tiếp dữ liệu ứng dụng đến SSL Record Protocol. 4.2.3. SSL Handshake Protocol SSL Handshake Protocol [8, 20] là giao thức con SSL chính được xếp lớp trên SSL Record Protocol. Kết quả, các thông báo thiết lập quan hệ SSL được cung cấp cho lớp bản ghi SSL nơi chúng được bao bọc trong một hoặc nhiều bản ghi SSL được xử lý và được chuyển như được xác định bởi phương pháp nén và thông số mật mã của session SSL hiện hành và các khóa mật mã của kết nối SSL tương ứng. Mục đích của SSL Handshake Protocol là yêu cầu một client và server thiết lập và duy trì thông tin trạng thái được sử dụng để bảo vệ các cuộc liên lạc. Cụ thể hơn, giao thức phải yêu cầu client và server chấp thuận một phiên bản giao thức SSL chung, chọn phương thức nén và thông số mật mã, tùy ý xác thực nhau và tạo một khóa mật chính mà từ đó các khóa session khác nhau dành cho việc xác thực và mã hóa thông báo có thể được dẫn xuất từ đó. Tóm lại, việc thực thi SSL Handshake Protocol giữa một client C và một server S có thể được tóm tắt như sau (các thông báo được đặt trong các dấu ngoặc vuông thì tùy chọn): 1: C -> S: CLIENTHELLO 2: S -> C: SERVERHELLO [CERTIFICATE] [SERVERKEYEXCHANGE] [CERTIFICATEREQUEST] SERVERHELLODONE 3: C -> [CERTIFICATE] [48] CLIENTKEYEXCHANGE [CERTIFICATEVERIFY] CHANGECIPHERSPEC FINISHED 4: S -> C: CHANGECIPHERSPEC FINISHED Khi Client C muốn kết nối với Server S, nó thiết lập một kết nối TCP với cổng HTTPS (không được đưa vào phần mô tả giao thức) và gửi một thông báo CLIENTHELLO đến server ở bước 1 của sự thực thi SSL Handshake Protocol. Client cũng có thể gởi một thông báo CLIENTHELLO nhằm phản hồi lại một thông báo HELLOREQUEST hoặc chủ động thương lượng lại các tham số bảo mật của một kết nối hiện có. Thông báo CLIENTHELLO bao gồm các trường sau đây: – Số của phiên bản SSL cao nhất được biểu hiện bởi client (thường là 3.0). – Một cấu trúc ngẫu nhiên do client tạo ra gồm một tem thời gian 32 bit có dạng UNIX chuẩn và một giá trị 28 byte được tạo ra bởi một bộ tạo số giả ngẫu nhiên. – Một định danh session mà client muốn sử dụng cho kết nối này. – Một danh sách các bộ mật mã client hỗ trợ. – Một danh sách các phương pháp nén mà client hỗ trợ. Chú ý rằng trường session identity (định danh session) nên rỗng nếu session SSL hiện không tồn tại hoặc nếu client muốn tạo các tham số bảo mật mới. Ở một trong hai trường hợp, một trường session identity không rỗng là xác định một session SSL hiện có giữa client và server (nghĩa là một session có các tham số bảo mật mà client muốn sử dụng lại). Định danh session có thể bắt nguồn từ một kết nối trước đó, kết nối này hoặc một kết nối đang hoạt động. Cũng chú ý rằng danh sách các bộ mật mã được hỗ trợ, được chuyển từ client đến server trong thông báo CLIENTHELLO, chứa các tổ hợp thuật toán mật mã được hỗ trợ bởi client theo thứ tự ưu tiên. Mỗi bộ mật mã xác định một thuật toán trao đổi khóa và một thông báo mật mã. Server sẽ chọn [49] một bộ mật mã hoặc nếu các lựa chọn có thể chấp nhận được không được trình bầy, trả về một thông báo lỗi và đóng kết nối một cách phù hợp. Sau khi đa gởi thông báo CLIENTHELLO, client đợi một thông báo SERVERHELLO. Bất kỳ thông báo khác được trả về bởi server ngoại trừ một thông báo HELLOREQUEST được xem như là một lỗi vào thời điểm này. Ở bước 2, server xử lý thông báo CLIENTHELLO và đáp ứng bằng một thông báo lỗi hoặc thông báo SERVERHELLO. Tương tự như thông báo CLIENTHELLO, thông báo SERVERHELLO có các trường sau đây: – Một số phiên bản server chứa phiên bản thấp hơn của phiên bản được đề nghị bởi client trong thông báo CLIENTHELLO và được hỗ trợ cao nhất bởi Server. – Một cấu trúc ngẫu nhiên do server tạo ra cũng gồm một tem thời gian 32bit có dạng UNIX chuẩn và một giá trị 28bit được tạo ra bởi một bộ tạo số ngẫu nhiên. – Một định danh session tương ứng với kết nối này. – Một bộ mật mã được chọn bởi server từ danh sách các bộ mật mã được hỗ trợ bởi client. – Một phương pháp nén được chọn bởi server từ danh sách các thuật toán nén được hỗ trợ bởi client. Nếu định danh session trong thông báo CLIENTHELLO không rỗng, server tìm trong cache session của nó nhằm tìm ra một mục tương hợp. Nếu mục tương hợp được tìm thấy và server muốn thiết lập kết nối mới bằng cách sử dụng trạng thái session tương ứng, server đáp ứng bằng cùng một giá trị như được cung cấp bởi client. Chỉ định này là một session được tiếp tục lại và xác định rằng cả hai phía phải tiến hành trực tiếp với các thông báo CHANGECIPHERSPEC và FINISHED được trình bày thêm bên dưới. Nếu không, trường này chứa một giá trị khác nhận biết một session mới. Server cũng có thể trả về một trường định danh session rỗng để biểu thị rằng session sẽ không được lưu trữ và do đó không thể được tiếp tục sau đó. Cũng chú ý rằng trong thông báo SERVERHELLO, server chọn một bộ mật mã và một phương pháp nén từ các danh sách được cung cấp bởi client trong thông báo CLIENTHELLO. Các thuật toán trao đổi khóa, xác thực, mã hóa và xác thực thông báo được xác định bởi bộ mã hoá được chọn bởi server và được gửi trong thông báo SERVERHELLO. [50] Các bộ mã hoá đã được xác định trong giao thức SSL về cơ bản giống như bộ mã hoá đã xác định cho TLS. Ngoài thông báo SERVERHELLO, server cũng phải gửi các thông báo khác đến client. Ví dụ, nếu server sử dụng sự xác thức dựa vào chứng chỉ số, server gửi chứng chỉ số site của nó đến client trong một thông báo CERTIFICATE tương ứng. Chứng chỉ số phải thích hợp cho thuật toán trao đổi khóa của bộ mã hoá được chọn và thường là một chứng chỉ số X.509v3. Cùng loại thông báo sẽ được sử dụng sau đó cho sự đáp ứng của client đối với thông báo sẽ được sử dụng sau đó cho sự đáp ứng của client đối với thông báo CERTIFICATERequest của server. Trong trường hợp của các chứng nhận X.509v3, một chứng chỉ số có thể thực sự tham chiếu đến toàn bộ một chuỗi các chứng chỉ số, được sắp xếp theo thứ tự với chứng chỉ số của đối tượng gửi trước tiên theo sau là bất kỳ chứng chỉ số CA tiến hành theo trình tự hướng đến một CA gốc (sẽ được chấp nhận bởi client). Tiếp theo, server có thể gửi một thông báo SERVERKEYEXCHANGE đến client nếu nó không có chứng chỉ số, một chứng chỉ số có thể được sử dụng chỉ để xác nhận các chữ ký kỹ số hoặc sử dụng thuật toán trao đổi khóa dựa vào token FORITEZZA (KEA). Rõ ràng, thông báo này không được yêu cầu nếu chứng chỉ số site gồm một khóa chung RSA có thể được sử dụng trong việc mã hóa. Ngoài ra, một server không nặc danh có thể tùy ý yêu cầu một chứng chỉ số cá nhân để xác thực client. Do đó, nó gửi một thông báo CERTIFICATERequest đến client. Thông báo này chứa một danh sách các loại chứng chỉ số được yêu cầu, được phân loại theo thứ tự ưu tiên của server cũng như một danh sách các tên được phân biệt cho các CA có thể chấp nhận. Ở cuối bước 2, server gửi một thông báo SERVERHELLODone đến client để chỉ định sự kết thúc SERVERHELLO và các thông báo đi kèm. Sau khi nhận SERVERHELLO và các thông báo đi kèm, client xác nhận rằng chứng chỉ số site server (nếu được cung cấp) là hợp lệ và kiểm tra nhằm bảo đảm rằng các thông số bảo mật được cung cấp trong thông báo SERVERHELLO có thể được chấp nhận. Nếu server yêu cầu sự xác thực client, client gửi một thông báo CERTIFICATE chứa một chứng chỉ số cá nhân cho khóa chung của người dùng đến server ở bước 3. Tiếp theo, client gửi một thông báo CLIENTKEYEXCHANGE có dạng phụ thuộc vào thuật toán cho mỗi khóa được chọn bởi server: [51] – Nếu RSA được sử dụng cho việc xác thực server và trao đổi khóa, client tạo một khóa mật premaster 48 byte, mã hóa nó bằng khóa chung được tìm thấy trong chứng chỉ số site hoặc khóa RSA tạm thời từ thông báo SERVERKEYEXCHANGE và gửi kết quả trở về server trong thông báo CLIENTKEYEXCHANGE. Lần lượt server sử dụng khóa riêng tương ứng để giải mã khóa mật chính. – Nếu các token FORTEZZA được sử dụng để trao đổi khóa, client dẫn xuất một khóa mã hóa token (TEK) bằng cách sử dụng KEA. Phép tình KEA cảu client sử dụng khóa chung từ chứng chỉ số server cùng với một số tham số riêng trong token của client. Client gửi các tham số chung cần thiết cho server để cũng tạo TEK, sử dụng các tham sô riêng của nó. Nó tạo một khóa mật master, bao bọc nó bằng cách sử dụng TEK và gửi kết quả cùng với một số vector khởi tạo đến server như là một phần của thông báo CLIENTKEYEXCHANGE. Lần lượt, server có thể giải mã khóa mật master một cách thích hợp. Thuật toán trao đổi khóa này không được sử dụng rộng rãi. Nếu sự xác thực client được yêu cầu, client cũng gửi một thông báo CERTIFICATEVERIFY đến server. Thông báo này được sử dụng để cung cấp sự xác thực rõ ràng định danh của người dùng dựa vào chứng chỉ số cá nhân. Nó chỉ được gửi theo sau một chứng chỉ client có khả năng tạo chữ ký (tất cả chứng nhận ngoại trừ các chứng chỉ số chứa các tham số Diffie - Hellman cố định). Sau cùng, client hoàn tất bước 3 bằng cách gửi một thông báo CHANGECIPHERSPEC và một thông báo FINISHED tương ứng đến server. Thông báo FINISHED luôn được gửi ngay lập tức sau thông báo CHANGECIPERSPEC để xác nhận rằng các tiến trình trao đổi khóa và xác thực đa thành công. Thực tế, thông báo FINISHED là thông báo đầu tiên được bảo vệ bằng các thuật toán mới được thoả thuận và các khóa session. Nó chỉ có thể được tạo và được xác nhận nếu những khóa này được cài đặt một cách phù hợp ở cả hai phía. Không đoi hỏi sự xác nhận thông báo FINISHED; các phía có thể bắt đầu gửi dữ liệu được mã hóa ngay lập tức sau khi đa gửi thông báo FINISHED. Việc thực thi SSL Handshake Protocol hoàn tất bằng việc server gửi một thông báo CHANGECIPHERSPEC và một thông báo FINISHED tương ứng đến client ở bước 4. Sau khi sự thiết lập SSL hoàn tất, một kết nối an toàn được thiết lập giữa client và server. Kết nối này bây giờ có thể được sử dụng để gửi dữ liệu ứng dụng. Chính xác hơn, dữ liệu ứng dụng có [52] thể được phân đoạn, được nén, hoặc được mã hóa và được xác thực theo SSL Record Protocol cũng như thông tin trạng thái session và kết nối bây giờ được thiết lập (tùy thuộc việc thực thi SSL Handshake Protocol). SSL Handshake Protocol có thể được rút ngắn nếu client và server quyết định tiếp tục lại một session SSL được thiết lập trước đó (và vẫn được lưu trữ) hoặc lặp lại một session SSL hiện có. Trong trường hợp này, chỉ ba dòng thông báo và tổng cộng sáu thông báo được yêu cầu. Các dòng thông báo tương ứng có thể được tóm tắt như sau: 1: C -> S: CLIENTHELLO 2: S -> C: SERVERHELLO CHANECIPHERSPEC FINISHED 3: S ->C: CHANGECIPHERSPEC FINISHED Ở bước 1, client gửi một thông báo CLIENTHELLO đến server có một định danh session cần được tiếp tục lại. Lần lượt server kiểm tra cache session của nó để tìm một mục tương hợp. Nếu một mục tương hợp được tìm thấy, server muốn tiếp tục lại kết nối bên dưới trạng thái session đã xác định, nó trả về một thông báo SERVERHELLO với cùng một định danh session ở bước 2. Vào thời điểm này, cả client lẫn server phải gởi các thông báo CHANGECIPHERSPEC và FINISHED đến nhau ở bước 2 và 3. Một khi việc tái thiết lập session hoàn tất, client và server có thể bắt đầu trao đổi dữ liệu ứng dụng. Các thuật toán mã hoá và xác thực của SSL được sử dụng bao gồm (phiên bản 3.0):  DES: chuẩn mã hoá dữ liệu (ra đời năm 1977), phát minh và sử dụng của chính phủ Mỹ.  DSA: thuật toán chữ ký điện tử, chuẩn xác thực điện tử, phát minh và sử dụng của chính phủ Mỹ.  KEA: thuật toán trao đổi khoá, phát minh và sử dụng của chính phủ Mỹ. [53]  MD5: thuật toán tạo giá trị “băm” (message digest), phát minh bởi Rivest.  RC2, RC4: mã hoá Rivest, phát triển bởi công ty RSA Data Security.  RSA: thuật toán khoá công khai, cho mã hoá và xác thực, phát triển bởi Rivest, Shamir và Adleman.  RSA key exchange: thuật toán trao đổi khoá cho SSL dựa trên thuật toán RSA.  SHA-1: thuật toán hàm băm an toàn, phát triển và sử dụng bởi chính phủ Mỹ.  SKIPJACK: thuật toán khoá đối xứng phân loại được thực hiện trong phần cứng Fortezza, sử dụng bởi chính phủ Mỹ.  Triple-DES: mã hoá DES ba lần. Cơ sở lý thuyết và cơ chế hoạt động của các thuật toán sử dụng về bảo mật trên hiện nay là phổ biến rộng rãi và công khai, trừ các giải pháp thực hiện trong ứng dụng thực hành vào trong các sản phẩm bảo mật (phần cứng, phần mềm). Đã có những kết luận cho rằng SSL cung cấp sự bảo mật hoàn hảo ngăn việc nghe lén và những cuộc tấn công thụ động khác, và người thực thi giao thức này sẽ ý thức đến một số cuộc tấn công chủ động tinh vi. 4.3. Khai thác tính năng bảo mật của bộ thư viện Web Service Enhancement (WSE) Có rất nhiều lựa chọn khác nhau có sẵn để giúp an ninh các dịch vụ web và các tổ chức khác nhau có các tiêu chí khác nhau giải quyết vấn đề an ninh của họ. Và trong luận văn này, tôi lựa chọn nghiên cứu về WSE. Wse là bộ thư viện lập trình trên nền .NET, hỗ trợ trong việc xây dựng các web service theo những chuẩn mới nhất như WS-Security, WS-SecureConversation, WS-Trust, WS-Policy, WS- securityPolicy, WS-Addressing, WS-Messageing và WS-Attachments. Với bộ thư viện này, ta có thể đưa ra các tính năng liên quan đến bảo mật này vào web service trong lúc thiết kế bằng cách sử dụng mã lệnh hay vào thời điểm triển khai thông qua việc sử dụng các tập tin policy. [54] 4.3.1. Những tính năng bảo mật web service của wse Wse sử dụng các cơ chế được định nghĩa trong ws-security để đặt các ủy quyền chứng thực (security credential) như security token vào trong các thông điệp SOAP. Wse sau đó sẽ thực hiện kiểm tra tính hợp lệ của những security credentials trước khi chuyển quyền thực thi cho các web service. Wse 2.0 hỗ trợ các loại security token sau: username/password, X.509 Certificate, Kerberos ticket, Security Context token và các loại security token do người dùng định nghĩa. Chúng ta sẽ tìm hiểu phần này ngay sau đây. Wse còn cho phép các nhà phát triển xây dựng riêng cho mình các dịch vụ security token. Các dịch vụ này có thể tạo ra các loại security token khác mà có thể dụng trong quá trình tương tác với các web service nào tin tưởng vào dịch vụ này. Thông qua việc hỗ trợ xác nhận số hay mã hóa các thông điệp SOAP sẽ tăng cường khả năng an toàn cho các web service. - Xác nhận một số thông điệp SOAP sẽ giúp cho đối tượng nhận thông điệp kiểm tra được thông điệp có bị thay đổi hay không. Hình 4.3: Xác nhận số một thông điệp - Mã hóa một thông điệp SOAP sẽ đảm bảo cho chỉ những web service mong muốn mới có thể đọc được nội dung của thông điệp đó. Hình 4.4: Mã hóa một thông điệp [55] 4.3.3. Hô trợ policy Wse hỗ trợ các nhà phát triển đưa ra các yêu cầu về quá trình gửi và nhận thông điệp bằng cách dùng các tập tin câu hình. Trước đây, một đối tượng khi nhận được một thông điệp SOAP phải dùng mã lệnh để kiểm tra các thông tin về thông điệp nhận được như là có được xác nhận số hay mã hóa chưa? Và cũng tương tự như thế, phía gửi cũng phải viết mã lệnh để lấy được các yêu cầu này từ phía nhà cung cấp. Nay thì các yêu cầu này có thể được cung cấp thông qua các tập tin cấu hình. Khi các cơ chế xác nhận policy được chỉ định: - Các thông điệp SOAP khi được gửi đi sẽ qua quá trình kiểm tra để đảm bảo chúng thỏa mãn các policy assertion của phía gửi. Nếu không thỏa mãn, wse sẽ đưa ra một ngoại lệ. - Các thông điệp SOAP trước khi được nhận vào sẽ phải được kiểm tra xem có đáp ứng được các policy assertion của phía nhận hay không? Nếu không, thông điệp đó sẽ được gửi trả về hay một ngoại lệ sẽ được đưa ra. Wse đã hỗ trợ sẵn một vài cơ chế xác nhận policy (ví dụ như: yêu cầu phần body của thông điệp phải được xác nhận-signed bởi một X.509 certificate). Ngoài ra, hệ thống policy còn cho phép thêm những cơ chế xác nhận policy khác do người dùng định nghĩa. a. SOAP messaging Đây là một tính năng nổi trội của wse.SOAP messaging hỗ trợ nhiều nghi thức ở tầng vận chuyển như HTTP, TCP, với giao diện bất đồng bộ hay đồng bộ. Đặc biệt, khi thực hiện việc gửi và nhận các thông điệp theo nghi thức TCP thì ta không cần phải có một Web Server. b. Điều phối các thông điệp SOAP Ta có thể sử dụng wse để xây dựng các ứng dụng phân tán mà kiến trúc phân tán của nó là trong suốt đối với người dùng. Ta sử dụng một máy tính trung gian và cấu hình nó chạy WSE router. Người dùng sẽ gửi yêu cầu đến WSE router thay vì trực tiếp đến web service. WSE router sau đó sẽ chuyển thông điệp SOAP đến máy đang chạy web service dựa trên thông tin cấu hình của router. Giải pháp này giúp hệ thống ta linh hoạt hơn, bền vững hơn, vì ta có thể thay đổi thông tin về các máy đích khi có sự cố xảy ra. [56] Hình 4.5: Điều phối thông điệp SOAP [7] c. Gửi những đối tượng kèm theo các thông điệp SOAP Wse hỗ trợ nghi thức DIME (Direct Internet Message Encapsulation). Nghi thức này định nghĩa cơ chế để đính kèm những đối tượng khác trong các thông điệp SOAP. Điều này cần thiết cho những web service nào có nhu cầu muốn gửi những thông tin có kích thước lớn (dạng text hay binary) như tập tin dạng ảnh hay âm thanh. Theo mặc định thì các thông điệp SOAP không thích hợp để gửi đính kèm các tập tin lớn. Vì định dạng của một thông điệp SOAP là theo XML, khi thêm một tập tin vào thông điệp SOAP thì đòi hỏi tập tin đó phải được chuyển đồi thành dạng XML. Điều này có thể làm tăng kích thước của tập tin lên đáng kể so với kích thước thật của nó. Nghi thức DIME giải quyết vấn đề này bằng cách định nghĩa một cơ chế để đặt toàn bộ nội dung tập tin gốc nằm ở bên ngoài thông điệp SOAP, như vậy sẽ loại bỏ được việc phải chuyển đổi nội dung tập tin sang dạng XML. CHƯƠNG 5 Xây dựng chương trình và đánh giá kết quả Từ các kiến thức về SOA và dịch vụ Web ở chương 2 và đặc biệt là kỹ thuật đảm bảo an ninh dịch vụ web ở chương 4. Tiếp theo, trong chương này sẽ đề xuất giải pháp để thực hiện bài toán, triển khai và xây dựng hệ thống. [57] 5.1. Mô tả hệ thống cần xây dựng Hệ thống nghiên cứu và xây dựng bao gồm các chức năng chính: đăng nhập, đăng kí tài khoản, mua cổ phiếu, bán cổ phiếu. Dưới đây là biểu đồ hoạt động của hệ thống. Hình 5.1 Biểu đồ hoạt động của hệ thống 5.2. Triển khai hệ thống 5.2.1. Lựa chọn ngôn ngữ lập trình Để xây dựng xây dựng một hệ thống hoàn chỉnh thực hiện đầy đủ các chức năng yêu cầu đặt ra đòi hỏi phải có một thời gian dài. Trong thời gian qua tôi đã tiến hành nghiên cứu và sử dụng lại hệ thống chứng khoán đã bước đầu đạt được những kết quả và xây dựng xong một số chức năng cơ bản mà hệ thống đặt ra và chạy thử. [58] Ngôn ngữ mà tôi sử dụng để xây dựng hệ thống là ASP.NET của bộ Visual Studio.NET. Với những tính năng nổi bật của ngôn ngữ này và nhận thấy phù hợp với sự phát triển của hệ thống cần xây dựng. 5.2.2. Hoạt động của hệ thống 5.2.2.1. Hiển thị thông tin trang chủ Hiển thị bảng giá chứng khoán, khi chưa đăng nhập cho phép xem thông tin bảng giá và chuyển sang giao diện đăng nhập hoặc đăng ký. 5.2.2.2. Đăng nhập Thời điểm: Trước khi giao dịch Mô tả: Trước khi thực hiện giao dịch nhà đầu tư cần đăng nhập vào tài khoản của mình (nếu nhà đầu tư chưa có một tài khoản có thể đăng ký một tài khoản mới theo phần đăng ký) để xác thực thông tin, sau khi đăng nhập các thông tin chi tiết của nhà đầu tư sẽ được hiển thị. [59] 5.2.2.3. Đăng ký tài khoản mới Thời điểm: Trước khi giao dịch Mô tả: Để có thể thực hiện giao dịch trước tiên nhà đầu tư phải đăng kí tài khoản chứng khoán và tài khoản ngân hàng nhà đầu tư cung cấp các thông tin cá nhân cần thiết cho công ty chứng khoán để tạo tài khoản. Nếu thông tin đầy đủ và chính xác thì hệ thống sẽ thông báo đăng ký tài khoản thành công, ngược lại sẽ báo lỗi tương ứng. Sau khi đăng ký tài khoản người dùng có thể đăng nhập và thực hiện giao dịch cổ phiếu bằng cách cung cấp các thông tin cá nhân. [60] 5.2.3.4. Thực hiện giao dịch Thời điểm: Sau khi đăng nhập Mô tả: Sau khi đăng nhập, nhà đầu tư có thể thực hiện việc mua bán bằng tài khoản của mình thông qua website.  Bán: nhà đầu tư chỉ có thể thực hiện lệnh bán đối với những cổ phiếu có trong tài khoản, số lượng cổ phiếu bán ra không được vượt quá số lượng cổ phiếu đó có trong tài khoản. Số tiền có được khi bán cổ phiếu sẽ được đưa vào tài khoản ngân hàng tương ứng của nhà đầu tư. [61]  Mua: nếu cổ phiếu mà nhà đầu tư mua đã có trong tài khoản thì cổ phiếu đó sẽ được cập nhật lại, nếu chưa có thì cổ phiếu đó sẽ được thêm vào tài khoản của nhà đầu tư. Số tiền dùng để mua cổ phiếu sẽ được trừ vào tài khoản trong ngân hàng tương ứng của nhà đầu tư. Nếu tổng giá trị của số lượng cổ phiếu mà nhà đầu tư thực hiện mua vượt quá số dư của tài khoản ngân hàng thì giao dịch sẽ không được thực hiện. 5.3. Tích hợp các thẻ bảo mật cho chương trình với công cụ WSE Thực thi WS với công cụ WSE phải chắc chắn rằng máy tính của chúng ta đã được cài đặt visual studio.NET. Sau đó thực hiện các bước sau:  Chuột phải vào tên project trong Solution Explorer và chọn WSE Settings 3.0 [62] Giao diện file config như sau: [63] Trước hết, để hệ thống hoạt động cần đánh dấu vào 2 ô “enable this project for Web Services Enhancements” và “enable Microsoft Web Services Enhancement Soap Protocol Factory”. Sau đó chúng ta thêm các thẻ secrutiy X509, Kerberos: [64] Trong tab policy phải enable Policy và dẫn đến file wse3policyCache.config. Trước khi thêm các thẻ cần phải thêm đoạn secsion để config trong file Web.config <section name="microsoft.web.services3" type="Microsoft.Web.Services3.Configuration.WebServicesConfiguration, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> [65] Sau khi thêm các thẻ trong bộ thư viện WSE, chương trình đã được bảo mật. Những thông tin trong thông điệp request bên client gửi đến cho server cũng được mã hóa, và bảo đảm. Các thông tin về username, password, các thông tin về tài khoản ngân hàng, tài khoản chứng khoán,… 5.4. Đánh giá kết quả chạy thử nghiệm chương trình Qua thời gian chạy thử nghiệm cho thấy chương trình thực hiện được các chức năng cơ bản như đăng ký, đăng nhập, mua/bán cổ phiếu đã đặt ra và đảm bảo được một số vấn đề an toàn khi cần thiết giao dịch. Sau đây chúng ta sẽ đi thử nghiệm vào các kịch bản cụ thể : - Kịch bản 1: tấn công bằng cách đăng nhập hệ thống để thành người dùng hợp pháp. Khi đăng nhập, hệ thống yêu cầu người dùng phải xác thực bằng cách nhập tài khoản và mật khẩu, mật khẩu được lưu trong biến session và được giải phóng sau khi người dùng đăng xuất để tránh kiểu tấn công. o Ấn định phiên làm việc (Session Fixation): Là 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 session 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 session ID đó và nghiễm nhiên trở thành người dùng hợp lệ. o Đánh cắp phiên làm việc (Session Hijacking): Là 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. Người dùng bình thường khác sẽ không đăng nhập trái phép được vì không có tài khoản và mật khẩu Với người quản trị hệ thống (người nắm giữ cơ sở dữ liệu của người dùng) cũng không thể đăng nhập được vào hệ thống bởi kết quả lưu trong cơ sở dữ liệu không phải là mật khẩu “thô” mà là kết quả băm. Hàm băm lại là hàm một chiều nên dù biết kết quả băm cũng “khó” có thể tìm ra được văn bản gốc (mật khẩu gốc) để đăng nhập. - Kịch bản 2: tấn công vào dữ liệu trên đường truyền từ nhà đầu tư (client) đến công ty chứng khoán (server). [66] Các phương pháp mà attacker có thể sử dụng để tấn công dữ liệu trên đường truyền là: Sniffing, Man In The Middle,.. để từ đó, Hacker thu thập thông tin trên đường truyền, tập hợp lại để phân tích tìm thông tin cần thiết cho việc tấn công, hoặc ở mức độ cao hơn là sửa đổi thông tin của client gửi đến server hay mạo danh client gửi yêu cầu đến server. o Sniffing là một chương trình nghe trộm gói tin (còn gọi là chương trình phân tích mạng, chương trình phân tích giao thức hay chương trình nghe trộm). Nó là một phần mềm máy tính có khả năng chặn và ghi lại giao thông dữ liệu qua một mạng viễn thông số hoặc một phần của một mạng. Khi các dòng dữ liệu di chuyển qua lại một mạng, chương trình nghe trộm bắt lấy từng gói tin rồi giải mã và phân tích nội dung của nó. Tùy theo cấu trúc mạng (hub hay chuyển mạch), người ta có thể nghe trộm tất cả hoặc chỉ một phần của giao thông dữ liệu từ một máy trong mạng [7]. Giả danh địa chỉ MAC của card mạng máy tính bị tấn công, thay vì gói tin được truyền đến máy tính cần đến thì nó lại được chuyển đến máy tính có cài đặt ettercap trước rồi sau đó mới truyền đến máy tính đích. Đây là một dạng tấn công rất nguy hiểm được gọi là Man In The Middle, trong trường hợp này phiên làm việc giữa máy gửi và máy nhận vẫn diễn ra bình thường nên người sử dụng không hề hay biết mình đang bị tấn công. Hệ thống được cài đặt SSL cho máy chủ Web nên đảm bảo: o Các bên giao tiếp xác thực nhau tránh bị giả mạo. o Dữ liệu trên đường truyền được mã hoá đảm bảo sự bí mật. o Kiểm tra tính toàn vẹn dữ liệu. - Kịch bản 3: tấn công Web services bằng cách thực hiện các dịch vụ của nó khi không giao dịch hay không phải nhà đầu tư hợp pháp. Các khả năng tấn công xảy ra: o Hacker sửa dữ liệu của người dùng hợp pháp như số tiền tăng/giảm của nhà đầu tư, làm sai lệch thông tin đến Web services. [67] o Hacker sẽ tìm cách để thực hiện các dịch vụ trái phép như tăng/giảm số lượng tiền trong ngân hàng mà không phải thông qua giao dịch mua bán cổ phiếu của công ty chứng khoán. Web service sử dụng công cụ WSE3.0 và giao dịch được hệ thống xác nhận qua hai lần mật khẩu (mật khẩu tài khoản chứng khoán, mật khẩu tài khoản ngân hàng), xác thực người dung nên đảm bảo chỉ đúng nhà đầu tư mới thực hiện được giao dịch. [68] CHƯƠNG 6 Kết Luận 1. Tổng kết Web Service đã và đang được triển khai và áp dụng trong nhiều lĩnh vực đời sống như ngân hàng, chứng khoán…và ngày càng trở lên phổ biến. Cùng với sự phát triển của nó là những đòi hỏi về tính an toàn, khả năng bảo mật…Bằng việc sử dụng các kỹ thuật đảm bảo an ninh web service sẽ giúp cho người sử dụng dịch vụ Web trở nên an tâm hơn. Việc chọn cơ chế an toàn cho dịch vụ Web phải đòi hỏi sao cho người dùng không cảm thấy quá phức tạp hay gò bó mà phải tạo nên sự trong suốt với người dùng. Do đó, chọn cơ chế an toàn nào trong dịch vụ Web 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ế an ninh dịch vụ Web 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 rất cần thiết. 2. Kết quả đạt được của luận văn Sau thời gian nghiên cứu tài liệu, tìm hiểu các chương trình mã nguồn mở, tôi đã hoàn thành luận văn với bài toán ban đầu đặt ra là “nghiên cứu an ninh dịch vụ web”. Với việc lựa chọn chương trình dịch vụ chứng khoán và kết hợp để đảm bảo an ninh cho các hoạt động được thực thi trên đó. Cho đến thời điểm hiện tại, luận văn đã đạt được một số kết quả sau: - Phân tích bài toán và tính cấp thiết của việc đảm bảo an toàn cho các web service. Đưa ra hướng phát triển cho bài toán. - Nghiên cứu về kiến trúc hướng dịch vụ SOA, Web Service và các thành phần của nó. Mối quan hệ ứng dụng kiến trúc SOA vào xây dựng web service và tích hợp chúng theo chuẩn. [69] - Tìm hiểu thực trạng bảo mật web service hiện nay, các công nghệ đảm bảo an ninh dịch vụ web như công nghệ bảo mật SSL và bộ thư viện WSE. - Cuối cùng, tập trung vào chạy chương trình chứng khoán, tích hợp các thẻ security trong bộ thư viện WSE vào để bảo mật thông tin cho các bên sử dụng. 3. Những hạn chế Để xây dựng được một hệ thống hoàn chỉnh có đầy đủ các chức năng và đảm bảo những yêu cầu đặt ra, cần rất nhiều thời gian. Trong thời gian nghiên cứu luận văn, cũng đã đạt được những kết quả nhất định, tuy nhiên vẫn còn nhiều hạn chế: - Chương trình khá đơn giản, với các chức năng đơn giản như đăng ký, đăng nhập, mua bán, hiển thị… - Không được đưa ra áp dụng thực tế nên sẽ có khả năng có nhiều bug mà người nghiên cứu không thể phát hiện ra. - Việc thiết kế cơ sở dữ liệu chưa thực sự tốt, vì luận văn chủ yếu tập trung vào vấn đề bảo mật cho web service. - Về bảo mật, chưa tìm hiểu hết được các loại thẻ security như WS-trust… mới chỉ dừng lại ở web service secrutiy policy. Và tích hợp với công cụ Web service enhancement. Nếu có điều kiện, trong tương lai tôi sẽ cố gắng tìm hiểu thêm về những mặt hạn chế của luận văn và cố gắng khắc phục để tạo ra một chương trình hoàn chỉnh và có thể áp dụng vào thực trạng ngành kinh doanh chứng khoán hiện nay. [70] Phụ lục Loose couping Tài liệu tham khảo Tiếng việt: 1. Bộ tài chính (2007), Quyết định 27/2007/QĐ-BTC về việc ban hành Quy chế tổ chức và hoạt động công ty chứng khoán. [7] 2. Vũ Đình Cường (2008), Tìm Hiểu Các Kiểu Tấn Công Cơ Bản & Phương Pháp Phòng Chống, Nhà xuất bản Lao động - Xã hội [7]. [8] 3. Thái Hồng Nhị, Phạm Minh Việt (2004), An toàn thông tin, Nhà xuất bản Khoa học và Kỹ thuật. [8] Tiếng anh 1. Microsoft (2008), Web Service Security Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0, Microsoft Hill. 2. July 2005 (Version 1.1), ws-securitypolicy. 3. Microsoft , Web Service Security, Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0 4. WS-Security 2004, Web Services Security, SOAP Message Security 1.0 5. OASIS Standard Specification, 1 February 2006, Web Services Security Kerberos Token Profile.