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

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

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

ภาพรวม

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

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

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

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

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

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

โซลูชัน Apigee สำหรับรายการความเสี่ยงด้านความปลอดภัย 10 อันดับสูงสุดของ OWASP ปี 2017

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

A1:2017 - Injection

Apigee มีนโยบายการตรวจสอบอินพุตหลายรายการเพื่อปกป้องจากการแทรกข้อมูลที่ไม่น่าเชื่อถือ เช่น SQL, NoSQL, LDAP และ JavaScript ซึ่งอาจส่งผลให้มีการเรียกใช้คําสั่งที่ไม่ตั้งใจหรือการเข้าถึงข้อมูลที่ไม่ได้รับอนุญาต Apigee จึงมีนโยบายการตรวจสอบอินพุตหลายรายการเพื่อยืนยันว่าค่าที่ไคลเอ็นต์ระบุตรงกับที่คาดไว้ก่อนที่จะอนุญาตให้ประมวลผลต่อไป 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 หรือ JWT มักใช้เพื่อแชร์การอ้างสิทธิ์หรือการยืนยันระหว่างแอปพลิเคชันที่เชื่อมต่อ Apigee มี การรองรับ JWT โดยใช้นโยบาย 3 รายการ

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

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

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

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

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

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

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

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

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

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

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

  • กำหนดค่าการลงชื่อเพียงครั้งเดียวด้วยผู้ให้บริการข้อมูลประจำตัวของบริษัท
  • กำหนดค่าการควบคุมการเข้าถึงตามบทบาท (RBAC) เพื่ออนุญาตให้ผู้ใช้เข้าถึงฟังก์ชันการทำงานและการกําหนดค่าที่จําเป็นเท่านั้นในพอร์ทัลนักพัฒนาซอฟต์แวร์ที่ใช้ Drupal
  • กำหนดค่าพอร์ทัลนักพัฒนาแอปให้แสดงผลิตภัณฑ์ API ที่เฉพาะเจาะจงตามบทบาทของผู้ใช้
  • กำหนดค่าพอร์ทัลให้แสดงหรือซ่อนเนื้อหาตามบทบาทของผู้ใช้

การควบคุมการเข้าถึงสําหรับการเข้าถึง 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 โดยอัตโนมัติ Edge สำหรับ Private Cloud (ในองค์กร) ลูกค้าต้องติดตั้งแพตช์ผลิตภัณฑ์ด้วยตนเอง

A7:2017-Cross-Site Scripting (XSS)

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

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

A8:2017 - การทำให้เป็นอนุกรมที่ไม่ปลอดภัย

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

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

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

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

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

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

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

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

การบันทึก

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

การตรวจสอบ

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

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

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

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

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

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

A8:2013 - การปลอมแปลงคําขอข้ามเว็บไซต์ (CSRF)

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

หลักเกณฑ์:

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

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

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

หลักเกณฑ์:

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