ภัยคุกคามของเว็บแอปพลิเคชันยอดนิยม 10 อันดับของ OWASP

คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่ เอกสารประกอบของ Apigee X info

เอกสารนี้อธิบายแนวทางต่างๆ ที่คุณใช้ได้ใน Apigee เพื่อจัดการกับ ช่องโหว่ด้านความปลอดภัยที่ OWASP ระบุ ดูแนวทางเพิ่มเติมที่จัดทำเอกสารไว้สำหรับ Apigee ได้ที่ ตัวเลือกการลดความเสี่ยงของ OWASP Top 10 2021 ใน Google Cloud

ภาพรวม

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

OWASP เป็นชุมชนแบบเปิดที่มุ่งมั่นที่จะช่วยองค์กร พัฒนา ซื้อ และดูแลรักษาแอปพลิเคชันและ API ที่เชื่อถือได้ OWASP เผยแพร่ความเสี่ยงด้านความปลอดภัยที่สำคัญที่สุดสำหรับเว็บแอปพลิเคชันและ REST API รวมถึงให้คำแนะนำในการจัดการกับความเสี่ยงเหล่านั้นผ่าน โปรเจ็กต์ OWASP API Security

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

  • URL
  • ส่วนหัว
  • เส้นทาง
  • เพย์โหลด

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

แพลตฟอร์มการจัดการ API อัจฉริยะของ Apigee ช่วยให้คุณจัดการกับช่องโหว่ด้านความปลอดภัยของ API ที่สำคัญที่สุดของ OWASP ได้อย่างราบรื่นเมื่อคุณใช้แนวทางที่เน้นการใช้งานในการออกแบบ API และเชื่อมต่อ API กับระบบแบ็กเอนด์ ด้านล่างนี้คือรายการนโยบาย/การกำหนดค่า ที่ Apigee แนะนำสำหรับภัยคุกคาม REST OWASP ที่สำคัญที่สุด

โซลูชัน Apigee สำหรับ OWASP Top 10 ปี 2017

การสร้างและรักษาความปลอดภัยของเว็บแอปพลิเคชันก่อให้เกิดข้อกังวลด้านความปลอดภัยมากมาย OWASP ได้เผยแพร่รายการ ภัยคุกคามด้านความปลอดภัย 10 อันดับแรกของ OWASP ปี 2017 สำหรับเว็บแอปพลิเคชัน แม้ว่าเว็บแอปพลิเคชันจะมีหลายส่วน แต่เว็บแอปส่วนใหญ่ในปัจจุบันก็พึ่งพา REST API เป็นอย่างมาก Apigee ไม่ได้มีไว้เพื่อจัดการกับความต้องการด้านความปลอดภัยทั้งหมดของเว็บแอปพลิเคชัน แต่มีบทบาทสำคัญในการรักษาความปลอดภัยของ REST API ด้านล่างนี้คือภัยคุกคามด้านความปลอดภัยที่สำคัญที่สุดของ OWASP พร้อมคำอธิบายเกี่ยวกับวิธีใช้ Apigee เพื่อช่วยจัดการกับภัยคุกคามเหล่านั้น

A1:2017 - การแทรก

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

แพลตฟอร์ม Apigee มีแนวทางหลายอย่างในการตรวจสอบอินพุต ดังนี้

  • JSONThreatProtection จะตรวจสอบเพย์โหลด JSON เพื่อหาภัยคุกคาม
  • XMLThreatProtection จะตรวจสอบเพย์โหลด XML เพื่อหาภัยคุกคาม
  • การตรวจสอบพารามิเตอร์สามารถทำได้โดยใช้ JavaScript
  • การตรวจสอบส่วนหัวสามารถทำได้ โดยใช้ JavaScript
  • SQLCodeInjection สามารถจัดการได้โดยใช้นโยบาย RegularExpressionProtection

ตรวจสอบประเภทเนื้อหา ดังนี้

A2:2017 - การตรวจสอบสิทธิ์และการจัดการเซสชันที่บกพร่อง

ผู้โจมตีสามารถเข้าถึงรหัสผ่าน โทเค็นเซสชัน และคีย์เพื่อแอบอ้างเป็นผู้ใช้รายอื่นได้โดยใช้ประโยชน์จากข้อบกพร่องในการใช้งานในแอปพลิเคชัน ซึ่งเป็นปัญหาในการใช้งานมากกว่าปัญหาเกี่ยวกับผลิตภัณฑ์ Apigee มีนโยบาย VerifyApiKey, OAuth และ JSON Web Token (JWT) ซึ่งช่วยป้องกันช่องโหว่นี้ได้

การตรวจสอบคีย์ API

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

Apigee รองรับการสร้างและการตรวจสอบคีย์ API Apigee จะสร้างคีย์ API และข้อมูลลับเมื่อมีการสร้างและอนุมัติแอปของนักพัฒนาแอปที่ลิงก์กับผลิตภัณฑ์ API อย่างน้อย 1 รายการ

บางครั้งคำว่า "คีย์ API" อาจมีความหมายแตกต่างกัน ใน Apigee เมื่อมีการสร้างความสัมพันธ์ระหว่างแอปกับผลิตภัณฑ์ Apigee จะสร้างรหัสไคลเอ็นต์และรหัสลับไคลเอ็นต์ บางคนเรียกทั้ง รหัสและข้อมูลลับว่าคีย์ API บางคนเรียกเฉพาะรหัสไคลเอ็นต์ว่าคีย์ API ใน UI ของ Edge คุณจะเห็น "คีย์ผู้ใช้" และ "ข้อมูลลับของผู้บริโภค"

ในนโยบาย VerifyAPIKey จะตรวจสอบเฉพาะรหัสไคลเอ็นต์หรือ "คีย์ผู้ใช้" นักพัฒนาแอปจะได้รับคีย์ผู้ใช้เมื่อ ลงทะเบียนแอปกับ Apigee และเชื่อมโยงแอปกับผลิตภัณฑ์ API นักพัฒนาแอปจะใส่ คีย์ผู้ใช้ในการเรียกที่แอปส่งไปยังพร็อกซี API ที่รวมอยู่ในผลิตภัณฑ์ API

นอกจากนี้ Apigee ยังรองรับความสามารถในการ นำเข้าคีย์ API ที่มีอยู่จากแหล่งที่มาภายนอก

สำหรับประเภทการให้สิทธิ์ OAuth ระบบจะใช้ทั้งรหัสไคลเอ็นต์และข้อมูลลับ

OAuth 2.0

เฟรมเวิร์กการให้สิทธิ์ OAuth 2.0 ช่วยให้แอปพลิเคชันของบุคคลที่สามได้รับสิทธิ์เข้าถึงบริการ HTTP แบบจำกัดในนามของเจ้าของทรัพยากรโดยการประสานการโต้ตอบการอนุมัติระหว่างเจ้าของทรัพยากรกับบริการ HTTP หรือโดยอนุญาตให้แอปพลิเคชันของบุคคลที่สามได้รับสิทธิ์เข้าถึงในนามของตนเอง

นโยบาย OAuth 2.0 ของ Apigee ช่วยให้คุณใช้งานและปรับแต่งประเภทการให้สิทธิ์ OAuth 2.0 ทั้ง 4 ประเภทได้ การบังคับใช้โทเค็นเพื่อการเข้าถึง OAuth สามารถทำได้โดยใช้ นโยบาย OAuthv2 ผู้บริโภคต้อง ลงทะเบียนและมีแอปที่ได้รับอนุมัติซึ่งให้สิทธิ์เข้าถึง API และจะได้รับ รหัสไคลเอ็นต์ API และรหัสลับไคลเอ็นต์ ผู้บริโภคต้องผ่านการให้สิทธิ์ OAuth อย่างใดอย่างหนึ่งเพื่อรับการตรวจสอบสิทธิ์ ซึ่งจะให้โทเค็นเพื่อการเข้าถึงแบบทึบแก่ผู้บริโภค คุณสามารถใช้โทเค็นนี้เพื่อควบคุมการเข้าถึง API ได้

JWT

JSON Web Token หรือ JWT ใช้กันโดยทั่วไปเพื่อแชร์การอ้างสิทธิ์หรือการยืนยันระหว่างแอปพลิเคชันที่เชื่อมต่อ Apigee รองรับ JWT โดยใช้นโยบาย 3 รายการ

  • สร้างโทเค็น JWT (รองรับลายเซ็น HS256 และ RS256)
  • ตรวจสอบโทเค็น JWT
  • ถอดรหัสโทเค็น JWT โดยไม่ตรวจสอบ

A3:2017 - การเปิดเผยข้อมูลที่ละเอียดอ่อน

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

TLS (Transport Layer Security ซึ่งเป็นเทคโนโลยีความปลอดภัยมาตรฐานสำหรับ การสร้างลิงก์ที่เข้ารหัสระหว่างเว็บเซิร์ฟเวอร์กับเว็บไคลเอ็นต์ เช่น เบราว์เซอร์หรือแอป ) Apigee รองรับ TLS แบบทางเดียวและสองทาง

TLS ขาเข้า (ไคลเอ็นต์เชื่อมต่อกับ API ที่ทำหน้าที่เป็นเซิร์ฟเวอร์) ได้รับการรองรับผ่านการใช้ การกำหนดค่า โฮสต์เสมือน คุณกำหนดค่าโฮสต์เสมือน สำหรับ TLS แบบทางเดียวหรือสองทางได้

TLS ขาออก (Apigee เป็นไคลเอ็นต์ที่เชื่อมต่อกับบริการแบ็กเอนด์) ได้รับการรองรับผ่านการใช้ การกำหนดค่าเซิร์ฟเวอร์เป้าหมาย คุณกำหนดค่าเซิร์ฟเวอร์เป้าหมายสำหรับ TLS แบบทางเดียวหรือสองทางได้

Apigee รองรับตัวเลือกการกำหนดค่า TLS มากมาย

การบังคับใช้ TLS แบบ 2 ทางช่วยให้มั่นใจว่า ไคลเอ็นต์ใช้ใบรับรองที่ได้เริ่มต้นใช้งานใน Apigee แล้ว OWASP ยังมี แนวทางปฏิบัติแนะนำสำหรับ TLS ด้วย

ใน Apigee hybrid, TLS จะพร้อมใช้งานที่ Ingress ผ่านนามแฝงโฮสต์ ซึ่งเป็นแนวคิดที่คล้ายกับโฮสต์เสมือน

ด้านล่างนี้คือหลักเกณฑ์สำหรับการรักษาความปลอดภัยของข้อมูลที่ละเอียดอ่อน

  • ใช้แพลตฟอร์มที่รองรับ TLS แบบทางเดียวและสองทาง ซึ่งจะช่วยปกป้องในระดับโปรโตคอล
  • ใช้นโยบาย เช่น นโยบาย AssignMessage และนโยบาย JavaScript เพื่อนำ ข้อมูลที่ละเอียดอ่อนออกก่อนที่จะส่งกลับไปยังไคลเอ็นต์
  • ใช้เทคนิค OAuth มาตรฐานและพิจารณาเพิ่ม HMAC, แฮช, สถานะ, Nonce, PKCE, หรือเทคนิคอื่นๆ เพื่อปรับปรุงระดับการตรวจสอบสิทธิ์สำหรับคำขอแต่ละรายการ
  • ใช้การตั้งค่าการมาสก์ข้อมูลเพื่อมาสก์ข้อมูลที่ละเอียดอ่อน ในเครื่องมือ Trace ของ Edge
  • ระมัดระวังในการจัดเก็บข้อมูลที่ละเอียดอ่อนในแคช (หรือเข้ารหัสข้อมูลที่ละเอียดอ่อนที่จัดเก็บไว้ในแคช) ใน Edge คุณสามารถเข้ารหัสข้อมูลที่ละเอียดอ่อนในขณะพักใน แมปค่าคีย์ได้

A4:2017 - XML External Entities

ระบบหรือแอปพลิเคชันที่ประมวลผล XML ต้องจัดการ "การอ้างอิงเอนทิตีภายนอก" ใน XML ซึ่งเป็นการอ้างอิงไฟล์หรือข้อมูลที่จะถูกแทนที่ด้วยข้อมูลจริงระหว่างการประมวลผล XML หากแอปพลิเคชันหรือตัวประมวลผล XML เก่าหรือมีการใช้งานที่ไม่ดี ผู้โจมตีสามารถ แฮ็กข้อมูลและใช้ข้อมูลดังกล่าวเพื่อขโมยข้อมูลหรือเปิดตัวการโจมตีประเภทต่างๆ ในระบบ เช่น การปฏิเสธการให้บริการ

นโยบาย ExtractVariables ของ Apigee ช่วยให้คุณแยกเนื้อหาจากคำขอหรือการตอบกลับ และกำหนดเนื้อหาดังกล่าวให้กับตัวแปรได้ คุณสามารถแยกส่วนใดก็ได้ของข้อความ รวมถึงส่วนหัว เส้นทาง URI เพย์โหลด JSON/XML พารามิเตอร์ของฟอร์ม และพารามิเตอร์การค้นหา นโยบายนี้ทำงานโดย ใช้รูปแบบข้อความกับเนื้อหาข้อความ และเมื่อพบรายการที่ตรงกัน ระบบจะตั้งค่าตัวแปร ด้วยเนื้อหาข้อความที่ระบุ

Apigee มีตัวแยกวิเคราะห์ XML ในตัวซึ่งเป็นส่วนหนึ่งของแพลตฟอร์มที่ใช้ XPath เพื่อแยกข้อมูล นอกจากนี้ยังมี นโยบาย XMLThreatProtection เพื่อป้องกันเพย์โหลด XML ที่เป็นอันตราย

A5:2017 - การควบคุมการเข้าถึงที่บกพร่อง

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

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

การควบคุมการเข้าถึงสำหรับ UI ของ Edge

การควบคุมการเข้าถึงสำหรับ Apigee Developer Portal

การควบคุมการเข้าถึงสำหรับการเข้าถึง API รันไทม์ของ Apigee

  • คุณบังคับใช้การเข้าถึง API ได้ผ่านคีย์ API, โทเค็น OAuth, ขอบเขต OAuth, ใบรับรอง, และเทคนิคอื่นๆ
  • ผู้ให้บริการ API จะกำหนดค่าทรัพยากรที่พร้อมใช้งานโดยกำหนด ผลิตภัณฑ์ API ระบบจะให้สิทธิ์เข้าถึงด้วยตนเองใน UI ผ่าน Management API หรือผ่านพอร์ทัลนักพัฒนาซอฟต์แวร์ เมื่อแอปของนักพัฒนาแอปได้รับสิทธิ์เข้าถึงผลิตภัณฑ์ API นักพัฒนาแอปจะได้รับรหัสไคลเอ็นต์และข้อมูลลับที่ ใช้ในกระบวนการตรวจสอบสิทธิ์
  • Apigee สามารถผสานรวมกับผู้ให้บริการข้อมูลประจำตัวรายใดก็ได้เพื่อดำเนินการ OAuth
  • Apigee สามารถสร้างโทเค็น JWT หรือใช้เทคนิคอื่นๆ เพื่อส่งข้อมูลประจำตัวผู้ใช้ไปยังบริการเป้าหมาย บริการเป้าหมายสามารถใช้ข้อมูลประจำตัวดังกล่าวเพื่อจำกัดการเข้าถึงบริการและข้อมูลตามความจำเป็น

A6:2017 - การกำหนดค่าความปลอดภัยที่ไม่ถูกต้อง

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

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

การเผยแพร่ผลิตภัณฑ์ของ Apigee ช่วยให้มั่นใจได้ถึงการปกป้องจากไลบรารีที่มีช่องโหว่ Apigee อาจเผยแพร่แพตช์หรือการอัปเดตเพิ่มเติมหากพบช่องโหว่ใหม่ ระบบจะแพตช์ Edge Public Cloud โดยอัตโนมัติ ลูกค้า Edge for Private Cloud (ภายในองค์กร) ต้องใช้แพตช์ผลิตภัณฑ์ด้วยตนเอง

A7:2017 - Cross-site Scripting (XSS)

Cross-site Scripting (XSS) ช่วยให้ผู้โจมตีเรียกใช้สคริปต์ในเว็บเบราว์เซอร์ของผู้ใช้เพื่อควบคุมเซสชันของผู้ใช้ จัดการเว็บไซต์ หรือส่งผลกระทบต่อผู้ใช้ในทางที่ผิดด้วยวิธีอื่นๆ ปัญหา XSS ไม่จำเป็นต้องเกี่ยวข้องกับ API แต่ Apigee มีนโยบายการป้องกันภัยคุกคามที่ใช้เพื่อป้องกัน XSS ใน API ได้ ใช้ Regular Expression ทั้งกับ นโยบาย RegularExpressionProtection หรือนโยบาย JavaScript เพื่อตรวจสอบเพย์โหลดและ ค่าพารามิเตอร์สำหรับการโจมตีประเภท JavaScript และการแทรกอื่นๆ

CORS ซึ่งเป็นหนึ่งในโซลูชันที่ใช้กันโดยทั่วไปสำหรับ นโยบายต้นทางเดียวกันที่ เบราว์เซอร์ทั้งหมดบังคับใช้ สามารถ ใช้ได้โดยใช้ นโยบาย AssignMessage

A8:2017 - การดีซีเรียลไลซ์ที่ไม่ปลอดภัย

ผู้โจมตีสามารถใช้ข้อบกพร่องในการดีซีเรียลไลซ์สำหรับการโจมตีประเภทต่างๆ เช่น การโจมตีแบบเล่นซ้ำ การโจมตีเพื่อยกระดับสิทธิ์ และการแทรก การดีซีเรียลไลซ์ที่ไม่ปลอดภัยยังอาจทำให้เกิดการดำเนินการกับโค้ดจากระยะไกลได้

Apigee ไม่แนะนำให้ดีซีเรียลไลซ์ อย่างไรก็ตาม นโยบาย JSONThreatProtection และนโยบาย RegularExpressionProtection สามารถช่วยป้องกันเพย์โหลด JSON ที่เป็นอันตรายได้ นอกจากนี้ คุณยังใช้นโยบาย JavaScript เพื่อสแกนเพย์โหลดหาเนื้อหาที่เป็นอันตรายได้ด้วย คุณสามารถใช้นโยบายแคชและนโยบายอื่นๆ เพื่อป้องกันการโจมตีแบบเล่นซ้ำ แพลตฟอร์ม Apigee ยังมีกลไกการป้องกันในระดับโครงสร้างพื้นฐานเพื่อปกป้องกระบวนการที่กำลังทำงาน

A9:2017 - การใช้คอมโพเนนต์ที่มีช่องโหว่ที่ทราบ

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

การเผยแพร่ผลิตภัณฑ์เป็นประจำของ Apigee ช่วยให้มั่นใจได้ถึงการปกป้องจากช่องโหว่ของคอมโพเนนต์ โดยเฉพาะอย่างยิ่งเมื่อมีการค้นพบช่องโหว่ที่เฉพาะเจาะจง ระบบจะแพตช์ Apigee Public Cloud โดยอัตโนมัติ และ Apigee จะแจ้งให้ลูกค้า Edge for Private Cloud ทราบเมื่อมีการติดตั้งแพตช์ภายในองค์กร

A10:2017 - การบันทึกและการตรวจสอบที่ไม่เพียงพอ

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

Apigee มีวิธีต่างๆ ในการบันทึก ตรวจสอบ จัดการข้อผิดพลาด และบันทึกการตรวจสอบ

การบันทึก

  • คุณสามารถส่งข้อความบันทึกไปยัง Splunk หรือปลายทาง Syslog อื่นๆ ได้โดยใช้ นโยบาย MessageLogging
  • คุณสามารถดึงข้อมูลการวิเคราะห์ API ผ่าน API การวิเคราะห์ และนำเข้าหรือส่งออกข้อมูลไปยังระบบอื่นๆ ได้
  • ใน Edge for Private Cloud คุณสามารถใช้นโยบาย MessageLogging เพื่อเขียนไปยังไฟล์บันทึกในเครื่องได้ นอกจากนี้ คุณยังดูไฟล์บันทึกจากคอมโพเนนต์ที่กำลังทำงานแต่ละรายการได้ด้วย
  • คุณสามารถใช้นโยบาย JavaScript เพื่อส่งข้อความบันทึกไปยังปลายทางการบันทึก REST แบบซิงโครนัสหรืออะซิงโครนัสได้

การตรวจสอบ

  • ใช้ UI หรือ API การตรวจสอบ API เพื่อตรวจสอบ API และ แบ็กเอนด์เป็นประจำและทริกเกอร์การแจ้งเตือน
  • ใช้การตรวจสอบสถานะเพื่อตรวจสอบแบ็กเอนด์ของเซิร์ฟเวอร์เป้าหมายเป็นประจำ
  • Apigee มีคำแนะนำสำหรับการ ตรวจสอบ Edge for Private Cloud
  • นอกจากนี้ Apigee ยังมี แนวทางปฏิบัติแนะนำ ที่ทีมของคุณใช้เพื่อตรวจสอบโปรแกรม API ได้

การจัดการข้อผิดพลาด

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

บันทึกการตรวจสอบ

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

โซลูชัน Apigee สำหรับช่องโหว่ OWASP ปี 2013

เมื่อ OWASP อัปเดตรายการสำหรับปี 2017 ช่องโหว่บางรายการจากรายการปี 2013 ถูกนำออกไป แต่ยังคงเป็นภัยคุกคามที่ถูกต้อง ส่วนต่อไปนี้จะอธิบายวิธีจัดการกับภัยคุกคามเหล่านี้ ด้วย Apigee

A8:2013 - Cross-Site Request Forgery (CSRF)

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

หลักเกณฑ์:

  • นี่เป็นปัญหาเกี่ยวกับเบราว์เซอร์มากกว่าปัญหาเกี่ยวกับผลิตภัณฑ์ API คุณสามารถจัดการกับช่องโหว่นี้ได้ด้วย OpenID Connect, OAuth และเทคนิคอื่นๆ
  • ลองใช้เทคนิค HMAC, สถานะ, แฮช, Nonce หรือ PKCE เพื่อป้องกันการปลอมแปลงและการโจมตีแบบเล่นซ้ำ

A10:2013 - การเปลี่ยนเส้นทางและการส่งต่อที่ตรวจสอบไม่ได้

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

หลักเกณฑ์:

  • ใช้ OAuth และบังคับใช้การตรวจสอบในคำขอแต่ละรายการ
  • ป้องกันการเปลี่ยนเส้นทาง 302 ที่ไม่คาดคิดโดยตรวจสอบรหัสการตอบกลับในตรรกะของพร็อกซี API และ จัดการการเปลี่ยนเส้นทางอย่างเหมาะสม