ฉันจะแน่ใจได้อย่างไรว่าไฟล์ JavaScript ของฉันที่ส่งผ่าน CDN จะไม่มีการเปลี่ยนแปลง

88

ฉันกำลังดำเนินการกับสถานการณ์ที่จะต้องโฮสต์ไฟล์ JavaScript บางไฟล์บน CDN ฉันต้องการมีกลไกบางอย่างเพื่อให้เมื่อดาวน์โหลดไฟล์เหล่านี้จากฝั่งผู้ใช้ฉันสามารถมั่นใจได้ว่าไฟล์ไม่ได้ถูกดัดแปลงและมาจาก CDN ที่ระบุ

ฉันเข้าใจว่างานนี้ง่ายมากถ้าฉันใช้ SSL แต่ถึงกระนั้นฉันก็ต้องการให้แน่ใจว่าไฟล์ที่ถูกต้องจะได้รับการให้บริการแม้ใน HTTP ที่ไม่มี SSL

เท่าที่ฉันสามารถค้นหาไม่มีกลไกที่มีอยู่เช่นลายเซ็นดิจิทัลสำหรับไฟล์ JavaScript ซึ่งรองรับในทุกแพลตฟอร์ม อาจจะไม่จำเป็น?

มีวิธีการบางอย่างที่สร้างขึ้นในเบราว์เซอร์เพื่อตรวจสอบผู้เขียนไฟล์ JavaScript หรือไม่ มีอะไรที่ฉันสามารถทำได้เพื่อให้ปลอดภัยหรือไม่?

javascript  code-signing 
— บาบา 26
แหล่งที่มา
13
ในขณะที่ฉันพบว่าคำถามนี้น่าสนใจ แต่ก็ไม่ได้นอกประเด็นใช่หรือไม่
— evolutionxbox
20
ทำไมคุณถึงให้บริการไฟล์บน http
— njzk2
12
“ แต่ทำไมไม่มีกลไกแบบนั้น” เพราะมันยากจริงๆ . เมื่อข้อมูลของคุณออกจากเซิร์ฟเวอร์ของคุณแล้วระบบจะหยุดทำงาน HTTPS ช่วยได้ แต่หากเป็นการเชื่อมต่อ HTTP ธรรมดาการตรวจสอบความถูกต้องอาจล้มเหลว (หรือมากกว่า - ผ่าน) การโจมตี MITM สามารถแก้ไขลายเซ็นที่คุณคาดไว้และ / หรือลายเซ็นของสิ่งที่คุณให้มาก่อนที่เบราว์เซอร์จะได้รับความคาดหวัง ดังนั้นเมื่อผู้ใช้ได้รับน้ำหนักบรรทุกบางส่วนก็ถือว่าปลอดภัยอย่างสมบูรณ์ ... เมื่อไม่จำเป็นต้องเป็นเช่นนั้น
— VLAZ
4
“ แต่ทำไมไม่มีกลไกแบบนั้น” เนื่องจากมีโซลูชันราคาถูกมีประสิทธิภาพและใช้ได้อย่างกว้างขวางใน HTTPS อยู่แล้ว
— Kevin Krumwiede
9
สิ่งนี้น่าจะอยู่ใน ServerFault หรือความปลอดภัยเนื่องจากเป็นเรื่องเกี่ยวกับการให้บริการไฟล์ด้วยวิธีที่ปลอดภัยและความสัมพันธ์ใด ๆ กับการเขียนโปรแกรมเป็นเพียงการสัมผัสแทนกันเท่านั้นเนื่องจากไฟล์ดังกล่าวเกิดขึ้นเพื่อแสดงซอร์สโค้ด
— underscore_d

คำตอบ:

140

เป็นเรื่องของความเป็นจริงที่มีคุณลักษณะเช่นนี้ได้ในขณะนี้ถูกร่างภายใต้ชื่อของSubresource ความซื่อสัตย์ ดูintegrityแอตทริบิวต์ของ<script>แท็ก แม้ว่าจะยังไม่ได้รับการรับรองอย่างสมบูรณ์ทั่วทั้งคณะแต่ก็ตอบสนองวัตถุประสงค์นี้ได้

integrity

มีข้อมูลเมตาแบบอินไลน์ที่ตัวแทนผู้ใช้สามารถใช้เพื่อตรวจสอบว่าทรัพยากรที่ดึงมาได้ถูกส่งมอบโดยปราศจากการจัดการที่ไม่คาดคิด โปรดดูที่ Subresource Integrity

ที่มา

Subresource Integrity (SRI) เป็นคุณลักษณะด้านความปลอดภัยที่ช่วยให้เบราว์เซอร์ตรวจสอบได้ว่าไฟล์ที่ดึงมา (เช่นจาก CDN) ถูกส่งโดยไม่มีการจัดการที่ไม่คาดคิด ทำงานโดยให้คุณระบุแฮชการเข้ารหัสที่ไฟล์ที่ดึงมาต้องตรงกัน

ที่มา

ตัวอย่าง:

<script src="https://example.com/example-framework.js"
    integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    crossorigin="anonymous"></script>

อย่างไรก็ตามโปรดทราบว่าสิ่งนี้จะไม่ป้องกันคุณจากการโจมตีของMan in the Middleหากคุณกำลังถ่ายโอนทรัพยากรของคุณผ่าน HTTP ธรรมดา ในกรณีนี้ผู้โจมตีสามารถปลอมรหัสแฮชได้ทำให้การป้องกันไฟล์สคริปต์ที่ถูกจัดการนั้นไร้ประโยชน์

ด้วยเหตุนี้คุณจึงควรใช้การเชื่อมต่อ HTTPS ที่ปลอดภัยแทน HTTP ธรรมดานอกเหนือจากมาตรการรักษาความปลอดภัยที่อธิบายไว้ข้างต้น

— Timo
แหล่งที่มา
9
ฉันคิดว่ามันคุ้มค่าที่จะกล่าวถึงการตรวจสอบความสมบูรณ์สามารถปลอมแปลงได้อย่างง่ายดายโดยสมมติว่า OP มีแผนที่จะส่ง HTML ของพวกเขาใน HTTP รวมทั้งไฟล์เนื้อหาของพวกเขา หากไซต์ของพวกเขาเป็น HTTPS และต้องการให้บริการเนื้อหาผ่าน HTTP เบราว์เซอร์ส่วนใหญ่จะไม่ชอบสิ่งนี้และเพิกเฉยต่อเนื้อหา HTTP
— MonkeyZeus
3
@MonkeyZeus นี่จะเป็นจริงเท่านั้นแม้ว่าในกรณีของการโจมตี MITM หรือถ้าเซิร์ฟเวอร์ของเราถูกบุกรุกถูกต้อง? ความเข้าใจของฉันคือคำถามนั้นถามอย่างชัดเจนว่าจะป้องกัน CDN ที่ถูกบุกรุกได้อย่างไร
— Timo
10
@TimoSta เป๊ะ! หากไม่มีการตรวจสอบเหล่านี้หากคุณรวมสคริปต์จากเช่นhttps://code.jquery.com/นั้นใครก็ตามที่บุกรุกcode.jquery.comสามารถ XSS ไซต์ของคุณได้ไม่ว่าcode.jquery.comจะเข้าถึงผ่าน HTTPS หรือไม่ก็ตาม ด้วยการตรวจสอบเหล่านี้ผู้โจมตีสามารถป้องกันไม่ให้สคริปต์โหลดเท่านั้นไม่สามารถแทนที่ด้วยสคริปต์ที่เป็นอันตรายได้
— Ajedi32
1
@MonkeyZeus ฉันได้เพิ่มบันทึกในคำตอบของฉันโดยระบุข้อกังวลของคุณ คุณเห็นด้วยกับคำพูดหรือไม่?
— Timo
1
@TimoSta ดีมากชอบ! btw ฉัน +1 ก่อนที่ฉันจะโพสต์ความคิดเห็นแรกของฉัน :-)
— MonkeyZeus
36

คุณกำลังมองหาการตรวจสอบความสมบูรณ์ของแหล่งข้อมูลย่อย

ตัวอย่างเช่นนี่คือข้อมูลโค้ด jQuery CDN:

<script src="https://code.jquery.com/jquery-3.1.0.js"
        integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk="
        crossorigin="anonymous"></script>
— ไบรอัน
แหล่งที่มา
2
ไร้ประโยชน์โดยสิ้นเชิงเพราะผู้โจมตีสามารถแก้ไขฟิลด์ความสมบูรณ์ได้ในเวลาเดียวกันพวกเขาแก้ไขสคริปต์ที่คุณกำลังดาวน์โหลด
— Lightness Races ใน Orbit
15
@LightnessRacesinOrbit: ไม่ได้ถ้าคุณสามารถควบคุมโดเมนของคุณเองซึ่งเข้าถึงได้ผ่าน HTTPS code.jquery.comแต่ไม่ควบคุม สิ่งนี้สามารถปกป้องคุณจากการบุกรุกcode.jquery.comได้
— SilverlightFox
2
@SilverlightFox: เอาล่ะไร้ประโยชน์โดยสิ้นเชิงกับการโจมตีของ MITM *
— Lightness Races in Orbit
@LightnessRacesinOrbit ใช่ ยังคงมีประโยชน์มากและจะป้องกันการโจมตีนี้ได้เช่นbleepingcomputer.com/news/security/…
— Adrian Mouat
6

ข้อจำกัดความรับผิดชอบ: เช่นเคยคุณควรพิจารณาว่ากลไกเหล่านี้ใช้งานได้เฉพาะเมื่อใช้ https เนื่องจากสามารถปิดใช้งานผ่าน MitM ด้วย http

นอกจากกลไกในคำตอบข้างต้นแล้วคุณยังสามารถใช้ส่วนหัวการตอบสนอง http นโยบายความปลอดภัยของเนื้อหาในเพจระดับบน

http://www.html5rocks.com/en/tutorials/security/content-security-policy/

นโยบายความปลอดภัยเนื้อหา: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng ='

มีบางสิ่งที่ควรทราบที่นี่ คำนำหน้า sha * - ระบุอัลกอริทึมที่ใช้สร้างแฮช ในตัวอย่างด้านบนใช้ sha256- CSP ยังรองรับ sha384- และ sha512- เมื่อสร้างแฮชอย่าใส่แท็ก นอกจากนี้การใช้อักษรตัวพิมพ์ใหญ่และช่องว่างรวมถึงช่องว่างนำหน้าหรือต่อท้าย

การใช้ Chrome 40 ขึ้นไปคุณสามารถเปิด DevTools จากนั้นโหลดหน้าของคุณซ้ำ แท็บคอนโซลจะมีข้อความแสดงข้อผิดพลาดพร้อมแฮช sha256 ที่ถูกต้องสำหรับสคริปต์อินไลน์แต่ละสคริปต์ของคุณ

กลไกนี้มีมาระยะหนึ่งแล้วดังนั้นการรองรับเบราว์เซอร์จึงค่อนข้างดีอย่าลืมตรวจสอบ

นอกจากนี้หากคุณต้องการให้แน่ใจว่าเบราว์เซอร์รุ่นเก่าที่ไม่เป็นไปตามข้อกำหนดจะไม่ปลอดภัยคุณสามารถรวมสคริปต์การเปลี่ยนเส้นทางแบบซิงโครนัสไว้ที่ด้านบนสุดของเพจที่นโยบายไม่อนุญาต

— ฟาบิโอเบลตรามินี
แหล่งที่มา
มีมาระยะหนึ่งแล้ว แต่การรองรับเบราว์เซอร์ไม่ค่อยดีนัก caniuse.com/subresource-integrity
— Sp0T
@ Sp0t - ความสมบูรณ์ของทรัพยากรย่อย (ลิงก์ของคุณเกี่ยวกับอะไร) เป็นกลไกในคำตอบอื่น ๆ คำตอบของฉันเกี่ยวกับนโยบายความปลอดภัยของเนื้อหาซึ่งได้รับการสนับสนุนที่ดีกว่ามาก
— Fabio Beltramini
3

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

— ddyer
แหล่งที่มา
2

หากโมเดลฝ่ายตรงข้ามของคุณอนุญาตให้ผู้โจมตีแก้ไขไฟล์ JavaScript ตามที่ส่งมาจาก CDN โมเดลฝ่ายตรงข้ามของคุณจะอนุญาตให้ผู้โจมตีแก้ไขแหล่งอ้างอิงตามที่ส่งมาเพื่อลบความพยายามใด ๆ ในการตรวจสอบเพื่อแก้ไขที่อยู่ต้นทางเป็นอื่นที่ไม่ใช่ CDN และ / หรือเพื่อลบการอ้างอิงถึง JavaScript ทั้งหมด

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

/ etc / hosts:

#  ...
1.2.3.4    vile-pirates.org    trustworthy.cdn
#  ...
— อาคาร Eric Towers
แหล่งที่มา
2
ประโยคแรกไม่จริงอย่างชัดเจน จะเกิดอะไรขึ้นถ้าหน้าอ้างอิงถูกโหลดผ่าน HTTPS และไฟล์ JavaScript ถูกโหลดผ่าน HTTP-not-S?
— user253751
หรือจะเกิดอะไรขึ้นถ้าตัว CDN ถูกบุกรุก แต่ไม่ใช่เซิร์ฟเวอร์ของคุณเอง?
— Ajedi32
@immibis: ฉันเลือกที่จะถือว่า OP ไม่ไร้เหตุผลที่จะเสนอสถานการณ์ดังกล่าว
— Eric Towers
1
@immibis นั่นไม่ใช่เหตุผลที่เบราว์เซอร์โดยทั่วไปไม่อนุญาตให้หน้า HTTPS โหลด JS ผ่าน HTTP?
— Barmar
1
@immibis ฉันบอกว่ามันช่วยปรับปรุงสถานการณ์ที่ไม่สามารถทำได้เพราะเบราว์เซอร์ไม่อนุญาต
— Barmar
1

คุณสามารถมั่นใจได้ด้วย Subresource Integrity CDN สาธารณะจำนวนมากรวมแฮช SRI ไว้ในโค้ดที่ฝังได้ที่นำเสนอบนเว็บไซต์ CDN ตัวอย่างเช่นใน PageCDN เมื่อคุณคลิกที่ไฟล์ jquery ในหน้าjQuery CDNคุณจะได้รับตัวเลือกในการคัดลอก URL หรือใช้แท็กสคริปต์ที่มีแฮช SRI ดังต่อไปนี้:

<script src="https://pagecdn.io/lib/jquery/3.4.1/jquery.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script>

ในการโหลดหน้าเว็บเบราว์เซอร์จะส่งคำขอสำหรับทรัพยากรนี้และเมื่อเสร็จสิ้นการร้องขอจะจับคู่แฮชของไฟล์ที่ได้รับกับไฟล์ที่ระบุเป็นค่าความสมบูรณ์ในแท็กสคริปต์ หากแฮชทั้งสองไม่ตรงกันเบราว์เซอร์จะทิ้งไฟล์ jquery

ในขณะนี้คุณสมบัตินี้รองรับ 91% ของเบราว์เซอร์ทั่วโลก รายละเอียดเพิ่มเติมเกี่ยวcaniuse

— 5377037
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.