Hoang  Kim

Hoang Kim

1661938824

Kiểm Soát Truy Cập Bị Hỏng Trong ASP.NET Core: Mọi Thứ Bạn Cần Biết

Trong bài viết này, chúng ta sẽ tìm hiểu về kiểm soát truy cập bị hỏng trong ASP.NET Core là gì, tại sao nó lại quan trọng và những lỗ hổng nào được che phủ trong kiểm soát truy cập bị hỏng trong ASP.NET Core. Chúng ta cũng sẽ tìm hiểu về cách những kẻ tấn công có thể khai thác các lỗ hổng này và cách sửa mã ASP.NET Core để giảm thiểu rủi ro liên quan đến lỗ hổng trong kiểm soát truy cập bị hỏng trong ASP.NET Core.

Đầu tiên chúng ta hãy hiểu kiểm soát truy cập là gì. Kiểm soát truy cập liên quan đến phần ủy quyền của ứng dụng và được định nghĩa là một tập hợp các chính sách hoặc cơ chế để cung cấp quyền kiểm soát các tài nguyên của ứng dụng. tức là khi người dùng đã đăng nhập thành công vào ứng dụng, cơ chế kiểm soát truy cập được sử dụng để cấp đặc quyền cho các tài nguyên mà người dùng đã đăng nhập được phép truy cập.

Kiểm soát truy cập bị hỏng có nghĩa là kiểm soát truy cập không được triển khai đúng cách hoặc không hoạt động như mong muốn để các lỗ hổng được đưa vào kiểm soát truy cập của ứng dụng. Những kẻ tấn công có thể khai thác các lỗ hổng này để truy cập vào các tài nguyên bị hạn chế.

Lỗ hổng kiểm soát truy cập bị hỏng rất cần được sửa chữa trong mã ứng dụng của chúng tôi và gần đây nó đã chuyển từ vị trí thứ năm lên vị trí đầu tiên trong 10 Rủi ro Bảo mật Ứng dụng Web hàng đầu của OWASP. Kiểm soát truy cập bị hỏng trong ASP.NET Core có liên quan đến các lỗ hổng trong phần ủy quyền của mã bảo mật.

Để khắc phục lỗ hổng kiểm soát truy cập bị hỏng này trong ứng dụng của mình, chúng tôi thực thi các chính sách ngăn người dùng truy cập tài nguyên hoặc thực hiện các hành động không được phép đối với người dùng, tức là người dùng sẽ không thể xem thông tin hoặc dữ liệu không thuộc về họ hoặc không được phép để truy cập và cũng không thể thực hiện các hành động không được phép (như thêm, sửa đổi, xóa, v.v.) trên dữ liệu.

Kiểm soát truy cập bị hỏng trong top 10 OWASP giải thích chi tiết về các lỗ hổng có thể có trong mã ủy quyền hoặc cấu hình có thể cho phép kẻ tấn công khai thác lỗ hổng để truy cập thông tin bị hạn chế và sửa đổi hoặc xóa thông tin đó. Nó thậm chí còn liệt kê các cách mà kẻ tấn công có thể khai thác lỗ hổng trong các ứng dụng web bằng cách giả mạo URL, cookie, mã thông báo bảo mật hoặc dữ liệu trang để truy cập vào thông tin bị hạn chế hoặc thực hiện các hành động mà chúng không được phép thực hiện.

Lỗ hổng kiểm soát truy cập bị hỏng

Theo OWASP, các lỗ hổng kiểm soát truy cập phổ biến có thể có trong mã và được bao gồm trong kiểm soát truy cập bị hỏng như sau

  • Không thực hiện nguyên tắc từ chối theo mặc định tức là quyền truy cập vào thông tin hoặc hành động bị hạn chế sẽ không được phép theo mặc định đối với bất kỳ ai và phải được kích hoạt trên cơ sở cần thiết cho một người dùng, vai trò hoặc nhóm người dùng cụ thể, tức là thông tin bị hạn chế sẽ không có sẵn cho tất cả người dùng theo mặc định và sau đó bạn tắt nó cho những người dùng không được phép truy cập nó. Để làm rõ hơn lỗ hổng này chỉ ra sự vi phạm chính sách trong quá trình tạo người dùng mới, trong đó chính sách quy định rằng người dùng mới theo mặc định không được có bất kỳ quyền truy cập nào vào dữ liệu bị hạn chế thay vào đó, quản trị viên nên cho phép rõ ràng các chức năng được phép được người dùng truy cập.
  • Nhận quyền truy cập vào tài nguyên hoặc thông tin bị hạn chế hoặc thực hiện hành động bị hạn chế đối với dữ liệu bằng cách bỏ qua cơ chế kiểm soát truy cập của ứng dụng bằng cách thao tác với URL của ứng dụng, tức là giả mạo URL liên quan đến việc sửa đổi các tham số URL, sửa đổi trang HTML hoặc bằng cách sử dụng công cụ tấn công để sửa đổi yêu cầu HTTP được gửi đến ứng dụng.
  • Nhận quyền truy cập vào các chi tiết hoặc dữ liệu thuộc về một số người dùng khác bằng cách sử dụng mã nhận dạng duy nhất của dữ liệu của người dùng kia. tức là những kẻ tấn công có thể sửa đổi định danh duy nhất đầu vào của dữ liệu thành yêu cầu truy cập dữ liệu thuộc về người dùng khác.
  • Bằng một số nghĩa là thay đổi các đặc quyền được chỉ định cho người dùng để người dùng có thể nhận được các đặc quyền cao hơn trong ứng dụng, tức là hoạt động như một người dùng đã đăng nhập được xác thực và được ủy quyền mà không cần thực hiện đăng nhập thành công hoặc một người dùng tiêu chuẩn bình thường đạt được người dùng quản trị.
  • Khai thác các lỗ hổng trong mã thông báo bảo mật được ứng dụng sử dụng, tức là phát lại hoặc giả mạo mã thông báo truy cập JSON Web Token (JWT) được sử dụng phổ biến nhất hoặc cookie hoặc trường ẩn để có quyền truy cập vào dữ liệu bị hạn chế hoặc các hành động không được phép đối với người dùng .
  • Cấu hình sai trong CORS (chia sẻ tài nguyên nhiều nguồn gốc) cho phép các trang web (trang web) có nguồn gốc không đáng tin cậy hoặc trái phép có quyền truy cập vào API ứng dụng và cho phép kẻ tấn công lừa người dùng thực hiện các hành động mà họ không biết.
  • Bằng một số nghĩa là buộc duyệt đến các trang đã được xác thực hoặc bị hạn chế bởi những người dùng không được xác thực và trái phép mạo danh người dùng đã được xác thực và được ủy quyền hoặc những người dùng chuẩn mạo danh người dùng quản trị.
  • Định cấu hình sai hoặc thiếu kiểm soát truy cập trong bảo mật cho các phương thức HTTP PUT, POST & DELETE cho phép người dùng hoặc kẻ tấn công trái phép có quyền truy cập vào API ứng dụng bị hạn chế bằng cách khai thác cấu hình kiểm soát truy cập bị thiếu.

Ứng dụng mẫu để trình diễn

Đây là liên kết đến Ứng dụng Web ASP.NET Core sẽ được sử dụng để trình diễn các lỗ hổng và các bản sửa lỗi liên quan đến kiểm soát truy cập bị hỏng trong ASP.NET Core.

https://github.com/procodeguide/ProCodeGuide.Samples.BrokenAccessControl/tree/master/ProCodeGuide.Samples.BrokenAccessContrrol/Initial

Dưới đây là danh sách các tính năng được cung cấp trong Ứng dụng Web ASP.NET Core

  • Xác thực đã được triển khai bằng Identity
  • Việc ủy ​​quyền đã được thực hiện bằng cách sử dụng Vai trò nhận dạng. Hai vai trò mặc định đã được cung cấp, Quản trị viên và Người dùng Chuẩn.
  • Đăng ký người dùng mặc định đã được sửa đổi để nắm bắt vai trò của người dùng.
  • Giao diện người dùng đã được cung cấp để tạo và xem các vai trò Danh tính và chỉ người dùng có vai trò Quản trị viên mới có thể truy cập chức năng này.
  • Trang blog đã được cung cấp để người dùng tạo và xem chi tiết các bài viết trên Blog do người dùng tạo. Tất cả những người dùng có thể tạo & xem chi tiết của các bài viết blog do họ tạo ra, tức là người dùng đã đăng nhập không thể xem chi tiết bài viết trên blog của người dùng khác.

Bạn có thể tải xuống mã nguồn từ liên kết GitHub được cung cấp ở trên và sau khi tải xuống, bạn sẽ phải chạy quá trình di chuyển. Bạn có thể thêm di chuyển và cập nhật cơ sở dữ liệu bằng cách thực hiện các lệnh dưới đây trong bảng điều khiển trình quản lý gói.

add-migration FirstMigration
update-database

Khi quá trình di chuyển được tạo thành công thì bạn có thể chạy ứng dụng. Sau khi chạy ứng dụng, bạn sẽ phải đăng ký tối thiểu 2 người dùng mới, một người có vai trò quản trị viên và một người khác có vai trò Người dùng tiêu chuẩn. Người dùng có vai trò quản trị viên sẽ có quyền truy cập vào chức năng vai trò và chức năng Bài đăng sẽ được phép cho tất cả người dùng nhưng không thể truy cập dữ liệu bài đăng của người dùng khác.

Với mục đích trình diễn, tôi đã tạo 2 người dùng mới, một người có vai trò quản trị viên sanjay@procodeguide.com và người khác có vai trò người dùng tiêu chuẩn support@procodeguide.com

Các lỗ hổng liên quan đến Kiểm soát truy cập bị hỏng trong ASP.NET Core

Cho đến nay, chúng ta đã thảo luận về các lỗ hổng có trong kiểm soát truy cập bị hỏng và các chi tiết được đề cập đến của ứng dụng mẫu được chuẩn bị để trình diễn. liên quan đến kiểm soát truy cập bị hỏng trong ASP.NET Core.

Tham chiếu đối tượng trực tiếp không an toàn

Lỗ hổng này liên quan đến một người dùng độc hại hoặc kẻ tấn công truy cập vào dữ liệu bị hạn chế hoặc cũng có thể xóa dữ liệu đó. Khi chúng tôi chèn dữ liệu vào cơ sở dữ liệu thì chúng tôi sẽ nhận được một số nhận dạng duy nhất được kết nối với dữ liệu để truy xuất hoặc sửa đổi dữ liệu này trong cơ sở dữ liệu. Đôi khi, chúng tôi kết thúc bằng cách sử dụng số thứ tự tăng dần cho các ID duy nhất này, điều này khiến người dùng rất dễ đoán các Id duy nhất sẽ có trong cơ sở dữ liệu.

Mặc dù trong các dạng xem ứng dụng, chúng tôi sẽ chỉ hiển thị các bản ghi thuộc về người dùng. Nhưng đối với một người dùng độc hại, có thể tìm thấy các số nhận dạng duy nhất này trong URL hoặc nội dung yêu cầu của bạn và khai thác bằng cách thay thế Id duy nhất trong yêu cầu bằng bất kỳ số nào không thuộc về người dùng. Bây giờ nếu ứng dụng của bạn không triển khai các kiểm soát truy cập đúng cách thì người dùng độc hại có thể kết thúc việc truy cập các bản ghi này và thậm chí xóa các bản ghi đó.

Hãy kiểm tra xem lỗ hổng này tồn tại như thế nào trong mã của chúng tôi và cách chúng tôi có thể sửa lỗi kiểm soát truy cập bị hỏng này trong ASP.NET Core bằng cách triển khai các kiểm soát truy cập thích hợp.

Kịch bản tấn công

Dưới đây là các bước về cách những kẻ tấn công có thể truy cập vào dữ liệu liên quan đến bài đăng của một người dùng khác

1. Chạy ứng dụng đã được tải xuống. Sau đó, đăng nhập với tư cách người dùng sanjay@procodeguide.com & tạo một vài bản ghi liên quan đến bài đăng bằng cách điều hướng đến màn hình Đăng-> Tạo. Thao tác này sẽ tạo ra các bản ghi trong Bài viết thuộc về người dùng sanjay@procodeguide.com như hình dưới đây

Ứng dụng web ASP.NET Core

 

2. Tiếp theo, đăng nhập với địa chỉ user support@procodeguide.com & tạo lại một vài dữ liệu liên quan đến bài đăng bằng cách điều hướng đến màn hình Đăng-> Tạo. Thao tác này sẽ tạo các bản ghi trong Bài viết thuộc về user support@procodeguide.com như hình dưới đây

Ứng dụng web ASP.NET Core

3. Bây giờ cho người dùng support@procodeguide.com 2 bản ghi có sẵn cho các bài đăng có Id 3 & 4.
4. Điều hướng đến trang chi tiết chế độ xem bài đăng cho một trong các bản ghi bài đăng như được hiển thị bên dưới

Ứng dụng web ASP.NET Core

5. Đối với kẻ tấn công, sẽ không khó để phát hiện ra rằng các ID bài đăng được tạo ra dưới dạng số lượng tăng dần và chắc chắn phải có các bản ghi với Id 1 & 2 cho một số người dùng. Ngoài ra, kẻ tấn công sẽ lưu ý rằng Id bài đăng đang được thêm vào URL trang vì vậy kẻ tấn công sẽ cố gắng giả mạo URL bằng cách thay đổi Id thành 1 hoặc 2 và yêu cầu dữ liệu như hình dưới đây

Tham chiếu đối tượng trực tiếp không an toàn - Kiểm soát truy cập bị hỏng trong ASP.NET Core

Như bạn có thể thấy từ màn hình trên, người dùng support@procodeguide.com có ​​thể truy cập bản ghi bài đăng từ dữ liệu thuộc về người dùng sanjay@procodeguide.com. vì vậy lỗi trên cho thấy rằng trang xem chi tiết bài đăng trong ứng dụng dễ bị tấn công và có thể bị khai thác bởi Tham chiếu đối tượng trực tiếp không an toàn.

Hãy xem cách chúng tôi có thể khắc phục lỗ hổng này liên quan đến Tham chiếu đối tượng trực tiếp không an toàn liên quan đến kiểm soát truy cập bị hỏng trong ASP.NET Core để đảm bảo rằng bất kỳ người dùng nào cũng không thể truy cập vào dữ liệu của người dùng khác.

Khắc phục các tham chiếu đối tượng trực tiếp không an toàn

Để khắc phục lỗ hổng tham chiếu đối tượng trực tiếp không an toàn này liên quan đến kiểm soát truy cập bị hỏng trong ASP.NET Core, chúng tôi sẽ giới thiệu một chính sách ủy quyền sẽ kiểm tra xem id người dùng của bài đăng được yêu cầu có giống với người dùng đã đăng nhập được xác thực yêu cầu những điều này không chi tiết bài đăng. Tức là Chúng tôi sẽ giới thiệu một chính sách ủy quyền sẽ không cho phép người dùng đã đăng nhập xem chi tiết bài đăng của những người dùng khác.

Thêm trình xử lý chính sách ủy quyền

Đầu tiên, thêm trình xử lý cho chính sách ủy quyền để khớp với id người dùng của bài đăng với người dùng đã đăng nhập.

Thêm các lớp bên dưới vào thư mục AuthorizationHandlers - AuthorizationHandlers \ IsPostOwnerRequirement.cs & AuthorizationHandlers \ PostOwnerAuthorizationHandler.cs

public class IsPostOwnerRequirement : IAuthorizationRequirement
{
    //empty class
}
public class PostOwnerAuthorizationHandler : AuthorizationHandler<IsPostOwnerRequirement, PostEntity>
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IsPostOwnerRequirement requirement, PostEntity resource)
    {
        if (context.User.FindFirst(ClaimTypes.NameIdentifier)?.Value == resource.CreatedBy)
        {
            context.Succeed(requirement);
        }
        else
        {
            context.Fail();
        }

        return Task.CompletedTask;
    }
}

Chính sách ủy quyền ở trên đang so sánh id người dùng của bài đăng với id người dùng của người dùng đã đăng nhập và nếu chúng khớp nhau thì chính sách đặt cờ thành công, nếu không chính sách đặt cờ là không thành công.

Đăng ký Trình xử lý Chính sách Cấp phép

Chúng tôi sẽ đăng ký các lớp của trình xử lý chính sách trong phần khởi động trong chức năng chính của tệp Program.cs. Chúng tôi sẽ thêm mã bên dưới để đăng ký trình xử lý chính sách trong chức năng chính.

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("IsPostOwnerPolicy", policy =>
        policy.Requirements.Add(new IsPostOwnerRequirement()));
});

builder.Services.AddSingleton<IAuthorizationHandler, PostOwnerAuthorizationHandler>();

Đoạn mã trên sẽ đăng ký chính sách ủy quyền như một dịch vụ trong vùng chứa tiêm phụ thuộc.

Sử dụng trình xử lý chính sách ủy quyền

Bây giờ chúng tôi đã xác định chính sách ủy quyền và cũng đã đăng ký giống như một dịch vụ khi khởi động, chúng tôi sẽ sử dụng chính sách này trong Bài đăng để bịt lỗ hổng tham chiếu đối tượng trực tiếp không an toàn. Chúng tôi sẽ cấu trúc lại tệp Services \ PostsService.cs để sử dụng chính sách ủy quyền. Chúng tôi đã thực hiện các thay đổi bên dưới đối với lớp PostService

public class PostsService : IPostsService
{
    IPostsRepository? _postRepository = null;
    private readonly IAuthorizationService _authorizationService;
    private readonly IHttpContextAccessor _httpContextAccessor;

    public PostsService(IPostsRepository postRepository, IAuthorizationService authorizationService,
        IHttpContextAccessor httpContextAccessor)
    {
        _postRepository = postRepository;
        _authorizationService = authorizationService;
        _httpContextAccessor = httpContextAccessor;
    }

    //Remaining code have been removed for readability


    public Post GetById(int id)
    {
        PostEntity postEntity = _postRepository.GetById(id);

        var authorizationResult = _authorizationService.AuthorizeAsync
            (_httpContextAccessor.HttpContext.User, postEntity, "IsPostOwnerPolicy");

        Post post = new Post();

        if (authorizationResult.Result.Succeeded)
        {
            post.Id = postEntity.Id;
            post.Title = postEntity.Title;
            post.CreatedOn = postEntity.CreatedOn;
            post.Description = postEntity.Description;
        }

        return post;
    }
}

Trong mã dịch vụ ở trên, chúng tôi đã đưa vào dịch vụ chính sách Ủy quyền và dịch vụ HttpContext để triển khai chính sách kiểm tra ủy quyền trong Dịch vụ bài đăng. HttpContext sẽ cung cấp cho chúng ta đối tượng cho người dùng đã đăng nhập.

Chạy & Kiểm tra Chính sách Cấp phép

Bây giờ, hãy xây dựng và chạy ứng dụng để xác minh xem chính sách ủy quyền mới được thêm vào có thể khắc phục lỗ hổng tham chiếu đối tượng trực tiếp không an toàn liên quan đến kiểm soát truy cập bị hỏng trong lõi ASP.NET hay không.

Chúng tôi sẽ kiểm tra cùng một kịch bản mà chúng tôi đã thảo luận trong kịch bản tấn công, chúng tôi sẽ đăng nhập bằng user support@procodeguide.com và cố gắng truy cập chi tiết bài đăng bằng đường dẫn URL Post / Details / 1 và điều này sẽ không trả lại bất kỳ dữ liệu nào theo mã chính sách ủy quyền mới được thêm vào.

Đã sửa lỗi tham chiếu đối tượng trực tiếp không an toàn - Kiểm soát truy cập bị hỏng trong ASP.NET Core

Như thể hiện trong hình trên, người dùng đã đăng nhập bây giờ không thể truy cập vào dữ liệu chi tiết bài đăng của người dùng khác.

Thiếu ủy quyền

Lỗ hổng này đề cập đến việc người dùng độc hại truy cập vào các hành động bị hạn chế do thiếu hoặc không đầy đủ cấu hình cho mã ủy quyền.

Hãy kiểm tra xem lỗ hổng này tồn tại như thế nào trong mã của chúng tôi và cách chúng tôi có thể sửa lỗ hổng cấu hình bị thiếu này liên quan đến kiểm soát truy cập bị hỏng trong ASP.NET Core bằng cách triển khai các kiểm soát truy cập thích hợp.

Kịch bản tấn công

Dưới đây là các bước về cách kẻ tấn công có thể truy cập vào trang Vai trò trong ứng dụng

1. Chạy ứng dụng và đăng nhập với tư cách người dùng sanjay@procodeguide.com
2. Vì sanjay@procodeguide.com là người dùng có vai trò quản trị viên nên menu Vai trò có sẵn cho người dùng này. Sử dụng trình đơn vai trò, quản trị viên có thể xem hoặc tạo một vai trò liên quan đến ứng dụng như hình bên dưới

Vai trò nhận dạng cốt lõi của ASP.NET

3. Đăng nhập tiếp theo bằng user support@procodeguide.com & bạn có thể thấy rằng vì người dùng này không phải là quản trị viên nên menu role không khả dụng cho người dùng này như được hiển thị trong màn hình bên dưới.

Ứng dụng web ASP.NET Core

4. Người dùng support@procodeguide.com không thể truy cập trang vai trò theo phân quyền được xác định trong ứng dụng nhưng bằng cách nào đó, người dùng này nắm được URL của trang vai trò và yêu cầu URL đó trực tiếp trong trình duyệt.
5. Sau khi người dùng yêu cầu URL thì chúng tôi nhận được màn hình bên dưới

Thiếu ủy quyền

Như bạn có thể thấy từ màn hình trên, mặc dù người dùng support@procodeguide.com không được phép nhưng vẫn có thể truy cập vào màn hình vai trò và tạo một vai trò mới.

Hãy để chúng tôi xem cách chúng tôi có thể khắc phục lỗ hổng này liên quan đến Thiếu hoặc không đầy đủ Cấu hình trong kiểm soát truy cập bị hỏng trong ASP.NET Core để đảm bảo rằng bất kỳ người dùng nào cũng không thể truy cập vào các hành động bị hạn chế.

Khắc phục việc thiếu ủy quyền

Để khắc phục lỗ hổng cấu hình bị thiếu này liên quan đến kiểm soát truy cập bị hỏng trong ASP.NET Core, chúng tôi sẽ giới thiệu một kiểm tra vai trò bị thiếu trong thuộc tính ủy quyền trong RoleController.cs.

Những gì chúng tôi đã phân tích là chúng tôi đã thêm thuộc tính ủy quyền trong RoleController và chúng tôi cũng đã thêm kiểm tra vai trò cho menu trong _Layout.cshtml nhưng chúng tôi đã bỏ lỡ đặc điểm kỹ thuật của vai trò Quản trị viên trong thuộc tính ủy quyền trong RoleController.cs

Thêm kiểm tra vai trò ủy quyền bị thiếu

Chúng tôi sẽ cấu trúc lại tệp Controllers \ RoleController.cs để thêm kiểm tra vai trò bị thiếu trong thuộc tính ủy quyền. Chúng tôi đã thực hiện các thay đổi sau đối với tệp RoleController.cs

[Authorize(Roles ="Administrator")]
public class RoleController : Controller
{
    //Remaining Code has been remove for readability
}

Bằng cách thêm cấu hình bị thiếu cho vai trò Quản trị viên trong thuộc tính ủy quyền trong RoleController.cs, chúng tôi chỉ định rằng tất cả các hành động trong RoleController chỉ được phép đối với người dùng có vai trò quản trị viên

Chạy và kiểm tra cấu hình ủy quyền

Bây giờ, chúng ta hãy xây dựng và chạy ứng dụng để xác minh xem cấu hình ủy quyền bị thiếu mới được thêm vào có thể sửa lỗ hổng ủy quyền bị thiếu liên quan đến kiểm soát truy cập bị hỏng trong lõi ASP.NET hay không.

Chúng tôi sẽ kiểm tra cùng một kịch bản mà chúng tôi đã thảo luận trong kịch bản tấn công mà chúng tôi sẽ đăng nhập với tên người dùng support@procodeguide.com và cố gắng truy cập URL vai trò và điều này sẽ không trả lại trang vai trò vì chúng tôi đã thêm sửa lỗi ủy quyền bị thiếu

Đã sửa lỗi thiếu quyền - Kiểm soát truy cập bị hỏng trong ASP.NET Core

Như thể hiện trong hình trên, người dùng support@procodeguide.com không có vai trò quản trị viên không thể truy cập vào trang vai trò để tạo và xem các vai trò.

Cấu hình sai CORS

Theo mặc định, trình duyệt thực hiện cùng một chính sách gốc nói rằng máy chủ không thể đưa ra yêu cầu đối với một miền khác với miền đang phân phát trang. Hạn chế này bảo vệ dữ liệu nhạy cảm khỏi các trang web có nguồn gốc độc hại.

Nhưng đôi khi cần phải ghi đè chính sách cùng nguồn gốc này và cho phép các miền khác truy cập API. Đây không phải là một tính năng bảo mật trên thực tế, nó làm giảm tính bảo mật của máy chủ bằng cách cho phép các miền khác truy cập vào API.

Cấu hình sai CORS liên quan đến kiểm soát truy cập bị hỏng trong ASP.NET Core theo cách mà khi bạn ghi đè chính sách cùng nguồn gốc thì bạn nên cẩn thận để chỉ cho phép các trang web được phép cụ thể thay vì cho phép tất cả các trang web để yêu cầu từ các trang khác các trang web được phép bị từ chối.

Bằng cách này, chúng tôi có quyền kiểm soát bảo mật tốt hơn bằng cách chỉ cho phép các trang web đáng tin cậy truy cập API và bằng cách hạn chế tất cả các trang web khác, chúng tôi ngăn các trang web độc hại truy cập vào API.

Nếu do nhầm lẫn bạn không định cấu hình CORS đúng cách, tức là nếu bạn định cấu hình sai CORS thì bạn đang tạo ra một lỗ hổng trong ứng dụng có thể bị kẻ tấn công khai thác để giành quyền truy cập vào API

Đoạn mã dưới đây sẽ ghi đè chính sách cùng nguồn gốc và cho phép truy cập vào tất cả các miền khác

app.UseCors(options => options.AllowAnyOrigin().AllowAnyMethod());

Cấu hình trên cho CORS để cho phép tất cả các phương thức và nguồn gốc nên tránh cho đến khi và trừ khi bạn đang làm việc trên một API công khai được sử dụng cho tất cả mọi người.

Dưới đây là mã chỉ định cấu hình miền được phép cụ thể để truy cập vào API

app.UseCors(options => options.WithOrigins("http://www.allowed-domain.com").AllowAnyMethod());

Về vấn đề bảo mật, bạn nên tuân theo quy tắc không có quyền truy cập theo mặc định và chỉ cho phép người dùng được ủy quyền truy cập vào các tài nguyên được yêu cầu.

Duyệt thư mục

Không nên cho phép duyệt thư mục trong ứng dụng ASP.NET Core, tức là nếu người dùng đã yêu cầu URL của một số đường dẫn thư mục thì danh sách các tệp có sẵn trong thư mục sẽ không được hiển thị trong trình duyệt.

Ví dụ: nếu người dùng yêu cầu URL của thư mục hình ảnh hoặc tập lệnh thì danh sách hình ảnh hoặc tập lệnh có sẵn trong thư mục sẽ không được hiển thị trực tiếp trong trình duyệt.

Bản tóm tắt

Chúng tôi đã tìm hiểu về các lỗ hổng nghiêm trọng trong kiểm soát truy cập bị hỏng trong lõi ASP.NET. Ngoài ra, chúng tôi đã đề cập đến cách kẻ tấn công có thể khai thác các lỗ hổng này và cách một nhà phát triển ASP.NET Core có thể xác định và giảm thiểu các lỗ hổng này liên quan đến kiểm soát truy cập bị hỏng trong ASP.NET Core.

Liên kết: https://procodeguide.com/programming/broken-access-control-in-aspnet-core/

#dotnet #apsdotnetcore #csharp #aspdotnet 

What is GEEK

Buddha Community

Kiểm Soát Truy Cập Bị Hỏng Trong ASP.NET Core: Mọi Thứ Bạn Cần Biết
Einar  Hintz

Einar Hintz

1602560783

jQuery Ajax CRUD in ASP.NET Core MVC with Modal Popup

In this article, we’ll discuss how to use jQuery Ajax for ASP.NET Core MVC CRUD Operations using Bootstrap Modal. With jQuery Ajax, we can make HTTP request to controller action methods without reloading the entire page, like a single page application.

To demonstrate CRUD operations – insert, update, delete and retrieve, the project will be dealing with details of a normal bank transaction. GitHub repository for this demo project : https://bit.ly/33KTJAu.

Sub-topics discussed :

  • Form design for insert and update operation.
  • Display forms in modal popup dialog.
  • Form post using jQuery Ajax.
  • Implement MVC CRUD operations with jQuery Ajax.
  • Loading spinner in .NET Core MVC.
  • Prevent direct access to MVC action method.

Create ASP.NET Core MVC Project

In Visual Studio 2019, Go to File > New > Project (Ctrl + Shift + N).

From new project window, Select Asp.Net Core Web Application_._

Image showing how to create ASP.NET Core Web API project in Visual Studio.

Once you provide the project name and location. Select Web Application(Model-View-Controller) and uncheck HTTPS Configuration. Above steps will create a brand new ASP.NET Core MVC project.

Showing project template selection for .NET Core MVC.

Setup a Database

Let’s create a database for this application using Entity Framework Core. For that we’ve to install corresponding NuGet Packages. Right click on project from solution explorer, select Manage NuGet Packages_,_ From browse tab, install following 3 packages.

Showing list of NuGet Packages for Entity Framework Core

Now let’s define DB model class file – /Models/TransactionModel.cs.

public class TransactionModel
{
    [Key]
    public int TransactionId { get; set; }

    [Column(TypeName ="nvarchar(12)")]
    [DisplayName("Account Number")]
    [Required(ErrorMessage ="This Field is required.")]
    [MaxLength(12,ErrorMessage ="Maximum 12 characters only")]
    public string AccountNumber { get; set; }

    [Column(TypeName ="nvarchar(100)")]
    [DisplayName("Beneficiary Name")]
    [Required(ErrorMessage = "This Field is required.")]
    public string BeneficiaryName { get; set; }

    [Column(TypeName ="nvarchar(100)")]
    [DisplayName("Bank Name")]
    [Required(ErrorMessage = "This Field is required.")]
    public string BankName { get; set; }

    [Column(TypeName ="nvarchar(11)")]
    [DisplayName("SWIFT Code")]
    [Required(ErrorMessage = "This Field is required.")]
    [MaxLength(11)]
    public string SWIFTCode { get; set; }

    [DisplayName("Amount")]
    [Required(ErrorMessage = "This Field is required.")]
    public int Amount { get; set; }

    [DisplayFormat(DataFormatString = "{0:MM/dd/yyyy}")]
    public DateTime Date { get; set; }
}

C#Copy

Here we’ve defined model properties for the transaction with proper validation. Now let’s define  DbContextclass for EF Core.

#asp.net core article #asp.net core #add loading spinner in asp.net core #asp.net core crud without reloading #asp.net core jquery ajax form #asp.net core modal dialog #asp.net core mvc crud using jquery ajax #asp.net core mvc with jquery and ajax #asp.net core popup window #bootstrap modal popup in asp.net core mvc. bootstrap modal popup in asp.net core #delete and viewall in asp.net core #jquery ajax - insert #jquery ajax form post #modal popup dialog in asp.net core #no direct access action method #update #validation in modal popup

Einar  Hintz

Einar Hintz

1602564619

MVC User Registration & Login with ASP.NET Core Identity

User registration and authentication are mandatory in any application when you have little concern about privacy. Hence all most all application development starts with an authentication module. In this article, we will discuss the quickest way to use **ASP.NET Core Identity for User Login and Registration **in a new or existing MVC application.

Sub-topics discussed :

  • How to add ASP.NET Core Identity to MVC application.
  • Customize ASP.NET Core Identity.
  • Identity.UI Design Customization.
  • Next step.

Background

ASP.NET Core Identity is an API, which provides both user interface(UI) and functions for user authentication, registration, authorization, etc. Modules/ APIs like this will really be helpful and fasten the development process. It comes with ASP.NET Core Framework and used in many applications before. Which makes the API more dependable and trustworthy.

ASP.NET Core MVC with user authentication can easily be accomplished using Identity.UI. While creating the MVC project, you just need to select Authentication as Individual User Accounts.

Showing how to create an MVC application with ASP.NET Core Identity API

The rest will be handled by ASP.NET Core Identity UI. It already contains razor view pages and backend codes for an authentication system. But that’s not what we want in most of the cases. we want to customize ASP.NET Core Identity as per our requirement. That’s what we do here.

Create an ASP.NET Core MVC Project

First of all, I will create a brand new ASP.NET Core MVC application without any authentication selected. We could add ASP.NET Core Identity later into the project.

In Visual Studio 2019, Go to File > New > Project (Ctrl + Shift + N). From new project window, select ASP.NET Core Web Application.

Create an ASP.NET Core Web application

Once you provide the project name and location. A new window will be opened as follows, Select _Web Application(Model-View-Controller), _uncheck _HTTPS Configuration _and DO NOT select any authentication method. Above steps will create a brand new ASP.NET Core MVC project.

Select Model View Controller templet under .NET Core

#asp.net core article #asp.net core #add asp.net core identity to existing project #asp.net core identity in mvc #asp.net core mvc login and registration #login and logout in asp.net core

AllowAnonymous in asp.net core

#Asp.net core #Asp.net core mvc #Core #Asp.net core tutorials #Asp.net core with entity framework

Authorization in asp.net core

#Asp.net core #Asp.net core mvc #Core #Asp.net core tutorials #Asp.net core with entity framework

Einar  Hintz

Einar Hintz

1602564706

Running WordPress on ASP.NET Core with Peachpie

In this article, you will learn how to use or integrate WordPress in ASP.NET and Running WordPress on ASP.NET Core, without PHP, or any source files on the server. The following demonstration will show you how to add WordPress as a frontend to an existing ASP.NET Core application step by step.

Running WordPress on NET Core

WordPress is a free, simplest, and most popular open-source content management system to create your own website or blog which is written in PHP and paired up with MySQL. WordPress on .Net Core is possible with peachpie, which is a compiler built on top of the Roslyn platform, it’s a set of runtime and base class libraries and everything that allows compiling a PHP project, a group of PHP files into a regular .net project.

Peachpie allows for seamless both-way interoperability between PHP and .NET applications. In simpler terms, this means that one can have some parts of an application written in PHP, while other modules are written in .NET and everything will work together as one application. Here is the original Repository of the WordPress SDK by PeachPie.

Here are the following steps to run WordPress with ASP.Net Core:-

Step1: Open your Visual Studio IDE and Create a new project – > ASP.NET Core Web Application

create new project | wordpress on asp.net core

Step 2: Select Web Application: A project template for creating an ASP.Net Core application with example ASP.Net Razor Pages Content.

#.net core #asp.net #wordpress asp.net core #wordpress on asp.net core #wordpress with asp.net core