วิธีทดสอบ API ของคุณกับอินพุตอันตราย (ก่อนที่แฮกเกอร์จะทำ)

TL;DR: อินพุตของ API ของคุณคือพื้นที่โจมตี ดังนั้นควรทดสอบเหมือนเป็นพื้นที่โจมตี เขียนกรณีทดสอบเชิงลบที่ส่งฟิลด์ที่มีขนาดใหญ่เกินไป, ชนิดข้อมูลผิดพลาด, เนื้อหาที่ผิดรูปแบบ และสตริงที่ใช้ในการฉีดโค้ด จากนั้นยืนยันว่า Endpoint ตอบกลับด้วย 4xx และไม่เคยตอบด้วย 5xx เปลี่ยนการตรวจสอบ Schema ให้เป็นการควบคุมความปลอดภัยด้วย additionalProperties: false, enums และการจำกัดความยาว รันชุดทดสอบทั้งหมดใน CI ทุกครั้งที่มีการเปลี่ยนแปลง AI agents ทำให้เรื่องนี้เร่งด่วน: พวกมันสร้างและส่ง Payload ด้วยความเร็วของเครื่องจักร ดังนั้น "โหลดข้อมูลนี้" ที่ค่อยๆ กลายเป็น "รันโค้ดนี้" จึงสามารถขยายขนาดได้แล้ว

ชุดทดสอบส่วนใหญ่พิสูจน์ว่า API ของคุณทำงานได้เมื่อผู้เรียกใช้งานสุภาพ คุณส่งเนื้อหาที่ถูกต้อง คุณได้รับ 200 การยืนยันผ่าน ผลลัพธ์นั้นแทบไม่ได้บอกอะไรคุณเลยเกี่ยวกับสิ่งที่เกิดขึ้นเมื่อเนื้อหาเป็นอันตราย อินพุตที่ไม่น่าเชื่อถือคือข้อมูลใดๆ ที่ Endpoint ของคุณไม่ได้สร้างขึ้นเอง: เนื้อหาคำขอ, สตริงแบบสอบถาม, เฮดเดอร์, การอัปโหลดไฟล์, Payload ของ Webhook และ JSON ที่ AI agent รวบรวมขึ้นมาแบบทันทีทันใด ทั้งหมดนี้สมควรได้รับการสมมติฐานเดียวกัน นั่นคือจะมีใครบางคนส่งเวอร์ชันที่แย่ที่สุดของมันในที่สุด

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

อินพุตคือพื้นที่โจมตี ไม่ใช่ฟิลด์ในฟอร์ม

การตรวจสอบมักถูกมองว่าเป็นความสุภาพในการใช้งาน: จับอีเมลที่ว่างเปล่า, แสดงขอบสีแดง, แล้วไปต่อ การวางกรอบความคิดเช่นนี้คือปัญหา ทุกฟิลด์ที่ API ของคุณยอมรับคือคำสัญญาที่ผู้เรียกสามารถละเมิดได้ และทุกคำสัญญาที่ถูกละเมิดคือเส้นทางเข้าสู่ตรรกะของคุณ พารามิเตอร์ limit ที่คุณคาดหวังให้เป็นจำนวนเต็มเล็กๆ กลายเป็น 999999999 ชื่อไฟล์ filename ที่คุณคาดหวังให้เป็นคำเดียวกลายเป็น ../../etc/passwd วัตถุ config ที่คุณคาดหวังให้เก็บการตั้งค่ากลายเป็นชุดคำสั่ง

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

"โหลดข้อมูลนี้" กลายเป็น "รันโค้ดนี้" ได้อย่างไร

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

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

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

การตรวจสอบ Schema เพื่อควบคุมความปลอดภัย

การควบคุมที่ถูกที่สุดที่คุณสามารถเพิ่มได้คือ schema ที่เข้มงวดที่ส่วนขอบ Schema ไม่ใช่แค่เอกสารประกอบเท่านั้น เมื่อคุณปฏิเสธสิ่งที่ไม่ตรงกัน Schema จะกลายเป็นตัวกรองที่ทำงานก่อนที่ตรรกะทางธุรกิจของคุณจะเห็นคำขอ JSON Schema มอบเครื่องมือพื้นฐานให้คุณในการสร้างตัวกรองที่แน่นหนา

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

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": false,
  "required": ["loader", "name"],
  "properties": {
    "loader": { "enum": ["csv", "json", "parquet"] },
    "name": { "type": "string", "maxLength": 128, "pattern": "^[\\w .-]+$" },
    "rows": { "type": "integer", "minimum": 0, "maximum": 1000000 }
  }
}

อ่านสิ่งนี้เป็นการป้องกันสี่แบบที่แยกกัน additionalProperties: false ปฏิเสธฟิลด์ template ที่ถูกลักลอบนำเข้าโดยสิ้นเชิง เพื่อให้ผู้โจมตีไม่สามารถเพิ่มมันได้ Enum ของ loader หมายความว่า pickle:// หรือตัวโหลดโค้ดระยะไกลใดๆ ก็ไม่เป็นค่าที่ถูกต้อง maxLength ป้องกันสตริงขนาดหลายเมกะไบต์ที่มุ่งเป้าไปที่การใช้หน่วยความจำจนหมด pattern บน name ปฏิเสธตัวอักษร {{ และ '; DROP TABLE ก่อนที่จะเดินทางไปไกลกว่านี้ บรรทัดเหล่านี้ไม่รู้จักผู้โจมตี พวกมันยอมรับเฉพาะชุดอินพุตที่แคบๆ ที่คุณรองรับจริงๆ เท่านั้น และความแคบนั้นคือคุณสมบัติความปลอดภัย

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

การทดสอบเชิงลบ: พิสูจน์ว่า Endpoint ปฏิเสธ

การทดสอบ Happy-path ยืนยันว่าอินพุตที่ดีสร้างเอาต์พุตที่ดี การทดสอบเชิงลบยืนยันว่าอินพุตที่ไม่ดีสร้างการปฏิเสธที่ควบคุมได้ ความแตกต่างมีความสำคัญเพราะการปฏิเสธคือคุณสมบัติ: 400 พร้อมข้อผิดพลาดที่ชัดเจนคือ API ของคุณกำลังปกป้องขอบเขตของมัน 500 คือ API ของคุณกำลังสูญเสียการควบคุม

สร้างกรณีเชิงลบด้วยวิธีเดียวกันทุกครั้ง สำหรับแต่ละฟิลด์ ให้เขียนลงไปว่าต้องปฏิเสธอะไรบ้าง: ชนิดข้อมูลผิด, ขาดหายเมื่อจำเป็น, มีอยู่เมื่อห้าม, ยาวเกินไป, นอกช่วง และสตริงที่ใช้ในการฉีดโค้ดที่เข้ากับรูปแบบของมัน จากนั้นยืนยันสองสิ่งในการตอบกลับ ประการแรก สถานะเป็น 4xx ซึ่งโดยปกติคือ 400 หรือ 422 ประการที่สอง สถานะไม่เคยเป็น 5xx 500 หมายความว่าอินพุตที่เป็นอันตรายของคุณไปถึงโค้ดที่ไม่พร้อมสำหรับมัน ซึ่งเป็นสิ่งที่ผู้โจมตีต้องการเข้าถึงอย่างแน่นอน รายการตรวจสอบการทดสอบความปลอดภัยของ API ของเรามีรายการเริ่มต้นแบบฟิลด์ต่อฟิลด์ที่คุณสามารถปรับใช้ได้

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

คลาสการฉีดโค้ดที่ควรค่าแก่การทดสอบเฉพาะทาง

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

• SQL injection: ส่ง 1); DROP TABLE datasets;-- เข้าไปในฟิลด์ใดๆ ที่เข้าถึงการสืบค้นข้อมูล Endpoint ควรจะถือว่าเป็นค่าแบบตัวอักษร (literal value) และตอบกลับด้วย 400 หรือส่งคืนผลลัพธ์ที่ว่างเปล่า และไม่ควรแสดงข้อผิดพลาดของฐานข้อมูล
• Template injection: ส่ง {{ 7*7 }} และ {{ config.__class__ }} เข้าไปในฟิลด์ชื่อและป้ายกำกับ หากการตอบกลับมี 49 อยู่ Template engine ได้ประเมินอินพุตของคุณ และนั่นคือโค้ดระยะไกลที่รอการทำงาน
• Insecure deserialization และ remote-code loaders: ส่ง loader เป็น pickle:// หรือวัตถุที่ถูกซีเรียลไลซ์ในที่ที่ควรเป็นค่าธรรมดา นี่คือรูปแบบของ Hugging Face อย่างแท้จริง Endpoint ควรรอปฏิเสธตัวโหลดที่ไม่รู้จักโดยใช้ Allowlist ไม่ใช่พยายามช่วยเหลือ
• Command injection: ส่ง ; id และ $(id) เข้าไปในฟิลด์ใดๆ ที่อาจกลายเป็นอาร์กิวเมนต์ของเชลล์ เช่น ชื่อไฟล์หรือตัวเลือกการแปลง ค่า 200 ที่เปิดเผยรหัสผู้ใช้เป็นข้อค้นพบที่สำคัญ ไม่ใช่เรื่องน่าสนใจ

ข้อมูลขนาดใหญ่เกินไป, ผิดรูปแบบ และความสับสนของประเภทเนื้อหา

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

ส่ง Payload ที่มีขนาดใหญ่เกินไป: ฟิลด์เดียวที่มีตัวอักษรห้าเมกะไบต์ หรืออาร์เรย์ JSON ที่มีล้านองค์ประกอบ API ที่ดีจะบังคับใช้ขีดจำกัดขนาดของ Body และส่งคืน 413 แทนที่จะจัดสรรหน่วยความจำจนกว่าจะล่ม ส่ง Body ที่ผิดรูปแบบด้วย: JSON ที่ถูกตัดทอน, เครื่องหมายจุลภาคท้าย, หรือ JSON ที่ซ้อนกันลึกเป็นพันระดับเพื่อตรวจสอบการใช้ Stack จนหมด คำตอบที่ถูกต้องคือ 400 ที่รวดเร็ว ไม่ใช่ Worker ที่ค้าง

ความสับสนของประเภทเนื้อหา (Content-type confusion) เป็นสิ่งที่เงียบสงบ ประกาศ Content-Type: application/json แต่ส่ง XML หรือประกาศ application/xml และส่ง Payload ที่มีเอนทิตีภายนอกเพื่อตรวจสอบ XXE ลองพลิกอีกทางหนึ่งและส่ง JSON เป็น text/plain เพื่อดูว่า Parser ที่หย่อนยานจะยอมรับมันหรือไม่ ความไม่ตรงกันแต่ละครั้งจะทดสอบว่าเซิร์ฟเวอร์ของคุณเชื่อถือเฮดเดอร์, เชื่อถือ Body หรือตรวจสอบว่าทั้งสองสอดคล้องกันหรือไม่ มันควรกำหนดให้มีการตกลงกันก่อนที่จะแยกวิเคราะห์สิ่งใดๆ

เหตุใด AI agents จึงเพิ่มความเสี่ยง

ทุกสิ่งที่กล่าวมาข้างต้นเป็นความจริงก่อนที่ Agent จะมีอยู่ Agent เปลี่ยนปริมาณและความเร็ว ผู้โจมตีที่เป็นมนุษย์พิมพ์คำขอที่เป็นอันตรายทีละรายการ AI agent สร้างและส่ง Payload ด้วยความเร็วของเครื่องจักร และมันจะสร้างอินพุตที่คนไม่เคยคิดจะลอง

คุณสมบัติสามประการที่ทำให้เรื่องนี้แย่ลง Agent สังเคราะห์อินพุต ดังนั้นพวกมันจึงสร้างค่าฟิลด์ที่มนุษย์ไม่ได้เขียนและไม่มีการทดสอบใดคาดการณ์ไว้ Agent พยายามซ้ำและเรียกใช้ต่อเนื่อง ดังนั้นเอกสารต้นทางที่ถูกโจมตีเพียงฉบับเดียวสามารถกลายเป็นคำขอที่เป็นอันตรายนับพันครั้งต่อ Endpoint ของคุณในไม่กี่วินาที และ Agent ส่งต่อข้อมูลที่ได้รับคำสั่งให้เชื่อถือ ซึ่งเป็นวิธีที่ Payload ที่ซ่อนอยู่ในชุดข้อมูลหรือ Webhook กลายเป็นคำขอจริงไปยัง API ของคุณ รูปแบบของ Hugging Face ที่ "โหลดข้อมูลนี้" กลายเป็น "รันโค้ดนี้" เป็นประเภทของคำสั่งที่ Agent จะดำเนินการข้ามขอบเขตความเชื่อถือโดยไม่สังเกตเห็น บันทึกของเราเกี่ยวกับ การฉีด Prompt สำหรับทีม API จะลงลึกในเรื่องการส่งมอบนี้ การป้องกันไม่เปลี่ยนแปลง; มันแค่ต้องเป็นไปโดยอัตโนมัติ เพราะคุณไม่สามารถตรวจสอบการรับส่งข้อมูลของ Agent ด้วยมือได้

สร้างชุดทดสอบเชิงลบและรันใน CI ทุกครั้งที่มีการเปลี่ยนแปลง

เปลี่ยนกรณีข้างต้นให้เป็นชุดทดสอบที่รันบนทุก Pull Request นี่คือเวอร์ชันพารามิเตอร์แบบกระชับใน pytest ที่เรียกใช้ Endpoint Staging และยืนยันการปฏิเสธที่ควบคุมได้:

import httpx
import pytest

BASE = "https://staging.internal/v1"

HOSTILE_CONFIGS = [
    {"loader": "pickle://s3/models/payload.pkl", "format": "auto"},  # ตัวโหลดโค้ดระยะไกล
    {"loader": "csv", "name": "{{ 7*7 }}"},                          # การฉีดเทมเพลต
    {"loader": "csv", "name": "{{ config.__class__ }}"},             # การสำรวจวัตถุ
    {"loader": "csv", "filter": "1); DROP TABLE datasets;--"},       # SQL injection
    {"loader": "csv", "name": "A" * 5_000_000},                      # ฟิลด์ที่มีขนาดใหญ่เกินไป
]

@pytest.mark.parametrize("config", HOSTILE_CONFIGS)
def test_dataset_config_is_refused(config):
    r = httpx.post(f"{BASE}/datasets", json={"config": config}, timeout=10)
    assert r.status_code in (400, 413, 422), r.text  # ขอบเขตที่ปฏิเสธ
    assert r.status_code < 500, "5xx หมายความว่า Payload ไปถึงตรรกะที่ไม่ควร"
    assert "49" not in r.text, "เทมเพลตถูกเรนเดอร์: การฉีดเทมเพลตฝั่งเซิร์ฟเวอร์"

เชื่อมต่อเข้ากับ CI เพื่อให้มันควบคุมการรวมโค้ด งาน GitHub Actions ขั้นต่ำก็ทำหน้าที่ได้:

name: api-abuse-tests
on: [push, pull_request]
jobs:
  negative-input:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pytest tests/negative_input.py -q

นี่คือจุดที่เครื่องมือที่เน้น Schema มาก่อนได้แสดงบทบาทสำคัญ ใน Apidog คุณออกแบบ Endpoint โดยอ้างอิงสัญญา OpenAPI ดังนั้นทุกคำขอและการตอบกลับจะถูกตรวจสอบกับสัญญานั้นในขณะที่คุณทำการทดสอบ คุณสามารถบันทึกสถานการณ์เชิงลบไว้ข้างสถานการณ์ Happy-path ได้เลย: ฟิลด์ที่มีขนาดใหญ่เกินไป, ชนิดข้อมูลผิดพลาด และสตริงที่ใช้ในการฉีดโค้ดข้างต้น โดยแต่ละกรณีมีการยืนยันว่าสถานะเป็น 4xx จากนั้นคุณรันสถานการณ์เดียวกันใน CI ผ่าน Apidog CLI เพื่อให้การเปลี่ยนแปลงที่ลดหย่อนการตรวจสอบเงียบๆ ล้มเหลวในการ Build แทนที่จะถูกนำไปใช้งาน หากคุณต้องการลอง ดาวน์โหลด Apidog และเพิ่มสถานการณ์เชิงลบหนึ่งกรณีให้กับ Endpoint ที่คุณมีอยู่แล้ว

ต้องเข้าใจขอบเขตให้ชัดเจน Apidog เป็นเครื่องมือสำหรับการออกแบบ, ทดสอบ, จำลอง (mock) และจัดทำเอกสารประกอบการทำงาน มันไม่ได้รัน Web Application Firewall, กรองทราฟฟิกแบบเรียลไทม์ หรือมาแทนที่ SIEM และการตรวจสอบสัญญาในระหว่างการทดสอบก็ไม่สามารถจับการโจมตีได้ทุกรูปแบบ สิ่งที่ทำได้ดีคือการทำให้สัญญาชัดเจนและช่วยให้คุณซื่อสัตย์กับสิ่งที่ Endpoint ยอมรับ เพื่อให้หมวดหมู่ "เราไม่เคยตรวจสอบ" ไม่ใช่สิ่งที่ทำให้คุณประหลาดใจในการใช้งานจริงอีกต่อไป

คำถามที่พบบ่อย

การทดสอบเชิงลบ (negative testing) กับ Fuzzing แตกต่างกันอย่างไร? การทดสอบเชิงลบจะส่งชุดอินพุตที่ไม่ดีที่เลือกมาอย่างตั้งใจ ซึ่งเลือกมาหนึ่งชุดต่อความล้มเหลวที่คุณสนใจ ส่วน Fuzzing จะส่งอินพุตแบบสุ่มหรือที่ถูกดัดแปลงจำนวนมากเพื่อค้นหากรณีที่คุณไม่ได้นึกถึง ให้เริ่มต้นด้วยการทดสอบเชิงลบเพราะทำได้รวดเร็ว, กำหนดผลลัพธ์ได้ และง่ายต่อการรันใน CI เพิ่ม Fuzzing เมื่อคุณต้องการความครอบคลุมที่เกินจินตนาการของคุณเอง

การทดสอบเหล่านี้ควรรันกับ Production หรือไม่? ไม่ ควรรันกับ Staging หรือสภาพแวดล้อมที่แยกออกมาต่างหาก บางกรณี เช่น Payload ที่มีขนาดใหญ่เกินไป หรือการตรวจสอบ Command Injection ถูกออกแบบมาเพื่อทดสอบระบบ และบางกรณีอาจเปลี่ยนแปลงข้อมูลได้หากมีบั๊ก สภาพแวดล้อมการทดสอบที่เฉพาะเจาะจงช่วยให้การทดสอบเป็นไปอย่างรุนแรงโดยไม่มีความเสี่ยงต่อผู้ใช้จริง

Firewall หรือ WAF จะจับสิ่งเหล่านี้ได้อยู่แล้วไม่ใช่หรือ? WAF เป็นการป้องกันเชิงลึกที่มีประโยชน์ แต่มันไม่สามารถใช้แทนการที่แอปพลิเคชันปฏิเสธอินพุตที่ไม่ดีได้ กฎต่างๆ สามารถถูกบายพาสได้ และ WAF ไม่สามารถรู้ตรรกะทางธุรกิจของคุณได้ จุดประสงค์ของการทดสอบเหล่านี้คือเพื่อพิสูจน์ว่า Endpoint นั้นปฏิเสธด้วยตัวเอง ดังนั้นคุณจึงไม่ต้องพึ่งพาตัวกรองที่คุณไม่สามารถควบคุมได้อย่างเต็มที่

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

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