Sự thất vọng của tôi luôn dâng cao vì nó lại xảy ra lần nữa. Nếu bạn đã đọc phân tích trước đây của tôi có tiêu đề CVE-2022–29622: (In)Phân tích lỗ hổng , thì bạn có thể nghi ngờ những gì tôi đang đề cập đến. Cùng một câu chuyện, nạn nhân khác nhau. Tuy nhiên, ngày tháng rất quan trọng trong trường hợp này. Phân tích bất khả xâm phạm trước đây của tôi là từ năm 2022, hôm nay tôi sẽ phân tích một vấn đề khác từ năm 2018.

Bạn có thể hỏi: “Tại sao bạn phải giải quyết một việc gì đó từ năm 2018?” Câu hỏi tuyệt vời! Bởi vì gần đây tôi đã kích hoạt Theo dõi phụ thuộc để lấy thông tin về lỗ hổng từ Chỉ mục OSS của Sonatype.

Hôm nay khi tôi đang lướt qua SCA để xem liệu chúng tôi có bất kỳ thành phần dễ bị tổn thương nào không và nếu có, hãy ưu tiên công việc khắc phục. Tôi đã đi qua một cái gì đó rất đáng ngạc nhiên. Koa.JS có một lỗ hổng nghiêm trọng?! Sau câu nói “#FFS, cả tuần của tôi cần sắp xếp lại” như thường lệ, tôi đã nói: “Hãy hít một hơi thật sâu và xem xét điều này nói về điều gì. Anh còn nhớ chuyện lần trước…”

Và vì vậy tôi đã làm. Trước hết, tiêu đề nói rõ rằng “vấn đề” đã được tìm thấy vào năm 2018. Bây giờ, tại sao tôi lại có một lỗ hổng trong thư viện vẫn được duy trì và tôi tiếp tục nâng cấp lên phiên bản mới nhất? Tại thời điểm này, phần điều tra trong não tôi bắt đầu hoạt động.

Chúng ta biết/thấy gì vào thời điểm này?

1. Bị cáo buộc có một lỗ hổng trong Koa vào năm 2018 với mức độ nghiêm trọng được chỉ định
2. Theo Chỉ số OSS và Theo dõi phụ thuộc của Sonatype, sự cố ảnh hưởng đến tôi vào năm 2022 khi đang chạy phiên bản Koa mới nhất

• Phiên bản nào của thư viện Koa.JS bị ảnh hưởng bởi “lỗ hổng”
• Nếu “lỗ hổng” xuất hiện trong Koa.JS mới nhất

Phân tích vấn đề

Hãy xem “lỗ hổng” là gì. Hãy để tôi liên kết nhanh vấn đề liên quan #1250 từ GitHub tại đây. Tôi sẽ chỉ sao chép-dán ví dụ (PoC?) bên dưới để chúng ta có thể phân tích.

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

app.use(async ctx => {
  ctx.redirect("javascript:alert(1);")
});

app.listen(3000);

“Là nhà phát triển ứng dụng web hoặc dịch vụ web, tôi có thể chuyển hướng trình duyệt của bạn đến bất cứ nơi nào tôi muốn nếu bạn truy cập trang web của tôi.”

Đó là ý nghĩa của đoạn mã trên. Trong PoC ở trên, không có vectơ tấn công nào được trình bày cho một tác nhân độc hại khai thác bất cứ thứ gì.

Nếu bạn muốn cung cấp một “PoC” thích hợp cho tính không dễ bị tổn thương này (yup, tôi vừa nói rồi), thì nó sẽ như thế này:

const Koa = require('koa');
const app = new Koa();
// Try: http://localhost:3000/?vector=javascript:alert(1);
app.use(async ctx => {
  ctx.redirect(ctx.request.query.vector);
});

app.listen(3000);

Nói về lỗ hổng XSS, nếu bất kỳ giá trị nào tôi đã nhập làm giá trị của vectortham số được hiển thị không an toàn trong ngữ cảnh HTML, thì ứng dụng tôi triển khai sẽ dễ bị tấn công bởi Cross Site Scripting. (Thêm về điều này sau)

Phóng to cách Sonatype trình bày điều này và phân tích thêm một chút:

“Chuyển hướng mở dẫn đến Cross-Site Scripting”? 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. Trong cái đầu tiên, không có vectơ tấn công, do đó không có chuyển hướng mở. PoC của tôi có vectơ tấn công, không lọc, do đó có một chuyển hướng mở. Tuy nhiên, như bạn có thể thấy, việc có hay không có chuyển hướng mở phụ thuộc vào tôi, nhà phát triển chứ không phải Koa.JS. Tốt hơn nữa, có chuyển hướng hay không cũng phụ thuộc vào tôi. Việc tôi có bao gồm đầu vào do người dùng cung cấp dưới dạng/trong URL chuyển hướng theo cách không an toàn hay không cũng tùy thuộc vào tôi. Chúng ta đang nói về lỗ hổng Koa.JS nào? Về mặt kỹ thuật, không có lỗ hổng nào và ai đó vẫn gán mức độ nghiêm trọng Nguy hiểm cho nó. Không chính xác chuyên nghiệp.

Dù sao đi nữa, hãy “khai thác” “lỗ hổng” đã nói được triển khai bởi PoC thích hợp. Xin lưu ý rằng tôi đã phải thay đổi cổng dịch vụ từ 3000 thành 4444 vì tôi đã nghe thấy gì đó trên cổng 3000.

Chúng ta có thể thấy Locationtiêu đề phản hồi có giá trị javascript:alert(1). Sau đó, trình duyệt chuyển hướng đến…

Hừ, tôi bình an vô sự! Không có hộp cảnh báo bật lên. Có, tôi có thể nhập https://google.comlàm giá trị của vectortham số truy vấn và được chuyển hướng đến Google, vì vậy ứng dụng (PoC) của tôi dễ bị chuyển hướng mở, nhưng không phải do Koa mà vì tôi đã chuyển dữ liệu người dùng chưa được lọc sang ctx.redirect. Đó không phải là điều tôi lo lắng, tôi sẽ không bao giờ làm điều này.

Một điều quan trọng cần lưu ý từ các nhận xét về vấn đề trên GitHub như sau:

Vấn đề bắt nguồn từ việc Koa in một siêu liên kết HTML trong phần nội dung của phản hồi chuyển hướng và điều đó có thể kích hoạt một cuộc tấn công kịch bản chéo trang.

Ah, điều đó có ý nghĩa hơn một chút! Hãy xem nếu đó vẫn là trường hợp.

Không, nó không còn là trường hợp nữa. Không có cơ quan phản ứng. Tôi đoán tôi có thể kết luận rằng “lỗ hổng” này không ảnh hưởng đến tôi. Tôi chỉ có thể đi và đánh dấu nó là dương tính giả trong Theo dõi phụ thuộc.

Phân tích bối cảnh

Tôi đề xuất “Phân tích bối cảnh” nên được tất cả các chuyên gia bảo mật chấp nhận và thực hiện trước khi báo cáo “các vấn đề”. Hãy để đây là một ví dụ khác và cho bạn thấy nó được thực hiện như thế nào. (Tôi vẫn khuyên bạn nên đọc CVE-2022–29622: (In)Phân tích lỗ hổng mặc dù nó giải thích tầm quan trọng của bối cảnh tốt hơn rất nhiều.)

1. Koa.JS out-of-the-box không chuyển hướng bạn đến bất cứ đâu. Do đó, có và không có “Chuyển hướng mở” như Sonatype OSS Index đã nêu.
2. Dựa trên “PoC” được cung cấp trên GitHub, có cơ hội cho nhà phát triển làm điều gì đó ngu ngốc có thể dẫn đến XSS. Nhưng, xem #1 ở trên. Koa.JS không tự thực hiện bất kỳ chuyển hướng nào. Xem #2 bên dưới.
3. Nhà phát triển phải triển khai ứng dụng của mình theo cách không an toàn để có “lỗ hổng” được báo cáo. Điều này gần như có nghĩa là Koa.JS mặc dù lẽ ra có thể làm tốt hơn, nhưng bạn không thể gọi nó là dễ bị tổn thương. Nó không phù hợp về mặt ngữ cảnh. Lỗ hổng được đề cập chỉ có thể xuất hiện trong ứng dụng web được triển khai không an toàn .

Để tôi cho bạn một ví dụ về cách xử lý tốt nhất những tình huống như thế này. Hãy xem vấn đề này mà tôi đã gửi tới Swagger Parser và cách nó được truyền đạt. Hãy phân tích báo cáo vấn đề:

1. Tiêu đề cho biết "Hành vi của trình giải quyết không an toàn". Tôi không nói về LFI (Bao gồm tệp cục bộ) trong tiêu đề. Điều này là do mặc dù có khả năng bao gồm tệp cục bộ NẾU TÔI LÀM LẠI MỌI THỨ, nhưng với tư cách là nhà phát triển, tôi thực sự phải biết mình đang làm việc với cái gì và làm việc với nó như thế nào. Hành vi mặc định là (có thể vẫn còn) không an toàn. Nhưng, thư viện của riêng nó, không có sự tham gia của tôi sẽ không làm được gì cả.
2. Sau đó, tôi nói rõ tôi đang nói về phiên bản nào của thư viện. Tôi làm cho bối cảnh rõ ràng hơn bằng cách liệt kê các điều kiện theo đó hành vi mặc định không an toàn của thư viện sẽ ảnh hưởng đến một ứng dụng. Điều này cho thấy khá rõ ràng rằng bản thân thư viện không dễ bị tổn thương, nhưng nó có hành vi không an toàn có thể được cải thiện để giúp các nhà phát triển.
3. Vì vậy, bây giờ bối cảnh đã được thiết lập, tôi cung cấp một PoC đang hoạt động, một đoạn mã dễ bị tổn thương (mà tôi đã viết dưới dạng PoC, nó không phải là một phần của Swagger Parser!) và kết quả thực sự của việc khai thác một ứng dụng/dịch vụ dễ bị tấn công sử dụng thư viện không an toàn.
4. Tôi đã thực hiện một số điều tra và thấy rằng với tư cách là nhà phát triển, tôi thực sự có thể định cấu hình thư viện theo cách giảm thiểu sự cố. (ở một mức độ nào đó) Tôi đã chia sẻ điều này với các nhà phát triển. Nếu không có gì khác, ít nhất họ có thể cập nhật tài liệu để nâng cao nhận thức.
5. Tôi đã cung cấp thêm ngữ cảnh, phân tích và ví dụ về cách cải thiện mọi thứ.

Phần kết luận

Trước hết, Sonatype nên làm tốt hơn với Chỉ mục OSS và đảm bảo thông tin phiên bản có sẵn cho từng lỗ hổng trong cơ sở dữ liệu. Đó là mức tối thiểu trần. (Điểm thưởng khi xóa hoàn toàn mục nhập cụ thể này khỏi cơ sở dữ liệu.)

Tôi nghi ngờ Dependency Track bị FOMO, do đó, nó sẵn sàng báo cáo các sự cố hoàn toàn dựa trên tên thành phần khớp nếu số phiên bản không khả dụng. Tôi hiểu ở một mức độ nào đó rằng họ sẽ không mạo hiểm bỏ lỡ một lỗ hổng nghiêm trọng. Vấn đề với hành vi này (dương tính giả) là nó không khuyến khích áp dụng Phân tích thành phần phần mềm. Nó sẽ khiến các nhà phát triển sợ hãi giống như những mặt tích cực sai của phân tích mã tĩnh. Phản tác dụng.

Bối cảnh! Bối cảnh đẫm máu nhé mọi người! Tôi đề nghị:

1. “Phân tích bối cảnh” sẽ được tất cả các chuyên gia bảo mật chấp nhận và thực hiện trước khi báo cáo “các vấn đề”
2. Phân biệt “hành vi không an toàn” với “lỗ hổng”
3. Hiểu sự khác nhau giữa thư viện phần mềm và ứng dụng/dịch vụ