หากฉันใช้การตรวจสอบความถูกต้องตามชื่อผู้ใช้ / รหัสผ่านจะไม่ปลอดภัยเพียงพอหรือไม่?
ไม่เพราะคุณระบุเพียงว่าWHOกำลังเข้าถึงเซิร์ฟเวอร์ API แต่ไม่ใช่สิ่งที่กำลังเข้าถึง
ความแตกต่างระหว่าง WHO และ WHAT คือการเข้าถึงเซิร์ฟเวอร์ API
เพื่อให้เข้าใจถึงความแตกต่างระหว่างWHOและสิ่งที่กำลังเข้าถึงเซิร์ฟเวอร์ API ได้ดีขึ้นลองใช้ภาพนี้:
ช่องทางการสื่อสารที่ตั้งใจหมายถึงแอปบนอุปกรณ์เคลื่อนที่ที่คุณใช้งานตามที่คุณคาดหวังโดยผู้ใช้ที่ถูกต้องโดยไม่มีเจตนาร้ายใด ๆ โดยใช้แอปบนอุปกรณ์เคลื่อนที่เวอร์ชันที่ไม่ได้รับการดูแลและสื่อสารโดยตรงกับเซิร์ฟเวอร์ API โดยไม่ต้องถูกคนตรงกลางโจมตี
ช่องจริงอาจแสดงสถานการณ์ที่แตกต่างกันเช่นผู้ใช้ที่ถูกต้องที่มีเจตนาร้ายซึ่งอาจใช้แอปมือถือเวอร์ชันบรรจุใหม่แฮ็กเกอร์ที่ใช้แอปมือถือเวอร์ชันของแท้ในขณะที่คนที่อยู่ตรงกลางโจมตีช่องนั้นเพื่อทำความเข้าใจว่า กำลังดำเนินการสื่อสารระหว่างแอปบนอุปกรณ์เคลื่อนที่และเซิร์ฟเวอร์ API เพื่อให้สามารถโจมตีโดยอัตโนมัติกับ API ของคุณได้ สถานการณ์อื่น ๆ เป็นไปได้ แต่เราจะไม่แจกแจงแต่ละสถานการณ์ที่นี่
ฉันหวังว่าตอนนี้คุณอาจจะได้เบาะแสแล้วว่าทำไมWHOและWHAT ถึงไม่เหมือนกัน แต่ถ้าไม่เป็นเช่นนั้นก็จะชัดเจนในอีกสักครู่
WHOนั้นใช้ของ app มือถือที่เราสามารถตรวจสอบสิทธิ์อนุญาตและระบุในหลายวิธีเช่นการใช้ OpenID Connect หรือ OAUTH2 ไหล
OAuth
โดยทั่วไป OAuth จะให้ "สิทธิ์การเข้าถึงที่ได้รับมอบสิทธิ์ที่ปลอดภัย" แก่ลูกค้าในนามของเจ้าของทรัพยากร ระบุกระบวนการสำหรับเจ้าของทรัพยากรในการอนุญาตให้บุคคลที่สามเข้าถึงทรัพยากรเซิร์ฟเวอร์ของตนโดยไม่ต้องเปิดเผยข้อมูลรับรอง ออกแบบมาโดยเฉพาะเพื่อทำงานกับ Hypertext Transfer Protocol (HTTP) โดยพื้นฐานแล้ว OAuth อนุญาตให้โทเค็นการเข้าถึงออกให้กับไคลเอนต์บุคคลที่สามโดยเซิร์ฟเวอร์การอนุญาตโดยได้รับการอนุมัติจากเจ้าของทรัพยากร จากนั้นบุคคลที่สามจะใช้โทเค็นการเข้าถึงเพื่อเข้าถึงทรัพยากรที่มีการป้องกันซึ่งโฮสต์โดยเซิร์ฟเวอร์ทรัพยากร
OpenID Connect
OpenID Connect 1.0 เป็นเลเยอร์ข้อมูลประจำตัวธรรมดาที่อยู่ด้านบนของโปรโตคอล OAuth 2.0 ช่วยให้ไคลเอนต์สามารถตรวจสอบตัวตนของผู้ใช้ปลายทางตามการพิสูจน์ตัวตนที่ดำเนินการโดยเซิร์ฟเวอร์การอนุญาตตลอดจนรับข้อมูลโปรไฟล์พื้นฐานเกี่ยวกับผู้ใช้ปลายทางในลักษณะที่ทำงานร่วมกันได้และเหมือน REST
แม้ว่าการตรวจสอบผู้ใช้อาจทำให้เซิร์ฟเวอร์ API รู้ว่าWHOกำลังใช้ API แต่ก็ไม่สามารถรับประกันได้ว่าคำขอนั้นมาจากสิ่งที่คุณคาดหวังซึ่งเป็นเวอร์ชันดั้งเดิมของแอปมือถือ
ตอนนี้เราต้องการวิธีระบุสิ่งที่เรียกเซิร์ฟเวอร์ API และที่นี่สิ่งที่ยุ่งยากกว่าที่นักพัฒนาส่วนใหญ่คิด อะไรคือสิ่งที่ทำให้การร้องขอไปยังเซิร์ฟเวอร์ API ที่ มันเป็นอินสแตนซ์ของจริงของแอพมือถือหรือเป็นบอทสคริปต์อัตโนมัติหรือผู้โจมตีด้วยตนเองโดยใช้เครื่องมือเช่น Postman?
สำหรับความประหลาดใจของคุณคุณอาจพบว่าอาจเป็นหนึ่งในผู้ใช้ที่ถูกกฎหมายโดยใช้แอพมือถือเวอร์ชันบรรจุใหม่หรือสคริปต์อัตโนมัติที่พยายามทำให้เป็นเกมและใช้ประโยชน์จากบริการที่แอปพลิเคชันจัดหาให้
ในการระบุสิ่งที่นักพัฒนามักจะใช้คีย์ API ซึ่งโดยปกติแล้วพวกเขาจะฮาร์ดโค้ดในโค้ดของแอพมือถือ นักพัฒนาบางรายก้าวไปอีกขั้นและคำนวณคีย์ตามเวลาทำงานในแอพมือถือดังนั้นจึงกลายเป็นความลับรันไทม์เมื่อเทียบกับวิธีการเดิมเมื่อความลับคงที่ฝังอยู่ในโค้ด
ข้อเขียนข้างต้นดึงมาจากบทความที่ฉันเขียนชื่อทำไมแอปบนอุปกรณ์เคลื่อนที่ของคุณจึงต้องมีคีย์ API และคุณสามารถอ่านแบบเต็มได้ที่นี่นั่นคือบทความแรกในชุดบทความเกี่ยวกับคีย์ API
การจัดเก็บข้อมูลที่ละเอียดอ่อนในอุปกรณ์ไคลเอนต์
และฉันไม่สามารถบันทึกชื่อผู้ใช้ / รหัสผ่านนั้นในอุปกรณ์ได้ด้วยเหตุผลด้านความปลอดภัยอย่างแน่นอน? ฉันควรออก GUID สำหรับผู้ใช้ทุกคนเมื่อลงชื่อสมัครใช้บันทึกไว้ในอุปกรณ์และเรียกข้อมูลทุกครั้งในระหว่างการร้องขอ API หรือไม่
ทุกสิ่งที่คุณบันทึกไว้ในอุปกรณ์แม้ว่าจะเข้ารหัสแล้วก็สามารถย้อนกลับทางวิศวกรรมได้ในระหว่างรันไทม์ด้วยเครื่องมือเช่น Frida หรือ Xposed
ฟรีด้า
ใส่สคริปต์ของคุณเองลงในกระบวนการกล่องดำ เชื่อมต่อฟังก์ชันใด ๆ สอดแนม API การเข้ารหัสลับหรือติดตามรหัสแอปพลิเคชันส่วนตัวไม่จำเป็นต้องใช้ซอร์สโค้ด แก้ไขกดบันทึกและดูผลลัพธ์ทันที ทั้งหมดไม่มีขั้นตอนการคอมไพล์หรือรีสตาร์ทโปรแกรม
xPosed
Xposed เป็นเฟรมเวิร์กสำหรับโมดูลที่สามารถเปลี่ยนพฤติกรรมของระบบและแอพได้โดยไม่ต้องแตะ APK ใด ๆ ยอดเยี่ยมมากเพราะหมายความว่าโมดูลสามารถทำงานกับเวอร์ชันต่างๆและแม้แต่ ROM ได้โดยไม่มีการเปลี่ยนแปลงใด ๆ (ตราบเท่าที่รหัสเดิม
ในอุปกรณ์ที่ผู้โจมตีควบคุมเขายังสามารถใช้พร็อกซีเพื่อดำเนินการกับ Man in the Middle Attack เพื่อดึงความลับใด ๆ ที่คุณอาจใช้เพื่อระบุสิ่งที่หรือWHOตามที่ฉันแสดงในบทความขโมยคีย์ API นั้นกับชายในการโจมตี :
แม้ว่าเราจะสามารถใช้เทคนิคขั้นสูงเช่น JNI / NDK เพื่อซ่อนคีย์ API ในโค้ดแอปบนอุปกรณ์เคลื่อนที่ได้ แต่จะไม่ขัดขวางใครบางคนจากการโจมตี MitM เพื่อขโมยคีย์ API ในความเป็นจริงแล้วการโจมตีแบบ MitM นั้นเป็นเรื่องง่ายจนถึงขั้นที่ผู้ที่ไม่ใช่นักพัฒนาสามารถทำได้ด้วยซ้ำ
ตอนนี้เป็นอย่างไร ... ฉันถึงวาระที่ฉันไม่สามารถปกป้องเซิร์ฟเวอร์ API ของฉันจากการถูกละเมิดได้ ??? เงียบเลย ... ความหวังยังมีอยู่ !!!
การแก้ปัญหาที่เป็นไปได้
ใครช่วยบอกหน่อยได้ไหมว่าแอปพลิเคชั่น Android ที่มีชื่อเสียงเช่น Facebook, FourSquare หรือ Twitter ใช้วิธีใดในการตรวจสอบทุกคำขอที่มาจากแอปพลิเคชันมือถือไปยังเซิร์ฟเวอร์ของตน
ขออภัยฉันไม่มีความรู้เพียงพอเกี่ยวกับแอพนี้ที่จะอธิบายคุณได้ แต่ฉันสามารถชี้ให้คุณเห็นแนวทางอื่น ๆ ได้
มีรูปแบบใดอีกบ้างที่มีประสิทธิภาพและปลอดภัยที่สุดฉันแค่ต้องการขั้นตอนกระบวนการเท่านั้น
ดังนั้นสิ่งใดก็ตามที่ทำงานในฝั่งไคลเอ็นต์และต้องการความลับในการเข้าถึง API อาจถูกนำไปใช้ในทางที่ผิดในรูปแบบต่างๆและคุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับชุดบทความเกี่ยวกับเทคนิคการรักษาความปลอดภัย Mobile API บทความนี้จะสอนวิธีใช้คีย์ API, โทเค็นการเข้าถึงของผู้ใช้, HMAC และ TLS Pinning เพื่อป้องกัน API และวิธีข้ามผ่านได้
ในการแก้ปัญหาสิ่งที่กำลังเข้าถึงแอพมือถือของคุณคุณต้องใช้หนึ่งหรือทั้งหมดวิธีแก้ปัญหาที่กล่าวถึงในชุดบทความเกี่ยวกับเทคนิคการรักษาความปลอดภัย Mobile API ที่ฉันได้กล่าวไว้ข้างต้นและยอมรับว่าพวกเขาสามารถทำให้การเข้าถึงเซิร์ฟเวอร์ API ของคุณโดยไม่ได้รับอนุญาตทำได้ยากขึ้นเท่านั้น บายพาส แต่ไม่เป็นไปไม่ได้
สามารถใช้โซลูชันที่ดีกว่าได้โดยใช้โซลูชัน Mobile App Attestation ซึ่งจะช่วยให้เซิร์ฟเวอร์ API ทราบว่าได้รับคำขอจากแอปบนอุปกรณ์เคลื่อนที่ของแท้เท่านั้น
การรับรองแอพมือถือ
การใช้วิธีการแก้ปัญหา Mobile App รับรองจะเปิดใช้งานเซิร์ฟเวอร์ API ที่จะรู้ว่าสิ่งที่จะส่งคำขอจึงช่วยให้การตอบสนองเพียงการร้องขอจากแอปมือถือของแท้ในขณะที่ปฏิเสธการร้องขอการอื่น ๆ ทั้งหมดมาจากแหล่งที่ไม่ปลอดภัย
บทบาทของโซลูชัน Mobile App Attestation คือการรับประกันในขณะทำงานว่าแอปบนอุปกรณ์เคลื่อนที่ของคุณไม่ได้รับการดัดแปลงไม่ได้ทำงานในอุปกรณ์ที่รูทไม่ได้ถูกใช้โดยเฟรมเวิร์กเช่น xPosed หรือ Frida ไม่ถูก MitM โจมตีและสิ่งนี้ ทำได้โดยการเรียกใช้ SDK ในพื้นหลัง บริการที่ทำงานในระบบคลาวด์จะท้าทายแอปและจากการตอบสนองจะเป็นเครื่องยืนยันความสมบูรณ์ของแอปบนอุปกรณ์เคลื่อนที่และอุปกรณ์ที่ทำงานอยู่ดังนั้น SDK จะไม่รับผิดชอบต่อการตัดสินใจใด ๆ
ในการยืนยันความสมบูรณ์ของแอพมือถือที่ประสบความสำเร็จโทเค็น JWT ที่มีอายุสั้น ๆ จะถูกออกและเซ็นชื่อด้วยความลับซึ่งมีเพียงเซิร์ฟเวอร์ API และบริการ Mobile App Attestation ในระบบคลาวด์เท่านั้น ในกรณีของความล้มเหลวในแอปบนอุปกรณ์เคลื่อนที่การยืนยันโทเค็น JWT จะถูกเซ็นชื่อด้วยความลับที่เซิร์ฟเวอร์ API ไม่ทราบ
ตอนนี้แอปจะต้องส่งไปพร้อมกับทุก API เรียกโทเค็น JWT ในส่วนหัวของคำขอ สิ่งนี้จะอนุญาตให้เซิร์ฟเวอร์ API ให้บริการเฉพาะคำขอเมื่อสามารถตรวจสอบลายเซ็นและเวลาหมดอายุในโทเค็น JWT และปฏิเสธเมื่อไม่ผ่านการตรวจสอบ
เมื่อแอปมือถือไม่ทราบความลับที่ใช้โดยบริการการยืนยันแอปบนอุปกรณ์เคลื่อนที่แล้วจะไม่สามารถทำวิศวกรรมย้อนกลับได้ในขณะทำงานแม้ว่าแอปจะถูกดัดแปลงทำงานในอุปกรณ์ที่รูทหรือสื่อสารผ่านการเชื่อมต่อที่เป็น เป้าหมายของชายในการโจมตีกลาง
บริการ Mobile App Attestation มีอยู่แล้วเป็นโซลูชัน SAAS ที่ Approov (ฉันทำงานที่นี่) ซึ่งให้ SDK สำหรับหลายแพลตฟอร์มรวมถึง iOS, Android, React Native และอื่น ๆ การรวมจะต้องมีการตรวจสอบเล็กน้อยในรหัสเซิร์ฟเวอร์ API เพื่อตรวจสอบโทเค็น JWT ที่ออกโดยบริการคลาวด์ การตรวจสอบนี้จำเป็นสำหรับเซิร์ฟเวอร์ API เพื่อให้สามารถตัดสินใจได้ว่าจะให้บริการคำขอใดและคำขอใดที่จะปฏิเสธ
ข้อสรุป
ท้ายที่สุดแล้วโซลูชันที่จะใช้เพื่อปกป้องเซิร์ฟเวอร์ API ของคุณจะต้องเลือกให้สอดคล้องกับคุณค่าของสิ่งที่คุณพยายามปกป้องและข้อกำหนดทางกฎหมายสำหรับข้อมูลประเภทนั้นเช่นข้อบังคับ GDPR ในยุโรป
คุณต้องการไปที่ EXTRA MILE หรือไม่?
โครงการ OWASP Mobile Security - ความเสี่ยง 10 อันดับแรก
โครงการ OWASP Mobile Security เป็นแหล่งข้อมูลส่วนกลางที่มีไว้เพื่อให้นักพัฒนาและทีมรักษาความปลอดภัยมีทรัพยากรที่จำเป็นในการสร้างและดูแลแอปพลิเคชันมือถือที่ปลอดภัย เป้าหมายของเราคือการจำแนกความเสี่ยงด้านความปลอดภัยของอุปกรณ์เคลื่อนที่และจัดให้มีการควบคุมเชิงพัฒนาการเพื่อลดผลกระทบหรือโอกาสในการแสวงหาประโยชน์จากโครงการดังกล่าว
