การแฮ็ค JavaScript ในเบราว์เซอร์ทำได้ง่ายขนาดไหน?

คำถามของฉันเกี่ยวกับความปลอดภัย JavaScript

ลองนึกภาพระบบการรับรองความถูกต้องที่คุณใช้เฟรมเวิร์ก JavaScript เช่นBackboneหรือAngularJSและคุณต้องการจุดปลายที่ปลอดภัย นั่นไม่ใช่ปัญหาเนื่องจากเซิร์ฟเวอร์มีคำสุดท้ายเสมอและจะตรวจสอบว่าคุณได้รับอนุญาตให้ทำสิ่งที่คุณต้องการหรือไม่

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

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

ผู้ใช้สามารถปรับเปลี่ยนตัวแปรนั้นและเข้าถึงได้ง่ายแค่ไหน?

ความรู้เกี่ยวกับความปลอดภัย (และ JavaScript) ของฉันไม่ได้ยอดเยี่ยม แต่ถ้าตัวแปรไม่ได้อยู่ในขอบเขตทั่วโลกและอยู่ในส่วนส่วนตัวของรูปแบบโมดูลซึ่งมีเพียง getters แต่ไม่ใช่ setters แม้ในกรณีนั้นคุณสามารถแฮ็คสิ่งนั้นได้หรือไม่

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

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

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

สมมติโปรโตคอลHTTPSเพื่อป้องกันการโจมตีจากคนกลาง (MITMA)

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

• ลูกค้าออฟไลน์อยู่ ลูกค้าต้องการดำเนินการที่เชื่อถือได้ ลูกค้าป้อนรหัสผ่านของเขาและคว้ากุญแจสาธารณะของเซิร์ฟเวอร์

• ตอนนี้ไคลเอ็นต์จะดำเนินการตามความรู้ของข้อมูลนั้นและลูกค้าจะเข้ารหัสทุกการกระทำที่ทำด้วยรหัสสาธารณะของเซิร์ฟเวอร์สำหรับลูกค้ารายนั้น

• เมื่อลูกค้าออนไลน์ลูกค้าจะส่งรหัสลูกค้าและการกระทำทั้งหมดที่ลูกค้าดำเนินการจะถูกส่งไปยังเซิร์ฟเวอร์ที่เข้ารหัสด้วยรหัสสาธารณะของเซิร์ฟเวอร์

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

บันทึก:

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

• คุณยังต้องใช้เซิร์ฟเวอร์เพื่อความปลอดภัยไม่ใช่ลูกค้า ทุกการกระทำที่ลูกค้าทำคุณต้องตรวจสอบความถูกต้องบนเซิร์ฟเวอร์

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

• สิ่งนี้ตรงกับความต้องการของคุณที่ดำเนินการ 'ไม่ ping ไปยังเซิร์ฟเวอร์' ผู้โจมตีไม่สามารถเลียนแบบคำร้องขอ HTTP พร้อมข้อมูลปลอมได้หากพวกเขาไม่ทราบรหัส

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

• นี่เป็นโครงร่างที่ค่อนข้างธรรมดาสำหรับแอปพลิเคชันหน้าเดียว (ตัวอย่างเช่นกับ AngularJS)

• ฉันเรียกคีย์สาธารณะของเซิร์ฟเวอร์ "สาธารณะ" เนื่องจากความหมายในรูปแบบเช่นRSAแต่จริงๆแล้วมันเป็นข้อมูลที่ละเอียดอ่อนในรูปแบบและควรได้รับการปกป้อง

• ฉันจะไม่เก็บรหัสผ่านไว้ทุกที่ในหน่วยความจำ ฉันจะให้ผู้ใช้ส่งรหัสผ่าน 'ออฟไลน์' ทุกครั้งที่เขา / เธอเริ่มใช้งานรหัสออฟไลน์

• อย่าม้วนการเข้ารหัสของคุณเอง - ใช้ไลบรารีที่รู้จักกันดีเช่น Stanford สำหรับการตรวจสอบสิทธิ์

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

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

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

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

วัสดุที่เกี่ยวข้อง:

• ใบรับรอง VS รหัสผ่านชื่อผู้ใช้
• ทำไมเราไม่สามารถรักษาความปลอดภัยผ่านทางฝั่งลูกค้า
• อย่าม้วน crypto ของคุณเอง
• การสนทนาที่เกี่ยวข้องเกี่ยวกับการทำให้ JS ปลอดภัยสำหรับการดำเนินการ crypto

ง่ายมาก: กลไกความปลอดภัยใด ๆ ที่อาศัยไคลเอนต์ให้ทำในสิ่งที่คุณบอกให้ทำนั้นอาจถูกโจมตีได้เมื่อผู้โจมตีมีอำนาจควบคุมลูกค้า

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

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

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

เมื่อข้อมูลของคุณออกจากเซิร์ฟเวอร์คุณต้องสมมติว่าผู้โจมตีสามารถเข้าถึงได้อย่างเต็มที่

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

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

พูดโดยเฉพาะเกี่ยวกับเชิงมุม:

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

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

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

หมายเหตุด้านข้าง: ไม่ควรมีสิ่งใดที่มีความอ่อนไหวอยู่ในเทมเพลตมุมมองที่แองกูลาร์ร้องขอ แต่อย่าทำเช่นนั้น ถ้ามีเหตุผลบางอย่างที่ทำให้คุณต้องปกป้องเทมเพลตมุมมองเหล่านั้นบนฝั่งเซิร์ฟเวอร์เช่นเดียวกับที่คุณทำถ้าคุณกำลังทำการเรนเดอร์ฝั่งเซิร์ฟเวอร์