การอัปเดตการวิเคราะห์ความคงกระพันของ Koa.js

Nov 26 2022

เมื่อไม่นานมานี้ ฉันได้เขียนเกี่ยวกับช่องโหว่ที่ส่งผลกระทบต่อ Koa.js ในปี 2018

ไม่นานมานี้ ฉันได้เขียนเกี่ยวกับช่องโหว่ที่ส่งผลกระทบต่อKoa.jsในปี 2018 ฉันผิดหวังที่ต้องจัดการกับปัญหาในปี 2018 ในขณะที่วันที่เป็นปี 2022 และฉันใช้ Koa เวอร์ชันล่าสุด 4 ปีผ่านไป นั่นเป็นเวลานาน รับรองไม่มีประเด็นนี้อีกแล้ว!? และเป็นและไม่เป็นไปพร้อมกัน นั่นหมายความว่าฉันผิดและถูกในเวลาเดียวกัน ดังนั้นนี่คือการอัปเดตของโพสต์ก่อนหน้าเพื่อบอกคุณว่า:

ฉันกล่าวหา Sonatype และ Dependency Track อย่างไม่ถูกต้องว่าไม่ดำเนินการกับข้อมูลเวอร์ชันในบางกรณี
ฉันสามารถถูกและผิดในเวลาเดียวกันเกี่ยวกับช่องโหว่

ดัชนี OSS มีข้อมูลเวอร์ชัน

หากคุณเคยอ่านโพสต์ก่อนหน้าของฉัน คุณอาจจำได้ว่าฉันได้สรุปว่าปัญหาไม่ได้ส่งผลกระทบต่อฉัน ข่าวดีก็คือฉันคิดถูก ข่าวร้ายคือฉันกล่าวหา Sonatype อย่างไม่ถูกต้องว่าไม่มีหมายเลขเวอร์ชันในข้อมูลที่จัดทำโดย OSS Index เพื่อให้ Dependency Track ใช้งานได้ ปรากฎว่าพวกเขามีข้อมูล มันมองไม่เห็นในที่ที่ฉันคาดไว้ว่ามันควรจะมองเห็นได้ ดูภาพหน้าจอด้านล่างที่ถ่ายเมื่อวันที่ 22/11/2022

ไม่มีข้อมูลเกี่ยวกับเวอร์ชันที่ได้รับผลกระทบ

เป็นไปได้ค่อนข้างมากว่า Dependency Track (DT) จะไม่ทำงานกับสิ่งที่แสดงบนหน้าเว็บด้านบน แต่ฉันไม่สนใจที่จะตรวจสอบว่าข้อมูลที่ DT ดึงมาจากดัชนี OSS มีลักษณะอย่างไร DT เพิ่งแสดงลิงก์ไปยัง OSS Index ซึ่งฉันสามารถเรียนรู้เพิ่มเติมได้ ฉันคลิกและเข้าสู่หน้านี้
Sonatype ได้รับความสนใจจากฉันในวันนี้ว่ามีหมายเลขเวอร์ชัน ฉันต้องดูที่อื่น แน่นอน หากคุณลงชื่อเข้าใช้บัญชีของคุณและค้นหา Koa หรือคลิกปุ่ม “ดูรายละเอียดสำหรับ koa” ในภาพหน้าจอด้านบน คุณจะพบมัน ดูภาพหน้าจอด้านล่าง

Koa ตามเวอร์ชันและตัวนับช่องโหว่พื้นฐาน

ดังนั้นฉันคิดผิด Sonatype มีข้อมูลในฐานข้อมูล ปัญหาเกิดขึ้นกับเลเยอร์การนำเสนอแล้ว จะดีกว่าหากมีเวอร์ชันที่ได้รับผลกระทบแสดงอยู่ในหน้าเว็บที่มีการกล่าวถึงช่องโหว่จริง เพื่อให้เราดูและตรวจสอบได้หากจำเป็น

ฉันกล่าวหา Sonatype OSS Index อย่างไม่ถูกต้องว่าไม่มีข้อมูลเวอร์ชัน ฉันยังกล่าวหาว่า Dependency Track ในทางที่ผิดว่าเต็มใจที่จะรายงานตามชื่อการพึ่งพาเพียงอย่างเดียวหากไม่มีข้อมูลเวอร์ชัน (ฉันยังต้องค้นหาว่าอันหลังจริงหรือเท็จ ฉันไม่ได้ตรวจสอบ)

อย่าเพิ่งยอมแพ้! สิ่งที่น่าตื่นเต้นกว่าที่จะพูดคุยคือช่องโหว่ที่เกิดขึ้นจริงและ (หวังว่า) การเปลี่ยนแปลงที่จะเกิดขึ้นต่อรายงานช่องโหว่ใน OSS Index เริ่มจากช่องโหว่กันก่อน

การเขียนสคริปต์ข้ามไซต์

Sonatype ระบุว่า XSS เป็น Koa ตามกระบวนการคิดด้านล่าง

Koa คือเอนทิตีที่เขียน URL ไปยังการตอบสนอง HTML ไม่ใช่นักพัฒนาซอฟต์แวร์ที่ใช้ Koa

เป็นเรื่องที่สมเหตุสมผลอย่างยิ่งที่จะคาดหวังให้นักพัฒนาตรวจสอบความถูกต้องของ URL ที่ให้มา ซึ่งน่าจะตรงข้ามกับรายการที่อนุญาต เพื่อป้องกันการเปลี่ยนเส้นทางแบบเปิดและไม่ใช่ Koa เนื่องจาก Koa ไม่รู้ว่า URL ใดที่คุณต้องการอนุญาตหรือไม่ อย่างไรก็ตาม ในฐานะนักพัฒนา ฉันไม่คิดว่าฉันควรจะต้องกังวลเกี่ยวกับการล้างข้อมูล XSS สำหรับ URL ที่ฉันกำลังส่งผ่านไปยังวิธีการเปลี่ยนเส้นทาง ()

Koa ดูเหมือนจะสนใจ XSS ในบริบทนี้เนื่องจากมีโค้ดป้องกันอยู่แล้ว เอนทิตี HTML ที่เข้ารหัส URL เมื่อพวกเขาเขียนลงใน HTML

ฉันเห็นด้วยในระดับหนึ่ง ฉันไม่เห็นด้วยมีดังต่อไปนี้เช่น

ฉันไม่คิดว่าฉันควรจะต้องกังวลเกี่ยวกับการทำ XSS sanitization สำหรับ URL ที่ฉันกำลังส่งไปยังเมธอด redirect()

หากคุณส่ง URL ที่ถูกต้องและปลอดภัยไปยังวิธีการเปลี่ยนเส้นทางที่คุณ (ผู้พัฒนา) ให้มา คุณก็ไม่ต้องกังวลเกี่ยวกับ XSS (แน่นอน) หากคุณส่งข้อมูลที่ผู้ใช้ให้มาทั้งหมดหรือบางส่วน นั่นคือสิ่งที่คุณต้องกังวลอยู่เสมอ ไม่ว่าคุณจะเป็นนักพัฒนาซอฟต์แวร์หรือผู้เชี่ยวชาญด้านความปลอดภัยก็ตาม ถึงกระนั้นก็ไม่ใช่เรื่องไกลเกินจริงที่จะคาดหวังให้ Koa ช่วยเหลือผู้พัฒนา

ให้ฉันยกตัวอย่างที่ดีซึ่งหวังว่าจะช่วยให้เข้าใจว่าฉันมาจากไหน ในตัวอย่างด้านล่าง ฉันส่งข้อมูลที่ผู้ใช้ให้ไว้กลับไปยังเบราว์เซอร์ในเนื้อหาการตอบสนอง ฉันทำสิ่งนี้โดยไม่มีการตรวจสอบ ฆ่าเชื้อ หรือเข้ารหัสใดๆ

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)>%

ลองนึกถึงสิ่งที่ฉันส่งไปยังเบราว์เซอร์ในเนื้อหาการตอบสนอง
พิจารณา (และน่าจะดีที่สุดในการควบคุมอย่างชัดเจน!) ค่าของส่วนหัวประเภทเนื้อหาสำหรับการตอบกลับ
โปรดทราบว่าตามค่าเริ่มต้น Koa จะปรับค่าของส่วนหัวประเภทเนื้อหาโดยอัตโนมัติตามค่าที่ส่งไปctx.bodyยัง (ลองผ่าน เช่นaaaดูการเปลี่ยนแปลง)

เมื่อพิจารณาจากctx.bodyตัวอย่าง “XSS” ข้างต้น ดูเหมือนเรากำลังตำหนิ Koa สำหรับการใช้มาตรการเฉพาะเพื่อป้องกันภัยพิบัติเมื่อctx.redirect()ใช้ อ้าง Sonatype อีกครั้ง:

Koa ดูเหมือนจะสนใจ XSS ในบริบทนี้เนื่องจากมีโค้ดอยู่แล้ว

นี่หมายความว่าหาก Koa ไม่สนใจ XSS ในบริบทนี้ เหมือนกับที่พวกเขาไม่สนใจ (และไม่ควร) กังวลเกี่ยวกับเรื่องนี้ ก็จะctx.bodyไม่มีใครตั้งค่าสถานะว่าเป็นช่องโหว่ XSS ใช่หรือไม่ มันค่อนข้างตลก ฉันสังเกตเห็นความคล้ายคลึงกันบางอย่างกับการวิเคราะห์ก่อนหน้านี้เกี่ยวกับเอกสารที่น่ากลัวที่นี่และที่นี่

เท่าที่ผมเคยพูดไป XSS ก็อยู่ที่นั่น… ไม่ใช่ในเวลาเดียวกัน เป็นไปได้อย่างไร? เรียบง่าย! มีอยู่ แต่คุณไม่สามารถใช้ประโยชน์จากมันได้ เว้นแต่:

เหยื่อใช้เว็บเบราว์เซอร์เก่า AND
มีการเปลี่ยนเส้นทางแบบเปิดที่นักพัฒนานำมาใช้โดยใช้ Koa's ctx.redirect(), AND
นักพัฒนาเชื่อถือข้อมูลที่ผู้ใช้ให้ทั้งหมดอย่างสมบูรณ์และส่งต่อแบบคำต่อคำctx.redirect()

หน้ารายงาน Sonatype กล่าวอย่างที่คุณเห็นจากภาพหน้าจอของวันนี้ “การเปลี่ยนเส้นทางแบบเปิดที่นำไปสู่การเขียนสคริปต์ข้ามไซต์” โพสต์ก่อนหน้าของฉันถามส่วน "เปลี่ยนเส้นทางแบบเปิด":

ประการแรก ไม่มีการเปลี่ยนเส้นทางแบบเปิด มันจะเปิดก็ต่อเมื่อคุณเปิดมัน และความแตกต่างระหว่าง PoC สองตัว (ตัวเดิมและตัวของผม) แสดงให้เห็นอย่างชัดเจน

Sonatype ยังตกลงด้วยว่า Koa จะไม่รับผิดชอบในการป้องกันการเปลี่ยนเส้นทางแบบเปิด ข้อกังวลของพวกเขา ข้อกังวลของฉัน และข้อกังวลหลักของทุกคนคือ XSS การเปลี่ยนเส้นทางแบบเปิดทำให้เกิดความสับสน ในขณะเดียวกันก็ไม่สมเหตุสมผลในทางเทคนิคดังที่เราจะได้เห็นในภายหลัง (มันจะส่งผลต่อการให้คะแนนช่องโหว่ด้วย)

ดังที่ได้กล่าวไว้ก่อนหน้านี้ การใช้ประโยชน์จากพฤติกรรมของ Koa ให้สำเร็จนั้นจำเป็นต้องมีการเปลี่ยนเส้นทางแบบเปิด แต่:

Koa จะไม่รับผิดชอบในการป้องกันการเปลี่ยนเส้นทางแบบเปิด (ตามที่สรุปไว้ก่อนหน้านี้)
Koa จะไม่ดำเนินการctx.redirect()โดยปราศจากคำสั่งของผู้พัฒนา
Koa ไม่บังคับให้นักพัฒนาใช้การเปลี่ยนเส้นทาง

ดังนั้นจึงมีการป้องกันอีกชั้นหนึ่ง: กรณีการใช้งาน นักพัฒนาซอฟต์แวร์จะไม่ต้องการการควบคุมตำแหน่งที่เบราว์เซอร์ถูกเปลี่ยนเส้นทางมากน้อยเพียงใด ไม่น่าเป็นไปได้มาก ซึ่งหมายความว่า เป็นไปได้มากที่นักพัฒนาจะส่งข้อมูลที่ผู้ใช้ควบคุมไปctx.redirect()ผนวกเข้ากับสตริงอีกชิ้นหนึ่ง ดังนั้น สิ่งที่คล้ายกับตัวอย่างด้านล่างจึงมีโอกาสเกิดขึ้นได้มากที่สุด:

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

การให้คะแนนช่องโหว่

ต้องมีเงื่อนไขสาม (3) เงื่อนไขที่ตรงตามเงื่อนไขสำหรับจุดบกพร่องที่สามารถใช้ประโยชน์ได้ ตามที่กล่าวไว้ในตอนท้ายของส่วนก่อนหน้า

เบราว์เซอร์เวอร์ชันใดที่ใช้ขึ้นอยู่กับผู้ใช้ปลายทาง
การใช้วิธีการเปลี่ยนเส้นทางและวิธีการใช้นั้นขึ้นอยู่กับผู้พัฒนา

สิ่งที่ต้องเน้นคือการใช้วิธีการเปลี่ยนเส้นทางด้วยวิธีที่ไม่ปลอดภัยคือเวกเตอร์การโจมตี จำเป็นต้องมีเวคเตอร์การโจมตีเพื่อการแสวงประโยชน์ที่ประสบความสำเร็จ Koa ไม่ได้ให้เวกเตอร์การโจมตี นักพัฒนาไม่

ลองเปรียบเทียบสิ่งนี้กับคำจำกัดความของ "ช่องโหว่ของซอฟต์แวร์" ที่จัดทำโดย NIST:

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

ส่วนที่ฉันต้องการเน้นคือ ใช้ Koa เป็นไลบรารีซอฟต์แวร์ คุณสามารถใช้ประโยชน์จากมันโดยไม่สร้างเวกเตอร์โจมตีที่จำเป็นก่อนได้หรือไม่? ไม่ ดังนั้นจากมุมมองของ Koa ไลบรารีซอฟต์แวร์จึงไม่มีเวกเตอร์โจมตีแสดงอยู่ หากปราศจากสิ่งนั้น การเอารัดเอาเปรียบก็เป็นไปไม่ได้ หากเราตีความคำจำกัดความอย่างเคร่งครัด (ซึ่งฉันทำ) เราจะไม่สามารถเรียกพฤติกรรมของ Koa ว่าเป็นช่องโหว่ได้
ลองคำนวณคะแนน CVSS โดยไม่ใช้เวกเตอร์โจมตี:

การคำนวณคะแนน CVSS โดยไม่ใช้เวกเตอร์โจมตี

ไม่มีคะแนนหากไม่มีเวกเตอร์การโจมตี ฉันจะบอกว่าสิ่งนี้สอดคล้องกับคำจำกัดความของช่องโหว่ของซอฟต์แวร์ที่จัดทำโดย NIST
มาทดลองและสร้างสถานการณ์สมมติที่มีเวกเตอร์การโจมตีอยู่

เวกเตอร์การโจมตีสมมติ

ยังคงมีปัญหาหลายอย่างที่นี่ นอกเหนือจากเวกเตอร์การโจมตีในจินตนาการ ความซับซ้อนของการโจมตีถูกตั้งค่าเป็นสูงเนื่องจากการแสวงหาผลประโยชน์ที่ประสบความสำเร็จต้องใช้เบราว์เซอร์รุ่นเก่า ผู้โจมตีต้องโน้มน้าวให้เหยื่อดาวน์โหลดและติดตั้งเบราว์เซอร์เก่า
ในแง่นั้น การโต้ตอบกับผู้ใช้เป็นสิ่งจำเป็น แม้ว่าเมตริกพื้นฐานของการโต้ตอบกับผู้ใช้จะไม่ได้เกี่ยวกับสิ่งนั้นจริงๆ ในสถานการณ์นี้ การใช้ประโยชน์จาก XSS ต้องมีการโต้ตอบกับผู้ใช้หรือไม่ ขึ้นอยู่กับวิธีที่เว็บแอปพลิเคชันใช้การเปลี่ยนเส้นทาง ไม่ใช่บน Koa ที่ควรค่าแก่การกล่าวถึงก็คือ JavaScript ที่แทรกไว้จะไม่ทำงานด้วยตัวเองเนื่องจากจำเป็นต้องมีการโต้ตอบกับผู้ใช้ในตอนแรก: การคลิกลิงก์ในการตอบสนองของ HTML

แล้วเราจะทำอย่างไรเพื่อบังคับให้มีคะแนนช่องโหว่ในเรื่องนี้? เราต้องเลือกบางอย่าง คิดปรารถนา สมมติสิ่งที่เลวร้ายที่สุด อะไรก็ได้ที่คุณชอบ สิ่งหนึ่งที่แน่นอนคือ คุณกำลังทำการคำนวณที่คุณไม่ควรทำตั้งแต่แรก และผลลัพธ์ที่ได้นั้นห่างไกลจากความเป็นจริงมากจนฉันไม่สามารถแม้แต่จะหาคำอธิบายได้

สิ่งที่ยิ่งใหญ่ต่อไปคือ Impact Metrics คุณต้องรู้ว่า Web Application กำลังจะบอกผลกระทบอะไร แต่เราไม่ได้คำนวณคะแนนช่องโหว่สำหรับเว็บแอปพลิเคชัน… เมื่อพิจารณาจากบริบทแล้ว XSS นี้ไม่มีผลกระทบต่อ Koa Koa ไม่จัดการหรือประมวลผลข้อมูลที่เป็นความลับด้วยตนเอง ข้อบกพร่องไม่มีผลกระทบต่อความพร้อมใช้งานหรือความสมบูรณ์ นั่นทำให้เรามีคะแนนสุดท้ายที่ 0.0 แม้จะบังคับเวกเตอร์โจมตีในการคำนวณแล้วก็ตาม

ดังนั้น คำถามคือ เรารายงานข้อเท็จจริงหรือเรื่องแต่ง?

Sonatype แจ้งคำแนะนำอย่างเป็นทางการสำหรับการให้คะแนนช่องโหว่ในไลบรารีซอฟต์แวร์ซึ่งเปิดตัวในปี 2019 ด้วย CVSSv3.1 ฉันยอมรับว่าฉันไม่รู้เรื่องซึ่งมีทั้งดีและไม่ดี ดีเพราะมันอาจส่งผลให้เกิดโพสต์คุยโว แย่เพราะบางทีถ้าฉันเห็นเร็วกว่านี้ ฉันคงหมดหวังก่อนที่จะพยายามอย่างมากในการพยายามอธิบายว่ามันไม่ใช่วิธีที่ถูกต้องในการดำเนินการ ดังนั้นคำแนะนำอย่างเป็นทางการพูดว่าอย่างไร?

เมื่อให้คะแนนผลกระทบของช่องโหว่ในไลบรารี … นักวิเคราะห์ควรให้คะแนนสำหรับสถานการณ์การใช้งานที่เลวร้ายที่สุดที่สมเหตุสมผล เมื่อเป็นไปได้ ข้อมูล CVSS ควรมีรายละเอียดสมมติฐานเหล่านี้

ดังนั้นคำตอบก็คือช่องโหว่ของการให้คะแนนนั้นขึ้นอยู่กับนิยาย

นอกจากนี้ อะไรคือ “ สถานการณ์การนำกรณีที่เลวร้ายที่สุดที่สมเหตุสมผล ”? หากเราวิเคราะห์หลายโครงการที่ใช้ Koa และพบว่านักพัฒนาส่วนใหญ่ใช้การเปลี่ยนเส้นทางแบบเปิดโดยใช้ctx.redirect()วิธีการของ Koa ก็อาจมีเหตุผลที่จะถือว่าแย่ที่สุด ฉันค้นหารหัสอย่างรวดเร็วในโครงการ JavaScript สำหรับctx.redirect(บน GitHub ฉันได้ผลลัพธ์ 16,827 รหัส การค้นหาcontext.redirect(ฉันได้รับผลลัพธ์ 15,751 รหัส นั่นจะเป็นผลลัพธ์ของรหัส 32,578 รายการที่จะวิเคราะห์ บางส่วนจะใช้ Koa บางส่วน Express และบางส่วนอาจเป็นอย่างอื่น (แน่นอนว่าบริบทสามารถเรียกด้วยชื่อใดก็ได้ ไม่ใช่แค่ctxหรือcontextดังนั้นอาจมีโค้ดให้ดูมากกว่านี้)

คำถามคือ: มีการส่งข้อมูลที่ผู้ใช้ให้โดยไร้สมองเพื่อเปลี่ยนเส้นทางโดยทั่วไปหรือไม่ ฉันใช้วิธีการกึ่งอัตโนมัติในการวิเคราะห์โดยการเขียนสคริปต์ขนาดเล็กเพื่อตรวจสอบโครงการทั้งหมดที่ตรงกับเกณฑ์การค้นหา น่าเสียดายที่ฉันไม่สามารถผ่าน 1,000 ครั้งแรกไปได้เนื่องจาก GitHub ปฏิเสธคำขอเพิ่มเติม:

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

จากสิ่งที่ฉันได้เห็นและพิจารณาถึงสิ่งที่จะกล่าวถึงในส่วนถัดไป (“เว็บเบราว์เซอร์เก่า”) ฉันไม่เชื่อว่าการสมมติว่ามีการใช้งานในกรณีที่เลวร้ายที่สุดจะสมเหตุสมผล ไม่ใช่ในกรณีนี้โดยเฉพาะ

คำแนะนำอย่างเป็นทางการยังกล่าวอีกว่า:

เมื่อให้คะแนนช่องโหว่ในการใช้งานที่กำหนดโดยใช้ไลบรารีที่ได้รับผลกระทบ จะต้องคำนวณคะแนนใหม่สำหรับการใช้งานเฉพาะนั้น

สิ่งนี้สมเหตุสมผลและลดแง่มุมของนิยายวิทยาศาสตร์ของสถานการณ์ลงในระดับหนึ่ง นี่คือสาเหตุที่ปัญหา Koa ซึ่งมีคะแนนช่องโหว่ 9.8 จบลงที่ 0.0 ในกรณีของเรา

สิ่งที่ดีคือ Sonatype เห็นพ้องกันว่าคะแนนช่องโหว่ 9.8 นั้นไม่สมเหตุสมผล และพวกเขาก็เต็มใจที่จะลด ฉันซาบซึ้งและอาจมีอีกหลายคนเช่นกัน

นอกจากนี้ Sonatype บอกฉันว่าเมื่อพวกเขาเพิ่มปัญหาลงในระบบของพวกเขา พวกเขาเชื่อว่าจะเป็นการดีที่สุดหากลูกค้าของพวกเขารู้เกี่ยวกับสถานการณ์ที่คาดไม่ถึงนี้ พวกเขากล่าวว่า “การตื่นตัวย่อมดีกว่าการเพิกเฉยต่อสิ่งที่เราเห็นและอาจส่งผลในทางลบ” และแน่นอนว่าพวกเขาพูดถูก

ฉันไม่เคยตั้งคำถามว่าควรแจ้งปัญหาด้านความปลอดภัยหรือไม่ ใช่ ต้องทำให้มองเห็นปัญหาด้านความปลอดภัย สิ่งที่ฉันกังวลคือวิธีการสื่อสารปัญหาเหล่านี้:

เหมาะสมหรือไม่ที่จะเรียกว่าช่องโหว่ หรือเหมาะสมกว่าที่จะเรียกว่าจุดอ่อนด้านความปลอดภัยหรือพฤติกรรมเริ่มต้นที่ไม่ปลอดภัย และอื่นๆ
คะแนนช่องโหว่ที่กำหนดนั้นสมเหตุสมผลหรือไม่?
มีรายละเอียดและบริบทเพียงพอหรือไม่

ตอนนี้เรามาพูดถึงเว็บเบราว์เซอร์รุ่นเก่ากันสักหน่อย

เว็บเบราว์เซอร์เก่า

หากไม่มีคนดีของ Sonatype ฉันคงไม่คิดถึงเว็บเบราว์เซอร์แบบเก่าอีกต่อไป

ฉันจะไม่พิจารณาเบราว์เซอร์เก่าต่อไปในอนาคตด้วย ก่อนอื่น มีหลายสิ่งที่ต้องจำไว้ ฉันไม่สามารถกังวลเกี่ยวกับเว็บเบราว์เซอร์รุ่นเก่าได้ ประการที่สองอายุเท่าไหร่ ( อย่าคลิกลิงก์หากคุณไม่มีอารมณ์ขัน! ) เว็บเบราว์เซอร์เก่า คำว่า “แก่” จริงๆ แล้วหมายความว่าอย่างไร? ถ้าใครใช้เบราว์เซอร์อายุประมาณ 1 ปี ก็น่าจะมีปัญหาที่ใหญ่กว่า XSS อยู่แล้ว

ถึงกระนั้นฉันก็ขุดและพบว่า:

Google Chrome 48.0.2564.109 (64 บิต) จากปี 2016 (!) ไม่แสดงเนื้อหาการตอบสนองด้วยซ้ำ เนื่องจากพบปัญหา Koa ในปี 2018 ฉันคิดว่าย้อนกลับไปในปี 2016 ก็น่าจะเพียงพอแล้ว แต่กลับกลายเป็นว่าไม่ใช่
Firefox 4.0 จากปี 2011 แสดงเนื้อหาการตอบสนอง แต่ต้องการให้ผู้ใช้คลิกลิงก์เพื่อให้เพย์โหลด JavaScript ดำเนินการ (แน่นอนว่ามันคือลิงค์!)
Firefox 52.0 จากปี 2017 1 ปีก่อนรายงานปัญหา Koa XSS นั้นไม่ได้แสดงเนื้อหาการตอบสนองพร้อมกับเพย์โหลด JavaScript Firefox เพิ่งแสดงข้อผิดพลาดว่า "ข้อผิดพลาดของเนื้อหาที่เสียหาย" เนื่องจาก "การละเมิดโปรโตคอลเครือข่าย"

Koa 0.0.1 เปิดตัวในปี 2013 ดังนั้นจึงมีเวลาไม่กี่ปีที่สามารถใช้ประโยชน์จากปัญหานี้ได้ ณ จุดนี้ อาจเป็นที่ยอมรับได้ที่จะแจ้งปัญหานี้ (ยังไม่ถึง 9.8 คะแนน) จนถึง Koa 2.5.0 ในปี 2018 อย่างไรก็ตาม หลังจากนั้นก็ไม่มีอะไรพิสูจน์ได้ว่าสิ่งใดอยู่เหนือ 1.0

ขณะที่ฉันกำลังขุดค้น ฉันพบบางสิ่งที่น่าสนใจใน วิ กิพีเดีย ให้ฉันพูด:

Firefox 15 เปิดตัวเมื่อวันที่ 28 สิงหาคม พ.ศ. 2555 … Firefox 15 แนะนำการอัปเดตแบบเงียบ ซึ่งเป็นการอัปเดตอัตโนมัติที่จะอัปเดต Firefox เป็นเวอร์ชันล่าสุดโดยไม่ต้องแจ้งให้ผู้ใช้ทราบ[65]คุณลักษณะที่เว็บเบราว์เซอร์Google ChromeและInternet Explorer 8ขึ้นไปมี ดำเนินการแล้ว

ดังนั้นเว็บเบราว์เซอร์หลักๆ ทั้งหมดจึงมีฟีเจอร์อัปเดตอัตโนมัติก่อนที่ Koa เวอร์ชันแรกจะเปิดตัว ซึ่งหมายความว่ามีโอกาสที่ผู้ใช้ส่วนใหญ่จะใช้เว็บเบราว์เซอร์เวอร์ชันล่าสุด มาดูสภาพในช่วงเวลาที่เกิด "บิ๊กแบง": 2013

Firefox 15 : ส่งกลับข้อผิดพลาดที่ระบุว่า "ข้อผิดพลาดของเนื้อหาที่เสียหาย" ซึ่งหมายความว่าเนื้อหาการตอบกลับไม่แสดงต่อผู้ใช้
Chrome 24.0.1312 (WebKit 537.17) : ไม่แสดงเนื้อหาการตอบสนองใดๆ ขณะที่ดูที่แท็บเครือข่ายของเครื่องมือสำหรับนักพัฒนา แทบไม่เห็นอะไรเลย ดังนั้นฉันจึงต้องเรียกใช้ Wireshark เพื่อดูว่าเบราว์เซอร์ทำตามคำขอตั้งแต่แรกหรือไม่ ใน Wireshark จะเห็นว่า Chrome ติดต่อบริการ PoC ของฉันและได้รับการตอบกลับด้วยเพย์โหลด JavaScript มันไม่ได้ทำให้ร่างกายตอบสนอง ดีกว่าไม่มีอะไรเกิดขึ้น
Internet Explorer 11 (11.0.9600.19180) : ดึงการตอบกลับจากบริการ PoC ของฉัน ซึ่งฉันตรวจสอบโดยใช้ Wireshark มันไม่ได้แสดงเนื้อหาการตอบสนองต่อผู้ใช้ มันกลับมาพร้อมกับหน้าแสดงข้อผิดพลาดในตัวแบบคลาสสิกที่ระบุว่า “ไม่สามารถแสดงหน้านี้”

หลังจากทำการวิจัยข้างต้นแล้ว กลับมาที่คำพูดจาก Sonatype กันสักวินาที:

แม้ว่าคำกล่าวนี้จะถูกต้อง แต่ข้อเท็จจริงที่ว่าไม่มีเบราว์เซอร์หลักรายใดที่อนุญาตให้มีการแสวงหาผลประโยชน์เมื่อ Koa เวอร์ชันแรกเปิดตัว ข้อความที่ยกมานี้ชี้ให้เห็นถึงบางสิ่งที่น่าสนใจ นอกเหนือจากสิ่งที่ประโยคต้องการแนะนำ โปรดทราบว่าฉันกำลังจะเขียนการคาดเดา เนื่องจากฉันไม่ทราบแน่ชัดว่านักพัฒนา Koa คิดอย่างไร ฉันสามารถจินตนาการได้อย่างง่ายดายว่านักพัฒนาได้ทดสอบพฤติกรรมที่เป็นปัญหาโดยใช้เว็บเบราว์เซอร์ที่ทันสมัย พวกเขาอาจพบว่าการเข้ารหัส HTML นั้นเหมาะสม เนื่องจากเป็นไปไม่ได้อยู่แล้วที่จะถูกแทรกโค้ด JavaScript ที่เรียกใช้จากhrefคุณสมบัติของaแท็ก สิ่งนี้ทำให้เกิดคำถามที่จริงจัง หลังจากใช้เวลามากกว่าห้าปีที่ผ่านมาในด้านการพัฒนาซอฟต์แวร์ ฉันก็ใช้ได้เช่นกัน: ในฐานะนักพัฒนา หากฉันกำลังจะสร้างเทคโนโลยีเว็บใหม่สำหรับฝั่งแบ็กเอนด์ ฉันควรสนใจเว็บเบราว์เซอร์เก่าหรือไม่ และถ้าฉันควร คำแนะนำอย่างเป็นทางการจากชุมชนความปลอดภัยเกี่ยวกับระยะเวลาที่ฉันต้องพิจารณาเว็บเบราว์เซอร์รุ่นเก่าย้อนเวลากลับไปในอดีตคืออะไร เราไม่ควรพิจารณาว่าแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยสำหรับผู้ใช้ปลายทางคือการทำให้เบราว์เซอร์ของพวกเขาทันสมัยอยู่เสมอ และคุณลักษณะการอัปเดตอัตโนมัติก็มีไว้เพื่อช่วยเหลือด้วยเช่นกัน นอกจากนี้ หากเราคาดหวังให้นักพัฒนาระลึกไว้เสมอและทดสอบกับเบราว์เซอร์รุ่นเก่า เราไม่สามารถคาดหวังให้ผู้เชี่ยวชาญด้านความปลอดภัยทำเช่นเดียวกันและตั้งชื่อเว็บเบราว์เซอร์ทั้งหมดและเวอร์ชันของเบราว์เซอร์ที่มีส่วนทำให้เกิดปัญหาเฉพาะ แทนที่จะอ้างถึง "เบราว์เซอร์เก่า" ”? มันจะยุติธรรมเท่านั้น

สิ่งหนึ่งที่แน่นอน ไม่มีอะไรต้องกังวลตั้งแต่ปีนี้...

เบราว์เซอร์สมัยใหม่

ในการวิเคราะห์ของฉัน โดยใช้เว็บเบราว์เซอร์ ฉันตรวจสอบเนื้อหาการตอบสนองและพบว่าว่างเปล่า ฉันไม่ได้ตรวจสอบว่าการตอบกลับที่ส่งผ่านสายมีเนื้อหาหรือไม่ ปรากฎว่ามีเพียง Google Chrome ที่เพิกเฉยต่อเนื้อหาการตอบสนองโดยสิ้นเชิง ดังนั้นจึงไม่แสดง นั่นก็เพียงพอแล้วสำหรับฉัน มีเหตุผลฉันต้องเพิ่ม

ตั้งแต่นั้นมา ฉันได้ดูการตอบสนองของบริการเว็บทดสอบของฉันโดยใช้ Koa เวอร์ชันล่าสุด เราสามารถเห็นด้านล่างว่ามีเนื้อหาการตอบสนอง HTML ที่มีโค้ด JavaScript ที่แทรกอยู่ในนั้น:

*   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>.

การเปลี่ยนแปลงที่จะเกิดขึ้น

ด้านล่างนี้คือรายการอัปเดตที่ Sonatype กำลังวางแผนที่จะดำเนินการเกี่ยวกับปัญหานี้:

ปรับปรุงบรรทัดสรุป/ชื่อเรื่องเพื่อขจัดความเข้าใจผิด (เกิดขึ้นแล้ว)
ลดคะแนนช่องโหว่เหลือ 4.7 (เกิดขึ้นแล้ว)
ระบุว่าช่องโหว่นี้สามารถถูกโจมตีได้หากผู้ใช้ใช้เบราว์เซอร์รุ่นเก่าเท่านั้น

การเปลี่ยนแปลงเพิ่มเติมที่ฉันอยากเห็น

นอกเหนือไปจากการเปลี่ยนแปลงที่กล่าวถึงในส่วนที่แล้ว มีบางสิ่งที่สามารถปรับปรุงเพิ่มเติมได้ เหล่านี้คือ:

ลดคะแนนช่องโหว่ลงอีก โดยเฉพาะอย่างยิ่งสำหรับเวอร์ชัน Koa ที่ออกหลังปี 2018
รวมถึงหมายเลขเวอร์ชันของเว็บเบราว์เซอร์หลักและวันที่เผยแพร่เป็นอย่างน้อย ซึ่งรวมอยู่ในรายงานเมื่อกล่าวถึง "เบราว์เซอร์รุ่นเก่า" สิ่งนี้จะช่วยทุกคนอย่างมากเมื่อ "ให้คะแนนช่องโหว่ในการใช้งานที่กำหนดโดยใช้ไลบรารีที่ได้รับผลกระทบ" ตัวอย่างเช่น หากฉันเห็นว่าผู้ใช้ต้องใช้เบราว์เซอร์จากปี 2011 ฉันจะทำเครื่องหมายปัญหาเป็น "ไม่ได้รับผลกระทบ" ใน SCA ภายในหนึ่งวินาที ประหยัดเวลาได้มาก
เวอร์ชันของ Koa ที่ได้รับผลกระทบจะแสดงอยู่ใน หน้า ของช่องโหว่

อย่างไรก็ตาม Sonatype ยังกล่าวถึงว่าพวกเขามีการตรวจสอบที่ยอดเยี่ยมบางอย่างในข้อเสนอเชิงพาณิชย์ เช่น ทำการตรวจสอบจริงในระดับรหัสเพื่อดูว่าแอปพลิเคชันได้รับผลกระทบจากช่องโหว่ที่รายงานหรือไม่ ฟังดูเรียบร้อย และด้วยลักษณะนิยายวิทยาศาสตร์ของวิธีการคำนวณคะแนนช่องโหว่สำหรับห้องสมุด การตรวจสอบประเภทนี้จึงเป็นสิ่งจำเป็นเพื่อลดภาระของทีมวิศวกรรม โดยเฉพาะอย่างยิ่งหากสิ่งต่างๆ ยังคงเป็นเช่นนี้

บทสรุป

นั่นคือการอัปเดตทั้งหมดที่ฉันมี ฉันดีใจที่ติดต่อ Sonatype เพราะพวกเขาเป็นมืออาชีพและเป็นมิตรมาก เป็นเรื่องที่น่ายินดีที่ได้ร่วมงานกับพวกเขาในเรื่องนี้

เกี่ยวกับ XSS ใน Koa: เป็นเรื่องที่พวกเราไม่ควรกังวลมาหลายปีแล้ว