Tăng cường an ninh cho các ứng dụng xây dựng trên nền

Theo cách này ta có thể sử dụng mức xác thức Packet Privacy. c. Các yêu cầu theo dõi Để chỉ ra các hiểm hoạ từ chối, các giao tác nhạy cảm được thực thi bởi các thành phần Enterprise Service nên được ghi lại. Khi thiết kế cần chú ý các loại giao tác và các chi tiết cần được theo dõi. Ít nhất là đặc tính nhận dạng khởi tạo một giao tác và đặc tính nhận dạng được dùng để thực hiện giao tác. d. Kiểu kích hoạt ứng dụng Khi thiết kế phải xác định kiểu kích hoạt thành phần dịch vụ. Ta có thể kích hoạt chúng bằng cách sử dụng một thể hiện của tiến trình Dllhost.exe hoặc ta có thể chạy chúng trong một tiến trình client. Các ứng dụng server chạy ngoài tiến trình trong một thể hiện của Dllhost.exe Các ứng dụng thư viện chạy trong không gian địa chỉ của tiến trình của client. e. Các giao tác Nếu ta sử dụng các giao tác phân tán thì chú ý nơi giao tác được khởi tạo và chú ý sự liên quan của các giao tác đang thực thi giữa các thành phần và trình quản lí tài nguyên bị ngăn bởi tường lửa. Trong ngữ cảnh này tường lửa phải được cấu hình để hỗ trợ giao thông Microsoft Distributed Transaction Coordinator (DTC). f. CAS Các ứng dụng sử dụng các thành phần dịch vụ hoàn toàn tin cậy và vì vậy CAS hạn chế sử dụng để chứng thực việc triệu gọi mã. Tuy nhiên Enterprise Service yêu cầu rằng việc gọi mã có quyền cần thiết để gọi mã không được quản lý. Sự liên quan chính của vấn đề này là ta không thể gọi trực tiếp một ứng dụng Enterprise Service từ một ứng dụng Web tin cậy một phần. Các mức tin cậy một phần của ASP.NET (High, Medium, Low, và Mininal) không cấp quyền cho mã không được quản lý. 2.4. Xây dựng các dịch vụ Web an toàn 2.4.1. Các mối hiểm hoạ và các biện pháp phòng chống: Các mối hiểm hoạ chính bao gồm: Truy cập không đựơc chứng thực Thực thi tham số Nghe lén mạng Phơi bày dữ liệu cấu hình Lặp lại thông báo Hình 9: Các mối hiểm hoạ chính đối với dịch vụ Web a. Truy cập không được chứng thực: Các dịch vụ web mà cung cấp thông tin nhạy cảm hoặc hạn chế nên xác thực và chứng thực các cuộc gọi đến nó. Xác thực và chứng thực yếu ớt có thể bị khám phá để đạt được truy cập không chứng thực tới các thông tin và các hoạt động nhạy cảm. Các điểm yếu: Bao gồm: Không sử dụng chức năng xác thực Mật khẩu ở dạng văn bản nguyên mẫu trong phần đầu mẩu tin của SOAP Chức năng xác thực cơ bản sử dụng trên khênh giao tiếp không đươc mã hoá. Các biện pháp phòng chống: Bao gồm: Sử dụng mật khẩu số hoá trong SOAP header cho kỹ thuật xác thực. Sử dụng các vé Kerberos trong SOAP header cho kỹ thuật xác thực. Sử dụng các chứng chỉ X.509 trong SOAP header cho kỹ thuật xác thực Sử dụng chức năng xác thực của Windows Sử dụng role-based authorization để hạn chế truy cập tới các dịch vụ Web. Điều này có thể được thực hiện bằng cách sử dụng kỹ thuật chứng thực URL để điểu khiển truy cập tới tệp dịch vụ Web (.asmx) hoặc ở mức phương thức web bằng việc sử dụng các yêu cầu quyền Principal. b. Thực thi tham số: Sự thực thi tham số đề cập tới sự chỉnh sửa dữ liệu không được chứng thực được gửi giữa người sử dụng dịch vụ web và dịch vụ web. Ví dụ, một kẻ tấn công có thể chặn một thông báo dịch vụ web( khi thông báo truyền qua các nốt trung gian tới đích) và có thể chỉnh sủa nó trước khi gửi cho đích đang cần nó. Các điểm yếu: Bao gồm: Các thông báo không được ký số Các thông báo không được mã hoá. Các biện pháp phòng chống: Bao gồm: Ký số thông báo. Chữ ký số được dùng ở điểm nhận cuối để chỉ ra rằng thông báo không bị xáo trộn trên đường truyền. Mã hoá thông báo để cung cấp khả năng cá nhân và khả năng xáo trộn thông tin. c. Nghe lén mạng: Một kẻ tấn công có thể xem các thông báo của dịch vụ web khi chúng được truyền qua mạng. Ví dụ: một kẻ tấn công có thể sử dụng phần mềm quản lý mạng để lấy dữ liệu nhạy cảm chứa trong thông báo SOAP. Thông báo này có thể chứa dữ liệu nhạy cảm mức ứng dụng hoặc là thông tin quan trọng. Các điểm yếu: Bao gồm: Các thông tin hợp pháp trong SOAP header ở dạng văn bản nguyên mẫu Không mã hoá ở mức thông báo Không mã hoá ở mức giao vận Các biện pháp phòng chống: Sử dụng các biện pháp phòng chống sau để bảo vệ các thông báo SOAP nhạy cảm khi chúng truyền qua mạng: Mã hoá ở tấng giao vận như SSL hay IPSec. Cách này chỉ áp dụng khi bạn điều khiển cả 2 điểm đầu cuối. Mã kích cỡ thông báo để cung cấp khả năng cá nhân. Áp dụng khi truyền qua các nốt trung gian theo đường tới điểm cuối. d. Phơi bày dữ liệu cấu hình: Có 2 trường hợp chính mà 1 dịch vụ Web có thể phơi bầy dữ liệu cấu hình. Thứ nhất, một dịch vụ Web có thể hỗ trợ việc tạo tự động của WSDL hoặc có thể cung cấp thông tin WSDL trong các tệp có tể tải về sẵn có trên Web server. Thứ hai, với việc nắm bắt ngoại lệ không tương ứng, dịch vụ web có thể phơi bày chi tiết thực thi bên trong. Các điểm yếu: Bao gồm: Các tệp WSDL không bị hạn chế có thể tải về từ Web server. Một dịch vụ Web được hạn chế hỗ trợ việc tạo tự động của WSDL và cho phép những người dùng không được chứng thực lấy được các đặc điểm của dịch vụ Web. Các biện pháp phòng chống: Bao gồm: Chứng thực truy cập tới các tệp WSDL bặng cách sử dụng các quyền NTFS. Huỷ bỏ các tệp WSDL từ Web server Không cho phép giao các giao thức tài liệu hoạt đọng để tránh sự sinh tự động của WSDL Nắm bắt và đưa ra các ngoại lệ SoapException hoặc SoapHeaderException - chỉ trả về máy khách các thông tin tối thiểu và vô hại. 2.4.2. Các lưu ý khi thiết kế Bao gồm: Yêu cầu xác thực Yêu cầu tính riêng tư và toàn vẹn Các đặc tính truy nhập tài nguyên An toàn truy nhập mã a. Yêu cầu xác thực: Nếu dịch vụ Web cung cấp thông tin nhạy cảm hoặc nên hạn chế, nó cần xác thực các cuộc gọi để hỗ trợ cho việc chứng thực. Trong môi trường Windows, ta có thể sử dụng Windows authentication. b. Yêu cầu tính riêng tư và tính toàn vẹn. WSE cung cấp việc kiểm tra tính toàn vẹn thông qua chữ ký số và nó cũng hỗ trợ mã hoá XML để mã hoá các yếu tố nhạy cảm của toàn bộ thông báo. Ưu điểm của hướng tiếp cận này là dựa vào chuẩn WS-Security và nó cung cấp một giải pháp đối với các thông báo truyền qua nhiều nốt trung gian. Để mã hoá tầng giao vận ta sử dụng các kênh SSL hoặc IPSec. Các giải pháp này chỉ áp dụng khi ta nắm quyền điều khiển cả 2 điểm đầu cuối. c. Các đặc tính truy cập tài nguyên Mặc định các dịch vụ Web ASP.NET không giả danh và tài khoản xử lý ASPNET có đặc quyền thấp nhất được sử dụng cho việc truy cập tài nguyên cục bộ và từ xa. Ta có thể sử dụng tài khoản này để truy nhập các tài nguyên từ xa như SQL Server (yêu cầu xác thực Windows) bằng cách tạo một tài khoản cục bộ tham chiếu tới máy chủ CSDL. d. CAS Mức độ tin cậy của dịch vụ Web được xác định bằng việc cấu hình yếu tố , nó ảnh hưởng đến các loại tài nguyên mà nó có thể truy cập và tới các hoạt động đặc quyền mà nó có thể thực thi. Nếu triệu gọi một dịch vụ Web từ một ứng dụng Web ASP.NET thì mức độ tin cậy của ứng dụng Web xác định phạm vi của các dịch vụ Web mà nó có thể triệu gọi. Ví dụ, một ứng dụng Web được cấu hình mặc định với độ tin cậy là Medium chỉ có thể triệu gọi các dịch vụ Web trên máy cục bộ. 2.4.3. Các kỹ thuật với các vấn đề quan trọng nhất. a. Kiểm tra giá trị đầu vào Cũng như bất kỳ ứng dụng nào mà chấp nhận dữ liệu đầu vào, các dịch vụ Web phải kiểm tra dữ liệu được truyền tới chúng để ép buộc các nguyên tắc nghiệp vụ và để tránh các vấn đề an toàn tiềm tàng. Các phương thức Web được đánh dấu với thuộc tính WebMethod là các điểm vào của dịch vụ web. Các phương thức Web có thể chấp nhận các tham số đầu vào định kiểu rõ ràng hoặc các tham só định kiểu lỏng lẻo, chúng thường được truyền như dữ liệu kiểu xâu. Các tham số định kiểu rõ ràng: Nếu ta sử dụng các tham số định kiểu rõ ràng được mô tả bởi hệ thống kiểu trong .NET Framework, ví dụ kiểu integer, double, date hoặc các loại đối tượng khác như Address hoặc Employee, lược đồ XSD tự động được tạo chứa một mô tả kiểu của dữ liệu. Các thành phần tiêu dùng có thể sử dụng mô tả định kiểu này để khởi tạo một XML được định dạng tương ứng với các yêu cầu SOAP được gửi tới các phương thức Web. Sau đó ASP.NET sử dụng lớp System.Xml.Serialization.XmlSerializer không xuất thông báo SOAP vào các đối tượng CLR. Ví dụ sau cho thấy một phương thức Web chấp nhận một đầu vào được định kiểu rõ ràng: [WebMethod] public void CreateEmployee(string name, int age, decimal salary) {...} Trong ví dụ trên, hệ thống kiểu .NET Framework thực hiện các kiểm tra kiểu một cách tự động. Để kiểm tra pham vi của các ký tự được cung cấp thông qua trường name, ta có thể sử dụng một biểu thức phổ biến. Ví dụ, đoạn mã sau đây cho thấy cách sử dụng lớp System.Text.RegularExpressions.Regex để ràng buộc phạm vi có thể của các ký tự đầu vào và cũng để kiểm tra độ dài tham số. if (!Regex.IsMatch(name, @"^[a-zA-Z'.`-´\s]{1,40}$")) { // Tên không đúng định dạng } Ví dụ sau đây cho thấy một phương thức Web chấp nhận một kiểu dữ liệu Employee truyền thống. using Employees; // Custom namespace [WebMethod] public void CreateEmployee(Employee emp) { ... } Các thành phần sử dụng cần biết lược đồ XSD để có thể triệu gọi dịch vụ Web. Nếu thành phần sử dụng là một ứng dụng .NET Framework client, nó có thể truyền một đối tượng Employee một cách đơn giản như sau: using Employees; Employee emp = new Employee(); // Populate Employee fields // Send Employee to the Web service wsProxy.CreateEmployee(emp); Các tham số định kiểu lỏng lẻo: Nếu ta sử dụng tham số kiểu string hoặc các mảng kiểu byte để truyền dữ liệu hợp lệ, ta sẽ đánh mất nhiều lợi ích của hệ thống kiểu .NET Framework. Ta phải chuyển kiểu dữ liệu đầu vào để kiểm tra nó bởi vì WSDL được tạo tự động một cách đơn giản mô tả các tham số như là đầu vào kiểu string của kiểu xsd:string. Ta cần lập chương trình kiểm tra kiểu, độ dài, định dạng và phạm vi như dưới đây: [WebMethod] public void SomeEmployeeFunction(string dateofBirth, string SSN) { . . . // EXAMPLE 1: Type check the date try { DateTime dt = DateTime.Parse(dateofBirth).Date; } // If the type conversion fails, a FormatException is thrown catch( FormatException ex ) { // Invalid date } // EXAMPLE 2: Check social security number for length, format, and range if( !Regex.IsMatch(empSSN,@"^\d{3}-\d{2}-\d{4}$",RegexOptions.None)) { // Invalid social security number } } Dữ liệu XML : Việc kiểm tra dữ liệu đầu vào phải được kiểm tra bởi phương thức Web trước khi nó được xử lý hoặc được truyền tới các thành phần. Client và server phải đánh giá và chấp nhận cho một lược đồ XML. Đoạn mã dưới đây cho thấy cách một phương thức Web có thể sử dụng lớp System.XmlValidatingReader để kiểm tra dữ liệu đầu vào. Ví dụ này mô tả một hành động đặt sách đơn giản. Chú ý rằng dữ liệu XML được truyền qua một tham số kiểu string đơn giản. using System.Xml; using System.Xml.Schema; [WebMethod] public void OrderBooks(string xmlBookData) { try { // Create and load a validating reader XmlValidatingReader reader = new XmlValidatingReader(xmlBookData, XmlNodeType.Element, null); // Attach the XSD schema to the reader reader.Schemas.Add("urn:bookstore-schema", @""); // Set the validation type for XSD schema. // XDR schemas and DTDs are also supported reader.ValidationType = ValidationType.Schema; // Create and register an event handler to handle validation errors reader.ValidationEventHandler += new ValidationEventHandler( ValidationErrors ); // Process the input data while (reader.Read()) { . . . } // Validation completed successfully } catch { . . . } } // Validation error event handler private static void ValidationErrors(object sender, ValidationEventArgs args) { // Error details available from args.Message . . . } Đoạn mã dưới đây cho thấy cách mà một thành phần sử dụng triệu gọi phương thức Web ở trên: string xmlBookData = "<book xmlns='urn:bookstore-schema' xmlns:xsi='>" + "Building Secure ASP.NET Applications" + "0735618909" + "1" + ""; BookStore.BookService bookService = new BookStore.BookService(); bookService.OrderBooks(xmlBookData)); Ví dụ trên sử dụng lược đồ XSD đơn giản sau để kiểm tra dữ liệu đầu vào: <xsd:schema xmlns:xsd="" xmlns="urn:bookstore-schema" elementFormDefault="qualified" targetNamespace="urn:bookstore-schema"> Nhúng SQL Nhúng SQL cho phép một kẻ tấn công để thực thi các lệnh hợp pháp trong cơ sở dữ liệu bằng cách sử dụng đăng nhập cơ sở dữ liệu của dịch vụ Web. Nhúng SQL là một vấn đề tiềm tàng đối với dịch vụ Web nếu các dịch vụ sử dụng dữ liệu đầu vào để khởi tạo các truy vấn SQL. b. Xác thực Nếu dịch vụ Web xuất ra dữ liệu nhạy cảm, bị hạn chế hoặc nếu nó cung cấp các dịch vụ bị hạn chế thì nó cần xác thực cuộc triệu gọi. Nhiều lược đồ xác thực sẵn có và có thể chia chúng làm 3 nhóm: Xác thực mức nền tảng Xác thực mức thông báo Xác thực mức ứng dụng Xác thực mức nền tảng: Nếu ta nắm quyền điều khiển cả hai điểm đầu cuối và cả hai điểm này cùng một miền, ta có thể sử dụng Windows authentication để xác thực cuộc gọi. Basic Authentication: You can use IIS to configure your Web service's virtual directory for Basic authentication. With this approach, the consumer must configure the proxy and provide credentials in the form of a Có thể sử dụng IIS để cấu hình thư mục ảo của dịch vụ Web được xác thực với Basic authentication. Với hướng tiếp cận này, người tiêu dùng phải cấu hình proxy và cung cấp các thông tin đăng nhập trong dạng của một tên và mật khẩu. Sau đó Proxy truyền chúng với mỗi yêu cầu dịch vụ Web qua proxy. Các thông tin đăng nhập được truyền ở dạng văn bản nguyên mẫu và vì vậy ta nên sử dụng Basic authentication với SSL. Integrated Windows Authentication: Có thể sử dụng IIS để cấu hình thư mục ảo của dịch vụ Web được xác thực ở trạng thái Integrated Windows authentication, sử dụng xác thực kiểu Kerberos hoặc NTLM tuỳ thuộc vào môi trường phía client hoặc server. Ưu điểm của hướng tiếp cận này so sánh với Basic authentication là các thông tin đăng nhập không được truyền qua mạng, điều này hạn chế hiểm hoạ nghe lén mạng Để gọi một dịch vụ Web được cấu hình ở trạng thái Integrated Windows authentication, người dùng phải cấu hình chính xác thuộc tính Credential trong proxy. Để dẫn một ngữ cảnh an toàn Window của client tới một dịch vụ Web ta có thể đặt thuộc tính Credential của proxy của dịch vụ Web thành CredentialCache.DefaultCredential như sau: proxy.Credentials = System.Net.CredentialCache.DefaultCredentials; Ta có thể sử dụng một bộ thông tin đăng nhập chính xác: CredentialCache cache = new CredentialCache(); cache.Add( new Uri(proxy.Url), // Web service URL "Negotiate", // Kerberos or NTLM new NetworkCredential(userName, password, domain)); proxy.Credentials = cache; c. Chứng thực Sau khi xác thực ta có thể hạn chế các cuộc gọi tới một phần chức năng bị phơi bày bởi dịch vụ Web, dựa vào đặc tính nhận dạng hoặc vai thành viên của cuộc gọi. Ta có thể hạn chế truy cập tới các phương thức Web riêng hoặc chức năng cụ thể trong các phương thức Web. Chứng thực phương thức Web Ta có thể sử dụng các yêu cầu quyền principal bằng cách khai báo để điều khiển truy cập tới các phương thức Web dựa vào đặc tính nhận dạng hoặc vai thành viên của cuộc gọi. Đặc tính nhận dạng và vai thành viên của cuộc gọi được duy trì bởi đối tượng principal kết hợp với yêu cầu Web hiện tại. ( HttpContext.User) [PrincipalPermission(SecurityAction.Demand, Role=@"Manager")] [WebMethod] public string QueryEmployeeDetails(string empID) { } Chứng thực bằng cách lập trình: Ta có thể sử dụng kiểm tra quyền hoặc kiểm tra vai bằng cách gọi phương thức IPrincipal.IsInRole trong các phương thức Web. GenericPrincipal user = User as GenericPrincipal; if (null != user) { if ( user.IsInRole(@"Manager") ) { // User được chứng thực để thực hiện chức năng manager } } Chương 3 – XÂY DỰNG ỨNG DỤNG ASP.NET AN TOÀN 3.1. Mô hình bảo mật trong ASP.NET 3.1.1. Các công nghệ thực thi trong ASP.NET Bao gồm: ASP.NET ASP.NET được sử dụng để thực thi các dịch vụ người dùng. ASP.NET cung cấp một kiến trúc có thể bổ xung mà có thể được dùng để xây dựng các trang Web. Enterprise Services Cung cấp các dịch vụ mức hạ tầng để thực thi các ứng dụng. Các dịch vụ này bao gồm các giao dịch phân tán và các dịch vụ quản lý tài nguyên. Web Services Cho phép trao đổi dữ liệu và sự triệu gọi từ xa của ứng dụng bằng cách sử dụng các trao đổi thông báo SOAP để truyền dữ liệu qua Firewall và giữa các hệ thống hỗn hợp. .NET Remoting Cung cấp khung làm việc cho việc truy cập các đối tượng phân tán. ADO.NET and Microsoft® SQL Server™ 2000 Cung cấp dịch vụ truy cập cơ sở dữ liệu. Nó được thiết kế cho các ứng dụng web phân tán. SQL Server cung cấp bảo mật tích hợp sử dụng các kỹ thuật xác nhận của hệ điều hành ( Kerberos hoặc NTML). Internet Protocol Security (IPSec) Cung cấp các dịch vụ xác thực và mã hoá mức giao vận Secure Sockets Layer (SSL) Cung cấp kênh giao tiếp an toàn. Dữ liệu gửi qua kênh được mã hoá 3.2.2. Kiến trúc bảo mật Hình dưới trình diễn mô hình tầng ứng dụng từ xa với tổ hợp của các dịch vụ bảo mật được cung cấp bởi rất nhiều các công nghệ như được giới thiệu ở trên. Sự xác thực và chứng thực xảy ra ở nhiều điểm ở các tầng. Các dịch vụ này đựơc cung cấp bởi IIS, ASP.NET, Enterprise Services, và SQL Server. Các kênh giao tiếp cũng được áp dụng qua các tầng và được bảo mật với sự kết hợp của SSL hoặc IPSec. Hình 10: Kiến trúc bảo mật 3.2. Xây dựng các trang và các điều khiển ASP.NET an toàn Hầu hết các vụ tấn công yêu cầu đầu vào ác ý được truyền qua với các yêu cầu HTTP. Mục đích chung hoặc là ép buộc các ứng dụng thực thi các hoạt động không được chứng thực hoặc là phá vỡ hoạt động bình thường. Điều này giải thích tại sao việc kiểm tra giá trị đầu vào là một phương pháp phòng chống quan trọng với nhiều vụ tấn công và nên được ưu tiên sử dụng khi phát triển các trang và các điều khiển Web. 3.2.1. Hiểm hoạ và biện pháp phòng chống Các hiểm hoạ hàng đầu: Nhúng mã Tấn công session Giả dạng đặc tính nhận dạng Thực thi tham số Nghe lén mạng Phơi bày thông tin a. Nhúng mã Xảy ra khi một kẻ tấn công sử dụng một đoạn mã độc đoán dựa trên ngữ cảnh bảo mật của ứng dụng. Rắc rối sẽ nảy sinh nếu ứng dụng đang được sử dụng bởi một tài khoản đặc quyền. Các hành động tấn công Bao gồm: Cross-site scripting. Đoạn mã ác ý được gửi tới một ứng dụng Web như là giá trị đầu vào. Nó được trả về trình duyệt của người dùng Buffer overflows. Việc kiểm tra an toàn mã được quản lý giảm rắc rối một cách đáng kể, nhưng ứng dụng của ta vẫn có thể bị tấn công đặc biệt là nơi nó gọi mã không được quản lý. Tràn bộ đệm có thể cho phép kẻ tấn công thực thi đoạn mã hợp pháp trong tiến trình của ứng dụng Web bằng cách sử dụng ngữ cảnh bảo mật của nó. SQL injection. Kẻ tấn công gửi SQL input làm thay đổi truy vấn mong đợi hoặc thực thi các truy vấn hoàn toàn mới trong cơ sở dữ liệu. Các điểm yếu Bao gồm: Kiểm tra giá trị đầu vào thiếu sót hoặc yếu ớt hoặc tin cậy vào việc kiểm tra giá trị đầu vào phí client. Bao gồm các giá trị vào không được kiểm tra trong đầu ra dạng HTML Tự động khởi tạo các câu lệnh SQL mà không sử dụng các tham số định kiểu. Sử dụng các tài khoản vượt quyền và các tài khoản đăng nhập vào cơ sở dữ liệu Các biện pháp phòng chống: Bao gồm: Kiểm tra giá trị đầu vào để một kẻ tấn công không thể nhúng mã script hoặc gây ra tràn bộ đệm Mã hoá tất cả các giá trị đầu ra( bao gồm cả giá trị đầu vào). Điều này tránh các thẻ script nguy hiểm tiềm tàng được thông dịch như là mã bởi trình duyệt phía client Sử dụng các stored procedure mà chấp nhận các tham số để tránh SQL input ác ý được coi như là các câu lệnh có thể thực thi bởi cơ sở dữ liệu. Sử dụng các tài khoản sử lý đặc quyền và nhân cách hoá thấp nhất. Điều này giảm rắc rối và giảm sự phá huỷ có thể được thực hiện nếu một kẻ tấn công cố gắng thực thi đoạn mã mà nó sử dụng ngữ cảnh bảo mật của ứng dụng. b. Tấn công session Xảy ra khi một kẻ tấn công lấy được thẻ xác thực và chiếm giữ các điều khiển của phiên của người dùng khác. Các thẻ xác thực thường được lưu trong các cookies hay trong URL. Nếu kẻ tấn công lấy được thẻ xác thực hắn có thể truyền nó tới ứng dụng kèm theo theo một request. Ứng dụng kết hợp request với phiên của người dùng hợp pháp cho phép kẻ tấn công đạt được truy cập tới các vùng bị hạn chể của ứng dụng . Sau đó kẻ tấn công thu thập đặc tính nhận dạng và các đặc quyền của người dùng hợp pháp. Các hành động tấn công Bao gồm: Cookie replay. Kẻ tấn công lấy được các cookie xác thực hoặc là bằng cách sử dụng phần mềm quản lý mạng hoặc là bằng một số phương tiện khác. Query string manipulation. Một người dùng ác ý thay đổi định danh session mà hiển thị rõ ràng trong xâu truy vấn URL Các điểm yếu Bao gồm: Không bảo vệ các định danh session Chộn các cookies cá nhân với các cookies xác thực Các cookies xác thực truyền qua các liên kết không được mã hoá. Các biện pháp phòng chống Có thể là: Tách riêng các cookies cá nhân với các cookies xác thực chỉ truyền các cookies xác thực qua kết nối HTTP Không truyền định danh session mà đại diện cho những người dùng được xác thực trong các query string. Xác thực lại người dùng trước các hoạt động quan trong, chẳng hạn: kiểm tra trình độ, chuyển tải tiền,… c. Giả dạng đặc tính nhận dạng Xảy ra khi một người dùng ác tâm thu thập đặc tính nhận dạng của người dùng hợp pháp để có thể truy cập ứng dụng. Các hành động tấn công: Cookie replay. Kẻ tấn công lấy trộm cookie xác thực hoặc là bằng cách sử dụng phần mềm quản lý mạng hoặc là bằng cách sử dụng một tấn công XSS. Sau đó hắn gửi cookie tới ứng dụng để đạt được truy cập giả mạo Brute force password attacks. Kẻ tấn công thử kết hợp lặp đi lặp lại username và password Dictionary attacks. Mỗi từ trong từ điển được thử như một mật khẩu. Các điểm yếu: Bao gồm: Các thông tin xác thực được truyền qua các đường liên kết không được mã hoá Các cookies xác thực được truyền qua các đường liên kết không được mã hoá Mật khẩu và các chính sách yếu ớt Lưu trữ thông tin xác thực yếu ớt trong user store Các biện pháp phòng chống: Có thể là: Chỉ truyền các thông tin xác thực và các cookies qua các kết nối HTTP Ép buộc password mạnh: Các biểu thức thông thường có thể được dùng để đảm bảo rằng passwork được cung cấp bởi người dùng hợp với các yêu cầu phức tạp Lưu các xác minh mật khẩu trong cơ sở dữ liệu: Lưu giá trị băm password không thể đảo ngược được kết hợp với một giá trị salt (được tạo tự động) để giảm rắc rối của kiểu tấn công từ điển. d. Thực thi tham số Các tham số là các dạng dữ liệu được truyền từ client tới server qua mạng. Chúng bao gồm: form field, query string, view state, cookies, and HTTP header. Nếu dữ liệu nhạy cảm hoặc dữ liệu mà được sử dụng để tạo các quyết định an toàn trên server được truyền qua bằng cách sử dụng các tham số không được bảo vệ, ứng dụng của bạn có nguy cơ bị phơi bày thông tin hoặc truy cập không được cấp quyền. Các hành động tấn công: Bao gồm: Cookie replay attacks. Kẻ tấn công lấy và sửa đổi một cookie và sau đó gửi ngược lại cho ứng dụng. Điều này có thể dễ dàng dẫn tới việc giả dạng đặc tính nhận dạng và vượt quyền nếu cookie chứa dữ liệu được dùng cho việc xác thực và chứng thực trên server. Manipulation of hidden form fields. Các trường này chứa dữ liệu được dùng cho các quyết đinh bảo mật trên server. Thực thi các tham số xâu truy vấn. Các điểm yếu: Bao gồm: Sử dụng form field ẩn hoặc query strings chứa dữ liệu nhạy cảm. Truyền các cookies chứa dữ liệu nhạy cảm được bảo mật qua các kết nối không được mã hoá. Các biện pháp phòng chống Bao gồm: Không dựa vào các tuỳ chọn quản lý trạng thái phía client. Tránh sử dụng bất kỳ tuỳ chọn quản lý trạng thái phía client như: view state, cookies, query strings hoặc hidden form fields để lưu trữ dữ liệu nhạy cảm. Lưu trữ dữ liệu nhạy cảm trên server. Sử dụng một thẻ phiên để kết hợp phiển của người dùng với loại dữ liệu nhạy cảm được duy trì trên server. Sử dụng MAC để bảo vệ thẻ phiên. Cặp đôi kỹ thuật này với việc xác thực, chứng thực và logic nghiệp vụ trên server để đảm bảo rằng thẻ đó không bị dùng lại( replay) e. Nghe lén mạng Liên quan đến việc sử dụng phần mềm quản lý mạng để theo dõi các gói dữ liệu được gửi giữa tình duyệt và Web server. Điều này có thể dẫn tới việc phơi bày ứng dụng - dữ liệu bí mật cụ thể, trả về toàn bộ các thông tin logon, hoặc nắm bắt các cookies xác thực. Các điểm yếu: Bao gồm: Không mã hoá dữ liệu nhạy cảm khi gửi đi. Gửi các cookies xác thực qua các kênh không đựoc mã hoá Các hành động tấn công: Các hành động nghe lén mạng đựoc thực thi bằng việc sử dụng các công cụ đánh hơi gói tin được đặt trên mạng để nắm bắt giao thông mạng. Các biện pháp phòng chống: Sử dụng SSL để cung cấp một kênh giao tiếp được mã hoá giữa trình duyệt và Web server. Đó là điều bắt buộc mà SSL được dùng bất cứ khi nào các thông tin nhận dạng, các vé xác thực, hoặc dữ liệu nhạy cảm đựoc gửi qua mạng. 3.2.2. Các lưu ý khi thiết kế. Kiểm tra đầu vào phía server Khoanh vùng Web site Xem xét đặc tính nhận dạng được dùng để truy cập tài nguyên Bảo vệ các thông tin đăng nhập và các thẻ xác thực Lỗi bảo mật Xem xét về chứng thực tập trung Đặt các điều khiển Web và các điều khiển người dùng trong các gói assemblies riêng biệt Các mã truy nhập tài nguyên trong một gói assembly riêng. a. Kiểm tra đầu vào phía server Khi thiết kế, xác định tất cả các đầu vào mà các trang và các điều khiển Web xử lý. Chúng bao gồm: form fields, query stríngs, và các cookies nhận từ Web user, cũng như dữ liệu từ back-end data sources. Người dùng Web hoàn toàn ở ngoài ứng dụng, vì vậy tất cả đầu vào ở các nguồn đó phải được kiểm tra ở server. Việc kiểm tra phía clients rất dễ bị truyền qua. b. Khoanh vùng web site Thiết kế Web site cần có sự phân biệt giữa các vùng có thể truy cập và các vùng hạn chế truy cập yêu cầu xác thực. Sử dụng các thư mục con trong thư mục gốc của úng dụng. Việc làm này cho phép sử dụng kỹ thuật SSL không bắt buộc trên toàn bộ web site, đồng thời làm giảm rắc rối của kiểu tấn công session. Hình 11: Khoanh vùng web site c. Xem xet đặc tính nhận dạng được dùng để truy nhập tài nguyên Mặc định, các ứng dụng ASP.NET không impersonate, và tài khoản ASPNET ít đặc quyền nhất được dùng để thực thi các ứng dụng Web ASP.NET và cho việc truy nhập tài nguyên. Khuyến nghị sử dụng cấu hình mặc định. Có vài tình huống ta cần đến ngữ cảnh bảo mật khác của Windows cho việc truy cập tài nguyên. Bao gồm: Chạy nhiều ứng dụng trên cùng một server Sử dụng IIS để cấu hình mỗi ứng dụng để sử dụng một tài khoản người dùng Internet ẩn danh. Mỗi ứng dụng có một đặc tính nhận dạng riêng cho việc truy cập tài nguyên Truy cập tới một tài nguyên ở xa với các yêu cầu xác thực cụ thể Nếu cần truy cập tới các tài nguyên ở xa và được cấp một tài khoản Windows riêng để sử dụng, ta có thể cấu hình tài khoản này như một tài khoản người dùng Web ẩn danh cho ứng dụng. d. Bảo vệ thông tin đăng nhập và các thẻ xác thực Việc thiết kế nên quan tâm tới cách bảo vệ các thông tin nhận dạng và các thẻ xác thực. Các thông tin nhận dạng cần được bảo mật nếu chúng được truyền qua mạng và trong khi chúng được lưu trong các dạng cố định chẳng hạn như trong file cấu hình. Các thẻ xác thực phải được bảo mật qua mạng vì chúng là các lỗ hổng cho việc tấn công. Kỹ thuật mã hoá cung cấp một giải pháp SSL hoặc IPSec có thể được dụng để bảo vệ các thông tin nhận dạng và các vé qua mạng và DPAPI cung cấp một giải pháp tốt cho việc mã hoá các thông tin nhận dạng trong các file cấu hình. e. Lỗi về bảo mật Nếu ứng dụng của ta bị lỗi với một điều kiện ngoại lệ không thể khắc phục, cần đảm bảo các thông báo lỗi không được trả về phí trình duyệt của người dùng. Ta có thể sử dụng kỹ thuật nắm bắt ngoại lệ có cấu trúc để giải quyết vấn đề này. d. Xem xét về chứng thực tập trung Nếu ta cấu hình một thư mục yêu cầu xác thực thì tất cả người dùng có quyền truy cập như nhau tới các trang trong thư mục. Nếu cần thiết, ta có thể áp dụng các nguyên tắc chứng thực khác nhau cho mỗi trang dựa vào đặc tính nhận dạng, hoặc các vai thành viên bằng cách sử dụng thành phần với thành phần e. Đặt các điều khiển web và các điều khiển người dùng trong các gói assemblies riêng biệt Khi các điều khiển Web và các điều khiển người dùng được đặt trong các gói assemblies riêng thì ta có thể cấu hình bảo mật cho mỗi gói một cách độc lập bằng cách sử dụng chính sách code access security. Điều này cung cấp thêm sự linh hoạt cho người quản trị và cũng có nghĩa là bạn không bị ép buộc cấp các quyền rộng ra cho toàn bộ điều khiển chỉ để thoả mãn các yêu cầu của một điều khiển. f. Đặt mã truy nhập tài nguyên trong một gói assembly riêng Sử dụng các gói assemblies riêng biệt và gọi chúng từ các lớp của trang của ta hơn là nhúng mã truy nhập tài nguyên vào trong các bộ nắm bắt sự kiện của lớp của trang. Điều này cung cấp sự linh hoạt cho chính sách code access security và là điều quan trọng cho việc xây dựng các ứng dụng partial-trust Web. 3.2.3. Các kỹ thuật với các hiểm hoạ điển hình a. Kiểm tra giá trị đầu vào Việc kiểm tra kiểu, độ dài, định dạng hoặc phạm vi của dữ liệu vào sẽ tránh được một số vụ tấn công. Ràng buộc và cải tiến Kiểm tra kiểu, độ dài, định dạng và phạm vi của giá trị đầu vào, đôi khi cần cải tiến giá trị đầu vào làm nó an toàn hơn Yêu cầu Tuỳ chọn Kiểm tra kiểu .System.Parse biến đổi kiểu thành kiểu mạnh và nắm bắt ngoại lệ FormatException Sử dụng các biểu thức kiểm tra. Dùng điều khiển RegularExpressionValidator hoặc lớp Regex. Kiểm tra độ dài Các biểu thức thông thường Sử dụng thuộc tính String.Length Kiểm tra định dạng Dùng biểu thức thông thường Hệ thống kiểu .NET Framework Kiểm tra phạm vi Điều khiển RangeValidator ( hỗ trợ dữ liệu kiểu currency, date, integer, double, và string) So sánh kiểu dữ liệu Regular Expressions Có thể sử dụng các biểu thức thông thường để hạn chế phạm vi các ký tự hợp lý và lược bỏ các ký tự không mong muốn, và để thực hiện việc kiểm tra độ dài và định dạng. ASP.NET cung cấp điều khiển RegularExpressionValidator và lớp Regex là có sẵn từ không gian tên System.Text.RegularExpressions. Việc kiểm tra ở phía client và server là khác nhau. Phía client sử dụng cú pháp biểu thức của Jscript. Phía server sử dụng cú pháp System.Text.RegularExpression. Regex. Regex regex = new Regex(@" ^ # anchor at the start (?=.*\d) # must contain at least one digit (?=.*[a-z]) # must contain one lowercase (?=.*[A-Z]) # must contain one uppercase .{8,10} # From 8 to 10 characters in length $ # anchor at the end", RegexOptions.IgnorePatternWhitespace); String Fields Để kiểm tra các trường dữ liệu kiểu xâu như tên, địa chỉ, …ta sử dụng các biểu thức thông thường để : Ràng buộc phạm vi có thể chấp nhận của các ký tự đầu vào. Áp dụng các nguyên tắc định dạng như: các mẫu ZIP code, postal code,.. Kiểm tra độ dài Tên: Ví dụ dưới đây sử dụng điều khiển RegularExpressionValidator để kiểm tra trường tên. <asp:RegularExpressionValidator id="nameRegex"runat="server" ControlToValidate="txtName" ValidationExpression="[a-zA-Z'.`-´\s]{1,40}" ErrorMessage="Invalid name"> Số bảo hiểm xã hội: <asp:RegularExpressionValidator id="ssnRegex" runat="server" ErrorMessage="Invalid social security number" ValidationExpression="\d{3}-\d{2}-\d{4}" ControlToValidate="txtSSN"> Hoặc có thể sử dụng lớp System.Text.RegularExpression.Regex trong mã. if (!Regex.IsMatch(txtSSN.Text, @"^\d{3}-\d{2}-\d{4}$")) { // Invalid Social Security Number } Date Fields Với các trường dữ liệu ta có thể biến đổi kiểu để kiểm tra. Chẳng hạn, để kiểm tra một ngày, ta có thể biến đổi giá trị vào thành một biến của kiểu System.DateTime và nắm bắt ngoại lệ nếu giá trị vào không tương thích. try { DateTime dt = DateTime.Parse(txtDate.Text).Date; } // Nếu biến đổi sai sẽ phát sinh một ngoại lệ FormatException catch( FormatException ex ) { // thông báo lỗi } Ngoài ra để định dạng và kiểm tra kiểu ta có thể thực hiện việc kiểm tra phạm vi trên một trường ngày . Cách này đựoc thực hiện dễ dàng hơn. DateTime dt = DateTime.Parse(txtDate.Text).Date; if ( dt > DateTime.Now.Date ) throw new ArgumentException("Date must be in the past"); Các trường số Có thể sử dụng Int32.Parse hoặc Convert.ToIn32 và nắm bắt ngoại lệ FormatException để kiểm tra. try { int i = Int32.Parse(txtAge.Text); . . . } catch( FormatException) { . . . } Range Checks Sử dụng điều khiển RangeValidator để kiểm tra phạm vi dữ liệu. Chẳng hạn kiểm tra giá trị vào là các số từ 0 đến 255. <asp:RequiredFieldValidator id="rangeRegex" runat="server" ErrorMessage="Please enter a number between 0 and 255" ControlToValidate="txtNumber" style="LEFT: 10px; POSITION: absolute; TOP: 47px" > <asp:RangeValidator id="RangeValidator1" runat="server" ErrorMessage="Please enter a number between 0 and 255" ControlToValidate="TextBox1" Type="Integer" MinimumValue="0" MaximumValue="255" style="LEFT: 10px; POSITION: absolute; TOP: 47px" > Hoặc có thể sử dụng lớp Regex: try { int i = Convert.ToInt32(sInput); if ((0 <= i && i <= 255) == true) { // data is valid, use the number } } catch( FormatException ) { . . . } Cải tiến đầu vào Sử dụng phương thức Regex.Replace để cải tiến dữ liệu vào khi cần thiết. Đoạn mã dưới đây loại bỏ các ký tự không an toàn, bao gồm: \ “ ‘ % ; () & private string SanitizeInput(string input) { Regex badCharReplace = new Regex(@"^([""'%;()&])$"); string goodChars = badCharReplace.Replace(input, ""); return goodChars; } b. Cross-Site Scripting Các tấn công XSS khám phá các lỗ hổng trong kiểm tra trang Web bằng cách nhúng đoạn mã từ phía client. Đoạn mã này sau đó được gửi trở về một người dùng mà không nghi ngờ gì và được thực thi bởi trình duyệt. Vì trình duyệt tải về đoạn mã từ một site tin cậy, trình duyệt không có cách nào xác định rằng đoạn mã không hợp lệ và các vùng an toàn của Internet Explorer không cung cấp rào cản. Các tấn công XSS cũng làm việc dựa trên các kết nối HTTP hoặc HTTPS(SSL). Một trong những khám phá quan trọng nhất xảy ra khi một kẻ tấn viết đoạn mã để lấy về cookie xác thực cung cấp thông tin truy cập tới site đáng tin và gửi nó tới một địa chỉ Web mà kẻ tấn công biết. Điều này cho phép kẻ tấn công giả dạng đặc tính nhận diện của người dùng hợp pháp và đạt được truy cập tới web site. Sử dụng các phương án phòng chống sau để tránh các tấn công XSS. Kiểm tra giá trị đầu vào: Kiểm tra bất kỳ đầu vào nào nhận được từ ngoài rào cản tin cậy của ứng dụng bao gồm: kiểu, độ dài, định dạng và phạm vi Mã hoá đầu ra: Nếu viết đầu ra dạng văn bản cho một trang Web và ta không hoàn toàn chắc chắn rằng văn bản không chứa các ký tự đặc biệt HTML như: , và &, thì phải đảm bảo sử lý trước nó bằng cách sử dụng phương thức HttpUtility.HtmlEncode. Sử dụng HttpUtility.UrlEncode để mã hoá các xâu URL. Phương thức HtmlEncode thay thế các ký tự có ý nghĩa đặc biệt trong HTML thành các biến HTML đại diện cho các ký tự này. Ví dụ: < thay thế với < và “ thay thế với &qout. Trình duyệt sẽ không thực thi dữ liệu được mã hoá. Thay vào đó dữ liệu được trả lại là mã HTML vô hại Response.Write(HttpUtility.HtmlEncode(Request.Form["name"])); Phương án rào cản sâu Để tránh tấn công kiểu XSS Đặt chế độ character encoding Sử dụng tuỳ chọn validateRequest ASP.NET version 1.1 Cài đặt URLScan trên Web server Sử dụng tuỳ chọn cookie HttpOnly Sử dụng thuộc tính an toàn Sử dụng thuộc tính innerText Đặt chế độ Character Encoding: ASP.NET cho phép ta chỉ ra bộ ký tự ở mức trang hoặc ở mức ứng dụng bằng cách sử dụng thành phần trong Web.config. Để thiết đặt chế độ mã hoá ký tự ở mức trang, sử dụng thành phần hoặc thuộc tính mức trang ResponseEncoding như sau: <meta http-equiv="Content Type" content="text/html; charset=ISO-8859-1" /> hoặc Để thiết đặt chế độ mã hoá ký tự trong Web.config, sử dụng cấu hình sau: <globalization requestEncoding="ISO-8859-1" responseEncoding="ISO-8859-1"/> Sử dụng đoạn mã sau để kiểm tra các ký tự Unicode trong một trang: using System.Text.RegularExpressions; . . . private void Page_Load(object sender, System.EventArgs e) { // Tên phải chứa các ký tự alphanumeric từ 1 đến 40 if(!Regex.IsMatch(Request.Form["name"],@"^[\p{L}\p{Zs}\p{Lu}\p{Ll}]{1,40}$")) throw new ArgumentException("Invalid name parameter"); // Sử dụng các biểu thực riêng để kiểm tra các tham số khác } Giải thích: {} Chỉ ra một lớp ký tự Unicode được đặt tên \p{} Kiểm tra sự phù hợp các ký tự bất ký trong lớp ký tự được đặt tên được chỉ ra bởi {} {L} Thực hiện kiểm tra sự phù hợp từ trái sang phải {Lu} Thực hiện kiểm tra phù hợp với chữ viết hoa {Ll} Thực hiện kiểm tra phù hợp với chữ thường {Zs} Ghép separator và space. {1,40} Không nhỏ hơn 1 và không lớn hơn 40 Sử dụng tuỳ chọn ASP.NET validateRequest: Thuộc tính validatRequest là một đặc điểm trong .NET Framework version 1.1. Thuộc tính này mặc định được thiết lập thành true trong thành phần trong Machine.config. Nó chỉ dẫn cho ASP.NET để kiểm tra tất cả dữ liệu nhận được từ trình duyệt đối với đầu vào nguy hiểm, ví dụ: giá trị vào chứa thành phần . Có thể áp dụng cho mỗi trang bằng cách sử dụng thẻ @page như sau: Sử dụng tuỳ chọn cookie HttpOnly: Internet Explorer 6 Service Pack 1 hỗ trợ thuộc tính HttpOnly, tránh client-side script từ việc truy cập tới cookie từ thuộc tính document.cookie. Thay vào đó một xâu rỗng được trả về. Cookie vẫn được gửi về server bất cứ khi nào người dùng duyệt một Web site trong miền hiện tại. Lớp System.Net.Cookie không hỗ trợ thuộc tính HttpOnly. Để thêm thuộc tính HttpOnly cho cookie, ta cần sử dụng một bộ lọc ISAPI, hoặc là nếu muốn sử dụng một giải pháp mã được bảo mật thì thêm đoạn mã vào Application_EndRequest của ứng dụng trong Global.asax., , protected void Application_EndRequest(Object sender, EventArgs e) { string authCookie = FormsAuthentication.FormsCookieName; foreach (string sCookie in Response.Cookies) { // Chỉ thiết lập thuộc tính HttpOnly trong cookie Forms authentication if (sCookie.Equals(authCookie)) { // Force HttpOnly to be added to the cookie header Response.Cookies[sCookie].Path += ";HttpOnly"; } } } c. Xác thực Xác thực yếu nảy sinh nguy cơ giả dạng đặc tính nhận dạng. Nếu các thông tin đăng nhập của người dùng rơi vào tay kẻ xấu, kẻ tấn công có thể giả dạng đặc tính nhận dạng của người dùng và đạt được truy cập tới ứng dụng. Kẻ tấn công chia sẻ tất cả các đặc quyền của người dùng trong ứng dụng. Các thông tin đăng nhập phải được bảo vệ khi chúng được truyền qua mạng. Cookie xác thực đại diện cho đặc tính nhận dạng đã được xác thực cho ứng dụng sau khi đăng nhập cũng phải được bảo vệ để giảm rắc rối của kiểu tấn công session và tấn công cookie replay. Forms Authentication Nguy cơ tấn công session hijacking và cookie replay là đáng kể với các ứng dụng sử dụng Forms authentication. Ta phải đặc biệt quan tâm khi truy vấn cơ sở dữ liệu bằng cách sử dụng các thông tin đăng nhập của người dùng để tránh tấn công SQL injection. Ngoài ra để tránh identity spoofing, ta phải đảm bảo rằng user store là an toàn và ép buộc strong password. một cấu hình "secure" Forms authentication trong Web.config: <forms loginUrl="Restricted\login.aspx" Login page in an SSL protected folder protection="All" Privacy and integrity requireSSL="true" Prevents cookie being sent over http timeout="10" Limited session lifetime name="AppNameCookie" Unique per-application name path="/FormsAuth" and path slidingExpiration="true" > Sliding session lifetime Khi sử dụng Forms authentication cần chú ý: Khoanh vùng Web site Bảo mật các trang được chế truy cập với SSL Sử dụng URL Authorization Bảo mật cookie xác thực Sử dụng URL để điều hướng Quản lý các thông tin đăng nhập Khoanh vùng web site: Trong thiết kế site đảm bảo các trang an toàn và các trang truy cập yêu cầu xác thực phải được đặt trong một thư mục con tách biệt với các trang có thể được truy cập ẩn danh. Bảo mật các trang được hạn chế truy cập với SSL: Thiết lập thuộc tính AccessSSL = true cho thư mục trong IIS Sử dụng URL Authorization: Sử dụng thành phần để cho phép các truy cập ẩn danh tới các trang công cộng. Sử dụng thành phần trong thành phần trong Web.config để từ chối truy cập người dùng không được xác thực và ép buộc một điều hướng tới trang đăng nhập được chỉ ra trong thành phần . Bảo mật cookie xác thực: Để tránh các tấn công session hijacking và cookie replay, cookie phải được truyền qua các kết nối SSL bằng cách sử dụng giao thức HTTPS. Để giảm rắc rối ta nên mã hoá cookie trước khi gửi nó tới client và giới hạn thời gian cho cookie đúng giá trị. Để cho cookie authentication được an toàn, ta cần thực hiện: Hạn chế authentication cookie với các kết nối HTTPS Mã hoá cookie Giới hạn thời gian sống của cookie Sử dung khoảng thời gian hết hạn cố định Không lưu authentication cookies. Giữ authentication và personalization cookíe riêng biệt Sử dụng tên và đường dẫn cookie phân biệt Hạn chế authentication cookie với các kết nối HTTPS: Các cookie hỗ trợ thuộc tính “secure” để xác định các trình duyệt có gửi cookie về server hay không. Khi thuộc tính này được thiết lập, cookie được gửi bởi trình duyệt tới trang an toàn được yêu cầu với HTTPS URL Nếu sử dụng .NET Framework version 1.1, thiết lập thuộc tính secure bằng cách sử dụng requireSSL =”true” trong thành phần : <forms loginUrl="Secure\Login.aspx" requireSSL="true" . . . /> Mã hoá cookie: Mã hoá nội dung cookie kể cả khi sử dụng SSL. Điều này tránh một kẻ tấn công xem hay chỉnh sửa cookie nếu hắn cố gắng lấy nó qua một tấn công XSS. Trong sự kiện này kẻ tấn công vẫn có thể sử dụng cookie để đạt được truy cập tới ứng dụng. Cách tốt nhất để giảm rắc rối là thực thi phương án phòng chống tương ứng để tránh các tấn công XSS và giới hạn thời gian sống của cookie. Để đảm bảo tính riêng tư và tính toàn vẹn cho cookie, ta thiết lập thuộc tính protection trong thành phần <forms protection="All" Privacy and integrity Giới hạn thời gian sống của cookie: <forms timeout="10" Reduced cookie lifetime (10 minutes) d. Chứng thực Sử dụng authorization để điều khiển truy cập tới các thư mục, các trang Web riêng, các lớp trang và các phương thức. Khi xây dựng authorization cho các trang và điều khiển cần chú ý: Sử dụng URL authorization để điều khiển truy cập trang và thư mục Sử dụng File authorization với Windows authentication Sử dụng các yêu cầu principal trong các lớp và các phương thức Sử dụng kiểm tra vai cho chứng thực được cấp quyền Sử dụng URL Authorization để điều khiển truy cập tới trang và điều khiển. Để điều khiển mức trang và thư mục, sử dụng URL authorization sử dụng thành phần để cấu hình. Để hạn chế truy cập tới các file hoặc các thư mục đặt thành phần trong thành phần Sử dụng File Authorization với Windows Authentication Nếu ASP.NET được cấu hình cho Windows authentication, FileAuthorization Module kiểm tra tất cả các loại file ASP.NET, bao gồm các trang ASP.NET (.aspx), các điều khiển người dùng (.ascx), và bất kỳ loại file nào khác được xác định bởi IIS nhờ bộ lọc ISAPI. Để cấu hình FileAuthorizationModule, thiết lập ACLs tương ứng trên các file ASP.NET. Sử dụng các yêu cầu Principal trên các lớp và các phương thức. Các yêu cầu quyền Principal cho phép ta xác định authorization dựa vào đặc tính nhận dạng và vai thành viên. Các đặc tính nhận dạng của cuộc triệu gọi và vai thành viên được duy trì bởi đối tượng principal được kết hợp với yêu cầu Web hiện tại ( truy cập qua HttpContext.User). Sử dụng các thuộc tính an toàn để cung cấp các điều khiển truy cập trên các lớp và các phương thức, như sau: // Declarative syntax [PrincipalPermission(SecurityAction.Demand, Role=@"DomainName\WindowsGroup")] public void SomeRestrictedMethod() { } Sử dụng các vai cụ thể để cho việc chứng thực Kiểm tra an toàn bằng cách khai báo ngăn một người dùng truy cập một lớp hoặc gọi một phương thức cụ thể. Nếu ta cần ràng buộc bên trong một phương thức để bổ xung các quyết định chứng thực, hoặc là sử dụng principal permission demands hoặc là explicit role checks bằng cách sử dụng Iprincipal.IsInRole. Ví dụ sử dụng imperative principal permission demand. // Imperative syntax public void SomeRestrictedMethod() { // Chỉ cho phép các thành viên của Windows group được phép truy cập PrincipalPermission permCheck = new PrincipalPermission( null, @"DomainName\WindowsGroup"); permCheck.Demand(); // Một số hoạt động bị hạn chế } Ví dụ sau sử dụng IPrincipal.IsInRole: public void TransferMoney( string fromAccount, string toAccount, double amount) { // Trích ra người dùng được xác thực từ ngữ cảnh HTTP hiện tại // Biến User là ngang bằng với HttpContext.Current.User nếu bạn đang sử //dụng trang .aspx hoăc .asmx WindowsPrincipal authenticatedUser = User as WindowsPrincipal; if (null != authenticatedUser) { // Lưu ý: Để lấy username của người dùng được xác thực ta sử dụng dòng //lệnh sau: // string username = authenticatedUser.Identity.Name; // Nếu amount vượt quá một ngưỡng, thì chấp nhận manager if (amount > thresholdValue) { // Thực hiện một role check if (authenticatedUser.IsInRole(@"DomainName\Manager") ) { // OK to proceed with transfer } else { throw new Exception("Unauthorized funds transfer"); } } else { . . . } } } Chương 4 – THIẾT KẾ DEMO 4.1. Dự án Cục tài nguyên môi trường. Theo dõi tiến độ thực hiện theo nghị định 64 QĐ-TTg. Thông tin về các cơ sở gây ô nhiễm môi trường được tổng hợp thống kê ở 2 cấp + Cấp Sở: Tổng hợp thông tin ô nhiễm của cơ sở gây ô nhiễm trực thuộc tỉnh của mình rồi gửi cho Cục. + Cấp Cục: Khi nhận được thông tin từ các Sở gửi lên, Cục sẽ tổng hợp lại thông tin, rồi đưa ra các báo cáo, quyết định, biện pháp xử lý. 4.1.1. Mô hình hoá chức năng (0).Hệ thống QL các cơ sở gây ô nhiễm môi trường (1) Ngoại tuyến cấp Cục (3) Cập nhật DL tĩnh (2) Trực tuyến Hình 12: Mô hình hoá chức năng. 4.1.2. Phân rã chức năng ngoại tuyến cấp Cục (1). Ngoại tuyến cấp Cục 1.2 Cơ sở gây ô nhiễm 1.3 Quản lý hồ sơ 1.5 Quản lý dữ liệu tĩnh 1.4 Quản lý người dùng 1.1 Hệ thống 1.6 Thống kê báo cáo 1.7 Hướng dẫn sử dụng Hình 13: Phân rã chức năng 1.1.5 Thoát khỏi chương trình 1.1.4 Đặt TS kết nối DL trung tâm 1.1.3 Đổi mật khẩu 1.1.2 Khóa chương trình 1.1.1 Đăng nhập vào hệ thống 1.1 Hệ thống a. Hệ thống Hình 14: Hệ thống 1.2.5 Cơ sở bị phả ánh ô nhiêm 1.2.4 Bổ sung cơ sở GON 1.2.3 Danh sach các cơ sơ GON 1.2.2 Theo tiến độ cấp sở 1.2.1 Theo tiến độ cấp cơ sở 1.2 Cơ sở GON b. Các cơ sở gây ô nhiễm Hình 15: Cơ sở gây ô nhiễm 1.3 Quản lý hồ sơ ồ sơ 1.3.2 Xét duyệt hồ sơ 1.3.1 Nhân hồ sơ từ cơ sở Nhân hồ sơ từ cơ sở GON 1.3.3 Bổ sung loại văn bản 1.3.4 Bổ sung trạng thái hồ sơ c. Quản lý hồ sơ Hình 16: Quản lý hồ sơ 1.4 Quản lý người dùng ồ sơ 1.4.2 Bổ sung mới người dùng 1.4.1 Xem danh sách người dùng Nhân hồ sơ từ cơ sở GON 1.4.3 Theo dấu vết người dùng 1.4.4 Quản lý cấp bậc 1.4.5 Quản lý quyền d. Quản lý người dùng Hình 17: Quản lý người dùng e. Quản lý dữ liệu tĩnh cấp cục 1.5.2 Trạng thái của hồ sở cơ sở 1.5.3 Loại kinh phí 1.5.5 Giai đoạn 1.5.4 Loại khó khăn ng 1.5.1 Biên pháp sử lý triệt để 1.5.6 Loại quy định 1.5.8 Loại cơ sở 1.5.9 Quản lý tỉnh 1.5.11 Quản lý theo lưu vực 1.5.10 Quản lý vùng ng 1.5.7 Bộ ngành 1.5 Quản lý dữ liệu tĩnh cấp Cục Hình 18: Quản lý dữ liệu tĩnh cấp cục f. Thống kê báo cáo 1.6.5 Theo biện pháp sử dụng 1.6.4 Theo tiến độ 1.6.3 Theo bộ ngành 1.6.2 Theo sở môi trường 1.6.1 Theo loại cơ sở 1.6 Thống kê – Báo cáo 1.6.6 Theo trạng thái hồ sơ Hinh 19: Thống kê báo cáo 4.2. Thiết kế Web site an toàn. 4.2.1 Vấn đề an toàn mà Web site đã làm được. + ASP.NET tự xác định được các hành động tấn công XSS. + Mã hoá mật khẩu của người dùng trước khi lưu vào cơ sở dữ liệu + Sử dụng Store Procedure ( tránh được kiểu tấn công SQL Injection). 4.2.2. Tăng cường an ninh. a. Đặt mã truy nhập tài nguyên trong một gói assembly riêng Dataaccess.dll: Các lớp truy xuất dữ liệu đặt trong thư viện . Utilities.dll: Các lớp tiện ích đặt trong thư viện. Security.dll: Các lớp dùng để tăng cường an ninh đặt trong thư viện. b. Mã hoá xâu kết nối cơ sở dữ liệu. Sử dụng hàm Encrypt() trong thư viện Encyption.dll để mã hoá xâu kết nối cơ sở dữ liệu, lưu xâu mã hoá vào trong Web.config hoặc trong Registry. Trong Web.config: - Mã hóa dựa trên thuật toán mã hóa 1 chiều MD5, - Sau khi mã hóa, sử dụng thuật toán encode Base64 để lưu dưới dạng Text //Giai ma xau ket noi public static string DecryptConfig() { string appSettingValue = ConfigurationSettings.AppSettings ["connectionString"]; return Decrypt(appSettingValue); } Trong Registry: //Ghi xâu mã hoá vào Registry. private void btnWriteRegistryData_Click(object sender, System.EventArgs e) { // tao registry key va values RegistryKey rk = Registry.LocalMachine.OpenSubKey("Software",true); rk = rk.CreateSubKey("WebUI"); rk.SetValue("connectionString",txtEncryptedString.Text.Trim().ToString()); MessageBox.Show("The data has been successfully written to the registry"); } //Giai ma xau ket noi lay tu Registry public static string GetConnectionString() { RegistryKey rk = Registry.LocalMachine. OpenSubKey( @"Software\TestApplication",false); string EncryptedString = (string)rk.GetValue("connectionString"); return Decrypt(EncryptedString); } . TÀI LIỆU THAM KHẢO [1] J.D.Meier, Alex Mackman, Content Master,Srinath Vasireddy, Michael Dunner, Ray Escamilla Anandha Murukan – Improving Web Application Security – Microsoft Corporation , Satyam Computer Services [2] J.D.Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy – Building Secure Microsoft ASP.NET Applications: Authentication, Authorization, and Secure Communication [3] Nguyễn thu Hải, Nguyễn thuý Hằng – Phần mềm quản lý và cập nhật thông tin về tình hình thực hiện Quyết định số 64/2003/QĐ –TTg.