SOA cung cấp cơ chế cho phép các hệ thống hoạt động trêncác nền tảng khác nhau có thể giao tiếp với nhau.Thiết kế SOA tách riêng phần thực hiện dịch vụ với giao tiếp gọi dịch vụ.Điều này
KIẾN TRÚC HƯỚNG DỊCH VỤ
Thực trạng
Phần mềm ngày nay đang ngày càng trở nên phức tạp và đường như đang vượt khỏi khả năng kiểm soát của các mô hình phát triển phần mềm hiện có. Hàng chục năm qua, nhiều kiến trúc phần mềm đã được xây dựng và triển khai nhằm giải quyết các vấn đề này Thế nhưng, độ phức tạp phần mềm vẫn tiếp tục tăng và đường như đã trở nên vượt quá khả năng xử lý của các kiến trúc truyền thống.
Nguyên nhân khiến cho độ phức tạp của các hệ thống phần mềm không ngừng tăng cao như thế là do sự xuất hiện của nhiều công nghệ mới tạo nên môi trường không đồng nhất, trong khi nhu cầu về trao đổi, chia sẻ, tương tác giữa các hệ thống không thể đáp ứng được trong một môi trường như vậy Một nguyên nhân khác cũng góp phần đến tình trạng khó khăn như thế chính là vấn đề lặp trình đồng thời và không thể tái sử dụng.
Những vấn đề trước đó chưa giải quyết, mà nay các tổ chức lãnh đạo phải đối mặt với những thách thức mới: đáp ứng nhanh chóng các sự thay đổi về thiết bị, giảm chi phí phát triển, tăng tính tương thích và khả năng tái sử dụng, Tất cả tạo nên một áp lực nặng nề đối với các nhà phát triển phần mềm.
Một mô hình số mô hình kiến trúc phân tán
Ba kiến trúc phân tán nhóm em đánh giá là CORBA, DCOM và EJB Các kiến trúc này là sự mở rộng của các hệ thống hướng đối tượng bằng cách cho phép phân tán các đối tượng trên mạng Đối tượng có thể tồn tại trong không gian bên ngoài ứng dụng, hoặc trên một máy khác so với máy chứa ứng dụng, trong khi vẫn có thể được tham chiếu và sử dụng như một phần của ứng dụng.
2.1 CORBA - Common Object Request Broker Architecture CORBA, hay Các Object Request Broker Architecture Common, là một đặc điểm kỹ thuật được phát triển bởi Object Management Group (OMG). CORBA mô tả một cơ chế thông điệp mà các đối tượng phân phối qua mạng có thể giao tiếp với nhau mà không phụ thuộc vào nền tảng và ngôn ngữ sử dụng để phát triển chúng Điều này giúp tạo ra một môi trường phát triển phần mềm phân tán linh hoạt và khả năng tương tác giữa các đối tượng từ các nguồn khác nhau, bất kỳ ngôn ngữ nào cũng có thể tương tác với nhau thông qua CORBA. Ưu điểm của CORBA là các lập trình viên có thể chọn bất kỳ ngôn ngữ, nền tảng phần cứng, giao thức mạng và công nghệ để phát triển mà vẫn thỏa mãn các tính chất của CORBA Tuy nhiên, CORBA có một số nhược điểm như ngôn ngữ lập trình cấp thấp, rất phức tạp, khó hiểu và cần một đội ngũ phát triển có kinh nghiệm Ngoài ra, các đối tượng CORBA cũng khó có thể tái sử dụng.
EJB (Enterprise JavaBeans) là một thành phần nằm ở phía server-side của ứng dụng web hoặc có thể hiểu là một phần trong kiến trúc Java EE EJB là nền tảng cho phép xây dựng phần mềm có tính di động, khả năng tái sử dụng cao, và tính bảo mật, đây là những đặc điểm quan trọng của EJB.Một điểm quan trọng khác là EJB hướng tới các ứng dụng có quy mô lớn và phù hợp với mô hình phân tán EJB được chia làm ba loại chính:
Entity beans: Tương tự như các đối tượng thực thể (entity object), chứa thông tin tác vụ và các phương thức hoạt động của nó.
Session beans: Quản lý các nhiệm vụ tác nghiệp của Client và Server. Client tương tác với server bằng cách triệu hồi các phương thức session bean thông qua một môi trường mạng, có thể là HTTP Session Bean sau đó gọi tới entity bean tương ứng để thực hiện tác vụ mà client yêu cầu Session bean có thể chia làm hai loại chính:
Stateless: Trạng thái client không được lưu lại cho những lần giao dịch sau Mỗi giao dịch là độc lập với nhau.
Stateful: Trạng thái giao tác của client được lưu trữ lại phục vụ cho những lần kế tiếp.
Message-driven beans: Chịu trách nhiệm điều khiển các tin nhắn giữa client và server.
2.3 DCOM - Distributed Component Object Model
DCOM (Distributed Component Object Model) là một mô hình phân tán dễ triển khai với chi phí thấp, hỗ trợ việc tích hợp chặt chẽ giữa các ứng dụng và hệ điều hành Mô hình Component Object Model (COM) định nghĩa cách các thành phần và Máy khách liên lục trao đổi với nhau trên cùng một máy. DCOM mở rộng COM bằng cách sử dụng các giao thức trên mạng chuẩn khi cần trao đổi dữ liệu với máy khác DCOM hỗ trợ kết nối giữa các đối tượng và có thể được thay đổi trong khi đang chạy Các đối tượng DCOM được triển khai bên trong các gói nhóm phân chia chứa các lệnh quản lý chu kỳ sống của đối tượng và việc đăng ký nó
DCOM mang lại nhiều ưu điểm như tính ổn định, không phụ thuộc vào vị trí địa lý, quản lý kết nối hiệu quả và dễ dàng mở rộng, là một lựa chọn tốt cho các doanh nghiệp sử dụng công nghệ của Windows để chạy các ứng dụng có yêu cầu cao về chính xác và ổn định Tuy nhiên, các công nghệ của Microsoft có một nhược điểm lớn là chúng hạn chế trên nền tảng Windows.
Khái niệm SOA
Theo đó SOA là một phong cách kiến trúc để tạo ra một công trình kiến trúc IT Kiến trúc này khai thác các nguyên tắc của hệ thống dịch vụ để tạo ra các mối quan hệ chặt chẽ giữa doanh nghiệp và hệ thống thông tin, nhằm hỗ trợ các doanh nghiệp.
Kiến trúc hệ thống dịch vụ là một phương tiện kết nối với việc thiết kế và tích hợp phần mềm, chức năng, hệ thống dưới dạng mô-đun, với mỗi mô-đun có tính chất "kết nối lỏng" và có khả năng truy cập thông qua môi trường mạng Một cách đơn giản, hệ thống SOA là một tập hợp các dịch vụ được chuẩn hóa trên mạng trao đổi với nhau trong ngữ cảnh của một tiến trình nghiệp vụ.
SOA đưa ra giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện nay như sự phức tạp, không linh hoạt và không ổn định Một hệ thống triển khai theo mô hình SOA có khả năng mở rộng dễ dàng và liên kết tốt. Điều này là cơ sở và nền tảng cho việc tích hợp, tái sử dụng lại những tài nguyên hiện có SOA cung cấp cơ chế cho phép các hệ thống hoạt động trên các nền tảng khác nhau có thể giao tiếp với nhau.
Thiết kế SOA tách riêng phần thực hiện dịch vụ với giao tiếp gọi dịch vụ. Điều này tạo ra một giao tiếp nhất quán cho ứng dụng khách Thay vì xây dựng các ứng dụng lớn và phức tạp, nhà phát triển sẽ xây dựng các dịch vụ tinh giản có thể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ. Điều này cho phép tái sử dụng phần mềm hiệu quả hơn và tăng tính linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà không ảnh hưởng đến ứng dụng của máy khách.
Thực tế, việc hướng tới một hệ thống SOA không phải là mới CommonObject Request Broker Architecture (CORBA) và mô hình DistributedComponent Object Model (DCOM) của Microsoft cũng như Enterprise JavaBean (EJB) của Java đã cung cấp tính năng này từ lâu Tuy nhiên, những phương tiện này còn gặp phải những vấn đề khó khăn như trên và SOA không chỉ là một cải tiến đáng kể giúp giải quyết những yếu điểm của các công nghệ trước đó mà còn mang lại nhiều ưu điểm nổi trội hơn.
Đối tượng trong hệ thống SOA
Service Provider: Cung cấp dịch vụ phục vụ cho một nhu cầu nào đó
Service Consumer: Người dùng sử dụng các dịch vụ của Service Provider
Service Registry: Nơi lưu trữ thông tin về các dịch vụ khác nhau, Service
Service Broker: Nó quản lý việc định tuyến, chuyển đổi định dạng, xác thực, và quản lý luồng thông điệp trong hệ thống
Nguyên tắc và tính chất của SOA
5.1 Tách Biệt Dịch vụ (Service Separation):
Các dịch vụ thực hiện quá trình tương tác chủ yếu thông qua thành phần giao tiếp Thành phần giao tiếp sẽ quy định định dạng thông điệp nào sẽ được chấp nhận và thông điệp nào sẽ không được xử lý Đây là cách duy nhất mà các đối tượng bên ngoài có thể truy cập thông tin và chức năng của dịch vụ Chỉ cần gửi các thông điệp theo các định dạng được định nghĩa mà không cần quan tâm đến cách xử lý của dịch vụ như thế nào
5.2 Các dịch vụ tự hoạt động:
Các dịch vụ cần được triển khai và hoạt động như những thực thể độc lập mà không phụ thuộc vào một dịch vụ khác Dịch vụ phải có tính bền vững cao, nghĩa là nó sẽ không bị sụp đổ khi có sự cố Để thực hiện điều này, dịch vụ cần duy trì đầy đủ thông tin cần thiết cho quá trình hoạt động của mình để có thể tiếp tục hoạt động trong trường hợp một dịch vụ cộng tác bị hỏng và để tránh các cuộc tấn công từ bên ngoài (như gửi thông điệp lỗi hoặc gửi thông điệp quá tải) bằng cách sử dụng các kỹ thuật về an toàn và bảo mật.
5.3 Các dịch vụ chia sẻ lược đồ:
Các dịch vụ nên cung cấp thành phần giao tiếp ra bên ngoài, và hỗ trợ chia sẻ cấu trúc thông tin, ràng buộc dữ liệu thông qua các loại dữ liệu chuẩn (như ngôn ngữ chung, hệ thống chuẩn) Như vậy, hệ thống sẽ có tính liên kết và khả năng dễ mở rộng.
5.4 Tính tương thích dựa trên chính sách:
Một dịch vụ khi muốn tương tác với một dịch vụ khác thì phải thỏa mãn các chính sách và yêu cầu của dịch vụ đó như là mức độ hòa nhập, bảo mật Để thực hiện điều này, mỗi dịch vụ cần phải cung cấp công khai các yêu cầu, chính sách đó.
5.5 Loose coupling ( kết nối lỏng )
SOA (Kiến trúc Dịch vụ Hướng) ủng hộ mối quan hệ "lỏng lẻo" giữa các dịch vụ, nghĩa là các dịch vụ không ràng buộc quá nhiều vào nhau Ý nghĩa: Các thành phần trong hệ thống nên liên kết "lỏng lẻo", có nghĩa là chúng không phụ thuộc quá mức lớn vào nhau Điều này giúp hệ thống linh hoạt và dễ dàng thay đổi khi cần thiết mà không làm ảnh hưởng đến các thành phần khác
Lợi ích: Giảm sự phụ thuộc giữa các thành phần, tăng khả năng thay đổi và mở rộng mà không làm ảnh hưởng đến các thành phần khác.
5.6 Tái sử dụng lại dịch vụ
Bởi vì các dịch vụ được cung cấp trên mạng và được đăng ký ở một nơi nhất định, nên chúng dễ dàng được tìm thấy và tái sử dụng Các dịch vụ có thể được tái sử dụng bằng cách kết hợp lại với nhau để đáp ứng nhiều mục đích khác nhau Tái sử dụng các dịch vụ cũng giúp loại bỏ những thành phần trùng lặp và tăng độ vững chắc trong cài đặt, đồng thời đơn giản hóa quản trị.
5.7 Quản lý các chính sách
Khi sử dụng các dịch vụ chia sẻ trên mạng, tùy thuộc vào từng ứng dụng sẽ có một tập hợp luật kết hợp riêng gọi là chính sách và thiết kế tách biệt Nếu không sử dụng chính sách, nhóm nhân viên phát triển phần mềm, nhóm điều hành và nhóm hỗ trợ phải làm việc với nhau trong quá trình triển khai và kiểm thử những chính sách đó Ngược lại, nếu sử dụng chính sách, những nhân viên phát triển phần mềm chỉ cần tập trung vào quy trình nghiệp vụ trong khi nhóm điều hành và nhóm hỗ trợ tập trung vào các luật kết hợp.
Với quy mô và độ phức tạp của các ứng dụng phân tán hiện nay, khả năng phục hồi của một hệ thống sau khi xảy ra lỗi trở thành một yếu tố quan trọng Một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà không cần sự can thiệp của con người.
Trong kiến trúc ảnh hưởng dịch vụ (SOA), các dịch vụ luôn có thể hoạt động hoặc ngừng bất kỳ lúc nào, đặc biệt là đối với những ứng dụng tổng hợp từ nhiều dịch vụ của nhiều tổ chức khác nhau Độ tin cậy phụ thuộc vào khả năng phục hồi của phần cứng sau khi xảy ra lỗi Một khía cạnh khác ảnh hưởng đến độ tin cậy là kiến trúc mà ứng dụng được xây dựng trên đó Một kiến trúc hỗ trợ kết nối và thực thi động khi chạy sẽ có khả năng tự phục hồi cao hơn so với một hệ thống không hỗ trợ những tính năng này.
Service-Oriented Architecture (SOA) là một phương pháp tiếp cận kiến trúc phần mềm, tập trung vào khả năng tương tác và cộng tác giữa các hệ thống khác nhau. Trong SOA, mỗi dịch vụ được xem như là một đơn vị tự đủ, cung cấp một giao diện mà các hệ thống khác có thể gọi và tương tác.
Một số mô hình triển khai SOA
6.1 Service Registry Đây là mô hình truyền thống để định vị và liên kết các dịch vụ trong một hệ thống SOA Mô hình này về cơ bản chỉ sử dụng các chuẩn Web services thông thường như SOAP, WSDL và UDDI Các liên kết dịch vụ trong mô hình là kết nối tĩnh và phải được định nghĩa trong quá trình thiết kế, điều này làm cho mô hình trở nên cứng nhắc Có một cách tiến xa hơn để làm cho mô hình này linh hoạt hơn là tìm kiếm và định vị các dịch vụ khi chạy UDDI hỗ trợ nhiều cấu hình khác nhau cho cùng một dịch vụ cung cấp bởi nhiều nhà cung cấp dịch vụ khác nhau.
Trong mô hình cơ bản, tất cả các thông điệp được trung chuyển qua Service broker Dịch vụ này có thể thực hiện nhiều chức năng như định tuyến dựa trên dữ liệu thông điệp, xử lý lỗi, chuyển đổi thông điệp, chia tải và lọc thông tin Nó cũng có thể cung cấp các dịch vụ bảo mật, chuyển đổi giao thức, lưu vết Tuy nhiên, Service broker có thể tạo ra hiện tượng nghẽn cổ chai và là điểm có khả năng hỏng hóc.
Mô hình broker phân tán là một bước tiến mới, trong đó mỗi nền tảng dịch vụ có một Broker cục bộ cho phép giao tiếp với một Service broker trung tâm và giao tiếp trực tiếp với các Service broker cùng cấp trên các nền tảng dịch vụ khác nhau Điều này giúp giảm nguy cơ nghẽn cổ chai và tăng tính đồng nhất trong hệ thống.
6.3 Service Bus Đây là mô hình mới nhất trong ba mô hình, và nó đã được sử dụng trong các sản phẩm thương mại lớn như IBM, BEA Service bus cũng là mô hình có tính kết nối lỏng nhất trong các mô hình, trong đó các dịch vụ không kết nối trực tiếp với nhau mà thay vào đó tạo thành một mạng Service bus.
Lợi ích khi sử dụng SOA
Hệ thống đảm bảo các dịch vụ có tính độc lập cao
Rút ngắn thời gian đưa ra thị trường
Tăng tính linh hoạt và khả năng triển khai cài đặt
Tăng khả năng mở rộng và sẵn sàng
Hỗ trợ đa thiết bị và nền tảng
WEB SERVICE
Giới thiệu về Service
Service là một hệ thống có khả năng nhận một hoặc nhiều yêu cầu xử lý và sau đó đáp ứng bằng cách trả về một hoặc nhiều kết quả Quá trình nhận yêu cầu và trả kết quả về được thực hiện thông qua các giao diện mà trước đó đã được định nghĩa Thông thường, việc giao tiếp này được thực hiện trên các giao diện đã được chuẩn hóa và sử dụng rộng rãi.
Một hệ thống được thiết kế theo kiểu hướng Service là một hệ thống trong đó các chức năng của hệ thống được xây dựng dựa trên các service có độ kết dính thấp Các service trong hệ thống giao tiếp với nhau thông qua việc gửi nhận các thông điệp
Mỗi service được xây dựng dựa trên các giao diện chuẩn hóa đã được sử dụng rộng rãi Chi tiết hiện thực của mỗi service sẽ không được thể hiện ra bên ngoài Mỗi service chỉ công bố một số các giao diện của nó mà người dùng có thể sử dụng để gửi các yêu cầu và nhận kết quả trả về.
Mỗi service có tính độc lập cao, có thể được xây dựng và đưa vào sử dụng mà không phụ thuộc vào các service khác.
Trao đổi dữ liệu: Các service không truyền các class và type trực tiếp Thay vào đó, các class và type sẽ được đặc tả hình thức.
Giới thiệu tổng quan về WebService
Web Service là một giao diện truy cập mạng đến các ứng dụng chức năng, được xây dựng từ việc sử dụng các công nghệ chuẩn Internet
Thuật ngữ Web Service diễn tả một cách thức tích hợp các ứng dụng trên nền website liên kết với nhau bằng cách sử dụng các công nghệ XML, SOAP, WSDL, UDDI trên nền tảng các giao thức Internet với mục tiêu tích hợp ứng dụng và truyền thông điệp XML được sử dụng để ánh dấu dữ liệu, SOAP được dùng để truyền dữ liệu, WSDL được sử dụng để mô tả các dịch vụ có sẵn và UDDI được sử dụng để liệt kê những dịch vụ nào hiện tại đang có sẵn để có thể sử dụng Web Service cho phép các tổ chức có thể trao đổi dữ liệu với nhau mà không cần phải có kiến thức hiểu biết về hệ thống thông tin nằm sau Firewall.
Không giống như mô hình khách/chủ truyền thống, Web Service không cung cấp cho người dùng một giao diện đồ họa nào Web Service đơn thuần chỉ là việc chia sẻ các dữ liệu logic và xử lý các dữ liệu đó thông qua một giao diện chương trình ứng dụng được cài đặt xuyên suốt trên mạng máy tính Web Service cho phép các ứng dụng khác nhau từ các nguồn khác nhau có thể giao tiếp với các ứng dụng khác mà không đòi hỏi nhiều thời gian lập trình, do tất cả các quá trình giao tiếp đều tuân theo định dạng XML, cho nên Web Service không phụ thuộc vào bất kỳ hệ điều hành hay ngôn ngữ lập trình nào.
Web Service cung cấp tính trừu tượng cho các giao diện chuẩn, cho nên sẽ không xuất hiện bất kỳ vấn đề gì trong quá trình tương tác Web Service cho phép giao tiếp giữa các nền tảng khác nhau có thể hoạt động cùng nhau theo nguyên tắc tạo ra một nền tảng trung gian có liên quan.
Tóm lại, Web Service là:
Làm việc xuyên qua tường lửa và proxy.
Sẵn sàng tương thích với các nền tảng máy trạm khác nhau. Một dịch vụ phần mềm được trình bày trên web thông qua giao thức SOAP, được mô tả bằng một tệp WSDL và được đăng ký trên UDDI."
Cho phép khách/chủ tương tác với nhau chủ yếu trong môi trường khác nhau
XML và HTTP là nền tảng kỹ thuật chính Phần lớn kỹ thuật của Web Service được xây dựng trong những dự án nguồn mở, nên độc lập và vận hành tốt với nhau
Web Service rất linh động: với UDDI và WSDL, việc mô tả và phát triển Web Service có thể tự động hóa.
Web Service bao gồm nhiều mô-đun và có thể công bố trên mạng Internet
Web Service có thể chia sẻ và gọi thực hiện qua mạng và có độ an toàn riêng.
Mô hình Web Service ưu điểm, nhược điểm
Nhà cung cấp đăng ký Dịch vụ Web với UDDI.
Người sử dụng tìm kiếm dịch vụ trên UDDI qua một URL thích hợp.
UDDI trả về một bản mô tả WSDL cho nhà cung cấp.
Người sử dụng triệu gọi dịch vụ bằng một cuộc gọi SOAP tới nhà cung cấp.
Nhà cung cấp trả về kết quả của cuộc gọi SOAP cho người sử dụng.
Web Service cho phép chương trình được viết bằng các ngôn ngữ khác nhau trên các nền tảng khác nhau tương tác được với nhau dựa trên một nền tảng tiêu chuẩn Đơn giản (chỉ sử dụng URL)
Làm việc với các giao thức chuẩn Web như XML, HTTP và TCP/IP
Sự an toàn của máy chủ và cơ sở dữ liệu luôn được bảo mật một cách chắc chắn.
Web Service giảm giá thành cho việc tích hợp các hệ thống khác nhau
Phụ thuộc vào tốc độ đường truyền Internet,
Web Service thiếu cơ chế khôi phục dữ liệu tin cậy để đảm bảo giao dịch được khôi phục lại trạng thái ban đầu trong trường hợp xảy ra sự cố
Số lượng các ứng dụng cộng tác cùng hoạt động sẽ ảnh hưởng tới hiệu suất tối ưu của Web Service Ứng dụng Web Service là các ứng dụng sử dụng rất nhiều thông điệp, khả năng bùng nổ số lượng giao dịch trao đổi có thể làm hệ thống máy chủ ứng dụng và kiến trúc hạ tầng hệ thống thông tin của doanh nghiệp trở nên không ổn định
Vì Web Service đòi hỏi kết nối thông qua nhiều máy chủ trung gian, băng thông/tốc độ của hạ tầng mạng và các yếu tố liên quan tới hệ thống đóng một vai trò quan trọng trong việc cải thiện hiệu suất của toàn bộ các ứng dụng Web Service.
Các thành phần chính của Web Service
3.1.Giao thức giao vận HTTP
Tầng giao vận liên quan tới cơ chế sử dụng để chuyển yêu cầu dịch vụ và thông tin phản hồi từ phía nhà cung cấp dịch vụ tới người sử dụng dịch vụ.
Có rất nhiều tiêu chuẩn sử dụng xung quanh Web Service, nhưng phổ biến nhất vẫn là giao thức HTTP.
Giao thức HTTP thường được sử dụng đối với yêu cầu dịch vụ và phản ứng. Ưu điểm:
HTTP là nền tảng hạ tầng phổ biến và sẵn sàng nhất
Giao thức HTTP hoàn toàn miễn phí và phát triển trên rất nhiều loại hệ thống
Hầu hết mọi tổ chức đều chấp nhận cho phép trao đổi thông tin dựa trên giao thức HTTP vượt qua tường lửa bảo vệ.
HTTP là một giao thức đơn giản và không có tính trạng thái, không được thiết kế đặc biệt cho mục đích vận chuyển dữ liệu của các ứng dụng
Giao thức này không hỗ trợ lưu trữ trạng thái và không phải là một giao thức đáng tin cậy phù hợp với nhu cầu truyền dữ liệu
3.2.Giao thức truyền thông SOAP
SOAP là giao thức được định nghĩa để chuyển một XML message từ A đến
B, sử dụng giao thức web chuẩn HTTP (hoạt động trên cổng 80) qua giao thức Internet TCP/IP.
SOAP là giao thức truyền thông giữa các ứng dụng.
SOAP được thiết kế để liên kết qua Internet và làm việc qua tường lửa.
SOAP độc lập nền tảng, độc lập ngôn ngữ.
SOAP dựa trên XML, đơn giản và dễ mở rộng.
SOAP được thiết kế đơn giản và có khả năng mở rộng.
Tất cả các thông điệp SOAP đều được mã hóa bằng XML.
SOAP sử dụng một giao thức truyền dữ liệu riêng.
SOAP không bị ràng buộc bởi ngôn ngữ lập trình hoặc công nghệ cụ thể.
SOAP không quan tâm đến công nghệ được sử dụng để thực hiện, miễn là người dùng sử dụng các thông điệp theo định dạng XML.
Một thông điệp SOAP là một văn bản XML được xác định bởi một thành phần Envelope, bao gồm một thành phần Body bắt buộc và một thành phần Header không bắt buộc Thành phần Body có khả năng chứa nhiều Body Entries Thành phần Fault, không bắt buộc, chỉ xuất hiện trong thông điệp khi có báo cáo về một quá trình xử lý ngoại lệ.
Phần tử Body mô tả về phương thức dưới dạng XML và chỉ chứa các tham số hoặc các trường trong các thẻ.
Dữ liệu được mã hóa và gói vào trong phần tử Body của một thông điệp và được gửi đến Host Host giải mã dữ liệu được định dạng XML về dạng đối tượng ban đầu.
SOAP Remote Procedure Call (RPC encoding): Là kiểu mã hóa đơn giản nhất cho người phát triển Bạn gọi tới một đối tượng từ xa, kèm theo là các tham số cần thiết Các tham số được chuyển lần lượt dưới dạng XML và truyền đến đích sử dụng giao thức giao tiếp như HTTP hay SMTP Sau khi nhận được, dữ liệu được chuyển trở lại thành đối tượng và kết quả được trả về cho phương thức gọi SOAP RPC xử lý tất cả công việc mã hóa và giải mã, thậm chí đối với các kiểu dữ liệu phức tạp.
SOAP Remote Procedure Call Literal encoding (SOAP RPC-literal): Sử dụng một phương thức mã hóa do người sử dụng chỉ định để mã hóa và giải mã dữ liệu dưới dạng XML.
SOAP document-style encoding: Toàn bộ XML được gửi đến máy chủ và người lập trình xác định giao thức giao tiếp, phân tích dữ liệu dưới dạng XML trong thông điệp yêu cầu và đáp ứng để tìm dữ liệu cần thiết.
3.2.5 Quá trình xử lý thông điệp a) Chuyển Yêu Cầu từ Khách Hàng:
Processor của khách hàng chuyển lời yêu cầu phương thức vào thông điệp SOAP. b) Truyền Thông Điệp qua Tầng Giao Tiếp:
Thông điệp được truyền qua tầng giao tiếp sử dụng HTTP và SMTP. c) Xử Lý ở Processor của Nơi Cung Cấp:
Thông điệp được phân tích thành lời yêu cầu phương thức.
Nơi cung cấp thực hiện bước logic cần thiết.
Kết quả được trả về cho processor của nơi cung cấp. d) Truyền Thông Điệp Phản Hồi:
Thông điệp phản hồi được truyền qua tầng giao tiếp. e) Xử Lý ở Processor của Khách Hàng:
Processor của khách hàng phân tích thông điệp phản hồi.
Kết quả được đưa ra dưới dạng một đối tượng.
3.3.Ngôn ngữ đánh dấu mở rộng XML
XML là nền tảng của Web Service và được sử dụng để trao đổi dữ liệu
XML là một chuẩn nổi tiếng cho việc tổ chức, lưu trữ và trao đổi dữ liệu
XML được hỗ trợ bởi hầu hết các ngôn ngữ lập trình hiện đại (DotNet, Java…)
XML được sử dụng rộng rãi trong việc trao đổi dữ liệu trên môi trường Internet
XML sử dụng các thẻ để tổ chức và lưu trữ dữ liệu.
XML được thiết kế để lưu trữ và trao đổi dữ liệu mà không hiển thị cách dữ liệu được hiển thị
XML có thể trao đổi dữ liệu giữa các hệ thống không tương thích.
3.3.3 Nguyên tắc cấu trúc a) Cấu trúc
XML hợp khuôn định: Khai báo XML và dữ liệu XML.
XML hợp lệ: Là tài liệu được kết hợp với định nghĩa kiểu tử liệu (Document Type Definition) và tuân theo tiêu chuẩn đó. b) Nguyên tắc
Các khai báo XML cần được đặt ở dòng đầu tiên của tài liệu.
Mọi phần tử XML đều phải có thẻ đóng: />
Tất cả các tài liệu XML phải có thẻ gốc, trong đó thẻ đầu tiên là thẻ gốc.
Các thẻ XML phân biệt chữ hoa_chữ thường và khoảng trắng được giữ lại.
Các giá trị thuộc tính phải luôn được đặt trong ngoặc kép.
3.3.4 Ưu nhược điểm a) Ưu điểm
XML mô tả dữ liệu ở dạng văn bản, cho phép phần lớn chương trình và phần mềm đọc được file mà không phụ thuộc vào chương trình hay phần mềm cụ thể nào. Đọc - Phân tích dữ liệu tuyệt vời
XML có khả năng đọc - phân tích nguồn dữ liệu nhanh chóng và dễ dàng, là công cụ hữu ích trong việc trao đổi dữ liệu giữa các hệ thống và chương trình.
Hỗ trợ thiết kế website:
XML được sử dụng trong Remote Procedure Calls để hỗ trợ dịch vụ trong quá trình thiết kế website.
Người dùng có thể tạo các file XML nhanh chóng thông qua các thao tác đơn giản và dễ nhớ. b) Nhược điểm
Kích thước tệp lớn hơn nhiều so với các định dạng khác, gây khó khăn trong việc truyền tải, lưu trữ và xử lý dữ liệu, đặc biệt là đối với các tệp có kích thước quá lớn
Cấu trúc phức tạp của nó cũng có thể gây chậm trễ trong quá trình xử lý, nhất là với các tệp dữ liệu lớn.
3.4.Ngôn ngữ mô tả dịch vụ WSDL
WSDL là ngôn ngữ dựa trên XML và mô tả cách thức truy cập Web Service
Thông thường, WSDL được sử dụng với SOAP và cấu trúc XML để cung cấp Web Service qua Internet Một máy khách kết nối tới Web Service có thể đọc WSDL để xác định các hàm hiện có trên máy chủ Khách hàng có thể sử dụng SOAP để gọi một trong nhiều hàm được liệt kê trong WSDL.
Một WSDL hợp lệ gồm có hai phần:
Phần giao diện mô tả giao diện và giao thức kết nối.
Phần thực hiện mô tả thông tin để truy xuất service.
Cả hai thành phần này sẽ được lưu trong hai tập tin XML, bao gồm: Tập tin giao diện service (cho phần 1)
Tập tin thực hiện service (cho phần 2)
3.4.3 Ưu nhược điểm của WSDL a) Ưu điểm
Nếu một ứng dụng có kế hoạch sử dụng Web Service, WSDL là một yêu cầu cơ bản bắt buộc để đáp ứng nhu cầu công bố giao tiếp và thỏa thuận cho các dịch vụ khác nhau. b) Nhược điểm
Tài liệu không cung cấp một số thông tin mà người sử dụng có nhu cầu biết, bao gồm:
Ai là nhà cung cấp dịch vụ?
Dạng kinh doanh mà nhà cung cấp dịch vụ đang hoạt động là gì? Các dịch vụ khác mà nhà cung cấp này cung cấp là gì?
Chất lượng dịch vụ này sẽ được đảm bảo như thế nào?
Dịch vụ này có phải là miễn phí hay có thu phí không?
3.5.Tích hợp mô tả trình bày tổng hợp UUID
UDDI (Universal Description, Discovery, and Integration) là một chuẩn công nghiệp được sử dụng để công bố và tìm kiếm thông tin về các dịch vụ web Nó định nghĩa một khung thông tin cho việc mô tả và phân loại tổ chức, dịch vụ, cũng như chi tiết kỹ thuật về giao diện của các dịch vụ web được cung cấp
UDDI cung cấp cách thức lưu trữ và truy xuất thông tin về các dịch vụ, đặc biệt là nhà cung cấp dịch vụ và các chi tiết liên quan đến giao tiếp kỹ thuật.
UDDI sử dụng các chuẩn đã tồn tại như ngôn ngữ đánh dấu rộng (XML) và giao thức truy cập đối tượng đơn giản (SOAP) Tất cả các triển khai của UDDI đều hỗ trợ các đặc tả UDDI để đảm bảo tính tương thích và tích hợp dễ dàng giữa các hệ thống khác nhau sử dụng UDDI.
UDDI là một phần chứa thông tin về các dịch vụ web, được xây dựng trên nền tảng NET
UDDI được mô tả bởi ngôn ngữ WSDL và thực hiện giao tiếp thông quaSOAP
Nhiệm vụ chính của UDDI là tìm kiếm đúng dịch vụ và xác định cách kích hoạt dịch vụ đó.
Các loại Web Service
SOAP là viết tắt của Simple Object Access Protocol Nó là một giao thức dựa trên XML để truy cập các web service.
SOAP được khuyến cáo bởi W3C cho giao tiếp giữa hai ứng dụng.
SOAP là giao thức dựa trên XML Đó là nền tảng độc lập và ngôn ngữ độc lập Bằng cách sử dụng SOAP, bạn sẽ có thể tương tác với các ứng dụng ngôn ngữ lập trình khác. Ưu điểm của SOAP web service
WS Security: SOAP định nghĩa bảo mật riêng của nó được gọi là WS Security.
Ngôn ngữ và nền tảng độc lập: các SOAP web service có thể được viết bằng bất kỳ ngôn ngữ lập trình nào và được thực thi trong bất kỳ nền tảng nào.
Nhược điểm của SOAP web service
Chậm: SOAP sử dụng định dạng XML phải được phân tích cú pháp Các ứng dụng SOAP phải tuân theo nhiều tiêu chuẩn Vì vậy, nó là chậm và chiếm nhiều băng thông và tài nguyên.
Phụ thuộc WSDL: SOAP sử dụng WSDL và không có bất kỳ cơ chế nào khác.
REST là viết tắt của REpresentational State Transfer.
REST là một kiểu kiến trúc không phải là một giao thức. Ưu điểm của RESTful web service
Nhanh: RESTful web service nhanh vì không có đặc tả nghiêm ngặt như SOAP Nó chiếm ít băng thông và tài nguyên hơn.
Ngôn ngữ và nền tảng độc lập: RESTful web service có thể được viết bằng bất kỳ ngôn ngữ lập trình nào và được thực hiện trong bất kỳ nền tảng nào.
Có thể sử dụng SOAP: RESTful web service có thể sử dụng các SOAP web servie khi thực hiện.
Cho phép nhiều định dạng dữ liệu khác nhau: RESTful web service cho phép định dạng dữ liệu khác nhau như Plain Text, HTML, XML và JSON.
Sự khác nhau giữa SOA và Web Service
Trong chương trình, chúng ta nghiên cứu về cấu trúc SOA và các khái niệm cũng như thành phần Web Service Việc triển khai một hệ thống SOA và tích hợp với Web Service không phải là điều dễ dàng Ngày nay, điều này không còn cần thiết nữa vì trong một hệ thống SOA, các chức năng này được
"dịch vụ hóa" và cung cấp ra cho các đối tượng bên ngoài truy cập thông qua các phương thức chuẩn của Web Service.
Rõ ràng, theo định nghĩa thì Web Service là một công nghệ trong khi SOA là một triết lý thiết kế phần mềm Web Service đư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 là Web Service Tuy nhiên, SOA và Web Service có mối quan hệ tương hỗ: sự phổ biến của Web Service thúc đẩy sự phát triển của SOA, và kiến trúc tốt của SOA sẽ giúp Web Service thành công.
SOA là một phương pháp thiết kế, trong khi Web Service chỉ là một công nghệ SOA có thể được thực hiện thông qua công nghệ Web Service 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.
AN TOÀN BẢO MẬT WEB SERVICE
Tổng quan về an toàn WebService
Từ những giai đoạn đầu tiên của Internet, các doanh nghiệp luôn đòi hỏi rất khắt khe về vấn đề bảo mật trong thương mại điện tử Những hạn chế của tường lửa như việc giám sát các gói tin được truyền tải dựa trên giao thức HTTP là chưa có; điều này có thể khiến cho máy chủ có nguy cơ bị những cuộc tấn công không hề biết trước Đã có rất nhiều thuật toán đưa ra cơ chế và những chuẩn về bảo mật như mã hoá thông tin, chữ ký số…; nhưng hầu hết chỉ tập trung vào việc đưa ra các dạng bảo vệ dữ liệu trong quá trình trao đổi, không quan tâm đến việc xác nhận các nghi thức mà các bên cần thực hiện khi tương tác với nhau.
Ngoài ra, những chuẩn chung về việc chỉ ra nghi thức giao tiếp giữa Web Service là chưa có, đã khiến cho các sản phẩm hỗ trợ bảo mật của Web Service không thể tích hợp với nhau, mặc dù các sản phẩm này đã được thiết kế dựa trên chuẩn về bảo mật cho web service.
Một chuẩn an toàn chung cho các hệ thống giao dịch trên mạng thường phải tập trung vào những điều sau :
Identification: xác định người truy cập tài nguyên hệ thống.
Authentication: chứng thực người muốn sử dụng tài nguyên.
Authorization: cho phép giao dịch khi đã xác nhận danh tính người truy cập.
Integrity: toàn vẹn thông tin trên đường truyền.
Confidentiality: bảo mật, không ai có thể đọc thông tin trên người.Auditing: kiểm tra, tất cả các giao dịch đều được lưu lại để kiểm tra.Non-repudiation: linh hoạt, cho phép chứng thực hợp pháp hóa của thông tin từ một phía thứ ba ngoài hai phía là người gửi và người nhận.
Bảo mật WebService
Web Service Security là một chuẩn an toàn cho SOAP và các phần mở rộng của SOAP, nó được dùng khi muốn xây dựng những web service toàn vẹn và tin cậy Web Service Security đảm bảo tính an toàn của thông điệp.
2.2 Chứng thực trong một ứng dụng
Máy khách sẽ cung cấp một dấu hiệu an toàn trong tập tin mô tả cũng như phải chỉ rõ một Callback handler để lấy tài khoản và mật khẩu từ thông điệp SOAP và gửi tới máy chủ.
Máy chủ chỉ định một Callback handler để cung cấp dấu hiệu an toàn trong SOAP từ máy khách và xác nhận nó.
2.3 Các bước tạo sự an toàn thông tin trong một ứng dụng Phía máy khách
- Chỉ rõ những thành phần của thông điệp mà phải có chữ ký hay một dấu hiệu chứng thục nào đó (nằm ở phần thân thông điệp)
- Chỉ rõ một khóa trên hệ thống tập tin mà sẽ ký lên thông điệp Chỉ những máy khách đã được cấp quyền mới có quyền sở hữu khóa này.
- Chỉ rõ những giải thuật sẽ được sử dụng bởi khóa để ký lên thông điệp. Phía máy chủ
- Chỉ rõ những thành phần của thông điệp cần được ký Nếu thông điệp đến không có một chữ ký hợp lệ, thì yêu cầu sẽ thất bại.
- Chỉ rõ một khóa để duyệt chữ ký của thông điệp đến xem có hợp lệ hay không.
- Chỉ rõ giải thuật mà khóa sử dụng để bảo đảm toàn vẹn của thông điệp gửi đến.
- Thông điệp phản hổi phải được ký và cung cấp thông tin chữ ký khi phản hồi.
Một số hình thức tấn công Web Service phổ biến và biện pháp
Tấn công này xảy ra khi kẻ tấn công chèn các câu lệnh SQL độc hại vào các trường nhập liệu hoặc tham số truy vấn của Web Service Nếu ứng dụng không kiểm tra và xử lý đầu vào đúng cách, kẻ tấn công có thể thu thập, sửa đổi, hoặc xóa dữ liệu từ cơ sở dữ liệu.
Sử dụng câu lệnh Prepared Statements hoặc Parametrized Statements để tránh chèn mã SQL độc hại.
Thực hiện kiểm tra và xử lý đầu vào người dùng đúng cách.
Sử dụng hệ thống ngăn chặn SQL Injection như WAF (Web Application Firewall).
XSS là một hình thức tấn công mà kẻ tấn công chèn mã JavaScript độc hại vào các trang web hoặc ứng dụng web, thường thông qua các trường nhập liệu Khi người dùng khác truy cập trang web, mã JavaScript này có thể thực hiện các hành động độc hại như đánh cắp thông tin đăng nhập. Cách phòng chống:
Escape hoặc mã hóa dữ liệu trước khi hiển thị trên trang web.
Sử dụng HTTP Only và Secure flag cho cookie để giảm nguy cơ bị đánh cắp thông tin đăng nhập.
Sử dụng Content Security Policy (CSP) để giới hạn việc thực thi mã JavaScript từ nguồn không tin cậy.
2.3 Cross-Site Request Forgery (CSRF):
CSRF xảy ra khi kẻ tấn công buộc người dùng thực hiện các hành động không mong muốn trên ứng dụng mà họ đã đăng nhập Điều này thường được thực hiện bằng cách chèn các yêu cầu giả mạo từ trang web hoặc email độc hại.
Sử dụng token CSRF để xác thực rằng yêu cầu được gửi từ nguồn đáng tin cậy. Đảm bảo rằng các yêu cầu thực hiện các hành động quan trọng đều yêu cầu xác thực của người dùng.
Tấn công XXE thường nhắm đến việc xử lý XML đầu vào không an toàn
Kẻ tấn công có thể chèn các thực thể XML bên ngoài để đọc dữ liệu nhạy cảm hoặc thậm chí thực hiện các hành động độc hại.
Tắt hỗ trợ cho các thực thể XML bên ngoài nếu không cần thiết.
Sử dụng XML Parser an toàn và hạn chế quyền truy cập đến các tài nguyên bên ngoài.
Lỗi cấu hình an ninh có thể bao gồm việc để lại một số tài nguyên không được bảo vệ, không kiểm soát quyền truy cập, hoặc để lại mặc định các thông số cấu hình không an toàn.
Thực hiện quy trình kiểm thử bảo mật định kỳ.
Hạn chế quyền truy cập cho các tài khoản và dịch vụ đúng cách. Xóa hoặc tắt những chức năng không sử dụng.
2.6 Denial of Service (DoS) và Distributed Denial of Service (DDoS): Tấn công này nhằm vào việc làm cho dịch vụ trở nên không khả dụng bằng cách tăng cường lưu lượng truy cập hoặc gửi các yêu cầu tới một dịch vụ cụ thể.
Sử dụng các dịch vụ chống DDoS hoặc tường lửa có khả năng chống DDoS.
Thực hiện giới hạn tần suất yêu cầu từ một nguồn IP để ngăn chặn tấn công DoS.
Giới thiệu các kỹ thuật WebService Security
SOAP là Giao Thức Truyền Thông: SOAP về bản chất là một giao thức dùng để truyền tải thông điệp giữa các ứng dụng
WS-Security Là Tiêu Chuẩn Bảo Mật: WS-Security được phát triển để bổ sung tính năng bảo mật cho các dịch vụ web Nó mô tả cách tích hợp các chứng chỉ bảo mật, xác thực người dùng, và mã hóa dữ liệu trong các thông điệp SOAP.
Quan hệ giữa WS-Security và SOAP:
- WS-Security giúp tăng cường bảo mật bằng cách thêm các tính năng như xác thực, mã hóa và chữ ký số vào các thông điệp SOAP
- WS-Security tuân theo các security bindings để tạo các SOAP header chứa các thông tin bảo mật, các SOAP header này được gửi cùng với một thông điệp SOAP bình thường.
- WS-Security cung cấp cơ chế xác thực và hỗ trợ mã hóa WS- Security thường sử dụng các tiêu chuẩn như XML Signature để ký số và XML Encryption để mã hóa dữ liệu WS-Security có thể thực hiện xác thực qua token hoặc chứng chỉ số công khai.
WSDL là Ngôn Ngữ Mô Tả Dịch Vụ Web:
WSDL (Web Services Description Language) đóng vai trò quan trọng trong việc định nghĩa cách một dịch vụ web có thể được gọi và sử dụng Nó mô tả giao diện của dịch vụ, xác định các tham số cần thiết và cách gọi dịch vụ.
WS-Security Là Tiêu Chuẩn An Ninh Dịch Vụ Web:
WS-Security (Web Services Security) mở rộng tính năng bảo mật cho dịch vụ web.
Quan hệ giữa WSDL và WS-Security:
- Security Bindings trong WSDL: WSDL có khả năng viết các phần mô tả an ninh thông qua WS-SecurityPolicy, được gọi là "security bindings," để xác định yêu cầu bảo mật cụ thể cho dịch vụ web
- Xác thực (Authentication): WS-Security thêm lớp bảo mật bằng cách thực hiện các xác thực trong quá trình truyền thông, các xác thức này được mô tả bằng WSDL.
- Mã hóa (Encryption): WS-Security có thể yêu cầu mã hóa thông điệp, được định nghĩa bằng WSDL qua security bindings
- Chữ ký số (Digital Signatures): WSDL định nghĩa cách màWS- Security ép chèn chữ ký số vào thông điệp, để xác nhận nguồn gốc và tính toàn vẹn của dữ liệu.
Vấn đề về chính sách truy cập trong web service:
- Chính Sách Điều Khiển Truy Cập Phức Tạp:
Trong môi trường phân phối, nơi có nhiều điểm triển khai dịch vụ web, quản lý và thực hiện chính sách điều khiển truy cập có thể trở nên rất phức tạp Mỗi điểm triển khai có thể đòi hỏi một cấu hình chính sách riêng biệt.
- Đắt Tiền và Không Đáng Tin Cậy:
Thực hiện chính sách điều khiển truy cập tại từng điểm có thể làm cho quá trình này trở nên đắt tiền và không đáng tin cậy, đặc biệt khi số lượng điểm triển khai lớn.
XACML Giải Quyết Vấn Đề Trên:
XACML (eXtensible Access Control Markup Language) được thiết kế để giải quyết những vấn đề này XACML cung cấp một tiêu chuẩn và ngôn ngữ duy nhất để xác định các chính sách điều khiển truy cập, giúp giảm độ phức tạp, chi phí, và tăng tính đáng tin cậy trong triển khai chính sách an ninh
Tại sao sử dụng XACML cùng với WS-Security:
- Fine-Grained Access Control: XACML cho phép định rõ quyền truy cập tới từng tài nguyên cụ thể, thậm chí từng hành động cụ thể Quyết định quyền truy cập trở nên linh hoạt và chi tiết hơn WS- Security
- Policy Enforcement: XACML cung cấp một cơ sở hạ tầng để triển khai và thực thi chính sách an ninh, đặc biệt là khi có nhiều đối tượng và tài nguyên tham gia trong các tương tác dịch vụ web.
- Dynamic Authorization: XACML hỗ trợ quyết định quyền truy cập dựa trên thông tin động và điều kiện Quyền truy cập có thể được xác định trên các yếu tố thời gian thực và ngữ cảnh.
Kiến trúc của XACML bao gồm các thành phần chính sau:
- PEP (Policy Enforcement Point): o Chức Năng: PEP đặt ở nơi mà quyết định quyền truy cập thực sự được thực hiện Nó là một thành phần trong hệ thống hoặc ứng dụng, thường là tại điểm truy cập tài nguyên. o Hoạt Động: Khi một yêu cầu truy cập được tạo ra (ví dụ: một người dùng cố gắng truy cập một tài nguyên), PEP sẽ gửi yêu cầu đó tới PDP để xác định xem quyền truy cập nên được cho phép hay không.
- PDP (Policy Decision Point): o Chức Năng: PDP là nơi thực hiện quyết định về quyền truy cập dựa trên chính sách đã được đặc tả Nó là trí óc của hệ thống XACML. o Hoạt Động: Khi nhận được yêu cầu truy cập từ PEP, PDP sẽ so khớp nó với các chính sách đã định và đưa ra một quyết định (cho hoặc từ chối) PDP sử dụng thông tin từ PIP để đưa ra quyết định.
TRIỂN KHAI VÀ ĐÁNH GIÁ KẾT QUẢ
Chống CSRF
Người tấn công tạo một trang web độc hại và tạo một biểu mẫu giả mạo, yêu cầu thay đổi mật khẩu hoặc thực hiện hành động quan trọng khác
Người tấn công gửi liên kết hoặc email chứa liên kết đến trang web độc hại đến người dùng mục tiêu.
Người dùng bị lừa mở liên kết hoặc truy cập trang web độc hại mà người tấn công đã tạo.
Trang web độc hại tự động gửi yêu cầu thay đổi mật khẩu hoặc thực hiện hành động quan trọng khác sử dụng cookie của người dùng mục tiêu, khiến người dùng không hề hay biết.
Khi người dùng đăng nhập sever sẽ trả về cho client một token và thường được lưu trữ ở trong cookies a)Trường hợp chưa chống CSRF Ở đây ta để ý trường SameSite chưa được tích nên request có thể được gửi từ trang web khác dẫn đến nguy cơ bị mất giữ liệu hoặc giả danh b)Trường hợp chống CSRF
Trong đoạn code add cookies ta có thể dùng thêm thuộc tính sameSite: true Điều này có thể đảm bảo request có gắn cookies này chỉ được gửi từ trang web gốc
Chống XSS
Kẻ tấn công tìm kiếm các điểm yếu trong ứng dụng web để chèn mã JavaScript độc hại Điều này có thể được thực hiện thông qua các trường nhập liệu không kiểm tra đầu vào, ví dụ như các hộp thoại tìm kiếm, bình luận, hoặc các trường khác.
Kẻ tấn công phát tán các liên kết chứa mã JavaScript độc hại thông qua email, tin nhắn, hoặc các kênh khác để lừa đảo người dùng nhấp vào liên kết.
Người dùng mở trang web chứa mã JavaScript độc hại, thường thông qua liên kết được kẻ tấn công phát tán.
Mã JavaScript độc hại chèn vào trang web sẽ thực hiện các hành động độc hại, chẳng hạn như đánh cắp thông tin đăng nhập, cookie, hoặc điều hướng người dùng đến các trang độc hại khác.
Hầu hết các framework hiện nay đã hỗ trợ phòng chống XSS Để phòng chống tốt hơn ta có thể thêm thẻ sau ở trong file html Điều này nhằm mục đích bảo với trình duyệt không bao giờ thực thi JavaScript trên domain nào khác ngoài domain ở trên
Triển khai 2: Setup client-server có mã hóa TLS
- Tạo cert trong folder: openssl req -x509 -newkey rsa:2048 -keyout server-key.pem -out server- cert.pem -days 365 -nodes
- Chạy Server từ folder: openssl s_server -key server-key.pem -cert server-cert.pem -tls1_3 -port 4433
Bước 2: bật Wireshark, capture loopback adapter
Bước 3: chạy client openssl s_client -connect localhost:4433 -tls1_3
Bước 4: Tìm TCP hoặc TLS package rồi follow TCP, từ đấy tìm được các gói tin trong handshake
TCP 3-Way Handshake ( (3 Gói Tin Ban Đầu):
1.TCP SYN (Gói Tin 1): o Máy khách gửi gói tin TCP với cờ SYN để bắt đầu kết nối. 2.TCP SYN-ACK (Gói Tin 2): o Máy chủ phản hồi bằng gói tin TCP với cờ SYN-ACK, xác nhận gói tin SYN và báo hiệu sẵn sàng thiết lập kết nối.
3.TCP ACK (Gói Tin 3): o Máy khách gửi gói tin TCP với cờ ACK, xác nhận gói tin SYN-ACK từ máy chủ và hoàn tất bắt tay ba bước.
TLS 1.3 Handshake (Bắt Tay - 5 Gói Tin):
4.ClientHello (Gói Tin 4): o Máy khách gửi một thông điệp TLS ClientHello, khởi tạo bắt tay TLS.
5.ServerHello & Change Cipher Spec (Gói Tin 5): o Máy chủ phản hồi bằng một thông điệp TLS ServerHello, xác nhận ClientHello và thiết lập các tham số mật mã. o Máy chủ cũng có thể gửi một thông điệp "Change Cipher Spec" báo hiệu rằng giao tiếp tiếp theo sẽ được mã hóa.
6.TCP ACK (Gói Tin 6): o Máy chủ gửi gói tin TCP với cờ ACK, xác nhận ClientHello TLS từ máy khách.
7.TCP ACK (Gói Tin 7): o Máy khách gửi gói tin TCP với cờ ACK, xác nhận ServerHello từ máy chủ.
8.TLS Change Cipher Spec & Application Data (Gói Tin 8): o Máy khách gửi một thông điệp TLS Change Cipher Spec, báo hiệu sự thay đổi sang giao tiếp được mã hóa. o Các gói tin tiếp theo có thể chứa dữ liệu ứng dụng được mã hóa được trao đổi giữa máy khách và máy chủ sau bắt tay TLS. Trao đổi dữ liệu sau Handshake:
9.TCP ACK (Gói Tin 9): o Máy chủ gửi gói tin TCP với cờ ACK, xác nhận Change Cipher Spec từ máy khách.
10 TLS Application Data (Gói Tin 10): o Máy chủ gửi một thông điệp TLS Application Data chứa dữ liệu được mã hóa.
11 TCP ACK (Gói Tin 11): o Máy khách gửi gói tin TCP với cờ ACK, xác nhận dữ liệu ứng dụng từ máy chủ.
12 TLS Application Data (Gói Tin 12): o Máy chủ gửi một thông điệp TLS Application Data khác chứa dữ liệu được mã hóa.
13 TCP ACK (Gói Tin 13): o Máy khách gửi gói tin TCP với cờ ACK, xác nhận dữ liệu ứng dụng thứ hai từ máy chủ.
3 Một số triển khai khác:
• Chạy câu lệnh: openssl genrsa -out key.pem Để tạo ra file key.pem có chứa private key
➢Tạo một CSR sử dụng private key
• Sử dụng câu lệnh openssl req – new -key key.pem – out csr.epm
• Cung cấp các thông tin cần thiết bao gồm ( country, email ,… )
• Ta sẽ có một file chứa khóa CSR như sau
➢Tạo chứng nhận (SSL) từ CSR
• Sử dụng câu lệnh sau
• Sử dụng JWT: Mỗi khi người dùng đăng nhập sever sẽ tạo ra token dựa trên khóa bí mật được lưu ở phía sever và trả về cho user token và refreshToken
• Token được lưu ở phía client ( cookies, localstorage,
… ) và được giữ bí mật Token sẽ chứa các thông tin định dạng người dùng như tên account và roleName ( Quyền )
• Mỗi khi người dùng thực hiện một request lên sever token sẽ được đính kèm vào header của request
• Khi sever nhận được request sẽ tiến hành giải mã
• Nếu token không hợp lệ thì sẽ báo lỗi còn nếu hợp lệ sẽ trả về thông tin của người dùng bao gồm ( account, roleName )
• Trong quá trình xử lý ta có thể sử dụng (account) để xác thực người dùng và (roleName) để cấp quyền cho người dùng
3.3 Mã hóa dữ liệu nhạy cảm
• Khi người dùng đăng nhập họ sẽ nhập mật khẩu và gửi request đến sever, điều này gây nguy hiểm tiềm tàng rằng mật khẩu có thể bị đánh cắp trên đường truyền
• Mã hóa mật khẩu khi gửi request: sử dụng thư viện bcrypt để mã hóa mật khẩu, mật khẩu được mã hóa sẽ được lưu trữ ở DB phía sever
• Khi muốn kiểm tra mật khẩu ta thực hiện code sau:
Web Service đã và đang được triển khai và áp dụng trong nhiều lĩnh vực của đời sống như ngân hàng, chứng khoán, trao đổi dữ liệu và ngày càng trở nên phổ biến Cùng với sự phát triển của nó là những yêu cầu về tính an toàn và khả năng bảo mật Bằng cách sử dụng các kỹ thuật bảo mật Web Service, người sử dụng Web Service sẽ cảm thấy an tâm hơn.
Việc chọn cơ chế an toàn cho Web Service phải đảm bảo rằng người dùng không cảm thấy quá phức tạp hay bị gò bó mà vẫn tạo nên sự trong suốt với người dùng Do đó, cần chọn các cơ chế an toàn mà Web Service phụ thuộc vào loại dịch vụ đó và những tính năng mà dịch vụ này cung cấp Ngoài ra, một điểm cần quan tâm là sự an toàn không chỉ phụ thuộc vào các giải thuật, tiêu chuẩn và cơ chế bảo mật Web Service mang lại, mà nó còn phụ thuộc vào tư duy 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.
Sau thời gian nghiên cứu tài liệu và tìm hiểu các chương trình mã nguồn mở, nhóm em đã hoàn thành báo cáo với bài toán ban đầu là "Dịch vụ web.An toàn bảo mật Web Service" Việc lựa chọn chương trình để trao đổi dữ liệu giữa hai máy tính trong mạng và đảm bảo an ninh cho việc truyền dữ liệu Báo cáo đã đạt được một số kết quả sau:
Phân tích bài toán và đánh giá cấp thiết của việc bảo mật cho các trang Web Service, đồng thời đề xuất 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 liên quan Tìm hiểu 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.
Tìm hiểu thực trạng bảo mật Web Service hiện nay, bao gồm các công nghệ bảo mật
3 Những hạn chế Để xây dựng một hệ thống hoàn chỉnh với nhiều chức năng và đảm bảo tuyệt đối những yêu cầu đặt ra, đòi hỏi rất nhiều thời gian Trong thời gian nghiên cứu và triển khai báo cáo nhóm em đã cố gắ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 chỉ với chức năng hiển thị dữ liệu, cũng như thiết kế dữ liệu chưa thực sự tốt.
Không được đưa ra áp dụng thực tế nên có khả năng xuất hiện nhiều lỗi mà người nghiên cứu không thể phát hiện ra.
Về bảo mật, chưa tìm hiểu hết về các loại thẻ bảo mật Web Service, việc triển khai chỉ dừng lại ở việc tích hợp vào chương trình mức cơ bản nhất, vẫn chưa đưa ra thực tế và sử dụng các phương pháp tấn công để kiểm tra độ bảo mật trên mức cơ bản của chương trình.
Nếu có điều kiện, trong tương lai, nhóm em sẽ cố gắng tìm hiểu thêm về những hạn chế của báo cáo này 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 tế.
Handshake (Bắt Tay - 5 Gói Tin)
Một số triển khai khác
• Chạy câu lệnh: openssl genrsa -out key.pem Để tạo ra file key.pem có chứa private key
➢Tạo một CSR sử dụng private key
• Sử dụng câu lệnh openssl req – new -key key.pem – out csr.epm
• Cung cấp các thông tin cần thiết bao gồm ( country, email ,… )
• Ta sẽ có một file chứa khóa CSR như sau
➢Tạo chứng nhận (SSL) từ CSR
• Sử dụng câu lệnh sau
• Sử dụng JWT: Mỗi khi người dùng đăng nhập sever sẽ tạo ra token dựa trên khóa bí mật được lưu ở phía sever và trả về cho user token và refreshToken
• Token được lưu ở phía client ( cookies, localstorage,
… ) và được giữ bí mật Token sẽ chứa các thông tin định dạng người dùng như tên account và roleName ( Quyền )
• Mỗi khi người dùng thực hiện một request lên sever token sẽ được đính kèm vào header của request
• Khi sever nhận được request sẽ tiến hành giải mã
• Nếu token không hợp lệ thì sẽ báo lỗi còn nếu hợp lệ sẽ trả về thông tin của người dùng bao gồm ( account, roleName )
• Trong quá trình xử lý ta có thể sử dụng (account) để xác thực người dùng và (roleName) để cấp quyền cho người dùng
3.3 Mã hóa dữ liệu nhạy cảm
• Khi người dùng đăng nhập họ sẽ nhập mật khẩu và gửi request đến sever, điều này gây nguy hiểm tiềm tàng rằng mật khẩu có thể bị đánh cắp trên đường truyền
• Mã hóa mật khẩu khi gửi request: sử dụng thư viện bcrypt để mã hóa mật khẩu, mật khẩu được mã hóa sẽ được lưu trữ ở DB phía sever
• Khi muốn kiểm tra mật khẩu ta thực hiện code sau: