.Net secure coding guidelines

Hướng dẫn code .Net an toàn

Tổng quan

     Trong .Net Evidence Based Security và Code access security cung cấp các cơ chế rõ ràng, mạnh mẽ để thực hiện bảo mật. Hầu hết các các ứng dụng có thể chỉ đơn giản là sử dụng cơ chế được triển khai bởi .NET. Nhưng trong một số trường hợp, việc tăng khả năng bảo mật dành riêng cho ứng dụng là bắt buộc, được xây dựng bằng cách mở rộng hệ thống bảo mật hoặc bằng cách sử dụng các phương pháp mới.

     Khi sử dụng các quyền để thực thi trong code của bạn, bạn nên dựng lớp bảo vệ để ngăn chặn mã độc truy cập thông tin mà bạn không muốn nó có được hay thực hiện các hành động không mong muốn khác. Ngoài ra, bạn phải đạt được sự cân bằng giữa bảo mật và khả năng sử dụng trong tất cả các tình huống khi ​​sử dụng code tin cậy.

     Tổng quan này mô tả các cách khác nhau mà việc viết code có thể thiết kế để làm việc với hệ thống bảo mật.

Bảo mật truy cập tài nguyên (Resource)

• Không sử dụng Code Access Security (CAS).
• Không sử dụng partial trusted code.
• Không sử dụng thuộc tính AllowPartiallyTrustedCaller (APTCA).
• Không sử dụng .NET Remoting.
• Không sử dụng Distributed Component Object Model (DCOM).
• Không sử dụng định dạng nhị phân.

Bảo mật State Data (Mô tả cách bảo mật private members)

    

     Các ứng dụng xử lý dữ liệu nhạy cảm cần phải giữ dữ liệu đó dưới sự kiểm soát của mình và chặn  các mã độc hại tiềm tàng khác truy cập trực tiếp vào dữ liệu. Cách tốt nhất để bảo vệ dữ liệu trong bộ nhớ là khai báo dữ liệu là các biến riêng tư(private) hoặc nội bộ(internal) (với phạm vi giới hạn trong cùng một assembly). Tuy nhiên, ngay cả dữ liệu này vẫn có thể truy cập, bạn nên biết:

• Sử dụng các cơ chế reflection, sử dụng có thể tham chiếu đối tượng của bạn có thể get và set private members.
• Sử dụng serialization, có thể get và set private members một cách hiệu quả nếu nó có thể truy cập dữ liệu tương ứng ở dạng tuần tự hóa của đối tượng.
• Bằng cách debugging, dữ liệu có thể được đọc.

  Hãy chắc chắn rằng không có method hoặc properties nào của bạn vô tình làm lộ ra các giá trị này.

Bảo mật User input

     Một số cân nhắc quan trọng liên quan đến dữ liệu người dùng bao gồm:(nhiều keyword ko dịch sang tiếng việt)

• Any user data in a server response runs in the context of the server's site on the client. If your Web server takes user data and inserts it into the returned Web page, it might, for example, include a <script> tag and run as if from the server.
• Remember that the client can request any URL.
• Consider tricky or invalid paths:
• ..\ , extremely long paths.
• Use of wild card characters (*).
• Token expansion (%token%).
• Strange forms of paths with special meaning.
• Alternate file system stream names such as filename::$DATA.
• Short versions of file names such as longfi~1 for longfilename.
• Remember that Eval(userdata) can do anything.
• Be wary of late binding to a name that includes some user data.
• If you are dealing with Web data, consider the various forms of escapes that are permissible, including:
• Hexadecimal escapes (%nn).
• Unicode escapes (%nnn).
• Overlong UTF-8 escapes (%nn%nn).
• Double escapes (%nn becomes %mmnn, where %mm is the escape for '%').
• Be wary of user names that might have more than one canonical format. For example, you can often use either the MYDOMAIN\username form or the username@mydomain.example.com form.

Bảo mật Race conditions

     Trong lĩnh vực lập trình Race condition là một tình huống xảy ra khi nhiều threads cùng truy cập và cùng lúc muốn thay đổi dữ liệu (có thể là 1 biến, 1 row trong database, 1 vùng shared data, memory , etc...). Vì thuật toán chuyển đổi việc thực thi giữa các threads có thể xảy ra bất cứ lúc nào nên không thể biết được thứ tự của các threads truy cập và thay đổi dữ liệu đó sẽ dẫn đến giá trị của data sẽ không như mong muốn. Kết quả sẽ phụ thuộc vào thuật toán thread scheduling của hệ điều hành.

     Nếu code của bạn lưu trữ thông tin bảo mật, hãy đảm bảo rằng bạn xem xét nó về lỗ hổng này.

Nguồn: https://docs.microsoft.com/en-us/dotnet/standard/security/