เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ · SHA เครื่องคำนวณแฮช
ความสมบูรณ์ของทรัพยากรย่อย: วิธีที่เบราว์เซอร์ใช้ SHA-384 เพื่อตรวจสอบสคริปต์
· พื้นหลัง
sha-256 base64 เบราว์เซอร์-apis ความปลอดภัย
คุณลักษณะความสมบูรณ์ช่วยให้เบราว์เซอร์ปฏิเสธสคริปต์ CDN ที่ไบต์มีการเปลี่ยนแปลง โพสต์นี้จะอธิบายรูปแบบของแอตทริบิวต์ เหตุใด SHA-384 ใน base64 จึงเป็นตัวเลือกทั่วไป และสิ่งที่ SRI ไม่สามารถป้องกันได้
CDN ที่สามารถให้บริการได้ทุกอย่าง — ความเสี่ยงด้านห่วงโซ่อุปทาน SRI ได้รับการออกแบบมาเพื่อ
แท็กสคริปต์บนหน้าเว็บสามารถมีแอตทริบิวต์ความสมบูรณ์: `<script src="https://cdn.example.com/lib.js" integrity="sha384-..."></script>` ค่าความสมบูรณ์เป็นส่วนย่อยของการเข้ารหัสลับของไบต์ของสคริปต์ เมื่อเบราว์เซอร์ดาวน์โหลดสคริปต์ เบราว์เซอร์จะคำนวณการแยกย่อยของไบต์ที่ได้รับและเปรียบเทียบกับแอตทริบิวต์ความสมบูรณ์ หากตรงกัน แสดงว่าสคริปต์ถูกโหลด หากไม่ตรงกัน เบราว์เซอร์จะปฏิเสธที่จะโหลดและรายงานความล้มเหลวในคอนโซล วิธีนี้จะช่วยป้องกัน CDN ที่ให้บริการโค้ดที่ถูกแก้ไขที่ถูกบุกรุก หรือจากผู้โจมตีเครือข่ายที่ขัดขวางและเปลี่ยนแปลงการตอบสนอง
ความสมบูรณ์ของทรัพยากรย่อย (SRI) คือข้อกำหนด W3C ที่ใช้กับสคริปต์และสไตล์ชีต เป็นการรับประกันการเข้ารหัสเพียงอย่างเดียวที่เบราว์เซอร์สามารถทำได้เกี่ยวกับเนื้อหาของทรัพยากรข้ามต้นทาง: ไบต์จะต้องตรงกับข้อมูลสรุป ไม่เช่นนั้นทรัพยากรจะถูกปฏิเสธ สิ่งนี้ไม่ได้พิสูจน์ว่าใครเป็นผู้สร้างทรัพยากร เพียงแต่ว่าไม่มีการเปลี่ยนแปลงนับตั้งแต่มีการคำนวณการแยกย่อย สำหรับทรัพยากรที่ให้บริการมากกว่า HTTPS จาก CDN ที่มีชื่อเสียง ข้อมูลสรุปจะให้การป้องกันจาก CDN ที่ถูกบุกรุกหรือให้บริการเนื้อหาแคชเก่าแก่คุณโดยเฉพาะ
คุณลักษณะความสมบูรณ์ — คำนำหน้าอัลกอริทึม ยัติภังค์ การย่อย base64 และการรองรับแฮชหลายรายการ
แอตทริบิวต์ Integrity มีรูปแบบเฉพาะ: ชื่ออัลกอริทึม, ยัติภังค์, แยกย่อยใน base64 ตัวอย่าง: `integrity="sha384-JZDdQnrrAMe+sxxpn47in+PwhkxrCrt4SNvt+xWqV3zPJUkeFF0Qq/wNtuvNqPP5"` ชื่ออัลกอริทึมอาจเป็น SHA-256, SHA-384 หรือ SHA-512 Base64 เป็นการเข้ารหัส ไม่ใช่เลขฐานสิบหก นี่เป็นตัวเลือกโดยเจตนาตามข้อกำหนด SRI Base64 มีขนาดกะทัดรัดกว่าฐานสิบหก (สั้นกว่าประมาณ 33% สำหรับการแยกย่อยเดียวกัน) ซึ่งสำคัญเมื่อฝังในแอตทริบิวต์ HTML ยัติภังค์แยกชื่ออัลกอริทึมออกจากไดเจสต์ สามารถแสดงรายการค่าความสมบูรณ์ได้หลายค่า โดยคั่นด้วยช่องว่าง หากค่าใดค่าหนึ่งตรงกัน ทรัพยากรจะได้รับการยอมรับ
ทำไมต้อง SHA-384 ข้อกำหนด SRI อนุญาต SHA-256, SHA-384 และ SHA-512 SHA-384 กลายเป็นค่าเริ่มต้นของชุมชนเนื่องจากมียอดคงเหลือขนาด/security SHA-256 มีขนาดเล็กกว่า (32 bytes, 44 อักขระใน base64) แต่ SHA-384 กว้างกว่า (48 bytes, 64 อักขระใน base64) และไม่ได้เพิ่มขนาดแอตทริบิวต์อย่างมีนัยสำคัญเมื่อเทียบกับ SHA-256 SHA-512 พร้อมใช้งานแต่ไม่ค่อยได้ใช้เนื่องจากการสรุปข้อมูลขนาดใหญ่ดูเหมือนไม่จำเป็นสำหรับกรณีการใช้งานนี้ ตัวเลือก SHA-384 เป็นไปตามประวัติศาสตร์และใช้งานได้จริง ไม่ใช่การสะท้อนถึงคุณสมบัติด้านความปลอดภัยที่เหนือกว่า (ทั้งสามมีการเข้ารหัสที่แข็งแกร่งสำหรับจุดประสงค์นี้)
SHA-384 ได้รับการเสนอและสร้างวัสดุ base64 ที่จำเป็น ความชอบของชุมชนไม่ได้อนุมานจากเครื่องมือนี้
การเข้ารหัส Base64 ใน SRI เป็น base64 มาตรฐาน ไม่ใช่ base64url base64 มาตรฐานใช้อักขระ + และ / ซึ่งใช้ได้ในแอตทริบิวต์ HTML โดยไม่มีการเข้ารหัสเปอร์เซ็นต์ แม้ว่าจะมีความหมายพิเศษใน URL และข้อมูลแบบฟอร์มก็ตาม รูปแบบ SRI ได้รับการออกแบบมาสำหรับแอตทริบิวต์ HTML ไม่ใช่ URL ดังนั้น base64 มาตรฐานจึงเหมาะสม หากคุณกำลังสร้างค่าความสมบูรณ์ด้วยตนเอง คุณจะต้องคำนวณการแยกย่อย SHA-384 (ลำดับของไบต์) จากนั้นเข้ารหัสไบต์เหล่านั้นเป็น base64 มาตรฐาน จากนั้นเติม `sha384-` ข้างหน้า และวางลงในแอตทริบิวต์ความสมบูรณ์
เบราว์เซอร์ดำเนินการขั้นตอนเดียวกันในทางกลับกัน: แยก base64 ออกจากแอตทริบิวต์ Integrity, ถอดรหัสเป็นไบต์เพื่อกู้คืนไดเจสต์, คำนวณ SHA-384 ของไบต์ของสคริปต์ที่ดาวน์โหลด และเปรียบเทียบค่าไดเจสต์ทั้งสองค่า ต้องตรงกันทุกประการ ความแตกต่างเพียงเล็กน้อยในการแยกแยะทำให้เกิดการปฏิเสธ ไม่มีการจับคู่ที่คลุมเครือหรือเครดิตบางส่วน: ความสมบูรณ์เป็นแบบไบนารี
พฤติกรรม SRI แบบข้ามต้นทางต้องใช้เอกสารประกอบของเบราว์เซอร์นอกเหนือจากเครื่องคำนวณแฮชนี้
SRI ต้องใช้ CORS สำหรับการตอบกลับแบบข้ามต้นทาง หากคุณโหลดสคริปต์จากต้นทางอื่น เซิร์ฟเวอร์จะต้องตอบกลับด้วย `Access-Control-Allow-Origin: *` หรือส่วนหัวต้นทางเฉพาะที่มีของคุณ หากไม่มีส่วนหัว CORS เบราว์เซอร์จะไม่สามารถตรวจสอบ SRI ได้ เนื่องจากหากไม่มี CORS จะไม่สามารถยืนยันได้ว่าเนื้อหาการตอบกลับตรงกับที่เซิร์ฟเวอร์ตั้งใจจะส่ง ส่วนหัว CORS เป็นคำสั่งของเซิร์ฟเวอร์ว่าการตอบสนองนี้ปลอดภัยที่จะตรวจสอบ SRI คือการตรวจสอบของคุณว่าไบต์ถูกต้อง เมื่อรวมกันแล้วจะก่อให้เกิดข้อผูกพันด้านซัพพลายเชน: เซิร์ฟเวอร์อนุญาตให้คุณตรวจสอบเนื้อหาได้ และคุณก็ทำอย่างนั้น
หากสคริปต์ข้ามต้นทางไม่มีส่วนหัว CORS และมีแอตทริบิวต์ความสมบูรณ์ เบราว์เซอร์จะดาวน์โหลดสคริปต์นั้น (หากสคริปต์จากต้นทางนั้นได้รับอนุญาตจาก CSP ของไซต์) แต่จะไม่ตรวจสอบความสมบูรณ์ สคริปต์จะถูกโหลดราวกับว่าไม่มีแอตทริบิวต์ความสมบูรณ์ นี่ไม่ใช่ความล้มเหลวของ SRI; เป็นขอบเขตด้านความปลอดภัย: คุณไม่สามารถตรวจสอบคำตอบที่คุณไม่สามารถอ่านได้
จะเกิดอะไรขึ้นหากไม่ตรงกัน — เบราว์เซอร์จะบล็อกทรัพยากรและรายงานในคอนโซล
เมื่อเบราว์เซอร์ตรวจพบความสมบูรณ์ที่ไม่ตรงกัน เบราว์เซอร์จะปฏิเสธที่จะรันสคริปต์และบันทึกข้อความในคอนโซลของเบราว์เซอร์ โดยทั่วไปข้อความจะตั้งชื่อ URL ซึ่งเป็นแฮชที่คาดหวังและแฮชที่คำนวณ ความล้มเหลวเป็นแบบอะตอมมิก: ทรัพยากรถูกโหลดตามที่เป็นอยู่หรือถูกปฏิเสธทั้งหมด ไม่มีการโหลดหรือทางเลือกบางส่วน หากเว็บไซต์ใช้สคริปต์นั้นและถูกปฏิเสธ ไซต์อาจใช้งานไม่ได้ นี่เป็นการกระทำโดยเจตนา: การส่งโค้ดผิดนั้นแย่กว่าการไม่ส่งโค้ดเลย และความล้มเหลวแบบเงียบ ๆ จะทำให้การโจมตีคงอยู่ต่อไปอย่างไม่มีกำหนด
การทดสอบการตั้งค่า SRI นั้นตรงไปตรงมา โดยเปิดคอนโซลของเบราว์เซอร์ โหลดหน้าเว็บ และค้นหาข้อความเกี่ยวกับความสมบูรณ์ที่ไม่ตรงกัน หากคุณเห็นว่าไม่ตรงกัน ให้เปรียบเทียบแฮชที่คำนวณแล้วซึ่งแสดงในคอนโซลกับแฮชในแอตทริบิวต์ Integrity ของคุณ หากไม่ตรงกัน ให้คำนวณใหม่: สคริปต์อาจได้รับการอัปเดตแล้ว และคุณต้องมีสรุปข้อมูลใหม่
ตัวอย่างการทำงาน — คำนวณไดเจสต์สำหรับสคริปต์และจัดรูปแบบให้เป็นค่าความสมบูรณ์ รวมถึงขั้นตอน base64
การคำนวณการแยกย่อย SRI ด้วยตนเองต้องใช้เพียงไบต์ของสคริปต์และเครื่องมือแฮช ดาวน์โหลดสคริปต์ วางลงในเครื่องคำนวณแฮช ToolAcre SHA เลือก SHA-384 คัดลอกเอาต์พุต base64 (ไม่ใช่เลขฐานสิบหก) นำหน้า `sha384-` และวางลงในแอตทริบิวต์ความสมบูรณ์ หากสคริปต์มีขนาดใหญ่ การใช้ curl หรือ wget เพื่อบันทึกลงในไฟล์แล้วการอ่านไฟล์จะเร็วกว่าการวาง สำหรับสคริปต์แบบอินไลน์ (ในแท็ก `<script>` ใน HTML แทนที่จะเป็นจาก URL) SRI จะไม่สามารถใช้ได้ สคริปต์อินไลน์จะได้รับความเชื่อถือตามคำจำกัดความเสมอ SRI มีไว้สำหรับทรัพยากรภายนอก
ตัวอย่างการทำงาน: สมมติว่าคุณต้องการโหลด jQuery จาก CDN ด้วย SRI ค้นหาสคริปต์ URL ดาวน์โหลด (หรือใช้ curl เพื่อดึงข้อมูล) วางไบต์ลงในเครื่องคิดเลข หรือใช้ `sha384sum` บนบรรทัดคำสั่ง รับ SHA-384 แยกย่อยเป็น base64 และจัดรูปแบบเป็น `sha384-[base64-digest]` วางลงในแอตทริบิวต์ Integrity ของแท็กสคริปต์ โหลดหน้าเว็บและตรวจสอบว่าไม่มีข้อผิดพลาดของคอนโซลปรากฏขึ้น
สิ่งนี้ไม่ครอบคลุมถึง — สคริปต์ที่เปลี่ยนแปลงโดยเจตนา และไซต์เช่น ToolAcre ที่ไม่โหลดสคริปต์ภายนอกเลย ดังนั้นจึงไม่มีอะไรจะปักหมุด
SRI ไม่ได้ป้องกันการโจมตีด้านซัพพลายเชนทั้งหมด โดยจะป้องกันการเปลี่ยนแปลงไบต์หลังจากคำนวณไดเจสต์ แต่จะไม่ป้องกันไดเจสต์ที่คำนวณจากโค้ดที่ถูกบุกรุกตั้งแต่แรก หาก CDN ถูกโจมตีก่อนที่คุณจะคำนวณสรุปข้อมูล SRI ก็ไม่สามารถช่วยได้ การสรุปข้อมูลจะเชื่อถือได้พอๆ กับแหล่งที่มาที่คุณคำนวณเท่านั้น เพื่อความมั่นใจสูงสุด ให้คำนวณไดเจสต์จากแหล่งที่มาดั้งเดิม (เช่น รุ่น GitHub ของไลบรารี) และใช้ไดเจสต์เหล่านั้นเมื่อโหลดจาก CDN การสรุปจะกลายเป็นข้อผูกพันจากผู้ดูแลตลอดกระบวนการรีลีส
SRI ยังไม่ป้องกันเครือข่ายที่ถูกบุกรุกในขณะที่คุณคำนวณไดเจสต์ หรือต่อเครื่องพัฒนาที่ถูกบุกรุก จะป้องกันเฉพาะการเปลี่ยนแปลงสคริปต์ระหว่างเวลาที่สร้างสรุปและเวลาที่เบราว์เซอร์โหลดสคริปต์ เพื่อความมั่นใจอย่างต่อเนื่อง การปรับใช้บางอย่างใช้ Release Signing นอกเหนือจาก SRI: Release ได้รับการลงนามโดยคีย์ของผู้ดูแล คุณตรวจสอบลายเซ็น คำนวณการแยกย่อยจากไบต์ที่ตรวจสอบแล้ว และใช้สิ่งนั้นใน SRI
บทความนี้ไม่ได้ยืนยันคลังสคริปต์ภายนอกทั่วทั้งไซต์ของ ToolAcre จากแหล่งแฮช
เครื่องคำนวณแฮช ToolAcre SHA จะส่งเสียงการแยกย่อยใน base64 มาตรฐานโดยตรง (เนื่องจาก `base64` เอาต์พุตจากฟังก์ชัน `toBase64()`) หากต้องการแปลงเป็นรูปแบบ SRI ให้เพิ่มชื่ออัลกอริทึมและเครื่องหมายยัติภังค์ไว้หน้า: `sha256-`, `sha384-` หรือ `sha512-` เครื่องคิดเลขไม่ใช้คำนำหน้านั้นโดยอัตโนมัติเนื่องจากมีแฮชปรากฏในหลายบริบท (git, Docker, npm, URL) โดยที่ชื่ออัลกอริทึมแยกหรือเข้ารหัสแตกต่างกัน ขอบเขตชัดเจน: เครื่องคิดเลขแฮชข้อความ UTF-8 ที่คุณวาง ไม่ใช่ไฟล์หรือไบนารีคีย์ มันส่งออกทั้ง hex และ base64 คุณเลือกได้ว่าจะใช้อันไหนตามบริบทของคุณ สำหรับ SRI จำเป็นต้องใช้ base64 ตามข้อกำหนด สำหรับคอมไพล์และเครื่องมืออื่นๆ ฐานสิบหกถือเป็นเรื่องธรรมดา สำหรับ npm และ Go จะใช้ base64 ตัวเลือกการเข้ารหัสเป็นของคุณ ไบต์ย่อยจะเหมือนกัน
SRI ยังคงเป็นหนึ่งในการตรวจสอบการเข้ารหัสลับไม่กี่แบบที่เบราว์เซอร์สามารถดำเนินการฝั่งไคลเอ็นต์ได้โดยไม่ต้องมีอำนาจจากส่วนกลาง การประมวลผลจะแยกแยะตัวคุณเองด้วยเครื่องมือที่เชื่อถือได้ เช่น เครื่องคิดเลข SHA ของ ToolAcre และการตรวจสอบกับทรัพยากรที่โหลดไว้เป็นวิธีที่เข้าถึงได้เพื่อทำให้เว็บไซต์แข็งแกร่งขึ้นจากการโจมตีห่วงโซ่อุปทานบางอย่าง การป้องกันจะดีพอๆ กับการแยกย่อยเท่านั้น คำนวณใหม่ทุกครั้งหลังการอัปเดตทรัพยากรภายนอก และทดสอบว่าเบราว์เซอร์โหลดสคริปต์โดยไม่ปฏิเสธ