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

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

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

ภาพรวม

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

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

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

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

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

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

โซลูชัน Apigee สำหรับ 10 อันดับยอดนิยมของ OWASP ในปี 2017

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

A1:2017 - การฉีดยา

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

มีหลายวิธีในการตรวจสอบความถูกต้องของอินพุตด้วยแพลตฟอร์ม Apigee ดังนี้

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

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

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

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

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

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

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

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

ในนโยบาย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 รายการ

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

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

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

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

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

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

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

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

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

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

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

A4:2017 - เอนทิตีภายนอก XML

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

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

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

A5:2017 - การควบคุมการเข้าถึงขัดข้อง

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

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

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

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

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

A7:2017 - การเขียนสคริปต์ข้ามเว็บไซต์ (XSS)

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

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

A8:2017 - การแยกอนุกรมที่ไม่ปลอดภัย

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

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

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

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

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

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

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

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

Logging

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

Monitoring

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

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 และจัดการการเปลี่ยนเส้นทางอย่างเหมาะสม