Khóa luận Tăng cường an ninh cho các ứng dụng xây dựng trên nền .NET Framework

g 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