Silverlight Security - Bảo vệ Ứng dụng Silverlight của bạn (2023)

Bài báo
12/08/2015

tháng 5 năm 2010

Tập 25 Số 05

QuaJosh xoắn| tháng 5 năm 2010

Với vai trò là nhà tư vấn về Dịch vụ của Microsoft, tôi thường xuyên thảo luận với khách hàng và đối tác về bảo mật ứng dụng. Trong bài viết này, tôi sẽ khám phá một số chủ đề nảy sinh trong các cuộc thảo luận đó. Cụ thể, tôi sẽ tập trung vào những thách thức mới mà các lập trình viên phải đối mặt khi cố gắng bảo mật các ứng dụng Silverlight và tôi sẽ xem xét nơi các nhóm phát triển nên tập trung nguồn lực của họ.

Bài viết này đề cập đến nhiều khái niệm kỹ thuật mà bạn sẽ thấy được đề cập chi tiết hơn ở những nơi khác (bao gồm cả tạp chí này). Vì lý do này, tôi sẽ không khám phá những chủ đề này một cách chuyên sâu về mặt kỹ thuật. Thay vào đó, mục tiêu của bài viết là “kết nối các dấu chấm” và chỉ ra cách bạn có thể khai thác các khái niệm này để bảo mật các ứng dụng của mình.

Khi lập kế hoạch bảo mật cho một ứng dụng, sẽ rất hữu ích khi nghĩ đến ba chữ A: xác thực, ủy quyền và kiểm tra.

xác thựclà hành động xác nhận rằng người dùng chính là người mà họ tuyên bố. Chúng tôi thường làm điều này với tên người dùng và mật khẩu.

ủy quyềnlà quá trình xác nhận rằng người dùng, sau khi được xác thực, thực sự có quyền thích hợp để thực hiện một hành động cụ thể hoặc truy cập một tài nguyên cụ thể.

Kiểm toánlà hành động duy trì hồ sơ hoạt động sao cho người dùng không thể từ chối các hành động và yêu cầu được thực hiện trên hệ thống.

Tôi sẽ tập trung vào hai điều đầu tiên, xác thực và ủy quyền, trong ngữ cảnh của ứng dụng Silverlight. Vì đây là Ứng dụng Internet phong phú (RIA), nên phần lớn các khái niệm được mô tả trong bài viết này đều áp dụng như nhau cho JavaScript và XML không đồng bộ (AJAX) hoặc các cách tiếp cận RIA khác. Tôi cũng sẽ thảo luận về cách bạn có thể ngăn truy cập không mong muốn vào các tệp ứng dụng Silverlight của mình.

cấu trúc liên kết

Silverlight là một plug-in đa trình duyệt tận dụng nhiều khái niệm đồ họa do Windows Presentation Foundation (WPF) tiên phong, cho phép các nhà phát triển Web tạo trải nghiệm người dùng phong phú vượt xa những gì có thể chỉ với HTML và JavaScript.

Không giống như ASP.NET, Silverlight là công nghệ phía máy khách nên nó chạy trên máy tính của người dùng. Vì vậy, sự phát triển Silverlight được cho là có nhiều điểm chung với Windows Forms hoặc WPF hơn là với ASP.NET. Theo nhiều cách, đây là một trong những ưu điểm lớn nhất của Silverlight, vì nó loại bỏ nhiều vấn đề gây ra bởi bản chất không trạng thái của các ứng dụng Web. Tuy nhiên, vì tất cả mã giao diện người dùng đều chạy trên máy khách nên bạn không thể tin tưởng vào nó nữa.

Dịch vụ

Không giống như Windows Forms, Silverlight hoạt động trong hộp cát của trình duyệt và có một bộ khả năng giảm bớt, do đó, nó cung cấp mức độ bảo mật cao hơn (mặc dù trong Silverlight 4, người dùng có thể xác định một số ứng dụng nhất định là đáng tin cậy và thúc đẩy các đặc quyền của chương trình để cho phép COM tương tác) . Do đó, Silverlight không thể kết nối trực tiếp với cơ sở dữ liệu, do đó, bạn phải tạo một lớp dịch vụ cung cấp quyền truy cập vào dữ liệu và logic kinh doanh của bạn.

Thông thường, bạn lưu trữ các dịch vụ này trên máy chủ Web của mình, chẳng hạn như bạn làm với các biểu mẫu Web ASP.NET của mình. Cho rằng mã Silverlight chạy sai phía của ranh giới tin cậy giữa máy chủ của bạn và thế giới thực (xemHình 1), trọng tâm nỗ lực của nhóm bạn phải luôn là bảo mật các dịch vụ.

Hình 1Silverlight chạy sai phía của ranh giới tin cậy

Việc triển khai kiểm tra bảo mật nghiêm ngặt trong chính mã Silverlight của bạn không có ý nghĩa gì. Xét cho cùng, kẻ tấn công sẽ dễ dàng loại bỏ hoàn toàn ứng dụng Silverlight và gọi trực tiếp các dịch vụ của bạn, bỏ qua mọi biện pháp bảo mật mà bạn đã triển khai. Ngoài ra, kẻ ác ý có thể sử dụng tiện ích như Silverlight Spy hoặc Debugging Tools for Windows để thay đổi hành vi ứng dụng của bạn khi chạy.

Xác thực Windows

Xác thực Windows tận dụng Cơ quan bảo mật cục bộ hoặc Active Directory để xác thực thông tin đăng nhập của người dùng. Đây là một lợi thế lớn trong nhiều tình huống; điều đó có nghĩa là bạn có thể quản lý tập trung người dùng bằng các công cụ đã quen thuộc với quản trị viên hệ thống. Xác thực Windows có thể sử dụng bất kỳ lược đồ nào được IIS hỗ trợ, bao gồm xác thực cơ bản, thông báo, xác thực tích hợp (NTLM/Kerberos) và chứng chỉ.

Sơ đồ tích hợp là lựa chọn phổ biến nhất để sử dụng với xác thực Windows, vì người dùng không phải cung cấp tên người dùng và mật khẩu của họ lần thứ hai. Sau khi người dùng đăng nhập vào Windows, trình duyệt có thể chuyển tiếp thông tin xác thực dưới dạng mã thông báo hoặc bắt tay xác nhận danh tính của người đó. Có một số nhược điểm khi sử dụng xác thực tích hợp vì cả máy khách và máy chủ đều cần khả năng hiển thị miền của người dùng. Do đó, nó được nhắm mục tiêu tốt nhất vào các kịch bản mạng nội bộ. Hơn nữa, mặc dù nó hoạt động tự động với Microsoft Internet Explorer, các trình duyệt khác, chẳng hạn như Mozilla Firefox, yêu cầu cấu hình bổ sung.

Cả xác thực cơ bản và xác thực thông báo thường yêu cầu người dùng nhập lại tên người dùng và mật khẩu của họ khi họ bắt đầu phiên làm việc với trang Web của bạn. Nhưng vì cả hai đều là một phần của đặc tả HTTP nên chúng hoạt động trong hầu hết các trình duyệt và ngay cả khi được truy cập từ bên ngoài tổ chức của bạn.

Silverlight tận dụng trình duyệt để liên lạc, do đó xác thực Windows dễ thực hiện với bất kỳ phương thức xác thực IIS nào vừa được thảo luận. Để biết mô tả chi tiết về cách thực hiện, tôi khuyên bạn nên đọc hướng dẫn từng bước “Cách: Sử dụng basicHttpBinding với Windows Authentication và TransportCredentialOnly trong WCF từ Windows Forms” tạimsdn.microsoft.com/library/cc949012. Ví dụ này thực sự sử dụng ứng dụng khách thử nghiệm Windows Forms, nhưng cách tiếp cận tương tự cũng áp dụng cho Silverlight.

Xác thực biểu mẫu

Xác thực biểu mẫu là một cơ chế cung cấp hỗ trợ đơn giản cho xác thực tùy chỉnh trong ASP.NET. Như vậy, nó dành riêng cho HTTP, có nghĩa là nó cũng dễ sử dụng trong Silverlight.

Người dùng nhập kết hợp tên người dùng và mật khẩu, được gửi tới máy chủ để xác minh. Máy chủ kiểm tra thông tin đăng nhập đối với nguồn dữ liệu đáng tin cậy (thường là cơ sở dữ liệu của người dùng) và nếu chúng đúng, sẽ trả về cookie FormsAuthentication. Sau đó, khách hàng sẽ trình bày cookie này với các yêu cầu tiếp theo. Cookie được ký và mã hóa, do đó, chỉ máy chủ mới có thể giải mã nó—người dùng ác ý không thể giải mã cũng như can thiệp vào nó.

Chính xác cách bạn gọi xác thực biểu mẫu khác nhau tùy thuộc vào cách bạn triển khai màn hình đăng nhập của mình. Ví dụ: nếu bạn đã sử dụng biểu mẫu Web ASP.NET chuyển hướng đến ứng dụng Silverlight của mình sau khi thông tin xác thực của người dùng đã được xác thực, thì có thể bạn không cần thực hiện thêm công việc xác thực nào nữa. Cookie sẵn có sẽ được gửi đến trình duyệt và ứng dụng Silverlight của bạn sẽ tiếp tục sử dụng cookie bất cứ khi nào đưa ra yêu cầu đối với miền đó.

Tuy nhiên, nếu bạn muốn triển khai màn hình đăng nhập bên trong ứng dụng Silverlight của mình, bạn sẽ cần tạo một dịch vụ hiển thị các phương thức xác thực của mình và gửi cookie thích hợp. May mắn thay, ASP.NET đã cung cấp những gì bạn cần—dịch vụ xác thực. Bạn chỉ cần kích hoạt nó trong ứng dụng của mình. Để được hướng dẫn chi tiết, tôi khuyên bạn nên đọc "Cách: Sử dụng Dịch vụ Xác thực ASP.NET để Đăng nhập thông qua Ứng dụng Silverlight" tạimsdn.microsoft.com/library/dd560704(VS.96).

Một tính năng tuyệt vời khác của xác thực ASP.NET là khả năng mở rộng của nó. Nhà cung cấp tư cách thành viên mô tả cơ chế xác minh tên người dùng và mật khẩu. May mắn thay, có một số nhà cung cấp thành viên có sẵn như một phần của ASP.NET, bao gồm một nhà cung cấp có thể sử dụng cơ sở dữ liệu SQL Server và một nhà cung cấp khác sử dụng Active Directory. Tuy nhiên, nếu không có nhà cung cấp đáp ứng yêu cầu của bạn, bạn có thể dễ dàng tạo triển khai tùy chỉnh.

Ủy quyền ASP.NET

Sau khi người dùng của bạn được xác thực, điều quan trọng là phải đảm bảo rằng chỉ họ mới có thể cố gắng gọi các dịch vụ. Cả dịch vụ WCF thông thường và Dịch vụ dữ liệu WCF đều được biểu thị bằng tệp .svc trong các ứng dụng ASP.NET. Trong ví dụ này, các dịch vụ sẽ được lưu trữ qua ASP.NET trong IIS và tôi sẽ trình bày cách bạn có thể sử dụng các thư mục để bảo mật quyền truy cập vào các dịch vụ.

Bảo mật các tệp .svc theo cách này hơi khó hiểu vì theo mặc định, một yêu cầu đối với một tệp như vậy thực sự bỏ qua hầu hết quy trình ASP.NET, bỏ qua các mô-đun ủy quyền. Do đó, để có thể dựa vào nhiều tính năng của ASP.NET, bạn sẽ phải bật chế độ tương thích ASP.NET. Trong mọi trường hợp, Dịch vụ dữ liệu WCF yêu cầu bạn kích hoạt nó. Một công tắc đơn giản bên trong tệp cấu hình của bạn sẽ hoàn thành nhiệm vụ:

Với khả năng tương thích ASP.NET được bật, có thể ngăn chặn quyền truy cập của người dùng chưa được xác thực bằng cách sử dụng phần ủy quyền của tệp web.config, cũng được hiển thị trong đoạn mã trước đó.

Khi sử dụng xác thực biểu mẫu, nhà phát triển phải suy nghĩ cẩn thận về phần nào của trang web cần có thể truy cập được, ngay cả đối với người dùng chưa được xác thực. Ví dụ: nếu tất cả các phần chỉ được giới hạn cho người dùng được xác thực, thì người dùng chưa được xác thực sẽ đăng nhập như thế nào?

Việc tạo cấu trúc thư mục hỗ trợ các yêu cầu ủy quyền cơ bản của bạn thường dễ dàng nhất. Trong ví dụ này, tôi đã tạo một thư mục “Được bảo mật” chứa các tệp MyWcfService.svc và MyWcfDataService.svc, đồng thời tôi đã triển khai tệp web.config. TRONGHình 2bạn có thể xem cấu trúc thư mục và đoạn mã trước hiển thị nội dung của tệp web.config.

Hình 2Thư mục bảo mật chứa tệp Web.config

Lưu ý rằng thư mục gốc của ứng dụng phải được phép truy cập ẩn danh, nếu không người dùng sẽ không thể truy cập trang đăng nhập.

Đối với các trang web sử dụng xác thực Windows, mọi thứ có thể đơn giản hơn một chút về mặt này, vì xác thực diễn ra trước khi người dùng truy cập tài nguyên có trong ứng dụng, do đó không cần trang đăng nhập cụ thể. Sử dụng phương pháp này, thực sự có thể hạn chế quyền truy cập vào các dịch vụ theo cách chi tiết hơn, chỉ cho phép các nhóm người dùng hoặc vai trò cụ thể truy cập tài nguyên. Để biết thêm thông tin, hãy xem “Ủy quyền ASP.NET”(msdn.microsoft.com/library/wce3kxhd).

Ví dụ này triển khai phần nào ủy quyền, nhưng chỉ riêng ủy quyền cấp thư mục là quá thô để dựa vào trong hầu hết các tình huống.

Ủy quyền trong Dịch vụ WCF

Sử dụng thuộc tính PrincipalPermission là một cách dễ dàng để yêu cầu một người gọi phương thức Microsoft .NET Framework nằm trong một vai trò cụ thể. Mẫu mã này minh họa cách điều này có thể được áp dụng cho ServiceOperation trong WCF trong đó người dùng đang gọi phải là một phần của vai trò “OrderApprovers”:

[PrincipalPermission(SecurityAction.Demand, Role = "OrderApprovers")]public void ApproveOrder(int orderId){ OrderManag-er.ApproveOrder(orderId);}

Điều này được thực hiện dễ dàng trong các ứng dụng sử dụng xác thực Windows để tận dụng cơ sở hiện có để tạo các nhóm Active Directory để tổ chức người dùng. Với các ứng dụng sử dụng xác thực biểu mẫu, có thể tận dụng một tính năng dựa trên nhà cung cấp tuyệt vời khác của ASP.NET: RoleProviders. Một lần nữa, có một số trong số này có sẵn, nhưng nếu không có cái nào phù hợp, bạn có thể triển khai cái của riêng mình.

Tất nhiên, thậm chí ủy quyền theo phương thức hiếm khi đủ để đáp ứng tất cả các nhu cầu bảo mật của bạn và bạn luôn có thể quay lại viết mã thủ tục bên trong các dịch vụ của mình như trongHình 3.

Hình 3 Sử dụng Mã thủ tục để thực hiện ủy quyền cụ thể

Public void CancelOrder(int orderId){ // truy xuất đơn hàng bằng Entity Framework ObjectContext OrdersEntities entity = new OrderEntities(); Đặt hàng orderForProcessing = entity.Orders.Where(o => o.Id == orderId).First(); if (orderForProcessing.CreatedBy != Thread.CurrentPrincipal.Identity.Name) { throw new SecurityException( "Chỉ người dùng đã tạo đơn hàng mới có thể hủy đơn hàng"); } OrderManager.CancelOrder(orderForProcessing);}

WCF là một nền tảng có khả năng mở rộng cao và cũng như mọi thứ trong WCF, có nhiều cách tiếp cận để triển khai ủy quyền trong các dịch vụ của bạn. Dominick Baier và Christian Weyer đã thảo luận chi tiết về một số khả năng trong số tháng 10 năm 2008 của tạp chíTạp chí MSDN. Bài báo, “Ủy quyền trong các dịch vụ dựa trên WCF” (msdn.microsoft.com/magazine/cc948343), thậm chí mạo hiểm với bảo mật dựa trên yêu cầu, một cách có cấu trúc để tổ chức ủy quyền trong ứng dụng của bạn.

Ủy quyền trong Dịch vụ dữ liệu WCF

Dịch vụ dữ liệu WCF, như tên cho thấy, được xây dựng trên WCF để cung cấp quyền truy cập dựa trên REST vào nguồn dữ liệu—có lẽ thường xuyên nhất là nguồn dữ liệu LINQ-to-SQL hoặc LINQ-to-Entity Framework. Tóm lại, điều này cho phép bạn cung cấp quyền truy cập vào dữ liệu của mình bằng cách sử dụng một URL ánh xạ tới các nhóm thực thể mà nguồn dữ liệu của bạn hiển thị (một nhóm thực thể thường ánh xạ tới một bảng trong cơ sở dữ liệu của bạn). Quyền đối với các bộ thực thể này có thể được định cấu hình bên trong tệp mã phía sau dịch vụ.hinh 4hiển thị nội dung của tệp MyWcfDataService.svc.cs.

Hình 4 Tệp mã phía sau dịch vụ dữ liệu WCF với cấu hình của quy tắc truy cập tập thực thể

Lớp công khai MyWcfDataService : DataService{ // Phương thức này chỉ được gọi một lần để khởi tạo các chính sách trên toàn dịch vụ. Khoảng trống tĩnh công khai InitializeService(IDataServiceConfiguration config) { config.SetEntitySetAccessRule("Orders", EntitySetRights.AllRead); config.SetEntitySetAccessRule("Sản phẩm", EntitySetRights.AllRead | EntitySetRights.WriteAppend | EntitySetRights.WriteDelete); }}

Ở đây, tôi đã cấp quyền Đọc đối với tập thực thể Đơn hàng và định cấu hình tập thực thể Sản phẩm để cho phép đọc toàn bộ, chèn bản ghi mới và xóa bản ghi hiện có.

Tuy nhiên, vì Dịch vụ dữ liệu WCF tự động hiển thị quyền truy cập vào dữ liệu của bạn dựa trên cấu hình này nên bạn không có quyền truy cập trực tiếp vào mã, vì vậy không có vị trí rõ ràng để triển khai bất kỳ logic ủy quyền cụ thể nào. WCF Data Services hỗ trợ các bộ chặn cho phép các nhà phát triển triển khai logic giữa máy khách và nguồn dữ liệu. Ví dụ: có thể chỉ định trình chặn truy vấn lọc kết quả cho một nhóm thực thể cụ thể. ví dụ trongHình 5hiển thị hai trình chặn truy vấn được thêm vào lớp MyWcfDataService.

Hình 5 Bộ chặn truy vấn trong Dịch vụ dữ liệu WCF

[QueryInterceptor("Products")]Public Expression> OnQueryProducts(){ String userName =ServiceSecurityContext.Current.PrimaryIdentity.Name; trả lại sản phẩm => product.CreatedBy == userName;}[QueryInterceptor("Orders")]Public Expression> OnQueryOrders(){ bool userInPrivateOrdersRole = Thread.CurrentPrincipal.IsInRole("PrivateOrders"); trả lại đơn hàng => !order.Private|| userInPowerUserRole;}

Đầu tiên được áp dụng cho tập thực thể Sản phẩm và đảm bảo rằng người dùng chỉ có thể truy xuất các sản phẩm do họ tạo. Điều thứ hai đảm bảo rằng chỉ những người dùng trong vai trò Đơn hàng riêng tư mới có thể đọc các đơn đặt hàng được gắn cờ là Riêng tư.

Tương tự như vậy, có thể chỉ định các trình chặn thay đổi chạy trước khi một thực thể được chèn, sửa đổi hoặc xóa như minh họa ở đây:

[ChangeInterceptor("Products")]public void OnChangeProducts(Product product, UpdateOperations operation{ if (product.CreatedBy != Thread.CurrentPrincipal.Identity.Name) { throw new DataServiceException( "Chỉ những sản phẩm được tạo bởi người dùng mới có thể bị xóa bởi điều đó người dùng"); }}

Khi xem lần đầu, trình chặn thay đổi OnChangeProducts trong mẫu mã này dường như để lộ lỗ hổng bảo mật, bởi vì việc triển khai dựa trên dữ liệu được truyền từ nguồn bên ngoài—cụ thể là tham số “sản phẩm”. Nhưng khi xóa một thực thể trong Dịch vụ dữ liệu WCF, chỉ một khóa thực thể được chuyển từ máy khách sang máy chủ. Điều đó có nghĩa là bản thân thực thể, trong trường hợp này là Sản phẩm, phải được tìm nạp lại từ cơ sở dữ liệu và do đó có thể được tin cậy.

Tuy nhiên, trong trường hợp cập nhật một thực thể hiện có (ví dụ: khi tham số hoạt động bằng UpdateOperations.Change), tham số sản phẩm là thực thể hủy đánh số thứ tự do khách hàng gửi, do đó không thể tin cậy được. Ứng dụng khách có thể đã được sửa đổi để chỉ định thuộc tính CreatedBy của sản phẩm cụ thể này thành danh tính riêng của người dùng độc hại, do đó nâng cao đặc quyền của kẻ chiếm đoạt. Điều đó có thể cho phép sửa đổi sản phẩm bởi một cá nhân lẽ ra không thể làm như vậy. Để tránh điều này, tôi khuyên bạn nên tìm nạp lại thực thể ban đầu từ nguồn dữ liệu đáng tin cậy chỉ dựa trên khóa thực thể, như minh họa trongHình 6.

Hình 6 Một bộ chặn thay đổi ngăn chặn các thao tác chèn, cập nhật và xóa trái phép

[ChangeInterceptor("Products")]Public void OnChangeProducts(Sản phẩm sản phẩm, hoạt động UpdateOperations){ if (operations == UpdateOperations.Add) { product.CreatedBy = Thread.CurrentPrincipal.Identity.Name; } khác nếu (hoạt động == UpdateOperations.Change) { Nguồn sản phẩmProduct = this.CurrentDataSource.Products.Where(p => p.Id == product.Id).First(); if (sourceProduct.CreatedBy != Thread.CurrentPrincipal.Identity.Name) { throw new DataServiceException( "Chỉ những bản ghi được tạo bởi người dùng mới có thể được sửa đổi bởi người dùng đó"); } } else if (operations == UpdateOperations.Delete && product.CreatedBy != Thread.CurrentPrincipal.Identity.Name) { Throw new DataServiceException( "Chỉ những bản ghi được tạo bởi người dùng mới có thể bị xóa bởi người dùng đó"); }}

Vì việc triển khai này phụ thuộc rất nhiều vào thuộc tính CreatedBy của thực thể Sản phẩm nên điều cực kỳ quan trọng là điều này được thực thi theo cách đáng tin cậy kể từ thời điểm dữ liệu được tạo.Hình 6cũng chỉ ra cách có thể đạt được điều này bằng cách ghi đè bất kỳ giá trị nào được ứng dụng khách chuyển cho thao tác Thêm.

Lưu ý rằng như ví dụ hiện tại, việc xử lý các thao tác thuộc loại UpdateOperations.Change sẽ không thành vấn đề. TRONGhinh 4, dịch vụ đã được định cấu hình để chỉ cho phép các hành động AllRead, WriteAppend (insert) và WriteDelete xảy ra trên các bộ thực thể Sản phẩm. Do đó, ChangeInterceptor sẽ không bao giờ được gọi cho thao tác Thay đổi, vì dịch vụ sẽ ngay lập tức từ chối mọi yêu cầu sửa đổi thực thể Sản phẩm tại điểm cuối này. Để bật cập nhật, hãy gọi SetEntitySetAccessRule tronghinh 4sẽ phải bao gồm WriteMerge, WriteReplace hoặc cả hai.

Xác thực tên miền chéo

Trình cắm Silverlight có thể thực hiện các yêu cầu HTTP tên miền chéo. Cuộc gọi tên miền chéo là một yêu cầu HTTP được thực hiện cho một tên miền khác với tên miền mà ứng dụng Silverlight đã được tải xuống. Khả năng thực hiện các cuộc gọi như vậy theo truyền thống được coi là một lỗ hổng bảo mật. Nó sẽ cho phép nhà phát triển độc hại đưa ra yêu cầu đến một trang web khác (ví dụ: trang web ngân hàng trực tuyến của bạn) và tự động chuyển tiếp bất kỳ cookie nào được liên kết với miền đó. Có khả năng, điều này có thể cấp cho kẻ tấn công quyền truy cập vào một phiên đăng nhập khác trong cùng một quy trình trình duyệt.

Vì lý do này, các trang web phải chọn tham gia cho phép cuộc gọi tên miền chéo thông qua việc triển khai tệp chính sách tên miền chéo. Đây là tệp XML mô tả loại cuộc gọi tên miền chéo nào được phép—ví dụ: từ tên miền nào đến URL nào. Để biết thêm thông tin, hãy xem “Tạo dịch vụ có sẵn trên các ranh giới miền”(msdn.microsoft.com/library/cc197955(VS.95)).

Bạn phải luôn thận trọng khi quyết định tiết lộ bất kỳ thông tin nhạy cảm nào cho các cuộc gọi giữa các miền. Nhưng nếu bạn quyết định đây là một tình huống mà bạn cần hỗ trợ cùng với xác thực, thì điều quan trọng cần lưu ý là các phương thức xác thực dựa trên cookie—như xác thực biểu mẫu được mô tả trước đó—không còn phù hợp nữa. Thay vào đó, bạn có thể xem xét tận dụng thông tin đăng nhập tin nhắn, trong đó tên người dùng và mật khẩu được chuyển đến máy chủ và được xác thực với mọi cuộc gọi. WCF hỗ trợ điều này thông qua chế độ bảo mật TransportWithMessageCredential. Để biết thêm thông tin, hãy xem “Cách: Sử dụng thông tin xác thực thư để bảo mật dịch vụ cho các ứng dụng Silverlight” (msdn.microsoft.com/library/dd833059(VS.95)).

Tất nhiên, cách tiếp cận này loại bỏ hoàn toàn ASP.NET khỏi quy trình xác thực, do đó, rất khó để tận dụng cùng với ủy quyền ASP.NET, đã thảo luận trước đó.

Bảo mật các tệp Silverlight XAP của bạn

Những người quan tâm đến bảo mật Silverlight thường hỏi, "Làm cách nào tôi có thể bảo vệ các tệp XAP của mình?" Đôi khi động lực đằng sau truy vấn này là để bảo vệ tài sản trí tuệ có trong mã. Trong trường hợp này, bạn sẽ cần xem xét kỹ thuật che giấu mã để khiến mọi người khó hiểu mã của bạn hơn.

Một động cơ phổ biến khác là ngăn những người dùng có ý đồ xấu thẩm vấn mã và hiểu cách thức hoạt động của ứng dụng Silverlight—tạo cho họ khả năng đột nhập vào các dịch vụ của bạn.

Tôi thường trả lời điều này với hai điểm. Đầu tiên, mặc dù có thể hạn chế tải xuống ứng dụng Silverlight của bạn (tệp .xap) chỉ cho những người dùng được xác thực và được ủy quyền, không có lý do gì để tin tưởng những người dùng này ít độc hại hơn người dùng chưa được xác thực. Sau khi ứng dụng đã được tải xuống ứng dụng khách, hoàn toàn không có gì có thể ngăn cản người dùng truy vấn mã nhằm nâng cao đặc quyền của họ hoặc chuyển tiếp thư viện cho người khác. Obfuscation có thể làm cho quá trình này khó khăn hơn một chút, nhưng nó không đủ tốt để làm cho ứng dụng của bạn an toàn.

Thứ hai, điều cực kỳ quan trọng cần nhớ là bất kỳ ai có thể gọi dịch vụ một cách hợp pháp thông qua ứng dụng Silverlight của bạn cũng có thể gọi trực tiếp các dịch vụ đó, chẳng hạn như sử dụng trình duyệt Internet và một số JavaScript. Bạn không thể làm gì để ngăn điều này xảy ra, vì vậy, điều tối quan trọng là bạn phải tập trung các nỗ lực bảo mật vào việc bảo vệ các dịch vụ của mình. Hãy làm điều này đúng và việc người dùng ác ý có thể thu được gì từ mã của ứng dụng Silverlight của bạn không quan trọng. Tuy nhiên, một số người vẫn muốn đảm bảo rằng chỉ những người dùng được xác thực mới có thể truy cập tệp .xap của họ. Điều này là có thể, nhưng mức độ dễ dàng tùy thuộc vào phiên bản IIS bạn đang sử dụng và phương thức xác thực bạn đã chọn.

Nếu bạn đang sử dụng xác thực Windows thì bạn có thể dễ dàng bảo vệ các tệp .xap của mình bằng IIS Directory Security. Tuy nhiên, nếu bạn đang sử dụng xác thực biểu mẫu thì mọi thứ sẽ phức tạp hơn một chút. Trong trường hợp này, việc chặn và xác minh cookie đi kèm với bất kỳ yêu cầu nào cũng như cho phép hoặc từ chối quyền truy cập vào tài nguyên được yêu cầu là tùy thuộc vào FormsAuthenticationModule.

Vì FormsAuthenticationModule là một mô-đun ASP.NET nên yêu cầu phải đi qua đường dẫn ASP.NET để quá trình kiểm tra này diễn ra. Trong IIS6 (Windows Server 2003) và các phiên bản trước đó, theo mặc định, các yêu cầu đối với tệp .xap sẽ không được định tuyến qua ASP.NET.

Tuy nhiên, IIS7 (Windows Server 2008) đã giới thiệu Đường ống tích hợp, cho phép tất cả các yêu cầu được định tuyến thông qua đường dẫn ASP.NET. Nếu bạn có thể triển khai lên IIS7 và sử dụng nhóm ứng dụng chạy ở chế độ Đường ống tích hợp, thì việc bảo mật các tệp .xap của bạn không khó hơn việc bảo mật các tệp .svc của bạn như được mô tả trước đó trong phần Ủy quyền ASP.NET. Nhưng nếu bạn phải triển khai lên IIS6 hoặc phiên bản cũ hơn, bạn có thể có thêm một số việc phải làm.

Một cách tiếp cận phổ biến liên quan đến việc truyền trực tuyến các byte tạo nên tệp .xap của bạn thông qua một phần mở rộng khác mà đường dẫn ASP.NET xử lý. Cách thông thường để thực hiện việc này là thông qua triển khai IHttpHandler (trong tệp .ashx). Để biết thêm thông tin, hãy xem “Giới thiệu về Trình xử lý HTTP” (msdn.microsoft.com/library/ms227675(VS.80)).

Một cách tiếp cận khác là thay đổi cấu hình của IIS để các tệp .xap được định tuyến qua đường dẫn ASP.NET. Tuy nhiên, vì điều này yêu cầu thay đổi không cần thiết đối với cấu hình IIS của bạn nên cách tiếp cận trước đây phổ biến hơn.

Một vấn đề khác cần xem xét với xác thực biểu mẫu là màn hình đăng nhập. Như đã đề xuất trước đó trong bài viết này, nếu bạn chọn một biểu mẫu Web ASP.NET thì không có vấn đề gì. Nhưng nếu bạn muốn màn hình đăng nhập được tạo trong Silverlight, bạn sẽ cần chia ứng dụng thành nhiều phần. Một phần (mô-đun đăng nhập) phải khả dụng cho người dùng chưa được xác thực và phần khác (ứng dụng được bảo mật) chỉ khả dụng cho người dùng được xác thực.

Bạn có thể thực hiện hai cách tiếp cận:

Có hai ứng dụng Silverlight riêng biệt. Đầu tiên sẽ chứa hộp thoại đăng nhập và nằm trong khu vực không an toàn của trang web. Khi đăng nhập thành công, điều này sau đó sẽ chuyển hướng đến một trang chỉ định tệp .xap trong khu vực an toàn trên trang web của bạn.
Chia ứng dụng của bạn thành hai hoặc nhiều mô-đun. .xap ban đầu, nằm ở khu vực không an toàn trên trang web của bạn, sẽ thực hiện quy trình xác thực. Nếu thành công, tệp .xap đó sẽ yêu cầu một tệp tiếp theo từ một khu vực an toàn có thể được tải động vào ứng dụng Silverlight. Gần đây tôi đã viết blog về cách bạn có thể làm điều này (thejoyofcode.com/How_to_download_and_crack_a_Xap_in_Silverlight.aspx).

Josh xoắnlà cố vấn chính của nhóm Tư vấn Phát triển Ứng dụng Microsoft tại Vương quốc Anh và có thể được tìm thấy viết blog tạithejoyofcode.com.

Cảm ơn các chuyên gia kỹ thuật sau đã xem xét bài viết này: Zulfiqar Ahmed, Chris Barker và Simon Ince