tìm hiểu hệ thống đăng nhập một lần sso - single sign on

tìm hiểu hệ thống đăng nhập một lần sso - single sign on

MỤC LỤC

MỤC LỤC 1

DANH MỤC CÁC TỪ VIẾT TẮT 2

LỜI NÓI ĐẦU 5

1.3 SSO trên các ứng dụng không trên nền tảng web 14

2.1.2 Kiến trúc SSO cho mạng nội bộ 17

2.2.2 Các kiểu tấn công vào hệ thống SSO 21

2.2.3 Tăng cường an toàn bằng các chính sách 23

2.4 Lược đồ giao thức 28

2.4.1 Liên hệ các trang web nguồn 28

2.4.2 Chuyển đến trang đích 29

2.4.3 SAML Request 29

2.4.4 SAML Response 30

2.4.5 Đáp ứng yêu cầu từ trình duyệt 31

2.5 Một số lỗ hổng có thể lợi dụng để thực hiện tấn công 31

2.5.1 Hijacking / Replay Attack 31

2.5.2 Tấn công xen giữa (Man-in-the-Middle) 32

2.5.3 HTTP Referrer Attack 34

2.5.4 Khai thác lỗ hổng của SSL/TSL 34

Bảng 2.1:CAS(Central Authentication service) 36

Bảng 2.2: Open source được phát triển bởi đại học Stanford 38

Bảng 2.3: Cosign 39

3.1 Khái niệm Center Authencation Service (CAS) 41

3.2.1 URI -/login đăng nhập 42

3.2.2 Các thông số 42

3.2.3 Các ví dụ về tham số đăng nhập 43

3.2.4 Chứng thực Username/Password 43

3.2.5 Chứng thực tin cậy 43

3.2.6 Phổ biến các thông số 43

3.2.7 Các thông số xác thực tên người dùng,mật khẩu 43

3.3 /Proxy 45

Bảng 3.1: /SAMLValidate 46

3.8 Xác thực trong CAS 62

DANH MỤC CÁC TỪ VIẾT TẮT

OpenSSO Open Single Sign On

LDAP Lightweight Directory Acess Protocol

CAS Central Athentication Service

URI Uniform Resource Identifier

URL Uniform Resource Locator

ESSO Enterprise Single Sign On

CRM Customer Relationship Management

DANH MỤC CÁC BẢNG

Bảng 2.1:CAS(Central Authentication service) 36

Bảng 2.2: Open source được phát triển bởi đại học Stanford 38

Bảng 2.3: Cosign 39

Bảng 3.1: /SAMLValidate 46

DANH MỤC CÁC HÌNH VẼ

Hình 1.1: Người dùng sử dụng Single Sign On 9

Hình 1.2:Ứng dụng single sign on sử dụng OpenID 12

Hình 1.3: Single Sign On trên windows 14

Hình 2.1:Kiến trúc SSO cho ứng dụng Internet 16

Hình 2.2: Kiến trúc SSO cho mạng nội bộ 17

Hình 2.3: Kiến trúc SSO cho nhiều miền 18

Hình 2.4: Kiến trúc SSO chéo 19

Hình 2.5: Tấn công Session Hijacking 22

Hình 2.6: Tấn công Man in the Middle 23

Hình 2.7: Giả mạo DNS 23

Hình 2.8: SAML Single Sign On 25

Hình 3.1 : Đăng nhập CAS 49

Hình 3.2 : Chứng thực một trình duyệt đển máy chủ CAS 49

Hình 3.3 : Truy cập vào ứng dụng 50

Hình 3.4: Trình duyệt truyền ST cho ứng dụng 50

Hình 3.5 : Ứng dụng truyền ST cho CAS 51

Hình 3.6 : Người dùng truy cập vào ứng dụng khi đã chứng thực với CAS 51 Hình 3.8: CAS trả về cho trình duyệt đồng thời TGC và ST 52

Hình 3.9 : Truyền ST cho ứng dụng 53

Hình 3.10:Người dùng truy cập vào ứng dụng mà chưa chứng thực với CAS 53

Hình 3.11: Cơ chế Proxy 54

Hình 3.12: Thu hồi TMP của một proxy CAS từ máy chủ CAS 56

Hình 3.13: Xác Nhận của PT người dùng CAS truy cập bởi một proxy CAS 57

Hình 3.14: Sơ đồ CAS 57

Hình 3.15 : Login Flow 59

Hình 3.16 : Proxy Flow 61

Hình 3.17 : Logout Flow 61

Hình 3.18: Mô hình triển khai ứng dụng 64

LỜI NÓI ĐẦU

Ngày nay, với sự phát triển nhảy vọt của khoa học công nghệ nói chung của ngành tin học nói riêng, với những tính năng ưu việt, sự tiện dụng và được ứng dụng rộng rãi, tin học ngày nay là một phần không thể thiếu được của nhiều

con người càng cần đến sự quan tâm và chia sẻ thông tin Chính điều này đã tạo

cơ hội cho mạng máy tính phát huy hết những tiện ích vốn có của mình

Hiểu rõ được tầm quan trọng và những ưu điểm vượt trội của việc bảo mật, trao đổi thông tin của hệ thống mạng máy tính mà số lượng các công ty, doanh nghiệp thiết lập, sử dụng hệ thống mạng ngày càng nhiều Từ những công ty có quy mô nhỏ, vừa đến các doanh nghiệp, tập đoàn tầm cỡ, không nơi nào không

có sự xuất hiện của hệ thống mạng trong khâu quản lý công việc của nhân viên, trong công tác quản lý, bảo mật và lưu trữ dữ liệu của công ty hay các thông báo, thông tin giữa các cá nhân trong cùng một tổ chức

Khi sử dụng càng nhiều các dịch vụ người dùng phải đối mặt với vấn đề khi

sử dụng các dịch vụ riêng biệt cần có một tài khoản và mật khẩu riêng, mỗi lần

sử dụng một dịch vụ khác nhau người dùng phải đăng nhập lại điều này dẫn đến các nguy cơ mất an toàn trên mạng, người dùng dễ bị ăn cắp tài khoản hay quên mật khẩu Thấy được tầm quan trọng của vấn đề em đã tìm hiểu và nghiên cứu

đề tài :”Tìm hiểu Single Sign On” Đề tài tập trung tìm hiểu và triển khai giải

pháp đăng nhập một lần giúp người sử dụng chỉ cần dùng một tài khoản và mật khẩu đăng nhập một lần duy nhất có thể sử dụng được tất cả các ứng dụng tin cậy

Thấy được tầm quan trọng và ý nghĩa thực tiễn của đề tài, qua ba tháng tìm hiểu nghiên cứu thực hiện đề tài Em đã hoàn thành đề tài với những nội dung: Tìm hiểu tổng quan về Single Sign On, độ an toàn hệ thống và triển khai sản phẩm Central Authentication Service (CAS) ứng dụng vào thực tế

Chương I: Tổng quan về Single Sign On

 Trình bài khái quát về Single Sign On

 Ý nghĩa thực tiễn của Single Sign On

Chương II: Các vấn đề an toàn của Single Sign On

 Tìm hiểu các kiến trúc Single Sign On

 Các lỗ hổng an ninh khi sử dụng Single Sign On

 Giao thức SAML Single Sign On

 Các phương pháp tấn công và giải pháp an toàn khi sử dụng SAML Single Sign On

Chương III: Central Authentication Service

 Tổng quan chung về phần mềm CAS

sự đóng góp ý kiến của thầy cô giáo và bạn bè

Với lòng biết ơn sâu sắc, em xin chân thành cảm ơn Th.s Nguyễn Anh

Tuấn,Th.s Nguyễn Quốc Toàn các anh chị trong công ty Cổ phần phần mềm Việt, các thầy cô giáo trong khoa An Toàn Thông Tin Học Viện Kỹ Thuật Mật Mã đã nhiệt tình hướng dẫn giúp đỡ em hoàn thành đồ án này

Cuối cùng tôi xin cảm ơn bạn bè, người thân đã luôn bên, kịp thời động viên

và giúp đỡ tôi trong thời gian vừa qua

Em xin chân thành cảm ơn !

Hà Nội, Tháng 6 năm 2011

Sinh viên Bùi Đăng Tân

Chương I

TỔNG QUAN VỀ SINGLE SIGN ON

1.1 Tìm hiểu Single Sign On

1.1.1 Tại sao Single Sign On?

Hệ thống CNTT ngày càng phát triển rộng khắp và ứng dụng vào tất cả các lĩnh vực.Người sử dụng phải đối mặt với vấn đề ngày càng phức tạp là phải nhớ nhiều tài khoản và mật khải để thực hiện công việc của họ

Người dùng thường phải đăng nhập vào nhiều hệ thống, cần phải có một lượng tương đương số lần đăng nhập, mỗi dịch vụ trong các hệ thống đó có thể bao gồm tài khoản và mật khẩu khác nhau Điều này dẫn đến người dùng phải đối mặt với các vấn đề:

 Quên tài khoản: do sử dụng nhiều tài khoản và mật khẩu để đăng nhập các ứng dụng

 Dùng một tài khoản và mật khẩu cho các hệ thống dẫn đến nguy cơ mất an toàn

Sử dụng Single Sign On:

• Sử dụng nhiều phương pháp xác thực: Là cần thiết để nhập thông tin đăng nhập của mình ngoài phương pháp nhập tài khoản và mật khẩu khi truy cập vào mỗi ứng dụng

• Đa phương diện: Tài khoản người dùng là duy nhất trong tổ chức này và

nó sẽ được mong muốn sử dụng nó truy cập vào tài nguyên máy tính từ các tổ chức khác có thể được sử dụng cùng một tài khoản.(sử dụng tài khoản yahoo, gmail, facebook …sử dụng OpenId)

• Quyền: Xác thực quyền hạn truy cập các tài nguyên của người dùng khi truy cập các ứng dụng khác nhau

• Xác thực tập trung: Trên một máy chủ duy nhất để xác thực tài khoản người dùng thông qua giao thức đã được mã hóa

• Trình duyệt sử dụng http chuyển hướng trình duyệt của người dùng giữa các ứng dụng mà không cần đăng nhập tài khoản và mật khẩu

1.1.2 Khái niệm

Single Sign On: Người sử dụng dùng tài khoản đăng nhập chỉ một lần và có thể sử dụng nhiều ứng dụng trong cùng một tổ chức một cách liên tục mà không cần phải nhập lại thông tin cho mỗi ứng dụng

Hình 1.1: Người dùng sử dụng Single Sign On

Ví dụ: Người dùng sử dụng nhiều dịch vụ: Email,forum,web…khi chưa có Single Sign On thì với mỗi dịch vụ ta phải nhập thông tin để xác thực.Khi một tổ chức đã thống nhất sử dụng Single Sign On cho hệ thống của họ thì người dùng chỉ phải đăng nhập một lần vào bất kì ứng dụng nào trong hệ thống thì khi dùng các ứng dụng khác người dùng không phải đăng nhập lại

1.1.3 Các khái niệm quan trọng của Single Sign On

 Xác thực: Quá trình xác minh danh tính của người dùng, làm cho chắc chắn rằng người dùng là họ Chúng ta có thể sử dụng các phương pháp xác thực như: username, password, thẻ thông minh, hay dùng sinh trắc học…

 Ủy quyền: Là một quy trình nhằm xác minh rằng một người dùng biết trước, có quyền lực để thao tác một quá trình hoạt động nào đó hay không

 Giấy chứng nhận: Là các chi tiết được cung cấp bởi một người dùng trong quá trình xác thực vào ứng dụng

 Domain: Là sự nhận dạng vị trí của một máy tính trên mạng Internet nói cách khác tên miền là tên của các mạng lưới, tên của các máy chủ trên mạng Internet

 Bảo vệ dữ liệu: Dữ liệu của hệ thống không thể cho tất cả mọi người có thể truy cập Người dùng cần phải thông qua xác thực và ủy quyền trước khi truy cập vào một nguồn tài nguyên bảo vệ.

 Cookie: Giao thức HTTP là một chuẩn giao thức không hỗ trợ lưu trạng thái Điều này có nghĩa là sau khi trình duyệt kết nối tới máy chủ và lấy xong dữ liệu thông qua HTTP, máy chủ liền tắt ngay kết nối mà không buồn quan tâm tới việc dữ liệu đó sẽ được xử lý, lưu trữ ra sao trên máy khách Chính vì sự “vô tình” này đã dẫn đến những tình huống phát sinh, chẳng hạn như trong một phiên làm việc, làm thế nào để biết được người sử dụng đó vừa mới truy cập lên máy chủ, hay người sử dụng đã lựa chọn những gì ở những lần truy cập trước đó? Để giải quyết vấn đề này, các nhà phát triển ứng dụng Web đã phải khai sinh một công cụ khác, gọi là cookie

Cookie là một (hoặc một số) thông tin được những nhà thiết kế web ấn định yêu cầu trình duyệt phải ghi lại ở đâu đó trên máy khách Mỗi khi trình duyệt kết nối tới máy chủ, các thông tin lưu trong cookie sẽ được gửi cùng lên máy chủ Nhờ những thông tin này, các nhà thiết kế web sẽ theo dõi được những hành vi của người sử dụng thông qua cookie

Trước đây rất nhiều người nhầm tưởng cookie là các đoạn mã độc hại, nhưng thực tế thì không phải như vậy Về bản chất, cookie chỉ là các bản ghi lưu trữ dữ liệu chứ không hề có chứa bất kỳ một đoạn mã chương trình nào cả Tuy nhiên, nhiều nhà phát triển ứng dụng Web thiếu kinh nghiệm đã lựa chọn cookie để lưu trữ những thông tin mang tính chất nhạy cảm (mật khẩu, số tài khoản cá nhân )

Vì vậy chúng rất dễ bị các chương trình gián điệp chạy trên máy khách thu thập

và đem ra sử dụng một cách mờ ám, gây hại cho người dùng Nếu bạn là người lập trình Web chuyên nghiệp, hãy cẩn thận với những tình huống này

Một cookie thường có những thông tin sau đây:

 Tên cookie (name): do người lập trình website thiết lập để phân biệt giữa các cookie

 Domain: xác định tên miền sẽ được sử dụng để gửi cookie đi

 Đường dẫn: xác định đường dẫn ở trên Website

 Thời điểm hết hạn (expires): xác định thời điểm cookie sẽ bị hết hiệu lực trên trình duyệt

 Bảo mật: nếu giá trị này đựơc thiết lập bên trong cookie, thông tin sẽ đựơc

mã hoá trong quá trình truyền giữa server và browser

 Giá trị (value): xác định dữ liệu được lưu trong cookie Giá trị này sẽ được chuyển tới máy chủ có địa chỉ xác định trong đường dẫn hoặc tên miền Các giá trị này ko chứa các khoảng trắng, dấu chấm, phẩy và bị giới hạn trong khoảng 4k

Cookie có thể được sử dụng để lưu một số thông tin như: tài khoản (tên truy cập và mật khẩu) của người sử dụng trên website, các thông tin lựa chọn giỏ hàng (trên các website mua bán trực tuyến), các mục chọn hay những thông tin khác do nhà thiết kế web chỉ định

Sau khi có một cookie, nếu người dùng duyệt để một ứng dụng khác nhau đó

là một phần của Single Sign On, thông tin được lưu trong cookie sẽ được trình duyệt sử dụng để trực tiếp đăng nhập vào ứng dụng khác, nếu người sử dụng được phép truy nhập vào

 Bảo mật tất cả các cấp độ của việc thoát hay truy xuất vào hệ thống

 Người phát triển ứng dụng không cần phải hiểu và thực hiện nhận dạng bảo mật trong ứng dụng của họ

1.2 Các loại Single Sign On

Hầu hết các sản phẩm SSO trên thế giới có thể được phân loại thành hai loại dựa trên kiến trúc:

1.2.1 Trên web (Enterprise SSO)

SSO trên web được sử dụng dưới các dạng:

 Single Domain: Khi xác thực thành công vào domain.com, người dùng

 Multi Domain: khi xác thực thành công vào facebook.com, người dùng đồng thời được xác thực vào example.com.

Các SSO được sử dụng phổ biến trên web hiện nay:

 OpenID: hệ thống đăng nhập một lần không có tính tập trung Đối với những trang web có sử dụng OpenID thì người sử dụng không cần phải nhớ các thông tin về username và password cho riêng trang đó nữa Thay vào đó họ chỉ cần đăng ký trước 1 tài khoản OpenID tại một trong những nhà cung cấp OpenID, hay thường gọi là i-broker Do OpenID không mang tính tập trung nên bất kỳ trang web nào cũng có thể sử dụng được OpenID như là một cách đăng nhập cho người dùng Các hệ thống lớn đang sử dụng là : yahoo, google, facebook…

Hình 1.2:Ứng dụng single sign on sử dụng OpenID

 Open Single Sign-On (OpenSSO) hoạt đông dựa trên Token: Là một sản phẩm open source của SUN Nó là một sản phẩm đơn lẻ, kết hợp các tính năng của Sun Java System Access Manager, Sun Java System Fedearation Manager và Sun System SAML v2 Java Plugin

 Java Open Single Sign On ( JOSSO)

 Central Authenticate Service (CAS) hoạt đông dựa trên Ticket

1.2.2 Đặc điểm của SSO trên web (Enterprise SSO)

Một WebSSO đúng nghĩa phải là một dịch vụ chứng thực tập trung đáp ứng đồng thời các yêu cầu sau:

 Đăng nhập một lần với một tài khoản duy nhất để chứng thực vào các ứng dụng web khác nhau sử dụng dịch vụ WebSSO Các ứng dụng web có thể chạy trên nhiều domain khác nhau Ví dụ: khi bạn đăng nhập vào hotmail.com thì bạn

sẽ không cần đăng nhập một lần nữa khi vào msn.com

 Web SSO yêu cầu một hệ thống network ổn định và đảm bảo vận hành xuyên suốt

 Phải sử dụng SSL và các phương thức mã hóa bất đối xứng Nếu một dịch

vụ chứng thực mà không dùng SSL cho các phiên chứng thực thì đều bị coi là không an toàn Và đây cũng là một mục tiêu quan trọng của một ứng dụng web khi dùng dịch vụ chứng thực tập trung

 Đăng xuất toàn bộ hệ thống SSO khi click vào button [Sign Out] hoặc tự động SignOut khi tắt trình duyệt

Trong SSO cũng như chứng thực thông thường, đều cần database để lưu trữ thông tin người dùng Còn SSO hoàn toàn không dùng database để lưu vết session SSO phải đảm nhiệm một nhiệm vụ rất lớn trong việc chứng thực toàn

bộ người dùng cho các ứng dụng web Do vậy vấn đề bảo mật luôn đặt lên hàng đầu, nếu SSO gặp một sự cố nào đó thì toàn bộ các partners (ứng dụng web dùng SSO) sẽ không thể đăng nhập được

1.2.3 Nguyên lí hoạt động của web SSO

 Bước 1 : Người dùng đăng nhập vào tài khoản tại url của dịch vụ SSO Authentication Service.Sau khi đăng nhập thành công -> bước 2

 Bước 2 : Authentication Service sẽ thực hiện việc sinh ra Authentication Token Đây là một chuỗi chứa thông tin chứng thực (không chứa password) và thông thường được mã hóa bằng DES hoặc RSA

 Bước 3 : Authentication Token sẽ được truyền tải trên http (không mã hóa SSL) giữa ứng dụng web (partner) và Authentication Service Trên mỗi ứng dụng web sẽ có một SSOAgent, có nhiệm vụ xử lý Authentication Token và kiểm tra việc chứng thực Trong quá trình này session cookie sẽ được tạo tại trình duyệt của người dùng đăng nhập nếu SSOAgent kiểm tra Authentication Token thành công

 Bước 4 : [Sign Out]: Khi chứng thực tự động vào một partner, Authentication Service sẽ lưu lại thông tin partner này, khi người dùng click [Sign Out] thì dịch vụ xác thực sẽ lần lượt Sign Out (xóa toàn bộ session cookie của ứng dụng sử dụng SSO).

1.3 SSO trên các ứng dụng không trên nền tảng web

Các doanh nghiệp trong những ngày này thường có Microsoft Windows ® người sử dụng máy tính để bàn truy cập các ứng dụng doanh nghiệp đa dạng, ứng dụng thường có yêu cầu an ninh khác nhau và phải đăng nhập cho các ứng dụng khác nhau SSO giữa Oracle Access Manager và IBM WebSphere Application Server Phổ biến nhất hiện nay là hệ thống của Microsoft sử dụng cho windows,Microsoft Office SharePoint Server

Hình 1.3: Single Sign On trên windows

Microsoft cung cấp một giải pháp xác thực cho phép người dùng Windows sử dụng Microsoft Internet Explorer (IE) để truy cập tài nguyên trên Microsoft Internet Information Server (IIS) mà không cần phải xác thực lại Đơn đăng ký giải pháp dựa trên cơ chế xác thực bản quyền Microsoft HTTP

Người dùng đăng ký và nền tảng hỗ trợ: WebSEAL SPNEGO hỗ trợ cung cấp đăng ký từ Internet Explorer chạy trên Windows máy trạm cấu hình vào miền Active Directory để WebSEAL

Single sign on trong SharePoint: Cung cấp lưu trữ và lập bản đồ của các thông tin như tên tài khoản và mật khẩu để các ứng dụng dựa trên cổng thông tin trang web có thể lấy thông tin từ các bên thứ ba ứng dụng và hệ thống back-end

Ví dụ, Enterprise Resource Planning (ERP) và hệ thống quản lý quan hệ khách hàng (CRM)

Kết chương I:

Nội dung của chương đã trình bày tổng quát các khái niệm quan trọng về single sign on , các dạng SSO đang được sử dụng trên thế giới Đăng nhập một lần đang được các hãng công nghệ sử dụng rộng rãi trong các ứng dụng phần mềm và đặc biệt trong các dịch vụ ứng dụng web Bên cạnh tính thuận tiện, đơn giản tiện lợi cho người dùng cũng có những nhược điểm về mặt an toàn Chương sau của đồ án sẽ trình bày rõ hơn về vấn đề an toàn của Single sign on

Chương II CÁC VẤN ĐỀ AN TOÀN CỦA SSO

2.1 Kiến trúc SSO

2.1.1 Kiến trúc SSO cho các ứng dụng Internet

Hình 2.1:Kiến trúc SSO cho ứng dụng Internet

Mô tả các vị trí thành phần khác nhau trong một đơn vị sử dụng các ứng dụng SSO.Ứng dụng ra ngoài Internet phải đối mặt với rất nhiều cuộc tấn công và do

đó bảo vệ theo chiều sâu được sử như một nguyên tắc trong kiến trúc SSO để bảo đảm an ninh tối đa cho các ứng dụng Các web server và ứng dụng cho phép

truy cập vào Internet nên được đặt trong phân vùng riêng (DMZ) Các công cụ truy cập, quản lý máy chủ và lưu trữ dữ liệu đặt trong mạng nội bộ.

Các giao tiếp giữa người dùng và máy chủ web có thể được bảo mật bằng cách sử dụng SSL(Secure Socket Layer) tránh bị ăn cắp user đăng nhập và mật khẩu được truyền đi dưới dạng văn bản rõ

Sử dụng tường lửa chỉ cho phép các máy chủ ứng dụng giao tiếp với nhau tại các cổng được chỉ định và từ chối tất cả các truy cập khác Điều này làm giảm cơ hội của chương trình độc hại như Trojan gửi các lưu lượng giả vào các máy chủ ứng dụng từ mạng Internet

Thường xuyên cập nhật các bản vá cho các máy chủ một cách sớm nhất ngay khi các bản vá được phát hành

Cập nhập các bản vá cho máy trạm trong mạng LAN, đặc biệt là nâng cấp trình duyệt không cho phép các trình duyệt đã quá cũ trên máy trạm được truy cập vào server Điều này giúp ngăn chặn được kẻ tấn công lợi dụng các lỗ hổng trình duyệt cũ để tấn công vào hệ thống

2.1.2 Kiến trúc SSO cho mạng nội bộ

Hình 2.2: Kiến trúc SSO cho mạng nội bộ

Tương tự như kiến trúc SSO cho các ứng dụng ra Internet, nhưng tất cả các thành phần của kiến trúc được đặt trong mạng nội bộ Các giải pháp an toàn cho kiến trúc internet được sử dụng theo chiều sâu

 Kiến trúc SSO cho nhiều miền

Hình 2.3: Kiến trúc SSO cho nhiều miền

Sử dụng một miền chính và các miền phụ trợ, người dùng sẽ được xác thực chung nhưng sẽ chỉ truy cập được đến tài nguyên mà các miền ấn định chính sách riêng cho từng người dùng, nhóm người dùng cụ thể Nếu người dùng truy cập vào các dữ liệu không được phép thì sẽ diễn ra theo các bước:

• Người dùng sử dụng trình duyệt của mình để truy cập vào một nguồn tài nguyên được bảo vệ bởi một chính sách truy cập trong các miền phụ

• Miền phụ gửi một phản ứng để người dùng trình duyệt để chuyển hướng đến miền chính để xác thực

• Truy cập miền chính qua thành phần xác thực người dùng, quyền các truy cập để kiểm tra và cấp phép

• Gửi thông tin xác thực và ủy quyền trở lại trình duyệt của người sử dụng, sau khi nhận được thông tin từ các công cụ truy cập, cookie được thiết lập trên trình duyệt của người dùng cho các tên miền chính

Khi người dùng nhấp vào nút đăng xuất trên một trang web trong miền phụ các máy chủ web trong miền phụ sẽ hủy các cookie đặt cho người sử dụng và chuyển hướng người dùng đến miền chính với các thông hủy cookie người dùng Các máy chủ web trong tên miền chính hủy các cookie của nó lưu cho người

sử dụng và người sử dụng thoát khỏi ứng dụng

 Kiến trúc SSO chéo

Hình 2.4: Kiến trúc SSO chéo

Cũng được tổ chức như các SSO thông thường nhưng có thêm phần xác thực giữa các hệ thống SSO với nhau Các bước xác thực như sau:

• Người dùng truy cập một ứng dụng trên các trang web của ứng dụng trên hệ thống SSO của mình

• Người sử dụng được xác thực và ủy quyền để truy cập ứng dụng

và được thiết lập một cookie trên trình duyệt của người dùng

• Người dùng sau đó nhấp chuột vào liên kết đưa người sử dụng một ứng dụng duy trì trên một trang web đối tác (hệ thống SSO khác)

• Các công cụ kết nối sử dụng cookie của trình duyệt người dùng để đóng gói nó như là một SAML(Security Assertion Markup Language khẳng định, các ký hiệu nó và sau đó chuyển hướng nó vào thành phần kết nối trong mạng SSO đối tác

• Hệ thống kết nối bên SSO đối tác xác nhận SAML được gửi từ đối tác SSO đã được tin cậy, sau đó kiểm tra và cấp phép cho phép người dùng truy cập vào ứng dụng.

2.2 Các vấn đề an toàn với SSO

2.2.1 Lỗ hổng an ninh

Khi đề cập đến lỗ hổng bảo mật và rủi ro, mối quan tâm chủ yếu quan tâm đến tính an toàn của hệ thống là các thuộc tính quan trọng của an toàn thông tin: Tính bí mật, tính toàn vẹn, tính xác thực, tính sẵn sàng Sự tồn tại của các lỗ hổng cho thấy hệ thống có nguy cơ bị các hacker lợi dụng lỗ hổng này có thể được khai thác các thông tin người dùng trong cuộc tấn công Các cuộc tấn công

có tính chất khác nhau tùy thuộc vào mức độ nghiêm trọng của các lỗ hổng này đang được khai thác

 Các rủi ro

 Rủi ro mật khẩu yếu: Sử dụng mật khẩu là phương pháp xác thực được sử dụng phổ biến nhất hiện nay Một mật khẩu được sử dụng nhiều lần và không được thay đổi trong thời gian dài để truy cập vào các ứng dụng Một phương pháp thông thường dùng để tấn công các mật khẩu yếu là đoán mật khẩu bằng cách sử dụng phương pháp tấn công từ điển Việc sử dụng mật khẩu có ý nghĩa quan trọng khi cho phép người dùng đăng nhập vào các ứng dụng Có thể khắc phục bằng cách thiết lập các chính sách mật khẩu mạnh

 Rủi ro của hình thức nhúng đăng nhập: Mô tả một kịch bản triển khai hợp định danh nhà cung cấp mẫu đăng nhập được nhúng vào trong một trang trình bày của một nhà cung cấp dịch vụ Mặc dù người dùng có thể giống đăng nhập bình thường nhưng trong quá trình đó thông tin của người dùng sẽ đưa trở lại cho nhà cung cấp dịch vụ nhận dạng Hình thức nhúng mang hiểm họa của việc đào tạo người sử dụng làm điều sai trái

 Rủi ro của việc triển khai ra mạng Internet: Nếu một người sử dụng sử dụng một trình duyệt để đăng nhập tài khoản dịch vụ SSO ở sân bay, bỗng dưng

hệ thống bị treo làm người dùng không thể thoát ra được Người dùng bỏ đi và sau khi hệ thống máy tính hoạt động bình thường trở lại bất kì ai tiếp xúc vật lí với máy tính đó có thể truy cập trái phép vào các thông tin của người dùng và

điều này càng đặc biệt nguy hiểm khi sử dụng cho các mục đích bất hợp pháp

Có thể tránh nó bằng cách đặt thời gian kết thúc phiên đăng nhập

 Rủi ro của mật mã yếu: Một trong những vấn đề gây nhiều tranh cãi nhất trong việc đảm bảo an toàn các dịch vụ web là các máy tính hiện đang cài đặt trình duyệt nhưng nhiều trình duyệt chỉ hỗ trợ mật mã 40-bit Mật mã 40-bit được coi là yếu và có thể bị tấn công Điều này đặt ra một nguy cơ từ thông tin liên lạc mã hóa của người sử dụng có thể dễ dàng thu thông tin không được mã hóa

2.2.2 Các kiểu tấn công vào hệ thống SSO

 Tràn bộ đệm

Một lỗi lập trình có thể gây ra một ngoại lệ truy nhập bộ nhớ máy tính và chương trình bị kết thúc, hoặc khi người dùng có ý phá hoại, họ có thể lợi dụng lỗi này để phá vỡ an ninh hệ thống Các lỗi tràn bộ đệm có thể làm cho một tiến trình đổ vỡ hoặc cho ra các kết quả sai Các lỗi này có thể được kích hoạt bởi các

dữ liệu vào được thiết kế đặc biệt để thực thi các đoạn mã phá hoại hoặc để làm cho chương trình hoạt động một cách không như mong đợi Bằng cách đó, các lỗi tràn bộ đệm gây ra nhiều lỗ hổng bảo mật (vulnerability) đối với phần mềm

và tạo cơ sở cho nhiều thủ thuật khai thác (exploit)

 Session Hijacking

Session Hijacking là quá trình chiếm lấy một session đang hoạt động, nhằm mục đích vượt qua quá trình chứng thực truy cập bất hợp lệ vào thông tin hoặc dịch vụ của một hệ thống máy tính

Khi một user thực hiện kết nối tới server qua quá trình xác thực, bằng cách cung cấp ID người dùng và mật khẩu của mình Sau khi người dùng xác thực, họ

có quyền truy cập đến máy chủ và hoạt động bình thường Trong quá trình hoạt động, người dùng không cần phải chứng thực lại Kẻ tấn công lợi dụng điều này

để cướp session đang hoạt động của người dùng và làm cho người dùng không kết nối được với hệ thống Sau đó kẻ tấn công mạo danh người dùng bằng session vừa cướp được, truy cập đến máy chủ mà không cần phải đăng nhập vào

hệ thống

Khi cướp được session của người dùng, kẻ tấn công có thể vượt qua quá trình chứng thực dùng, có thể ghi lại phiên làm việc và xem lại mọi thứ đã diễn ra Đối với cơ quan pháp lý, có thể dùng làm bằng chứng để truy tố, đối với kẻ tấn công,

có thể dùng thu thập thông tin như ID người dùng và mật khẩu Điều này gây nhiều nguy hại đến người dùng

Vấn đề này càng đặc biệt nghiêm trọng với hệ thống SSO vì khi chiếm được phiên kẻ tấn công có thể truy cập vào được các ứng dụng khác để khai thác thông tin

Hình 2.5: Tấn công Session Hijacking

 Man in the Middle

Hoạt động bằng cách thiết lập các kết nối đến máy tính nạn nhân và relay các message giữa chúng Trong trường hợp bị tấn công, nạn nhân cứ tin tưởng là

họ đang truyền thông một cách trực tiếp với nạn nhân kia, trong khi đó sự thực thì các luồng truyền thông lại bị thông qua host của kẻ tấn công Và kết quả là các host này không chỉ có thể thông dịch dữ liệu nhạy cảm mà nó còn có thể gửi xen vào cũng như thay đổi luồng dữ liệu để kiểm soát sâu hơn những nạn nhân của nó

Một số kiểu tấn công Man in the Middle hay được sử dụng : ARP Cache, DNS Spoofing, chiếm quyền điều khiển (hijacking) HTTP session

Hình 2.6: Tấn công Man in the Middle

Hình 2.7: Giả mạo DNS

2.2.3 Tăng cường an toàn bằng các chính sách

Các sản phẩm SSO có nhiều tính năng tăng cường tính bảo mật cho hạ tầng của các đơn vị Tuy nhiên các sản phẩm SSO không thể đảm bảo tất cả tính an toàn cho một tổ chức nếu thực hiện không cẩn thận SSO còn làm xuất hiện thêm

các lỗ hổng bảo mật mới Do vậy một hệ thống SSO cần được tăng cường bởi các chính sách:

• Không để người sử dụng tránh cách quên mật khẩu bằng cách viết ra giấy dán trên máy tính, lưu vào một file văn bản

• Quản lí tập trung các thông tin ứng dụng được SSO trên một máy chủ trung tâm

• Thi hành các chính sách về mật khẩu như: Độ dài mật khẩu tối thiểu, không đặt các mật khẩu phổ biến, không đặt là tên, ngày sinh, sử dụng kết hợp cả chữ hoa chữ thường và các kí tự đặc biệt…

• Cơ chế phục hồi mật khẩu để phục hồi trong trường hợp người dùng quên mật khẩu

• Khóa phiên đăng nhập sau một số lần đăng nhập không thành công liên tiếp

• Thi hành chính sách đổi mật khẩu lần đầu truy nhập và sau một thời gian

sử dụng nhất định với các quản trị

• Lưu giữ các mật khẩu đã được sử dụng và đảm bảo mật khẩu mới không trùng với mật khẩu đã được sử dụng

• Hết hạn mật khẩu sau một thời gian nhất định

• Phiên làm việc kết thúc sau một thời gian không sử dụng ứng dụng liên tục

• Tăng cường hệ thống giám sát và báo cáo

2.3 Tăng khả năng an toàn với giao thức SAML Single Sign On

2.3.1 Giới thiệu SAML

SAML là một tiêu chuẩn mã hóa xác nhận các thông điệp giao thức dạng XML, sử dụng thẻ an toàn(security tokens) để xác nhận thông dựa trên các thông tin chứa trong nó : Thông tin về người dùng, trung tâm xác thực và dịch vụ yêu cầu, hỗ trợ việc xác thực trên web và được sử dụng là một tiêu chuẩn phổ biến của đăng nhập một lần

SAML Single Sign On mô tả việc sử dụng thông điệp để thực hiện hoạt động đăng nhập giữa ba bên: Người dùng U sử dụng một trình duyệt tiêu chuẩn B, một web nguồn S và web đích D.

Hình 2.8: SAML Single Sign On

Giả sử người sử dụng U đã chứng thực đăng nhập với web site S, trình tự xác nhận của giao thức SAML Single Sign On:

1 Người dùng truy cập vào web site D

2 Do người dùng U đã xác nhận đăng nhập với S nên trình duyệt chuyển hướng từ web site D về site nguồn S để xác nhận thông tin chứng thực

3 Hoàn thành việc chuyển hướng xác nhận người dùng về site S

4 Site S xác nhận việc chứng thực của người dung

5 Chuyển hướng người dùng về site D cùng với một số thông tin dữ liệu xác nhận cho D khẳng định việc xác thực U đã thực hiện và đang được lưu giữ

2.3.2 Bí mật,Toàn vẹn

SAML Single Sign On giao thức truyền thông điệp đảm bảo tính toàn vẹn, bí mật Thông điệp được chuyển qua kênh truyền thông thường hoặc sử dụng SSL/TLS, nhưng ở lớp này của giao thức dễ bị tấn công man-in-the-middle nên SAML SSO sẽ loại bỏ kênh truyền thông thường vì mức an toàn thấp

S → cid R:adr-msg

R: Bên nhậnAdr: Tên máyMsg: Thông điệp,tham sốNgay cả khi gửi thông điệp không sử dụng các kênh truyền SAML SSO sử dụng một kênh nhận dạng dạng cid được viết như chỉ số đại diện đầu mũi tên Trong thực hiện không có kênh truyền chỉ định cid sẽ là kênh đại diện tiếp nhận các kết nối mạng cơ bản Các kênh thông điệp được định nghĩa trong thông điệp đầu tiên được gửi Nó có thể thêm vào đầu vào cho các hoạt động gửi, thực tế tất

cả thông điệp được truyền qua cùng một kết nối

Khi SAML SSO không sử dụng giao thức xác thực trong các loại hình truyền thông điệp, giao thức sẽ không diện được mức an toàn và thấy kiểm tra thấy thiếu sự nhận dạng và các nhân tố đảm bảo an toàn do vậy không phù hợp

Các nhân tố đảm bảo bảo mật và toàn vẹn và chống chối bỏ:

• Bí mật: Ngoài người gửi ban đầu,chỉ có một bên có thể giải mã thông điệp msg Điều này thường được chỉ định bởi các ADR

• Toàn vẹn: Kiểm chứng được bên đọc được msg ở trạng thái nguyên vẹn chưa bị sửa chữa

2.3.3 Bảo mật kênh truyền

SAML SSO xác nhận thông tin người dùng lần hai sau lần người dùng đã được chứng thực Nó đảm bảo tính bí mật, toàn vẹn và xác thực hai bên Tất cả các thông tin được truyền qua một kênh an toàn Có thể thực hiện với SSL/TLS

có chứng chỉ xác thực hai bên người dùng và máy chủ:

S(snd _id) ⇒ cid R(rcv_id):adr-msgHai bên giao tiếp: Bên gửi S và bên nhận R trong đó S có đặc trưng snd_id và bên R có định danh rcv_id Tên máy tính được đặt trong lần đầu tiên gửi thông điệp và bỏ qua nó trong lần tiếp theo nếu cùng sử dụng kênh truyền cid Việc thiết lập kênh truyền giữa S và R sử dụng thông điệp msg để gửi nhận thông qua một kênh được thành lập:

 Xác thực hai bên: Hai bên gửi (S) và nhận(R) xác nhận mình với snd_id

và rcv_id, cả hai bên kiểm tra chứng chỉ tương ứng và chỉ tiến hành quá trình bắt tay nếu chứng chỉ hợp lệ

 Bí mật: Chỉ có S với định danh snd_id và người nhận R với rcv_id mới có thể đọc được nội dung thông điệp msg

 Toàn vẹn: Bên nhận R có thể xác minh nội dung thông điệp msg được gửi

từ từ S có định danh snd_id Nếu R nhận được thông điệp msg từ bên khác

S gửi đến nó sẽ trả về một thông báo lỗi

2.3.4 Theo dõi người sử dụng

Là một thành phần quan trọng trong giao thức SAML Single Sign On, trang web nguồn S không yêu cầu người dùng U đăng nhập lại nhưng phải xác thực U

tự động Toàn bộ quá trình tương tác trong suốt với người dùng được gọi là quá trình xác thực và theo dõi người dùng đăng nhập

Giả sử người dùng U đã đăng nhập trước đó và phiên đăng nhập của U chưa hết hạn, người dùng sử dụng trình duyệt B trở lại web nguồn S trong bước 1 của giao thức, website S có thể liên kết các trình duyệt vẫn còn đăng nhập hợp lệ Site S định danh người dùng U từ liên kết này Các thông tin đăng nhập được xây dựng:

a): S → cid B⇒U :Yêu cầu đăng nhập

b): U ⇒ B →cidB :Đăng nhập lU,S

c): S →cidB : Xác minh thông tin vi

Bước (a): Đăng nhập asite nguồn S được xác thực người dùng bằng một kênh truyền được định danh bởi các cid, trình duyệt B yêu cầu người dùng U đăng nhập

Bước (b): Trong bước này người dùng U đăng nhập thông tin của mình(lU,S) vào trình duyệt S Thông tin đăng nhập của người dùng có thể là user/password, trình duyệt B chuyển tiếp vào site nguồn S thông qua kênh định danh bởi cid Site nguồn S kiểm tra thông tin đăng nhập, sau khi quá trình đăng nhập hoàn thành site S gửi lại một xác minh đăng nhập thành công cho trình duyệt B Trình duyệt xem thông tin và xác định thông tin đăng nhập người dùng U

Người dùng có thể tiếp tục theo dõi các hoạt động mà không cần tương tác với giao diện người dùng:

d): S→cid’B yêu cầu vi

c): B→cid’S Kiểm chứng vi

Site nguồn S theo dõi người dùng và yêu cầu xác minh vi thông qua một kênh được định danh cid’ Trình duyệt B căn cứ vào các thông tin xác minh để đưa ra phản ứng với S Sau khi xác minh được các thông tin với trình duyệt người dùng, site nguồn chấp nhận các thông tin đăng nhập

2.4 Lược đồ giao thức

2.4.1 Liên hệ các trang web nguồn

Trong bước đầu tiên của giao thức trình duyệt B thiết lập quan hệ với site nguồn S

• a): B →bs_cidS :ist_host – GET <IST-URL>s? TARGET=target

<HTTP-Version>

• b) S: Kiểm tra các yêu cầu

• (a): Trình duyệt B kết nối với các trang web liên kết:Chuyển URL<IST-URL>s. của S B và S chuyển thông điệp với các thuộc tính bí mật, toàn vẹn như đã mô tả trước đó tới trang nguồn S

• (b): S phân tích, kiểm tra các yêu cầu và bắt đầu một phiên làm việc mới S cố gắng xác định các thông tin yêu cầu từ chuỗi thông tin truy vấn người dùng yêu cầu

Sự thiếu xác thực: Kết nối này không cung cấp xác thực một bên do đó trình duyệt B có thể không nhất thiết xác minh S bằng cách kiểm tra chứng chỉ của S

và xác nhận của nhà cung cấp chứng chỉ tin cậy Việc thiếu xác thực này có thể dẫn đến tấn công xen giữa (man-in-the-middle) việc truyền thông giữa trình duyệt và web nguồn (B↔A↔S) Kẻ tấn công xen giữa chỉ cần phá vỡ quá trình theo dõi người dùng ở bước tiếp theo là có thể thành công

Định dạng thông điệp: Thông điệp gửi tới S là một HTTP GET yêu cầu đường dẫn của <IST-URL>s nó chứa thông tin tài nguyên mà người dùng U muốn truy cập trên trang web đích D Các giao thức SAML SSO không quy định

cụ thể các yếu tố thêm vào các URL cũng như không ngăn cấm bao gồm các yếu

tố khác Giao thức đã không mô tả rõ cách đặt tên rõ ràng dẫn đến cản trở việc điều phối các thông điệp để sử dụng các module giao thức khác nhau

 Chuyển hướng đến trang web đích:

Sau khi xác nhận thành công người dùng U,trang nguồn S tạo ra nhiều kiến trúc SAML Nó chuyển hướng đến trình duyệt B tạo các URL <AR-URL>D của web đích D và với các thành phần của SAML

(a) S: Xác định các trang web đích tương ứng D đối với mục tiêu Bước 1 trong <AR-URL>D trong bảng kiến trúc gửi

(b) S: Tạo ra một hoặc nhiều kiến trúc SAML<SAMLart>i có chứa SourceIDS của nó

(c) S: Tạo ra một searchpart SAML SAM LSP

(d)S →bs cid B : <HTTP-Version> 302 <Reason Phrase> Location URL>D ? SAM Lsp

<AR-Trong bước (b), site nguồn nhận được URL <AR-URL>D Giao thức SAML Single Sign On không xác định thủ tục này Chúng ta giả định rằng nó tìm kiếm cho một URL có tên máy ngang bằng với nguồn đích Site nguồn này sinh ra một

số của SAML artifacts và lưu trữ nó các thông tin artifacts đã được ban hành tới site đích D Site đích cũng như site nguồn không có chứng chỉ hoặc định danh của D, nó có thể sử dụng tên máy site S hoặc tham chiếu của nó Ở bước này chúng ta trải qua cùng một vấn đề định dạng thông điệp ở bước 1 Hơn nữa, chúng ta không dựa vào xác thực thì tấn công man in the middle có thể xảy ra

2.4.2 Chuyển đến trang đích

Ở bước 3, trình duyệt B kết nối với D <AR-URL>D.

(a) B: Extracts the URL <AR-URL>D ? SAM Lsp

(b) B →bd cid D: ar host – GET <AR-URL>D ? SAM Lsp Version>

<HTTP-2.4.3 SAML Request

Trong bước 4 web đích D thiết lập một kênh an toàn để web nguồn S sử dụng các sourceID của các SAML artifacts nhận được để tìm ra tương ứng các SAML trả lời tương ứng cho các yêu cầu

(a) D: Kiểm tra artifact <SAMLart>i the SAM Lsp chứa SourceID

(b) D: Xem <SR-URL>S tương ứng với SourceID

(d) D(idD ) ⇒ds_cid S(idS ): sr_host – SAML yêu cầu <SR-URL>S chứa

artifacts<SAMLart>i

Trong bước 4a, site đích tạo ra một phiên để phân tích các URL yêu cầu Site đích này hủy bỏ chạy nếu yêu cầu không dành cho <AR-URL>D. Nếu D không thể phân tích cú pháp searchpart SAML, hoặc nếu yêu cầu không bao gồm SAML artifacts Site đích kiểm tra giá trị của artifacts<SAMLart>i trong searchpart Tất cả artifacts phải được định dạng,có id version hợp lệ, và không bao gồm các bản với SourceID Site đích D sử dụng SourceID để tìm kiếm <SR-URL>S của site S( bước 4b)

Bước 4d, site nguồn sẽ thiết lập kênh truyền bảo mật ds_cid tới site S với xác thực hai bên Nó gửi SAML request với received artifacts qua kênh truyền này

Đặc điểm kỹ thuật của trang web nguồn: Bước này của giao thức không xác định đầy đủ thông tin của site S SAML Single sign on chỉ trạng thái site D <SR-URL>S.Vì vậy chúng ta có thể giả định rằng D không biết định danh ids của S.Một yêu cầu sở hữu của SAML Artifact: Trong giao thức Sigle sign on, SAML artifacts chỉ được sử dụng một lần, nó được quy định ở bước 5, trong khi site D không lưu trữ artifacts received Vì vậy, nếu việc chuyển của SAML khác

D thì SAML đòi hỏi định danh của U idU

Nhiều dịch vụ trên một host: Một site nguồn S có thể chỉ cần xác minh với máy gửi ở bước 4 Nếu có nhiều dịch vụ trên web đích D, một số dịch vụ nhưng bảo mật kém được sử dụng mạo danh người dùng U để thao tác với các dịch vụ

có mức bảo mật cao hơn, ví dụ tại dịch vụ ngân hàng dịch vụ phân tích chứng khoán,thị trường chạy cùng với các dịch vụ nghiệp vụ của ngân hàng trên cùng một máy chủ và sử dụng SAML Single Sign On cho các dịch vụ Một mã độc được thực thi chuyển hướng từ phân tích thi trường sang sử dụng các quyền của người dùng U có quyền thực hiện các giao dịch điện tử ngân hàng(<AR-URL>DBank ,stock đến <AR-URL>DBank ,ebank)

2.4.4 SAML Response

Trong bước 5 site nguồn phân tích yêu cầu SAML và tạo ra phản hổi Nó gửi phản hồi trở lại thông qua kênh truyền với id ds_cid tạo ra ở bước 4

(a) S: Kiểm tra các đích

(b) S: Thực thi việc thực hiện một lần các artifact

(c) S: Xem hoặc tạo ra các xác nhận SAML tương ứng với các artifacts

<SAMLart>i

(d) S: Tạo các ID phản hồi

(e) S(idS ) →ds_cidD(idD ): Phản hồi SAML <SR-URL>S chứa các xác nhận về SSO hoặc mã lỗi ,đáp ứng tham chiếu các yêu cầu của bước 4 (f) D: Xác minh tính hợp lệ của các SAML

Trong bước 5a site nguồn S kiểm tra thông tin phản hồi lại từ các site yêu cầu thông tin, giao thức SAML SSO lưu thông tin các yêu cầu thông tin từ các site đích để site nguồn không xác định và không cấp yêu cầu đó cho các site đích yêu cầu khác Các site nguồn có thể chỉ lưu trữ tên máy hoặc <AR-URL> cho các yêu cầu Nó sẽ so sánh tên máy của site đích hoặc AR-URL trong bảng lưu trữ

mà nó đã phát hành để đưa ra các phản hồi Nếu trong bước 5b các thông tin phản hồi được tìm thấy site nguồn S sẽ đưa ra phản hồi với các tài nguyên được yêu cầu Đây là tài nguyên được yêu cầu một lần, mỗi lần yêu cầu sử dụng lại site nguồn sẽ xác nhận và gửi phản hồi sử dụng cho các lần tiếp theo Nếu thông tin yêu cầu không xác định tên máy đích, AR-URL site nguồn S sẽ phản hồi yêu cầu lại bước 4

2.4.5 Đáp ứng yêu cầu từ trình duyệt

Trong bước 6 web đích D đáp ứng các yêu cầu của trình duyệt B, nếu D xác định được các thông tin của người dùng U qua các bước trên nó sẽ cho phép truy cập các tài nguyên yêu cầu Nếu không nó sẽ trả về một thông báo lỗi

D→bd_cidB: thông điệp lỗiĐặc điểm kỹ thuật của bước này: Giao thức SAML SSO không xác định được đúng các thông tin yêu cầu nó sẽ bỏ qua các bước yêu cầu bảo mật cho kết nỗi này

2.5 Một số lỗ hổng có thể lợi dụng để thực hiện tấn công

2.5.1 Hijacking / Replay Attack

Một kẻ tấn công có thể cướp kết nối của SAML SSO sử dụng lại và chuyển

Điều kiện tiên quyết: Kẻ tấn công A có thể chặn các kết nối và có thể quan sát các kết nối từ trình duyệt B để thu được các URL<AR-URL >Dcủa bước 3 Ngoài ra phải hoàn toàn sở hữu thông điệp msg và không có ràng buộc toàn vẹn cho bên gửi phòng ngừa bị sử dụng phát lại.

Kẻ tấn công chặn kết nối từ bước 3 đến site đích D và sử dụng lại thông điệp

đã được mã hóa

• B → D: Chuyển đến <AR-URL>D

• Kẻ tấn công A: Chặn quá trình chuyển hướng từ B đến D và chấm dứt kết nối từ B đến D

• AB → D: Phát lại các thông tin chuyển cho D <AR-URL>D và mạo

danh trình duyệt B nó sử dụng một giao thức phụ để sửa đổi thông điệp mã hóa cho phép gửi trực tiếp Đích D không thể phân biệt được

B và A do thiếu xác thực

• D → S: SAML yêu cầu q cho SAML artifacts của thông điệp p

• S → D: SAML đưa ra phản ứng r với yêu cầu xác nhận

• D→ AB: Đáp ứng cho bước 3,D sẽ đáp ứng cho AB và cấp quyền truy cập tương tự trình duyệt B và người sử dụng U

Kết luận: Vì có tính toàn vẹn và bí mật ở bước 3 nên kẻ tấn công A không thể xem hoặc chỉnh sửa được tin nhắn p Nhưng đặc tính này không đủ mạnh đển chống lại tấn công phát lại Kẻ tấn công A đóng giả trình duyệt B gửi yêu cầu tới Site D

Do thiếu xác thực trong bước này và thiếu định danh trong chuyển hướng, D không phân biệt được bên B và AB Ngoài địa chỉ IP của các bên, thì quan điểm của D là như nhau trong giao tiếp với B và AB

Giải pháp: Site S có thể nhập địa chỉ IP của trình duyệt B như các chuỗi truy vấn trong khi chuyển hướng Site đích D sẽ kiểm tra địa chỉ IP của thông báo nhận được với địa chỉ IP của trình duyệt B Nếu kiểm tra thấy không trùng nhau

D sẽ không thực hiên các bước sau

2.5.2 Tấn công xen giữa (Man-in-the-Middle)

Giả mạo DNS là một kỹ thuật Man-in-the-Middle được sử dụng nhằm cung cấp thông tin DNS sai cho một host để khi người dùng duyệt đến một địa chỉ nào

đó Lúc này kẻ tấn công đóng vai trò là một proxy đứng giữa trình duyệt B và web nguồn S: B ↔A↔ S

Điều kiện tấn công: Cần giả mạo ARP cache thiết bị mục tiêu để định tuyến lại lưu lượng của nó qua host đang tấn công của mình, từ đó có thể chặn yêu cầu DNS và gửi đi gói dữ liệu giả mạo Mục đích của kịch bản này là lừa người dùng trong mạng mục tiêu truy cập vào website của kẻ tấn công thay vì website mà họ đang cố gắng truy cập

• AS: Đóng vai trò giả mạo nguồn web S <IST-URL>S đến trình duyệt B

<IST-URL>sB =<IST-URL>A

• B →As Kết thúc quá trình chuyển hướng Quá trình này không yêu cầu xác thực

• AB →S Kết thúc việc chuyển hướng từ trình duyệt giả mạo AB đến web

S A thực hiện đứng giữa B và S, vì hệ thống theo dõi người dùng của

S không chống lại được tấn công Man in the Middle nên A có thể chuyển tiếp được tất cả giao tiếp giữa B và S trong quá trình theo dõi người dùng

• AB →D Kết thúc quá trình chuyển hướng đến <AR-URL>D AB đóng

vai trò của B để chuyển hướng các AML artifacts và cho phép AB có quyền truy cập của người dùng U

• A→B: Chuyển hướng yêu cầu <IST-URL>S một người ban đầu sử dụng trình duyệt B giả định người dùng đã được xác thực với site S Khi đó không cần các tương tác ở bước 1,2, A lúc này có thể sử dụng giao thức của B để sử dụng một phiên kết nối với quyền người dùng

mà không bị thông báo thiết lập lại trạng thái của giao thức

Do các bên không yêu cầu chứng thực ở bước 1,2 nên trình duyệt B có thể không phân biệt <IST-URL >A của kẻ tấn công và <IST-URL>S của nguồn thật website

Các giải pháp: Xác thực một bên trong tất cả các bước của giao thức có thể ngăn chặn giả mạo site S, để website nguồn S theo dõi trình duyệt B được chỉ định trong giao thức SAML single sign on Được sử dụng trong các sản phẩm

2.5.3 HTTP Referrer Attack

Cuộc tấn công cho phép người dùng thu thập được các thông tin rò rỉ về SAML artifacts Nó sử dụng các referen TAG để không sử dụng các SAML artifacts

Điều kiện tấn công: Kẻ tấn công có thể khai thác các kênh truyền và chặn các kết nối Ngoài ra, để cho B là một trình duyệt đã đưa ra HTTP Referrer Tag theo mặc định

Kẻ tấn công làm gián đoạn sự kết nối trang web D và web site nguồn S để thu thập thông tin của SAML artifacts

2.5.4 Khai thác lỗ hổng của SSL/TSL

SOAP trên HTTP là một trong những thành phần quan trọng nhất các ràng buộc của giao thức SAML Single Sign On Nó sử dụng SSL 3.0 hoặc TLS 1.0 là kênh truyền thông cho các kết nối yêu cầu tính bí mật và tính toàn vẹn Khi liên kết này vượt quá các yêu cầu an ninh của các giao thức riêng của mình, các cuộc tấn công sẽ có nhiều khó khăn thực hiện Tấn công Hijacking / Replay Attack không còn thực hiện được

2.6 Bảng đánh giá các sản phẩm SSO (open source)

• Stanford WebAuth: Stanford , Oxford University

• Cosign: Michigan , Edinburgh University

Và còn nhiều tool khác như Pubcookie , KX.509, A-Select Ở đây trong

survey này sẽ giới thiệu về CAS , Stanford WebAuth, Cosign , nêu lên các ưu nhược điểm, và đánh giá thông qua 1 số các tiêu chí về các tool trên qua đó xem xét tool nào là thích hợp nhất cho hệ thống xác thực của trường đại học

2.6.2 CAS (Central Authentication Service)

 Open source được phát triển bời đại học Yale

 CAS server được viết bằng Java và chạy trên nền J2EE

 Dưa trên mô hình cookie-Based Model.

 Sử dụng giao thức Kerberos, việc authentication sẽ được dựa vào session

ID cookie ( hay là Ticket Granting ticket)

kế từ J2EE application server

Tính hiệu quả Tốt Code thì rõ ràng và có sử dụng

in-memory ticket cache

(Số lượng transaction

của application có thể

đáp ứng)

Tốt CAS thừa hưởng các đặc tính tốt về

Throughput từ J2EE application server

Total Cost of

Ownership

Tốt CAS có thể có mức chi phí cao dựa

vào sự triển khai của J2EE application server.Nhưng nhìn chung,chi phí cho CAS ở mức thấp

Khả năng mở rộng Tuyệt vời Khả năng mở rộng của CAS thì phụ

thuộc nhiều vào khả năng tạo nhóm mà J2EE application server cung cấp Dựa vào tải ,mà J2EE application server có thể triển khai thêm Servlets để có thể đáp ứng

Supportability(Mức độ

tích hợp ứng dụng có

thể được hỗ trợ)

Rất tốt Hầu hết J2EE application servers

cung cấp rất tốt các tool để giám sát các thánh phần của J2EE mà triển khai trên

nó Tiếc rằng các tool này ko được mờ rộng Application server cung cấp cơ chế logging tập trung

Ko có 1 trang dành cho người quản trị để có thể thấy logged-on users

Khả năng bảo trì Tốt Ứng dụng có thể dễ dàng được sửa

chữa vào bảo trì, Nhưng nó sẽ đòi hỏi phải triển khai trên tất cả các J2EE application server và cập nhật cho các client đang sử dụng trên Web servers

Bảng 2.1:CAS(Central Authentication service)

 Nhận xét về CAS :

 An toàn

 Hỗ trợ N-tier installations mà ko cần phải truyền password

 Việc thiết kế tốt Service ticket là một trong những điểm mạnh của CAS

 Hỗ trợ rất lớn về thư viên bên client như : Java, Perl, JSP, ASP, PHP, PL/SQL, Apache, PAM module

 Được rất nhiều trường đại học tin dùng

 Dễ bị tổn hại khi network và server bị lỗi

 Một trong những điểm bất lợi của CAS là CAS sử dụng Java Java có một điểm bất lợi về tốc độ đáp ứng là một trong những điều quan trọng của hệ thống

Nhưng vấn đề này có thể giải quyết bằng cách viết code tốt và triển khai được một kiến trúc tốt Nếu được như vậy thì tốc độ của hệ thống sẽ hiệu quả giống như những hệ thống được viết bằng các ngôn ngữ khác

2.6.3 Open source được phát triển bời đại học Stanford

Tiêu chí Mức độ Đánh giá

Tính mềm dẻo Hợp lý WebAuth đưa ra thiết kế kết nối chặt :

WebKDC xử lý mọi thứ Dù vậy, theo thiết

kế, WebKDC ko xử lý việc xác nhận các token (điều này được thực hiện bởi Web server trong khi giải mã các Token)

Tính hiệu quả Tốt Code WebAuth được viết bằng Perl, mà

Perl thì rất hiệu quả (mặc dù là ngôn ngữ dạng thông dịch) Một vấn đề lớn của Perl

là có khuynh hướng sử dụng nhiều bộ nhớ hơn 1 ứng dụng C tương đương

Độ đảm bảo khi

gặp lỗi

Rất tốt Perl cung cấp việc xử lý lỗi tốt và

WebAuth sử dụng khả năng này của PerlThroughput(Số

lượng transaction

của ứng dụng có

thể đáp ứng)

Rất tốt Bởi vì WebKDC không làm việc kiểm

định các token cho nên performance không

bị ảnh hưởng bởi việc token bị sai Và cũng bởi vị bản chất tự nhiên của WebKDC là không trạng thái, nên sẽ có throughput cao hơn.Duy chỉ có 1 điểu trở ngại lớn là sử dụng ngôn ngữ dạng thông dịch

Total Cost of

Ownership

Kém Chi phí triển khai cho WebAuth có lẽ

khá cao so với việc client hỗ trợ Mặc dù là chi phí dành cho WebAuth sẽ nhỏ nhưng chi phí dành cho Perl sẽ lớn hơn Java

Khả năng mở

rộng

Rất tốt Bởi vì WebKDC là không trạng thái (tất

cả trạng thái được lưu vào trong cookies trong browser), nên WebAuth thì có tính

mở rộng cao Multiple servers có thể được vận hành với WebKDC

Ko có 1 trang dành cho người quản trị

để có thể thấy logged-on users

Khả năng bảo

trì

Tốt Ứng dụng có thể dễ dàng được sửa chữa

vào bảo trì, Nhưng nó sẽ đòi hỏi phải triển khai trên tất cả các J2EE application server

và cập nhật cho các client đang sử dụng trên Web servers

Bảng 2.2: Open source được phát triển bởi đại học Stanford

2.6.4 Cosign

Tiêu chí Mức độ Đánh giá

Tính mềm dẻo Rất tốt Nếu các thành phần của hệ thống được

phân bố 1 cách hợp lý, hệ thống sẽ có tính mềm dẻo Cosign đưa ra kết nối thấp , vì vậy , những mô hình có thể triển khai là rất phong phú và đa dạng Bởi vì CoSign server có khả năng sao lặp dữ liệu cho các server khác ,nên dữ có thể dẽ dáng được phân bố và làm tăng tính mềm dẻo và nâng cao throughput

Tính hiệu quả Tốt Tất cả những authentication cookie và

service cookie thì được lưu thành dạng file

ở trên đĩa Điều này tạo ra sự hiệu quả trong các trường hợp high-load

Độ đảm bảo khi

gặp lỗi

Tốt Một khi ừng dụng được chạy, Cosign

có khả năng xử lý lỗi 1 cách hợp lýThroughput(Số

lượng transaction

của application có

thể đáp ứng)

Rất tốt Đại học Michigan đang sử dụng

CoSign trên 3 máy dual 2.8Ghz với 4GB RAM và phục vụ xấp xỉ đăng ký 255000

ST và 180000 login request / ngày

Total Cost of

Ownership

Tốt CoSign có thể có mức chi phí cao về

việc triển khai và thay đổi code để phù hợp vời yêu cầu.Nhưng nhìn chung, chí phí cho Cosign là nhỏ

Khả năng mở rộng Rất tốt Tất cả authentication cookies và

service cookies thì được lưu dưới dạng file trên đã cứng Điều này ảnh hưởng nhiều đến khả năng mở rộng, như là có một số lượng tối đa các object mà hệ điều hành cho phép trong một thư mục

Có 1 quá trình lớn phục vụ cho việc nhân rộng các TGT và ST tới các dịch vụ cosignd khác đang chạy trên các host Mối quan hệ giữa CoSign CGI và cosignd /monster services không cần thiết phải là quan hệ 1 -1

Ko có 1 trang dành cho người quản trị

để có thể thấy logged-on users

Khả năng bảo trì Tốt Phần lõi cùa ứng dụng dễ dàng được

bảo trì

Bảo trì , sửa chữa client và các hàm API của client thì sẽ khó khăn hơn 1 chút bởi vì bản chất phân tán của chúng

Bảng 2.3: CosignThông qua tìm hiểu và xem xét thì ta thấy, mỗi giải pháp đều có điểm mạnh

và điểm yếu riêng CoSign là 1 giải pháp tốt cho việc hiện thực hệ thống single sign on, thế nhưng với tài liệu ít ỏi mà CoSign đưa ra việc hiện thực CoSign là rất khó khăn( hầu như không có hỗ trợ nào về tài liệu cho dù đây là 1 open