Trong vài năm trở lại đây, điện toán đám mây đã có những bước phát triển vô cùng mạnh mẽ, và dần nổi nên như một sự lựa chọn hàng đầu thay thế cho các biện pháp lưu trữ và xử lý dữ liệu truyền thống.
Cũng từ xu hướng phát triển này, các ứng dụng máy tính để bàn truyền thống hiện đã được bổ sung thêm giao diện Internet, hoặc thậm chí sở hữu cùng một phiên bản tương tự có sẵn trên đám mây, cách xử lý nó sẽ không còn khác biệt với các ứng dụng đám mây. Hiện nay, yếu tố bảo mật đối với ứng dụng máy tính để bàn truyền thống dần bị xem nhẹ. Trong khi trên thực tế, bảo mật ứng dụng máy tính để bàn nên được triển khai giống như ứng dụng đám mây.
Bảo mật ứng dụng máy tính để bàn nên được triển khai giống như ứng dụng đám mây.
Dưới đây là một số điểm yếu phổ biến nhất của ứng dụng máy tính để bàn trên bất kỳ nền tảng hệ điều hành nào:
- Dễ dàng trở thành mục tiêu của các cuộc tấn công brute force tự động sau khi tin tặc tiếp cận được với sách mật khẩu đã biết.
- Hacker nắm được quyền truy cập vào các mật khẩu yếu, dễ đoán hoặc thường được sử dụng phổ biến.
- Lưu trữ mật khẩu với văn bản đơn giản hoặc hàm băm (hash) yếu.
- Không có xác thực đa yếu tố (MFA).
- Vô hiệu phiên không hợp lệ khi đăng xuất hoặc sau thời gian chờ.
Nếu bạn triển khai MFA (xác thực đa yếu tố) cho ứng dụng của mình, kẻ tấn công sẽ không thể hoàn thành các bước MFA một cách kịp thời và tự động, từ đó giúp ngăn ngừa từ xa các cuộc tấn công nhồi thông tin xác thực cũng như brute force.
Đối với mật khẩu, hãy sử dụng danh sách mật khẩu chung để phát hiện và xác minh các mật khẩu yếu hoặc phổ biến, kết hợp với việc sử dụng thuật toán băm mạnh mẽ cho mật khẩu người dùng. Hạn chế đến mức tối đa việc sử dụng các hàm băm yếu như MD5. Đồng thời không nên lưu trữ mật khẩu của bạn trong các văn bản đơn giản.
Ngoài ra, bạn cũng nên chú ý tới các thông báo lỗi đăng nhập mơ hồ, có chủ ý khi một người nhập tên tài khoản hoặc mật khẩu không chính xác. Nếu không, kẻ gian có thể sử dụng yếu tố này để kích hoạt các cuộc tấn công, từ đó “mò” ra một tài khoản hợp lệ.
Một số phương thức giúp ngăn chặn việc dữ liệu nhạy cảm bị đánh cắp từ một ứng dụng bao gồm:
- Đảm bảo rằng lưu lượng truy cập web được mã hóa đầy đủ, được gửi qua HTTPS với chứng chỉ SSL hợp lệ và được cập nhật khi có thể kết nối không an toàn.
- Yêu cầu Encrypt (letencrypt.org) cấp chứng chỉ SSL miễn phí nhằm đảm bảo lưu lượng truy cập web liền mạch và an toàn.
- Mã hóa và ký cookie trình duyệt có chứa thông tin nhạy cảm.
- Xóa bỏ dữ liệu nhạy cảm khi không còn cần thiết.
- Các mật khẩu sử dụng thuật toán băm mạnh.
- Mã hóa toàn bộ dữ liệu bí mật, có giá trị cao.
Ngăn chặn lỗ hổng SQL Injection
SQL Injection là một trong những kiểu hack web bằng cách inject các mã SQL query/command vào input trước khi chuyển cho ứng dụng web xử lí, bạn có thể login mà không cần username và password, remote execution (thực thi từ xa), dump data và lấy root của SQL server. Công cụ dùng để tấn công là một trình duyệt web bất kì, chẳng hạn như Internet Explorer, Netscape, Lynx,...
Ngay cả khi đã sử dụng công nghệ mã hóa cơ sở dữ liệu tự động, nếu một cuộc tấn công SQL Injection được triển khai thành công, dữ liệu phải được đọc và mã hóa ở cấp cơ sở. Bước mã hóa/giải mã nên được thực hiện như một phần của logic ứng dụng cốt lõi, giúp ngăn chặn hậu quả từ các cuộc tấn công SQL Injection.
Kiểm soát truy cập
Kiểm soát truy cập là yếu tố quan trọng trong bảo mật ứng dụng
Nếu một ứng dụng được trang bị khả năng phân biệt người dùng dựa trên các đặc quyền hoặc cấp phép truy cập, điều này có thể mở ra một lỗ hổng trong kiểm soát truy cập, từ đó làm gia tăng các quyền mà kẻ tấn công không nên có. Một số ví dụ bao gồm:
- Không thể ngăn chặn quyền truy cập vào các trang “chỉ dành cho thành viên” (Members Only) khi người dùng chưa đăng nhập hoặc không sở hữu quyền thích hợp để xem trang.
- Không xác thực các tham số URL có thể sửa đổi người dùng (chẳng hạn như trao đổi ID từ người dùng này sang người dùng khác)
- Tin tưởng rằng giá trị của cookie không bị thay đổi khi được sử dụng để xác định vai trò của người dùng. Bằng cách xác minh cả mã hóa cookie và chữ ký, bạn có thể tin tưởng rằng giá trị không thay đổi.
Điều quan trọng khác là xác minh và chú ý đến quyền của người dùng. Đừng nên đặt nhiều niềm tin đối với dữ liệu đầu vào mà người dùng có thể thay đổi nếu muốn.
Khi gặp lỗi với cấu hình bảo mật, các mối quan tâm chính trong trường hợp này bao gồm:
- Các bản vá bảo mật lỗi thời trên hệ thống máy chủ.
- Bảo mật framework ứng dụng không được kích hoạt, hoặc bị cấu hình không chính xác.
- Tài khoản, mật khẩu và khóa bảo mật mặc định vẫn hợp lệ hoặc không thay đổi.
- Cổng không được sử dụng hoặc tắt theo mặc định, dịch vụ vẫn được bật trên hệ thống máy chủ.
Việc đảm bảo rằng các bản vá bảo mật trên hệ thống máy chủ đang chạy ứng dụng đã được cập nhật với phiên bản mới nhất, và các tính năng bảo mật thích hợp của framework ứng dụng đã được kích hoạt là vô cùng quan trọng. Bên cạnh đó, bạn cũng nên đảm bảo rằng key bảo mật riêng tư (private key) của nền tảng bên thứ ba không được upload lên nhà cung cấp kiểm soát nguồn, đặc biệt nếu ứng dụng là nguồn mở. Chúng có thể được dễ dàng bị kẻ tấn tiếp cận thông qua một công cụ quét tự động.
Trong trường hợp này, tốt nhất bạn nên lưu trữ các private key riêng biệt hoàn toàn với mã nguồn.
Sử dụng các phần mềm chứa lỗ hổng liên tục trong thời gian dài
Các phần mềm hiện đại ngày nay có xu hướng sử dụng rất nhiều thành phần của bên thứ ba, do đó, việc cập nhật ứng dụng cũng như các thành phần của ứng dụng lên phiên bản mới nhất đóng vai trò tiên quyết trong việc phòng ngừa các cuộc tấn công phát sinh hoặc lỗ hổng bảo mật đã biết. Thật không may, số lượng thành phần phụ thuộc lớn của ứng dụng đôi khi cũng gây khó khăn cho việc xác định và xử lý các thành phần dễ bị tổn thương, cho dù là trực tiếp hay gián tiếp.
Giám sát và ghi nhật ký
Giám sát và ghi nhật ký là tác vụ bắt buộc trong bảo mật ứng dụng
Khả năng phát hiện vi phạm, kiểu tấn công và hoạt động của người dùng là những thuộc tính chính và gần như bắt buộc phải có trong mọi quy trình bảo vệ hệ thống. Nếu không sở hữu đủ các tính năng ghi nhật ký và giám sát ứng dụng, sẽ rất khó để xác định xem hệ thống đã bị xâm phạm hay chưa, xâm phạm như thế nào, nguồn gốc của nó ra sao, điểm bắt đầu và vị trí của lỗ hổng trong chiến lược bảo mật ứng dụng. Rất đơn giản, nếu bạn không biết rõ lỗ hổng ở đâu, bạn sẽ không thể vá được nó!