บทความนี้จะจัดการกับช่องโหว่ของ OAUTH ที่รู้จักกันดี ผู้อ่านจะเรียนรู้วิธีการใช้การอนุญาตที่ปลอดภัยและปลอดภัยในเว็บแอปพลิเคชัน
OAuth เป็นโปรโตคอลที่เชื่อถือได้ แต่ระดับความปลอดภัยส่วนใหญ่ขึ้นอยู่กับการรับรู้ของนักพัฒนาเว็บเมื่อใช้การอนุญาต สิ่งนี้ทำให้หัวข้อนี้สำคัญอย่างยิ่งสำหรับผู้เชี่ยวชาญด้านความปลอดภัยของข้อมูล พวกเขาจำเป็นต้องให้การป้องกันบัญชีของผู้ใช้ในระดับสูง ถึงเวลาที่จะทำความคุ้นเคยกับผู้ปฏิบัติงานที่มีประสิทธิภาพที่จะช่วยลดอันตรายจากการขายที่ไม่ดีของ OAuth
บทนำโปรโตคอล OAuth 2.0 ใช้กันอย่างแพร่หลายในการใช้งานที่หลากหลาย การใช้งานอินเทอร์เฟซผู้ใช้ที่สะดวกจะพร้อมใช้งานการรับรองความถูกต้องและการอนุญาตที่ง่ายขึ้นเมื่อเทียบกับวิธีการแบบดั้งเดิมสำหรับการป้อนชื่อผู้ใช้และรหัสผ่าน ด้วยการใช้งานที่เหมาะสมและรอบคอบโปรโตคอล OAUTH จะปลอดภัยกว่าการอนุญาตแบบดั้งเดิมเนื่องจากผู้ใช้ไม่จำเป็นต้องแบ่งปันข้อมูลการบัญชีของพวกเขากับแอปพลิเคชันบุคคลที่สามเพื่อเข้าถึงทรัพยากรที่เฉพาะเจาะจง ผู้ใช้มักจะชอบที่จะเข้าสู่ระบบโดยใช้บัญชี Google, Facebook หรือ LinkedIn ของพวกเขาแทนที่จะสร้างบัญชีใหม่ทุกครั้งที่คุณต้องลงทะเบียนในเว็บไซต์บางแห่ง ดังนั้นโปรโตคอล OAUTH ทำให้ชีวิตของเราง่ายขึ้นอย่างมาก
โดยทั่วไปผู้ให้บริการ OAUTH ยอดนิยมมีความน่าเชื่อถือมาก เข้าสู่ระบบด้วยบัญชี Google หรือ Facebook เป็นแรงบันดาลใจให้ความปลอดภัยบางอย่างและมันถูกต้อง โปรโตคอลถูกทดสอบอย่างถี่ถ้วนโดยผู้เชี่ยวชาญ ช่องโหว่ที่มีอยู่ทั้งหมดได้รับการแก้ไขอย่างรวดเร็วโดยทีมนักพัฒนาซอฟต์แวร์ อย่างไรก็ตามมันเป็นที่น่าสังเกตว่าความรู้สึกของความปลอดภัยที่สมบูรณ์สามารถเป็นเท็จได้
ผู้ให้บริการ OAUTH ปล่อยให้ผู้พัฒนาแอปพลิเคชันมีเหตุผลมากมายในการติดต่อกับความปลอดภัยของโปรแกรมของพวกเขา ในความเป็นจริงบริการ OAUTH ที่ได้รับการคุ้มครองในขั้นต้นดำเนินการอย่างไม่ถูกต้องในกระบวนการติดตั้งสามารถกลายเป็นเป้าหมายที่ง่ายสำหรับผู้บุกรุก ความลุ่มหลงเช่นนี้จะนำไปสู่การขโมยข้อมูลส่วนบุคคลของผู้ใช้
ต่อไปคุณควรพิจารณาช่องโหว่ที่พบบ่อยที่สุดในแอปพลิเคชันของบุคคลที่สามที่ใช้โปรโตคอล OAUTH เพื่อมอบอำนาจให้ผู้ใช้ของพวกเขา ต้องจำไว้ว่าโปรโตคอลนั้นปลอดภัยและเชื่อถือได้ หลังจากการใช้งานที่ไม่ถูกต้องจะกลายเป็นเสี่ยงต่อการโจมตีของแฮ็กเกอร์
OAUTH TOCKEY ขโมยโดยใช้ส่วนหัวของผู้อ้างอิงเมื่อแอปพลิเคชันร้องขอการอนุญาตในนามของผู้ใช้ที่ OAUTH Server บุคคลจะได้รับรหัสเพื่อป้อนและส่งกลับไปยังเซิร์ฟเวอร์สำหรับการตรวจสอบที่ตามมา หากในระหว่างการทำงานผู้ใช้จะถูกนำไปยังหน้าอื่นรหัสจะถูกมองเห็นในส่วนหัว "ผู้อ้างอิง" ของคำขอ HTTP ดังนั้นรหัสจะตกลงบนเว็บไซต์ภายนอกซึ่งจะคุกคามข้อมูลผู้ใช้ที่ลงทะเบียนบนเซิร์ฟเวอร์ OAUTH
หมายเหตุ: ส่วนหัวของการอ้างอิงเป็นส่วนหัวของ HTTP Query นั้นจะส่งโฮสต์ URL ที่ส่งคำขอ
เพื่อลดผลที่ตามมาของช่องโหว่นี้นักพัฒนาต้องตรวจสอบให้แน่ใจว่าเว็บแอปพลิเคชันไม่มีการฉีด HTML ใด ๆ หากตรวจพบการฉีดผู้โจมตีสามารถตั้งค่าแท็กรูปภาพไปยังเว็บเซิร์ฟเวอร์และหาวิธีเปลี่ยนเส้นทางผู้ใช้ได้อย่างง่ายดาย ดังนั้นเขาจะได้รับโอกาสที่จะขโมยรหัสจากส่วนหัว "ผู้อ้างอิง" ของคำขอ HTTP
OAUTH TOCKEY ขโมยโดยใช้พารามิเตอร์ Redirect_uriแอปพลิเคชั่นเริ่มต้นกระบวนการอนุญาตโดยส่งคำขอไปยังเซิร์ฟเวอร์ OAUTH:
https://www.example.com/signin/authorize ray. כככ&redirect_uri. httpps://demo.example.com/loginsuccessful
แบบสอบถามมักจะมีพารามิเตอร์ "redirect_uri" ที่ใช้โดยเซิร์ฟเวอร์ OAUTH เพื่อส่งโทเค็นกลับไปที่แอปพลิเคชันหลังจากผู้ใช้ให้ความยินยอมของเขา หากไม่ได้ควบคุมค่าของพารามิเตอร์นี้หรือไม่ได้ตรวจสอบผู้โจมตีสามารถเปลี่ยนและเปลี่ยนเส้นทางการร้องขอไปยังเว็บไซต์ได้อย่างง่ายดายซึ่งใช้โปรแกรมพิเศษสำหรับการประมวลผลโทเค็นและเข้าถึงทรัพยากรที่ จำกัด
https://www.example.com/signin/authorize คืออะไร. asdire_.urie=httpps://localhost.evil.com
บางครั้ง URL ที่คล้ายกันจะถูกบล็อก ผู้โจมตีสามารถเปลี่ยนเส้นทางข้อมูลที่ได้รับใน URL ที่เปิดอยู่เช่นนี้:
https://www.example.com/oauth20_authorize.srf? ه .. ; v&redirect_uri=httpps://accounts.google.com/backtoouthsubtarget?next=httpset://evil.com
หรือสิ่งนี้:
https://www.example.com/oauth2/authorize? [... ]% iRect_uri = https% 3a% 2f% 2fapps.facebook.com% 2fattacker% 2f.
เมื่อใช้ OAUTH คุณไม่สามารถรวมทั้งโดเมนในรายการสีขาว ควรเพิ่ม URL เพียงไม่กี่ตัวใน "redirect_uri" ที่ไม่ได้เปลี่ยนทิศทางการร้องขอการเปลี่ยนเส้นทางแบบเปิด
การปลอมแปลงคำขอข้ามบรรทัดการปลอมแปลงคำขอที่เปลี่ยนแปลงอาจเกิดขึ้นเมื่อผู้โจมตีประสบความสำเร็จในการทำให้เหยื่อคลิกที่ลิงค์ของเขาและดังนั้นเพื่อสร้างคำขอที่ว่าเขาจะไม่สร้าง การปลอมแปลงคำขอข้ามบรรทัดมักจะอ่อนลงด้วยโทเค็น CSRF ซึ่งเชื่อมโยงกับเซสชันผู้ใช้ ช่วยให้แอปพลิเคชันตรวจสอบบุคคลของบุคคลที่ส่งคำขอ พารามิเตอร์ "รัฐ" ในโปรโตคอล OAUTH ทำหน้าที่เป็นโทเค็น CSRF
มันคุ้มค่าที่จะดูว่าการโจมตีของ CSRF ดำเนินการเกี่ยวกับ OAuth และเป็นพารามิเตอร์ "รัฐ" สามารถใช้เพื่อลดผลกระทบของช่องโหว่
แฮ็กเกอร์เปิดเว็บแอปพลิเคชันและเปิดตัวกระบวนการอนุญาตเพื่อเข้าถึงผู้ให้บริการโดยใช้ OAuth แอปพลิเคชันร้องขอผู้ให้บริการในการเข้าถึงที่ต้องการให้ แฮ็กเกอร์จะถูกนำไปยังเว็บไซต์ผู้ให้บริการที่คุณมักจะต้องป้อนชื่อผู้ใช้และรหัสผ่านของคุณเพื่ออนุมัติการเข้าถึง แฮ็กเกอร์จับและป้องกันคำขอนี้และบันทึก URL ของตน แฮ็กเกอร์เป็นสาเหตุของเหยื่อที่จะเปิด URL นี้ หากเหยื่อเข้าสู่ระบบของผู้ให้บริการโดยใช้บัญชีข้อมูลรับรองจะถูกใช้เพื่อออกรหัสการอนุญาต รหัสการอนุมัติการแลกเปลี่ยนการเข้าถึงโทเค็นการเข้าถึง ตอนนี้บัญชีแฮ็กเกอร์ในแอปพลิเคชันได้รับอนุญาต สามารถเข้าถึงบัญชีของเหยื่อได้
ดังนั้นฉันจะป้องกันไม่ให้สถานการณ์นี้ใช้พารามิเตอร์ "รัฐ" ได้อย่างไร
แอปพลิเคชันจะต้องสร้างค่าที่เป็นไปตามบัญชีต้นฉบับ (ตัวอย่างเช่นใช้ปุ่มแฮชเซสชันผู้ใช้) มันไม่สำคัญมากในสิ่งที่เป็นสิ่งสำคัญคือค่านั้นเป็นเอกลักษณ์และสร้างขึ้นโดยใช้ข้อมูลส่วนตัวเกี่ยวกับผู้ใช้ดั้งเดิม มันถูกกำหนดให้กับพารามิเตอร์ "รัฐ"
ค่านี้จะถูกส่งไปยังผู้ให้บริการเมื่อเปลี่ยนเส้นทาง ตอนนี้แฮ็กเกอร์เชิญเหยื่อให้เปิด URL ซึ่งเขายังคงอยู่
รหัสการอนุญาตจะถูกออกและส่งกลับไปยังไคลเอนต์ในเซสชั่นพร้อมกับพารามิเตอร์ "รัฐ"
ไคลเอ็นต์สร้างค่าพารามิเตอร์ตามข้อมูลเซสชันและเปรียบเทียบกับค่า "สถานะ" ซึ่งถูกส่งกลับจากการร้องขอการอนุญาตไปยังผู้ให้บริการ ค่านี้ไม่ตรงกับพารามิเตอร์ "รัฐ" ในแบบสอบถามเนื่องจากมีการสร้างขึ้นบนพื้นฐานของข้อมูลเกี่ยวกับเซสชันปัจจุบันเท่านั้น เป็นผลให้คุณค่าที่ได้รับไม่ได้รับการยอมรับจากระบบ
ช่องโหว่อื่น ๆ ที่ตรวจพบเมื่อการใช้งาน OAUTH รวมถึงความสามารถในการดำเนินการ XSS (สคริปต์ข้ามไซต์) โดยใช้พารามิเตอร์ "redirect_uri" การตั้งค่าคีย์ส่วนตัว OAUTH (บางครั้งคีย์สามารถรับได้เมื่อถอดรหัสแอปพลิเคชันมือถือ) และการละเมิดกฎรหัสการอนุญาต (เมื่อ รหัสการอนุญาตสามารถใช้งานได้มากกว่าหนึ่งครั้งเพื่อออกโทเค็นการเข้าถึงหลายครั้ง) ช่องโหว่เหล่านี้มีน้อยกว่าที่อธิบายไว้ข้างต้น แต่มันไม่ได้ทำให้พวกเขาอันตรายน้อยลง นักพัฒนาควรรู้วิธีปฏิบัติที่จำเป็นทั้งหมดเพื่อให้แน่ใจว่าการทำงานของเว็บแอปพลิเคชันที่เชื่อถือได้
ผู้เขียนบทความที่แปล: Simon Saliba
สำคัญ! ข้อมูลเพียงเพื่อวัตถุประสงค์ทางวิชาการ โปรดปฏิบัติตามกฎหมายและไม่ใช้ข้อมูลนี้เพื่อวัตถุประสงค์ที่ผิดกฎหมาย
วัสดุที่น่าสนใจมากขึ้นบน cisoclub.ru สมัครสมาชิกกับเรา: Facebook | vk | ทวิตเตอร์ | Instagram โทรเลข เซน | Messenger | ICQ ใหม่ | YouTube | ชีพจร.