Cập nhật phân tích khả năng bất khả xâm phạm của Koa.js

Nov 26 2022

Cách đây không lâu, tôi đã viết về một lỗ hổng ảnh hưởng đến Koa.js vào năm 2018.

Cách đây không lâu, tôi đã viết về một lỗ hổng ảnh hưởng đến Koa.js vào năm 2018. Tôi đã rất thất vọng vì phải xử lý một vấn đề từ năm 2018 trong khi ngày là năm 2022 và tôi đang sử dụng phiên bản Koa mới nhất. 4 năm đã trôi qua. Đó là một thời gian dài. Chắc chắn vấn đề không còn nữa!? Và nó đã và không cùng một lúc. Điều đó có nghĩa là tôi đã sai và đúng cùng một lúc. Vì vậy, đây là bản cập nhật cho bài viết trước để cho bạn biết cách thực hiện:

Tôi đã cáo buộc sai Sonatype và Dependency Track không hoạt động với thông tin phiên bản trong các trường hợp cụ thể
Tôi có thể đúng và sai cùng một lúc về một lỗ hổng

Chỉ mục OSS có Thông tin Phiên bản

Nếu bạn đã đọc bài viết trước của tôi, bạn có thể nhớ rằng tôi đã kết luận rằng vấn đề không ảnh hưởng đến tôi. Tin tốt là tôi đã đúng. Tin xấu là tôi đã buộc tội sai Sonatype về việc không có số phiên bản trong dữ liệu do Chỉ mục OSS cung cấp để Theo dõi phụ thuộc hoạt động. Hóa ra họ có thông tin. Nó chỉ không hiển thị ở nơi mà tôi mong đợi nó sẽ hiển thị. Xem ảnh chụp màn hình bên dưới được chụp vào ngày 22/11/2022.

Thiếu thông tin về các phiên bản bị ảnh hưởng

Rất có khả năng Theo dõi phụ thuộc (DT) không hoạt động chính xác với những gì được hiển thị trên trang ở trên, nhưng tôi không quan tâm đến việc kiểm tra xem dữ liệu mà DT tìm nạp từ Chỉ mục OSS trông như thế nào. DT chỉ hiển thị một liên kết đến Chỉ mục OSS, nơi tôi có thể tìm hiểu thêm. Tôi đã nhấp và hạ cánh trên trang này.
Hôm nay Sonatype đã thông báo cho tôi rằng số phiên bản đã có sẵn; Tôi phải tìm nơi khác. Thật vậy, nếu bạn đăng nhập vào tài khoản của mình và tìm kiếm Koa hoặc nhấp vào nút “Xem chi tiết về koa” trong ảnh chụp màn hình ở trên, thì bạn có thể tìm thấy nó. Xem ảnh chụp màn hình bên dưới.

Koa theo phiên bản và bộ đếm lỗ hổng cơ bản

Vì vậy, tôi đã sai. Sonatype có thông tin trong cơ sở dữ liệu. Sau đó, vấn đề là với lớp trình bày. Sẽ tốt hơn nếu họ liệt kê các phiên bản bị ảnh hưởng trên trang nơi lỗ hổng thực sự được thảo luận để chúng tôi có thể xem và xác minh nếu cần.

Tôi đã buộc tội nhầm Sonatype OSS Index không có thông tin phiên bản. Tôi cũng đã cáo buộc sai Theo dõi phụ thuộc sẵn sàng báo cáo hoàn toàn dựa trên tên phụ thuộc nếu không có thông tin phiên bản. (Tôi vẫn cần tìm hiểu xem điều sau là đúng hay sai, tôi đã không kiểm tra.)

Đừng bỏ cuộc! Những điều thú vị hơn để thảo luận là lỗ hổng thực tế và (hy vọng là) những thay đổi sắp tới đối với báo cáo lỗ hổng trong Chỉ mục OSS. Hãy bắt đầu với lỗ hổng.

Tập lệnh chéo trang

Sonatype gán XSS cho Koa dựa trên quá trình suy nghĩ dưới đây.

Koa là thực thể đang ghi URL vào phản hồi HTML, không phải nhà phát triển sử dụng Koa

Hoàn toàn hợp lý khi mong đợi nhà phát triển xác thực URL được cung cấp, có khả năng dựa trên danh sách cho phép, để ngăn chuyển hướng mở chứ không phải Koa vì Koa sẽ không biết bạn muốn cho phép hay không cho phép URL nào. Tuy nhiên, với tư cách là nhà phát triển, tôi không nghĩ mình phải lo lắng về việc thực hiện khử trùng XSS cho một URL mà tôi đang chuyển sang phương thức redirect().

Koa dường như quan tâm đến XSS trong bối cảnh này vì họ đã có mã ở đó để ngăn chặn nó, thực thể HTML mã hóa URL khi họ ghi nó vào HTML

Tôi đồng ý ở một mức độ nào đó. Tôi không đồng ý với điều sau đây, chẳng hạn.

Tôi không nghĩ rằng mình phải lo lắng về việc làm sạch XSS cho một URL mà tôi đang chuyển sang phương thức redirect()

Nếu bạn chuyển một URL an toàn, hợp lệ tới một phương thức chuyển hướng mà bạn (nhà phát triển) đã cung cấp, thì bạn không phải lo lắng về XSS (rõ ràng). Nếu bạn chuyển toàn bộ hoặc một phần dữ liệu do người dùng cung cấp, đó là điều bạn luôn phải lo lắng, cho dù bạn là nhà phát triển hay chuyên gia bảo mật. Tuy nhiên, không quá xa vời khi mong đợi Koa giúp đỡ nhà phát triển.

Hãy để tôi đưa cho bạn một ví dụ tuyệt vời mà hy vọng sẽ giúp bạn hiểu tôi đến từ đâu. Trong ví dụ bên dưới, tôi chuyển dữ liệu do người dùng cung cấp trở lại trình duyệt trong phần nội dung phản hồi. Tôi làm điều này mà không cần bất kỳ xác thực, khử trùng hoặc mã hóa nào.

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.body = ctx.query.payload;
});

app.listen(4444);

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=<img%20src=x%20onerror=alert(1)> HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 28
< Date: Wed, 23 Nov 2022 10:59:17 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
<img src=x onerror=alert(1)>%

Hãy suy nghĩ về những gì và cách tôi chuyển đến trình duyệt trong nội dung phản hồi
Xem xét (và có lẽ tốt nhất là kiểm soát rõ ràng!) giá trị của tiêu đề Kiểu nội dung cho phản hồi
Biết rằng Koa, theo mặc định, tự động điều chỉnh giá trị của tiêu đề Loại nội dung dựa trên giá trị được chuyển đến ctx.body. (Ví dụ aaa, hãy thử chuyển vào và xem nó thay đổi như thế nào)

Xem xét ctx.bodyví dụ “XSS” ở trên, có vẻ như chúng tôi đang đổ lỗi cho Koa vì đã thực hiện các biện pháp cụ thể để ngăn chặn thảm họa khi sử dụng ctx.redirect(). Trích dẫn Sonatype một lần nữa:

Koa dường như quan tâm đến XSS trong bối cảnh này vì họ đã có mã ở đó.

Điều này có nghĩa là nếu Koa không quan tâm đến XSS trong bối cảnh này, tương tự như cách họ không (và không nên) quan tâm đến nó khi nói đến ctx.body, thì sẽ không ai đánh dấu nó là lỗ hổng XSS? Điều đó khá hài hước. Tôi nhận thấy một số điểm tương đồng với phân tích trước đây của tôi về Formidable được ghi lại ở đây và ở đây .

Như đã nói bất cứ điều gì tôi đã nói cho đến nay, một XSS tình cờ ở đó… và không phải cùng một lúc. Làm thế nào là có thể? Giản dị! Nó ở đó, nhưng bạn không thể khai thác nó trừ khi:

Nạn nhân sử dụng một trình duyệt web cũ, VÀ
Có một chuyển hướng mở do nhà phát triển triển khai bằng cách sử dụng ctx.redirect()AND của Koa
Nhà phát triển hoàn toàn tin tưởng vào tất cả dữ liệu do người dùng cung cấp và chuyển nó nguyên văn choctx.redirect()

Trang báo cáo của Sonatype cho biết như bạn có thể thấy từ ảnh chụp màn hình ngày hôm nay, “Mở chuyển hướng dẫn đến Cross-Site Scripting”. Bài đăng trước của tôi đã đặt câu hỏi về phần "chuyển hướng mở":

Trước hết, không có chuyển hướng mở. Nó chỉ mở nếu bạn mở nó và sự khác biệt giữa hai PoC (bản gốc và của tôi) cho thấy rõ điều này.

Sonatype cũng đồng ý rằng Koa không chịu trách nhiệm ngăn chặn các chuyển hướng mở. Mối quan tâm chính của họ, mối quan tâm của tôi và mọi người khác là XSS. Bắt liên quan đến chuyển hướng mở chỉ là khó hiểu. Đồng thời, nó không phải là vô lý về mặt kỹ thuật, như chúng ta sẽ thấy sau. (Nó cũng sẽ ảnh hưởng đến việc chấm điểm lỗ hổng.)

Như đã đề cập trước đó, việc khai thác thành công hành vi của Koa yêu cầu chuyển hướng mở. Nhưng mà:

Koa không chịu trách nhiệm ngăn chặn các chuyển hướng mở (như đã kết luận trước đó)
Koa sẽ không thực thi ctx.redirect()nếu không có sự cho phép của nhà phát triển
Koa không buộc các nhà phát triển sử dụng chuyển hướng

Vì vậy, có một lớp bảo vệ khác: các trường hợp sử dụng. Khả năng một nhà phát triển không muốn kiểm soát nơi trình duyệt được chuyển hướng là bao nhiêu? Rất khó xảy ra. Điều này có nghĩa là rất có thể các nhà phát triển sẽ chuyển dữ liệu do người dùng kiểm soát để ctx.redirect()nối vào một đoạn chuỗi khác. Vì vậy, điều gì đó tương tự như các ví dụ được hiển thị bên dưới có nhiều khả năng xảy ra nhất:

ctx.redirect(`http://website.example.org/search?q=${userInput}`);
ctx.redirect(`/search?topic=${userInput}`);

Điểm dễ bị tổn thương

Phải có ba (3) điều kiện đáp ứng để lỗi có thể bị khai thác, như đã thảo luận ở cuối phần trước.

Phiên bản trình duyệt nào được sử dụng tùy thuộc vào người dùng cuối
Việc sử dụng phương pháp chuyển hướng và cách sử dụng tùy thuộc vào nhà phát triển

Điều cũng cần nhấn mạnh là việc sử dụng phương pháp chuyển hướng theo cách không an toàn là vectơ tấn công. Một vectơ tấn công là cần thiết để khai thác thành công. Koa không cung cấp vectơ tấn công; nhà phát triển làm.

Hãy tương quan điều này với định nghĩa về “Lỗ hổng phần mềm” do NIST cung cấp:

https://csrc.nist.gov/glossary/term/software_vulnerability

Phần tôi muốn nhấn mạnh là “có thể bị khai thác”. Lấy Koa làm thư viện phần mềm. Bạn có thể khai thác nó mà không cần tạo vectơ tấn công cần thiết trước không? Không. Vì vậy, từ quan điểm của Koa, một thư viện phần mềm, không có vectơ tấn công nào được trình bày; không có điều đó, việc khai thác là không thể. Nếu chúng tôi giải thích định nghĩa một cách chặt chẽ (mà tôi làm), chúng tôi không thể gọi hành vi của Koa là một lỗ hổng.
Hãy thử tính điểm CVSS mà không cần vectơ tấn công:

Tính điểm CVSS không có vectơ tấn công

Không có điểm nếu không có vectơ tấn công. Tôi muốn nói rằng điều này phù hợp với định nghĩa về Lỗ hổng phần mềm do NIST cung cấp.
Hãy thử nghiệm và tạo ra một kịch bản tưởng tượng có tồn tại véc tơ tấn công.

Vectơ tấn công hư cấu

Vẫn còn một số vấn đề ở đây, ngoài vectơ tấn công tưởng tượng. Độ phức tạp của cuộc tấn công được đặt thành Cao vì việc khai thác thành công yêu cầu một trình duyệt cũ. Kẻ tấn công phải thuyết phục nạn nhân tải xuống và cài đặt một trình duyệt cũ.
Theo nghĩa đó, Tương tác của người dùng là bắt buộc, mặc dù các số liệu cơ sở về Tương tác của người dùng không thực sự nói về điều đó. Trong trường hợp này, việc khai thác XSS có yêu cầu tương tác của người dùng hay không tùy thuộc vào cách Ứng dụng web sử dụng chuyển hướng chứ không phải trên Koa. Điều đáng nói nữa là JavaScript được đưa vào sẽ không tự thực thi vì nó yêu cầu tương tác của người dùng ngay từ đầu: nhấp vào liên kết trong phản hồi HTML.

Vì vậy, những gì chúng ta có thể làm để buộc điểm dễ bị tổn thương về điều này? Chúng ta phải chọn một cái gì đó. Mơ tưởng, giả định điều tồi tệ nhất, bất cứ điều gì bạn thích. Có một điều chắc chắn là bạn đang thực hiện một phép tính mà ngay từ đầu bạn không được phép làm, và kết quả khác xa với thực tế đến mức tôi thậm chí không thể tìm ra từ ngữ để diễn tả nó.

Điều quan trọng tiếp theo là Số liệu tác động. Bạn phải biết Ứng dụng web sắp nói lên tác động gì. Nhưng chúng tôi không tính toán điểm dễ bị tổn thương cho Ứng dụng web... Dựa vào ngữ cảnh, XSS này không ảnh hưởng đến Koa. Koa không tự xử lý hoặc xử lý thông tin bí mật. Lỗi này không ảnh hưởng đến tính khả dụng hoặc tính toàn vẹn. Điều đó để lại cho chúng tôi số điểm cuối cùng là 0,0, ngay cả sau khi buộc một vectơ tấn công vào tính toán.

Vì vậy, câu hỏi là, chúng ta báo cáo sự thật hay hư cấu?

Sonatype đã lưu ý đến tôi hướng dẫn chính thức về Chấm điểm lỗ hổng trong Thư viện phần mềm , được phát hành vào năm 2019 cùng với CVSSv3.1. Tôi thừa nhận rằng tôi không biết về nó, điều đó vừa tốt vừa xấu. Tốt vì nó có thể dẫn đến một bài viết chỉ trích, tệ vì có lẽ nếu tôi nhìn thấy nó sớm hơn, tôi đã mất hết hy vọng trước khi tôi nỗ lực hết sức để giải thích rằng đó không phải là cách đúng đắn để giải quyết vấn đề đó. Vì vậy, hướng dẫn chính thức nói gì?

Khi chấm điểm tác động của lỗ hổng bảo mật trong thư viện… Nhà phân tích nên chấm điểm cho tình huống triển khai hợp lý trong trường hợp xấu nhất. Khi có thể, thông tin CVSS nên trình bày chi tiết các giả định này.

Vì vậy, câu trả lời là việc chấm điểm lỗ hổng dựa trên hư cấu.

Ngoài ra, " kịch bản triển khai hợp lý trong trường hợp xấu nhất" là gì? Nếu chúng tôi phân tích nhiều dự án đã sử dụng Koa và nhận thấy rằng hầu hết các nhà phát triển đã triển khai chuyển hướng mở bằng ctx.redirect()phương pháp của Koa, thì có thể hợp lý khi giả định điều tồi tệ nhất. Tôi đã tìm kiếm mã nhanh trong các dự án JavaScript ctx.redirect(trên GitHub. Tôi nhận được 16.827 kết quả mã. Tìm kiếm context.redirect(tôi nhận được 15.751 kết quả mã. Đó sẽ là 32.578 kết quả mã để phân tích. Một số trong số này sẽ sử dụng Koa, một số Express và một số có thể là thứ khác. (Tất nhiên, bối cảnh có thể được gọi bằng bất kỳ tên nào, không chỉ ctxhoặc context, vì vậy thậm chí có thể có nhiều mã hơn để xem xét.)

Câu hỏi đặt ra là: việc truyền dữ liệu do người dùng cung cấp một cách vô thức để chuyển hướng có phổ biến như vậy không? Tôi đã sử dụng phương pháp phân tích bán tự động bằng cách viết một tập lệnh nhỏ để kiểm tra tất cả các dự án phù hợp với tiêu chí tìm kiếm. Thật không may, tôi không thể vượt qua 1.000 lượt truy cập đầu tiên vì GitHub đã từ chối các yêu cầu tiếp theo:

{
    "message":"Only the first 1000 search results are available",
    "documentation_url":"https://docs.github.com/v3/search/"
}

Dựa trên những gì tôi đã thấy và xem xét những gì được thảo luận trong phần tiếp theo (“Trình duyệt web cũ”), tôi không tin rằng việc giả định triển khai trong trường hợp xấu nhất là hợp lý. Không phải trong trường hợp cụ thể này.

Hướng dẫn chính thức cũng nói rằng:

Khi chấm điểm một lỗ hổng trong một triển khai cụ thể bằng thư viện bị ảnh hưởng, điểm phải được tính lại cho triển khai cụ thể đó.

Điều này là hợp lý và giảm thiểu khía cạnh khoa học viễn tưởng của tình huống ở một mức độ nào đó. Đây là cách vấn đề Koa này, với điểm dễ bị tổn thương là 9,8, cuối cùng lại là 0,0 trong trường hợp của chúng tôi.

Điều tốt là Sonatype đồng ý rằng điểm dễ bị tổn thương 9,8 là không hợp lý và họ sẵn sàng giảm nó. Tôi đánh giá cao nó, và có lẽ nhiều người khác cũng sẽ như vậy.

Ngoài ra, Sonatype nói với tôi rằng khi họ thêm vấn đề vào hệ thống của mình, họ tin rằng sẽ tốt nhất nếu khách hàng của họ biết về tình huống bất ngờ có thể xảy ra này. Họ nói, “thà cảnh giác còn hơn bỏ qua những gì chúng ta đã thấy và có khả năng dẫn đến kết quả tiêu cực”. Và, tất nhiên, họ đã đúng.

Tôi chưa bao giờ đặt câu hỏi liệu các vấn đề bảo mật có nên được thông báo hay không. Có, các vấn đề bảo mật phải được hiển thị. Điều tôi quan tâm là làm thế nào những vấn đề này được truyền đạt:

Có thích hợp để gọi một cái gì đó là một lỗ hổng hay thích hợp hơn để gọi nó là một điểm yếu bảo mật hoặc hành vi mặc định không an toàn, v.v.?
Điểm dễ bị tổn thương được chỉ định có hợp lý không?
Có đủ chi tiết và ngữ cảnh được cung cấp không?

Bây giờ hãy nói về các trình duyệt web cũ một chút.

Trình duyệt web cũ

Nếu không có những người tốt của Sonatype, tôi sẽ không bao giờ nghĩ về các trình duyệt web cũ, có lẽ là không bao giờ nữa.

Tôi cũng sẽ tiếp tục không xem xét các trình duyệt cũ trong tương lai. Trước hết, có quá nhiều điều cần lưu ý; Tôi không thể lo lắng về các trình duyệt web cũ. Thứ hai, ( đừng nhấp vào liên kết nếu bạn không có khiếu hài hước! ) một trình duyệt web cũ bao nhiêu tuổi ? "Cũ" thực sự có nghĩa là gì? Nếu bất kỳ ai chỉ sử dụng trình duyệt ~1 năm tuổi, rất có thể họ đã gặp sự cố lớn hơn nhiều so với XSS.

Tuy nhiên, tôi đã thực hiện một số hoạt động đào bới và thấy rằng:

Google Chrome 48.0.2564.109 (64-bit) từ năm 2016 (!) thậm chí không hiển thị nội dung phản hồi. Vì vấn đề Koa đã được tìm thấy vào năm 2018, tôi nghĩ rằng quay trở lại năm 2016 là đủ, nhưng hóa ra không phải vậy.
Firefox 4.0 từ năm 2011 đã hiển thị nội dung phản hồi, nhưng nó yêu cầu người dùng nhấp vào liên kết để tải trọng JavaScript thực thi. (Tất nhiên, đó là một liên kết!)
Firefox 52.0 từ năm 2017, 1 năm trước khi sự cố Koa XSS được báo cáo, đã không hiển thị nội dung phản hồi với tải trọng JavaScript. Firefox vừa báo lỗi "Lỗi nội dung bị hỏng" do "vi phạm giao thức mạng".

Tuy nhiên, Koa 0.0.1 đã được phát hành vào năm 2013, vì vậy đã có một vài năm vấn đề có thể bị khai thác. Do đó, có thể chấp nhận gắn cờ vấn đề này (vẫn không có điểm 9,8) cho đến Koa 2.5.0 vào năm 2018. Tuy nhiên, sau đó, không có gì biện minh cho bất kỳ điều gì trên 1.0.

Trong khi tôi đang đào bới, tôi đã tìm thấy một điều thú vị trên Wikipedia . Hãy để tôi trích dẫn:

Firefox 15 được phát hành vào ngày 28 tháng 8 năm 2012… Firefox 15 đã giới thiệu các bản cập nhật im lặng, một bản cập nhật tự động sẽ cập nhật Firefox lên phiên bản mới nhất mà không cần thông báo cho người dùng, [65] một tính năng mà trình duyệt web Google Chrome và Internet Explorer 8 trở lên có đã được thực hiện

Vì vậy, tất cả các trình duyệt web chính đều có tính năng tự động cập nhật trước khi phiên bản đầu tiên của Koa được phát hành, điều đó có nghĩa là rất có thể phần lớn người dùng đang sử dụng trình duyệt web cập nhật. Hãy xem trạng thái tại thời điểm “vụ nổ lớn”: 2013.

Firefox 15 : Đã trả về lỗi "Lỗi nội dung bị hỏng", nghĩa là nội dung phản hồi không được hiển thị cho người dùng.
Chrome 24.0.1312 (WebKit 537.17) : Nó không hiển thị bất kỳ nội dung phản hồi nào. Trong khi xem tab mạng của các công cụ dành cho nhà phát triển, hầu như không có gì hiển thị, vì vậy tôi phải chạy Wireshark để xem trình duyệt có thực hiện yêu cầu ngay từ đầu hay không. Trong Wireshark, có thể thấy rằng Chrome đã liên hệ với dịch vụ PoC của tôi và nhận được phản hồi với tải trọng JavaScript. Nó không hiển thị nội dung phản hồi. Thậm chí tốt hơn, không có gì xảy ra.
Internet Explorer 11 (11.0.9600.19180) : Nó đã tìm nạp phản hồi từ dịch vụ PoC của tôi mà tôi đã xác minh bằng Wireshark. Nó không hiển thị nội dung phản hồi cho người dùng. Nó trở lại với trang lỗi tích hợp, cổ điển có nội dung: “Không thể hiển thị trang này”.

Sau khi thực hiện nghiên cứu trên, chúng ta hãy quay lại trích dẫn từ Sonatype trong giây lát:

Koa dường như quan tâm đến XSS trong bối cảnh này vì họ đã có mã ở đó để ngăn chặn nó, thực thể HTML mã hóa URL khi họ ghi nó vào HTML

Mặc dù tuyên bố này đúng, nhưng thực tế là không có trình duyệt chính nào cho phép khai thác vào thời điểm phiên bản đầu tiên của Koa được phát hành, phần trích dẫn gợi ý điều gì đó thú vị, điều gì đó khác với điều mà câu muốn đề xuất. Xin lưu ý rằng tôi sắp viết bài phỏng đoán vì tôi không thể biết chính xác các nhà phát triển Koa đã nghĩ như thế nào. Tôi có thể dễ dàng tưởng tượng (các) nhà phát triển đã kiểm tra hành vi được đề cập bằng trình duyệt web cập nhật. Họ có thể đã thấy rằng mã hóa HTML là phù hợp vì không thể thực thi mã JavaScript được đưa vào từ thuộc hreftính củaanhãn. Điều này đặt ra một câu hỏi nghiêm túc. Đã dành hơn 5 năm qua cho mảng phát triển phần mềm, điều đó cũng áp dụng cho tôi: Là một nhà phát triển, nếu tôi sắp tạo ra một công nghệ web mới cho phía phụ trợ, tôi có nên quan tâm đến các trình duyệt web cũ không? Và nếu tôi nên, khuyến nghị chính thức từ cộng đồng bảo mật về thời gian tôi phải xem xét các trình duyệt web cũ là bao lâu? Chúng ta có nên xem xét rằng phương pháp bảo mật tốt nhất cho người dùng cuối là luôn cập nhật trình duyệt của họ và tính năng tự động cập nhật cũng có sẵn để trợ giúp điều đó không? Ngoài ra, nếu chúng tôi mong đợi các nhà phát triển ghi nhớ và thử nghiệm với các trình duyệt cũ, thì chúng tôi không thể mong đợi các chuyên gia bảo mật cũng làm như vậy và đặt tên cho tất cả các trình duyệt web và phiên bản của chúng góp phần gây ra một vấn đề cụ thể thay vì chỉ đề cập đến “các trình duyệt cũ ”? Nó sẽ chỉ là công bằng.

Một điều chắc chắn là không có gì phải lo lắng kể từ nhiều năm nay…

Trình duyệt hiện đại

Trong phân tích của tôi, sử dụng trình duyệt web của mình, tôi đã kiểm tra nội dung phản hồi và thấy nó trống. Tôi đã không kiểm tra xem phản hồi được gửi qua dây có nội dung hay không. Hóa ra chỉ có Google Chrome đã hoàn toàn bỏ qua nội dung phản hồi; do đó, nó đã không hiển thị. Điều đó là đủ tốt cho tôi. Hợp lý, tôi phải thêm.

Kể từ đó, tôi đã xem xét phản hồi của dịch vụ web thử nghiệm của mình bằng phiên bản Koa mới nhất. Chúng ta có thể thấy bên dưới có một nội dung phản hồi HTML với mã JavaScript được chèn trong đó:

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=javascript:alert(1); HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: javascript:alert(1);
< Content-Type: text/html; charset=utf-8
< Content-Length: 71
< Date: Tue, 22 Nov 2022 17:55:12 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="javascript:alert(1);">javascript:alert(1);</a>.

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=%22><%2f HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: %22%3E%3C/
< Content-Type: text/html; charset=utf-8
< Content-Length: 61
< Date: Tue, 22 Nov 2022 22:18:49 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="&quot;&gt;&lt;/">&quot;&gt;&lt;/</a>.

Thay đổi sắp tới

Dưới đây là danh sách các bản cập nhật mà Sonatype dự định thực hiện liên quan đến vấn đề này:

Cập nhật dòng Tóm tắt/Tiêu đề để loại bỏ hiểu lầm (đã xảy ra)
Giảm điểm dễ bị tổn thương xuống 4,7 (đã xảy ra)
Đề cập rằng lỗ hổng bảo mật chỉ có thể bị khai thác nếu người dùng đang chạy trình duyệt cũ hơn

Những thay đổi bổ sung mà tôi muốn xem

Ngoài những thay đổi được đề cập trong phần trước, một số điều có thể được cải thiện hơn nữa. Đó là:

Giảm điểm dễ bị tổn thương hơn nữa, đặc biệt là đối với các phiên bản Koa được phát hành sau năm 2018.
Bao gồm số phiên bản của ít nhất các trình duyệt web chính và ngày phát hành của chúng trong báo cáo khi đề cập đến “các trình duyệt cũ hơn”. Điều này sẽ giúp ích đáng kể cho bất kỳ ai khi “chấm điểm một lỗ hổng trong một triển khai nhất định bằng cách sử dụng thư viện bị ảnh hưởng”. Ví dụ: nếu tôi thấy rằng một người dùng phải sử dụng trình duyệt từ năm 2011, tôi sẽ đánh dấu sự cố là “không bị ảnh hưởng” trong SCA trong vòng một giây. Đó là rất nhiều thời gian tiết kiệm.
Các phiên bản Koa bị ảnh hưởng sẽ được liệt kê trên trang của lỗ hổng .

Nhân tiện, Sonatype cũng đề cập rằng họ có một số kiểm tra thú vị trong sản phẩm thương mại của mình, chẳng hạn như thực hiện kiểm tra thực tế ở cấp độ mã để xem liệu một ứng dụng có bị ảnh hưởng bởi các lỗ hổng được báo cáo hay không. Điều đó nghe có vẻ gọn gàng và với tính chất khoa học viễn tưởng về cách tính điểm dễ bị tổn thương cho các thư viện, những loại kiểm tra này là bắt buộc phải có để giảm tải cho các nhóm kỹ thuật, đặc biệt nếu mọi thứ tiếp tục như thế này.

Phần kết luận

Đó là khá nhiều tất cả các bản cập nhật tôi có. Tôi rất vui vì đã liên hệ với Sonatype vì họ rất chuyên nghiệp và thân thiện. Đó là một niềm vui làm việc với họ về điều này.

Về XSS ở Koa: đó là điều mà không ai trong chúng ta nên lo lắng trong vài năm nay.