Rate this post

Denial of Service (DoS) tập trung vào việc làm cho một tài nguyên (trang web, ứng dụng, máy chủ) không khả dụng cho mục đích mà nó được thiết kế. Có nhiều cách để làm cho một dịch vụ không khả dụng cho người dùng hợp pháp bằng cách thao túng các gói mạng, lập trình, logic hoặc xử lý tài nguyên trong các lỗ hổng bảo mật, trong số những cách khác. Nếu một dịch vụ nhận được một số lượng rất lớn các yêu cầu, nó có thể ngừng cung cấp cho những người dùng hợp pháp. Theo cách tương tự, một dịch vụ có thể dừng nếu một lỗ hổng lập trình bị khai thác hoặc cách dịch vụ xử lý tài nguyên mà nó sử dụng.

Các bài viết liên quan:

Đôi khi kẻ tấn công có thể đưa và thực thi mã tùy ý trong khi thực hiện tấn công DoS để truy cập thông tin quan trọng hoặc thực hiện các lệnh trên máy chủ. Các cuộc tấn công từ chối dịch vụ làm suy giảm đáng kể chất lượng dịch vụ của những người dùng hợp pháp. Các cuộc tấn công này gây ra độ trễ phản hồi lớn, tổn thất quá mức và gián đoạn dịch vụ, dẫn đến ảnh hưởng trực tiếp đến tính khả dụng.

Các yếu tố rủi ro

Các yếu tố rủi ro có thể chia thành nhiều loại. Hai nguồn rủi ro chính bao gồm nguồn lực không đủ và động cơ đe dọa phi kỹ thuật.

Ví dụ đầu tiên về yếu tố rủi ro, không đủ tài nguyên, cần được chú ý nếu kiến ​​trúc hệ thống không được thiết kế để đáp ứng sự tràn nhu cầu lưu lượng. Rủi ro này làm giảm khó khăn khi thực hiện thành công một cuộc tấn công DoS và có thể, không được kiểm tra, dẫn đến các triệu chứng DoS không có một cuộc tấn công thực sự.

Ví dụ thứ hai và có lẽ là yếu tố rủi ro lớn nhất không phải là yếu tố kỹ thuật và nằm trong lĩnh vực quan hệ công chúng hoặc truyền thông chiến lược. Một tổ chức nên tránh thực hiện hành động có thể khiến họ trở thành mục tiêu của một cuộc tấn công DoS trừ khi lợi ích của việc làm đó lớn hơn chi phí tiềm năng hoặc các biện pháp kiểm soát giảm thiểu được áp dụng.

Các yếu tố rủi ro khác cũng có thể tồn tại tùy thuộc vào môi trường cụ thể.

Các ví dụ

Các ví dụ và kỹ thuật DoS sau đây được trích xuất từ ​​Hướng dẫn kiểm tra OWASP v2.

Phân bổ đối tượng do người dùng chỉ định

Nếu người dùng có thể cung cấp, trực tiếp hoặc gián tiếp, một giá trị sẽ chỉ định số lượng đối tượng cần tạo trên máy chủ ứng dụng và nếu máy chủ không thực thi giới hạn trên cố định cho giá trị đó, thì có thể khiến môi trường chạy hết bộ nhớ khả dụng. Máy chủ có thể bắt đầu phân bổ số lượng đối tượng cần thiết được chỉ định, nhưng nếu đây là một số lượng cực lớn, nó có thể gây ra sự cố nghiêm trọng trên máy chủ, có thể lấp đầy toàn bộ bộ nhớ khả dụng và làm hỏng hiệu suất của nó.

Sau đây là một ví dụ đơn giản về mã dễ bị tấn công trong Java:

String TotalObjects = request.getParameter(“numberofobjects”);
int NumOfObjects = Integer.parseInt(TotalObjects);
ComplexObject[] anArray = new ComplexObject[NumOfObjects];  // wrong!

Đầu vào của người dùng DoS dưới dạng bộ đếm vòng lặp

Tương tự như vấn đề trước đây về Phân bổ đối tượng do người dùng chỉ định, nếu người dùng có thể trực tiếp hoặc gián tiếp chỉ định một giá trị sẽ được sử dụng làm bộ đếm trong hàm vòng lặp, điều này có thể gây ra sự cố hiệu suất trên máy chủ.

Sau đây là một ví dụ về mã dễ bị tấn công trong Java:

public class MyServlet extends ActionServlet {
   public void doPost(HttpServletRequest request, HttpServletResponse response)
          throws ServletException, IOException {
          . . .
          String [] values = request.getParameterValues("CheckboxField");
      // Process the data without length check for reasonable range – wrong!
          for ( int i=0; i<values.length; i++) {
                // lots of logic to process the request
         }
         . . .
   }
    . . .
}

Như chúng ta có thể thấy trong ví dụ đơn giản này, người dùng có quyền kiểm soát bộ đếm vòng lặp. Nếu mã bên trong vòng lặp đòi hỏi rất nhiều về tài nguyên và kẻ tấn công buộc nó phải được thực thi một số lần rất cao, điều này có thể làm giảm hiệu suất của máy chủ trong việc xử lý các yêu cầu khác, gây ra tình trạng DoS.

DoS không phát hành tài nguyên

Nếu một lỗi xảy ra trong ứng dụng ngăn cản việc phát hành tài nguyên đang được sử dụng, thì tài nguyên đó có thể không khả dụng để sử dụng tiếp. Các ví dụ có thể bao gồm:

  • Ứng dụng khóa tệp để ghi, sau đó xảy ra ngoại lệ nhưng không đóng và mở khóa tệp một cách rõ ràng
  • Rò rỉ bộ nhớ ở các ngôn ngữ mà nhà phát triển chịu trách nhiệm quản lý bộ nhớ, chẳng hạn như C & C ++. Trong trường hợp xảy ra lỗi khiến luồng logic bình thường bị phá vỡ, bộ nhớ đã cấp phát có thể không bị xóa và có thể được để ở trạng thái mà bộ thu gom rác không biết nó nên được lấy lại.
  • Sử dụng các đối tượng kết nối DB trong đó các đối tượng không được giải phóng nếu một ngoại lệ được ném ra. Một số yêu cầu lặp lại như vậy có thể khiến ứng dụng sử dụng tất cả các kết nối DB, vì mã sẽ vẫn giữ đối tượng DB đang mở, không bao giờ giải phóng tài nguyên.

Sau đây là một ví dụ về mã dễ bị tấn công trong Java. Trong ví dụ, cả Connection và CallableStatement phải được đóng trong một khối cuối cùng.

public class AccountDAO {
    … …
    public void createAccount(AccountInfo acct)
                 throws AcctCreationException {
       … …
           try {
            Connection conn = DAOFactory.getConnection();
            CallableStatement  calStmt = conn.prepareCall(…);
          …  … 
           calStmt.executeUpdate();
           calStmt.close();
          conn.close();
       }  catch (java.sql.SQLException e) {
            throw AcctCreationException (...);
       }
    }
}

DoS Buffer overflow

Bất kỳ ngôn ngữ nào mà nhà phát triển có trách nhiệm trực tiếp quản lý cấp phát bộ nhớ, đáng chú ý nhất là C & C ++, đều có khả năng xảy ra Tràn bộ đệm. Trong khi rủi ro nghiêm trọng nhất liên quan đến tràn bộ đệm là khả năng thực thi mã tùy ý trên máy chủ, rủi ro đầu tiên đến từ việc từ chối dịch vụ có thể xảy ra nếu ứng dụng bị treo.

Sau đây là một ví dụ đơn giản về mã dễ bị tấn công trong C:

void overflow (char *str) {
   char buffer[10];
   strcpy(buffer, str); // Dangerous!
}

int main () {
  char *str = "This is a string that is larger than the buffer of 10";
  overflow(str);
}

Nếu ví dụ mã này được thực thi, nó sẽ gây ra lỗi phân đoạn và kết xuất lõi. Lý do là strcpy sẽ cố gắng sao chép 53 ký tự vào một mảng chỉ gồm 10 phần tử, ghi đè lên các vị trí bộ nhớ liền kề. Trong khi ví dụ trên là một trường hợp cực kỳ đơn giản, thực tế là trong một ứng dụng dựa trên web có thể có những nơi mà người dùng nhập không được kiểm tra đầy đủ về độ dài của nó, khiến cho kiểu tấn công này có thể xảy ra.

DoS lưu trữ quá nhiều dữ liệu trong phiên

Cần phải cẩn thận để không lưu trữ quá nhiều dữ liệu trong một đối tượng phiên người dùng. Lưu trữ quá nhiều thông tin trong phiên, chẳng hạn như số lượng lớn dữ liệu được truy xuất từ ​​cơ sở dữ liệu, có thể gây ra sự cố từ chối dịch vụ. Vấn đề này càng trầm trọng hơn nếu dữ liệu phiên cũng được theo dõi trước khi đăng nhập, vì người dùng có thể khởi động cuộc tấn công mà không cần tài khoản.

DoS Khóa tài khoản khách hàng

Trường hợp DoS đầu tiên cần xem xét liên quan đến hệ thống xác thực của ứng dụng đích. Một biện pháp phòng thủ phổ biến để ngăn chặn việc phát hiện ra mật khẩu người dùng một cách thô bạo là khóa tài khoản để sử dụng sau từ ba đến năm lần đăng nhập không thành công. Điều này có nghĩa là ngay cả khi một người dùng hợp pháp cung cấp mật khẩu hợp lệ của họ, họ sẽ không thể đăng nhập vào hệ thống cho đến khi tài khoản của họ được mở khóa. Cơ chế phòng thủ này có thể được biến thành một cuộc tấn công DoS chống lại một ứng dụng nếu có một cách để dự đoán các tài khoản đăng nhập hợp lệ.

Lưu ý, có một sự cân bằng kinh doanh so với bảo mật phải đạt được dựa trên các trường hợp cụ thể xung quanh một ứng dụng nhất định. Có những ưu và nhược điểm đối với việc khóa tài khoản, để khách hàng có thể chọn tên tài khoản của riêng mình, sử dụng các hệ thống như CAPTCHA, v.v. Mỗi doanh nghiệp sẽ cần phải cân bằng giữa rủi ro và lợi ích, nhưng không phải tất cả các chi tiết của các quyết định đó đều được đề cập ở đây.

Leave a Reply

Call now
%d bloggers like this: