Đối với mọi regex 'ác', có tồn tại một sự thay thế không xấu xa, hay là ma quỷ trong ngữ pháp?

Rõ ràng, các cuộc tấn công ReDos khai thác các đặc điểm của một số biểu thức chính quy (nếu không hữu ích) ... về cơ bản gây ra sự bùng nổ các đường dẫn có thể thông qua biểu đồ được xác định bởi NFA.

Có thể tránh những vấn đề như vậy bằng cách viết một biểu thức tương đương 'không xấu xa' không? Nếu không (do đó, ngữ pháp không thể được xử lý trong không gian / thời gian thực tế bằng NFA), phương pháp phân tích cú pháp nào sẽ tốt hơn? Tại sao?

Nó phụ thuộc vào việc bạn có biểu hiện chính quy hay biểu thức chính quy: biểu thức chính là xấu, nhưng biểu thức chính quy là một điều hay và sẽ không bao giờ trở thành xấu xa đối với bạn.

Theo regrec, tôi có nghĩa là một biểu thức chính quy hiện đại: nghĩa là một biểu thức chính quy với các tính năng hiện đại bổ sung như phản hồi - ví dụ: biểu thức chính quy tương thích Perl. Điều này mạnh hơn một biểu thức chính quy cổ điển từ sách giáo khoa lý thuyết / ngôn ngữ chính thức, vì các biểu thức chính quy cổ điển không cho phép phản hồi, nhìn, nhìn, v.v.

$n$$O(n)$

Điều này không phụ thuộc vào việc thực hiện trình so khớp biểu thức chính quy. Nếu bạn có một triển khai trình so khớp ngây thơ hoặc kém, thì việc khớp có thể mất thời gian theo cấp số nhân; chắc chắn có các thuật toán với tài sản đó. Nhưng câu trả lời tốt nhất cho điều đó có lẽ là không thay đổi biểu thức chính quy; Có lẽ tốt hơn để chọn một công cụ đối sánh tốt hơn, nếu bạn lo ngại về các cuộc tấn công từ chối dịch vụ.

Trong so sánh, một số regexps hiện đại là không thể tránh khỏi cái ác. Nếu bạn có một biểu thức chính quy hiện đại, thì kết hợp có thể yêu cầu thời gian theo cấp số nhân. Cụ thể, biểu thức chính quy với phản hồi có thể nhận ra ngôn ngữ NP-hard. Do đó, theo các giả định hợp lý, tồn tại một lớp các biểu thức xấu xa trong đó việc kiểm tra một trận đấu mất thời gian theo cấp số nhân. Do đó, một số biểu thức hiện đại là không thể tránh khỏi sự xấu xa: không có cách nào khả thi để tìm một biểu thức chính quy tương đương mà sẽ không gây ra sự bùng nổ theo cấp số nhân trong thời gian chạy.

(Một lý thuyết tương đương như vậy có thể tồn tại và thậm chí có thể tìm thấy trên lý thuyết, nhưng theo các giả định hợp lý, việc tìm ra biểu thức chính quy tương đương sẽ mất thời gian theo cấp số nhân, điều này không khả thi trong thực tế. Nếu bạn có một quy trình có hệ thống để tìm ra biểu thức tương đương trong thời gian đa thức , sau đó bạn có thể giải quyết vấn đề NP-hard trong thời gian đa thức, chứng minh rằng P = NP. Sẽ không có ích gì khi tồn tại một regrec tương đương nếu không có cách nào thực sự tìm thấy nó trong suốt cuộc đời của bạn.)

Bối cảnh và nguồn:

• Những ngôn ngữ nào biểu thức chính quy tương thích Perl nhận ra? và Tính biểu cảm của các biểu thức chính quy hiện đại cung cấp các tham chiếu để chứng minh rằng các biểu thức chính hiện đại có thể nhận ra các ngôn ngữ NP-hard.

• Làm thế nào để mô phỏng backreferences, lookahead và lookbehinds trong trạng thái automata hữu hạn? và Khi biểu thức chính quy không phải là Biểu thức chính quy? có thể hữu ích để hiểu sự khác biệt giữa biểu thức chính quy và biểu thức chính quy.

• Bài viết này của Russ Cox có một lời giải thích hay về hai cách khác nhau để xây dựng một trình so khớp biểu thức chính quy và giải thích tại sao thời gian chạy nếu bạn sử dụng thuật toán thích hợp là tuyến tính theo độ dài của chuỗi đầu vào (khi biểu thức chính quy được giữ cố định và chiều dài của nó được coi là một hằng số). Cụ thể, thuật toán dựa trên NFA - còn được gọi là thuật toán Thompson - có thời gian chạy trường hợp xấu nhất tuyến tính. Nó cũng cho thấy một số ngôn ngữ phổ biến có triển khai regex có thể đi theo cấp số nhân trên một số biểu thức chính và nó thảo luận về khía cạnh nào của biểu thức chính hiện đại có thể giới thiệu thời gian chạy theo cấp số nhân.

• Trong bài này tôi giả sử P! = NP. Hơn nữa, khi tôi đề cập đến "các giả định hợp lý", tôi đang đề cập đến giả thuyết thời gian theo cấp số nhân .

Câu trả lời này sẽ có cái nhìn bao quát hơn về tình huống giao thoa bất thường này, trong đó lý thuyết phức tạp được áp dụng cho an ninh mạng và ví dụ này chứa một số sắc thái / sự tinh tế đáng kể có thể xảy ra trong lĩnh vực này. Điều này về cơ bản tương tự như một "cuộc tấn công tiêm chích" trong đó một số yếu tố đầu vào bất ngờ gây ra hành vi bệnh lý hoặc làm sập hệ thống hoặc khiến nó mất nhiều thời gian bất thường.

Wikipedia có 15 loại tấn công từ chối dịch vụ và cuộc tấn công này rơi vào "lũ cấp ứng dụng" trong danh sách đó. Một ví dụ khác có phần tương tự là một cuộc tấn công lấp đầy nhật ký ứng dụng.

Một cách khắc phục cho các cuộc tấn công tiêm là "làm sạch đầu vào". Nhà thiết kế ứng dụng có thể đánh giá lại nếu cần thiết phải biên dịch các biểu thức tùy ý được cung cấp bởi người dùng có khả năng gây hại. Chỉ cần tước bỏ các biểu thức lồng nhau trong biểu thức chính quy hoặc một số giới hạn tương tự khác có lẽ là đủ để tránh cuộc tấn công này. Mặc dù chúng là bản chất của rất nhiều phần mềm hiện đại, một lượng lớn chức năng có thể được cung cấp mà không cần đánh giá các biểu thức thông thường. Các vấn đề bối cảnh, một số ứng dụng sẽ không yêu cầu bảo mật như vậy.

Một cách tiếp cận khác để cải thiện khả năng chịu lỗi / khả năng phục hồi được áp dụng ở đây là thời gian chờ được chỉ định ở các cấp khác nhau của ngăn xếp / phân cấp phần mềm. Ý tưởng sẽ là chỉ định giới hạn thời gian / cpu hoặc hướng dẫn trong đánh giá biểu thức chính quy "trung bình" và chấm dứt sớm nếu vượt quá. Chúng có thể được thực hiện với các giải pháp tùy chỉnh nhưng không có nhiều phần mềm hoặc ngôn ngữ lập trình có thời gian chờ tích hợp hoặc khung cho mục đích này.

Dưới đây là một ví dụ hay về việc sử dụng thời gian chờ để cải thiện khả năng chịu lỗi và hiển thị thiết kế / kiến ​​trúc / POV ở mức độ cao để giảm thiểu các vấn đề như vậy: Dung sai lỗi trong khối lượng lớn, Hệ thống phân tán / Netflix. Nó không có gì liên quan cụ thể đến các biểu thức thông thường nhưng đó là điểm chính ở đây: hầu như bất kỳ / tất cả logic cấp độ ứng dụng có thể phù hợp với khung này hoặc một cái gì đó tương tự.

Bài viết này chỉ ra cách quay lại cụ thể có thể dẫn đến kết hợp regrec chậm. Regexps có nhiều tính năng khác nhau và người ta có thể cố gắng đánh giá cái nào dẫn đến hành vi xấu nhất.

Dưới đây là một khảo sát khoa học tốt đẹp về chủ đề cụ thể này với (các) giải pháp phân tích tĩnh được đề xuất:

• Phân tích tĩnh cho thời gian chạy biểu thức theo hàm mũ thông thường thông qua các logic logic cấu trúc / Rathnayake, Thielecke

  Kết hợp biểu thức chính quy bằng cách sử dụng quay lui có thể có thời gian chạy theo cấp số nhân, dẫn đến một cuộc tấn công phức tạp thuật toán được gọi là REDoS trong tài liệu bảo mật hệ thống. Trong bài báo này, chúng tôi xây dựng trên một phân tích tĩnh được công bố gần đây để phát hiện xem một biểu thức chính quy đã cho có thể có thời gian chạy theo cấp số nhân cho một số đầu vào hay không. Chúng tôi xây dựng một cách có hệ thống một phân tích chính xác hơn bằng cách hình thành các quyền hạn và sản phẩm của các mối quan hệ chuyển đổi và do đó làm giảm vấn đề REDoS thành khả năng tiếp cận. Tính chính xác của phân tích được chứng minh bằng cách sử dụng phép tính cấu trúc của các cây tìm kiếm, trong đó sự phân nhánh của cây gây ra hiện tượng nổ theo cấp số nhân được đặc trưng như một dạng phi tuyến tính.