ความเสี่ยงด้านความปลอดภัยของเอเจนต์เบราว์เซอร์เกิดขึ้นเมื่อแอปพลิเคชัน API หรือ CI/CD pipeline ใช้ส่วนหัว User-Agent เพื่อทำการตรวจสอบสิทธิ์หรือการอนุญาตcisแม้ว่าส่วนหัวนั้นจะเป็นสตริงที่ลูกค้าส่งมา ซึ่งคำขอใดๆ ก็สามารถเขียนใหม่ได้อย่างอิสระก็ตาม
ความเสี่ยงที่ซ่อนอยู่เบื้องหลังความไว้วางใจของเอเจนต์ผู้ใช้
แอปพลิเคชันบนเว็บ, API และอื่นๆ อีกมากมาย CI/CD ระบบต่างๆ ยังคงเชื่อถือส่วนหัว User-Agent ในการระบุว่าใครเป็นผู้ส่งคำขอ ซึ่งเป็นข้อสันนิษฐานที่หลงเหลือมาจากยุคแรกๆ ของเว็บ แต่ในปัจจุบัน โลกของ DevSecOpsข้อสันนิษฐานนั้นเป็นอันตราย ความเสี่ยงด้านความปลอดภัยของเอเจนต์เบราว์เซอร์เกิดขึ้นทุกครั้งที่มีการเขียนโค้ด pipelineAPI หรือแอปพลิเคชันต่างๆ ใช้สตริง User-Agent เพื่อใช้ตรรกะหรือบังคับใช้นโยบายความปลอดภัย ตัวอย่างเช่น:
- การสร้าง API อาจอนุญาตให้ส่งคำขอได้เฉพาะจาก "ตัวแทนที่เชื่อถือได้" เท่านั้น
- คลังเก็บอาร์ติแฟกต์อาจอนุญาตเฉพาะเอเจนต์ผู้ใช้บางประเภทเท่านั้น
- ตัวกรองความปลอดภัยอาจบล็อกหรือจำกัดอัตราการส่งคำขอโดยพิจารณาจากส่วนหัวของคำขอ
แต่ส่วนหัว User-Agent เป็นเพียงสตริงข้อความหนึ่ง ซึ่งผู้โจมตีสามารถแก้ไขได้
⚠️ ตัวอย่างที่ไม่ปลอดภัยนี้จัดทำขึ้นเพื่อการศึกษาเท่านั้น ห้ามนำไปใช้ในการผลิตจริง
หากแบ็กเอนด์ของคุณหรือ pipeline หากตรรกะนี้ถือว่าสตริง User-Agent ระบุแหล่งที่มาที่น่าเชื่อถือ นั่นหมายความว่าคุณได้สร้างความเสี่ยงด้านความปลอดภัยของเบราว์เซอร์เอเจนต์แล้ว ซึ่งอาจนำไปสู่การถูกบุกรุกในห่วงโซ่อุปทานได้
การปลอมแปลง User-Agent ทำงานอย่างไรในทางปฏิบัติ
โปรแกรมปลอมแปลง User Agent อาจเป็นเพียงส่วนขยายของเบราว์เซอร์ ไคลเอนต์ HTTP ที่ได้รับการดัดแปลง หรือบอทอัตโนมัติที่ตั้งค่าให้เลียนแบบการรับส่งข้อมูลการสร้างที่ถูกต้องตามกฎหมาย
ผู้โจมตีใช้การปลอมแปลง User Agent เพื่อ:
- ข้ามตัวกรองการเข้าถึงใน API ที่เชื่อถือส่วนหัวเฉพาะบางรายการ
- ปลอมตัวเป็นระบบสร้างโปรแกรม (เช่น Jenkins, GitHub Actions หรือ GitLab Runners)
- หลีกเลี่ยงข้อจำกัดอัตราหรือเครื่องมือวิเคราะห์ความปลอดภัย
- เรียกใช้งานฟังก์ชันเบื้องหลังที่สงวนไว้สำหรับตัวแทนที่ได้รับอนุญาตเท่านั้น
// Attacker sets the User-Agent to impersonate a trusted CI system
curl -A "Jenkins-Agent/2.4" https://internal-api.example.com/build/trigger// Instead of trusting the header, validate a signed request token
if not verify_signature(request.headers["X-Signature"], shared_secret):
reject(request)การปลอมแปลง User Agent นั้นง่าย แต่การตรวจสอบตัวตนที่แท้จริงนั้นไม่ใช่เรื่องง่าย
ความเสี่ยงด้านความปลอดภัยของเอเจนต์เบราว์เซอร์จริงใน CI/CD และห่วงโซ่อุปทาน
ความเสี่ยงด้านความปลอดภัยของเอเจนต์เบราว์เซอร์จะมีความสำคัญอย่างยิ่งเมื่อส่งผลกระทบต่อโครงสร้างพื้นฐานการสร้างหรือการส่งมอบผลลัพธ์ pipelineNS. ใน CI/CD ในสภาพแวดล้อมเช่นนี้ คำขอส่วนใหญ่มักมาจากตัวแทนอัตโนมัติ และผู้โจมตีจะใช้ประโยชน์จากขอบเขตความไว้วางใจนั้น ตัวอย่างจริงได้แก่:
- คำขอสร้างปลอมไปยังรีจิสทรีอาร์ติแฟกต์
- การพึ่งพาภาพสะท้อนในทางที่ผิด
- Pipeline การแสดงบทบาท
// Registry verifies a signed provenance attestation instead of trusting a header
if not verify_attestation(request.artifact, build_provenance):
reject_artifact_upload(request)การร้องขอปลอมแปลงเพียงครั้งเดียวอาจแทรกส่วนประกอบที่เป็นอันตรายเข้าไปในระบบการผลิตได้โดยตรง pipelineนี่คือตัวอย่างสำคัญของความเสี่ยงด้านความปลอดภัยของเอเจนต์เบราว์เซอร์ที่นำไปสู่การละเมิดห่วงโซ่อุปทาน
เหตุใดการตรวจสอบความถูกต้องของส่วนหัวขั้นพื้นฐานจึงล้มเหลวในฐานะมาตรการควบคุมความปลอดภัย
บางครั้งนักพัฒนาอาศัยตัวกรอง regex ที่อิงตามส่วนหัวหรือรายการที่อนุญาตแบบคงที่เพื่อตรวจสอบความถูกต้องของคำขอจากเอเจนต์ แต่น่าเสียดายที่วิธีการเหล่านี้ไม่สามารถป้องกันการปลอมแปลงเอเจนต์ผู้ใช้ได้เลย การตรวจสอบแบบคงที่ เช่น:
⚠️ การตรวจสอบความถูกต้องโดยใช้ Regex ไม่ใช่การรับรองความถูกต้อง ผู้โจมตีสามารถเลียนแบบรูปแบบที่คาดหวังได้ด้วยสตริง User-Agent ปลอม
สามารถหลีกเลี่ยงได้อย่างง่ายดายด้วยวิธี:
ตรรกะแบบนี้จะนำไปสู่ความไว้วางใจที่ผิดพลาดและความเสี่ยงด้านความปลอดภัยสูงสำหรับเบราว์เซอร์ เนื่องจากไม่มีสิ่งใดพิสูจน์ได้ว่าผู้ส่งเป็นบุคคลตามที่กล่าวอ้าง
เสริมความแข็งแกร่งด้านการตรวจสอบความถูกต้องด้วยคำขอที่ลงนามและความสมบูรณ์ของอาร์ติแฟกต์ – หลีกเลี่ยงความเสี่ยงด้านความปลอดภัยของเอเจนต์เบราว์เซอร์
แทนที่จะเชื่อถือค่า User-Agent นักพัฒนาควรตรวจสอบแหล่งที่มาของทุกคำขอผ่านการตรวจสอบความถูกต้องทางด้านการเข้ารหัสและบริบท กลยุทธ์สำคัญในการลดความเสี่ยงด้านความปลอดภัยของเอเจนต์เบราว์เซอร์ ได้แก่:
- TLS ร่วมกัน (mTLS)
- ข้อมูลเมตาหรือคำขอที่ลงนามแล้ว (AWS SigV4, HMAC, JWT)
- การลงนามและการตรวจสอบสิ่งประดิษฐ์
- โทเค็น API ที่มีขอบเขต
- การตรวจสอบนอกแบนด์
ขั้นตอนเหล่านี้ช่วยให้มั่นใจได้ว่า แม้ว่าผู้ปลอมแปลง User Agent จะเลียนแบบส่วนหัวที่เชื่อถือได้ ระบบก็จะยังคงปฏิเสธการรับส่งข้อมูลที่ไม่ได้รับการตรวจสอบหรือไม่ได้ลงนาม
การบูรณาการการตรวจจับและการป้องกันเข้ากับ DevSecOps Pipelines
การตรวจจับการปลอมแปลง User Agent ควรเป็นส่วนหนึ่งของระบบของคุณ CI/CD ระบบส่งข้อมูลทางไกลและการตรวจสอบความถูกต้องอย่างต่อเนื่อง
ทีม DevSecOps สามารถฝังส่วนควบคุมต่างๆ ได้ เช่น:
- การตรวจสอบความถูกต้องของคำขออัตโนมัติ
- ความสัมพันธ์ของข้อมูลโทรมาตร
- การตรวจจับความผิดปกติ
- การบังคับใช้นโยบายตามบริบท
// CI step fails the build if request signatures aren't verified
- name: Verify request provenance
run: xygeni verify-attestation --fail-on unsignedการผสานการตรวจจับและการบังคับใช้นโยบายช่วยให้มั่นใจได้ว่าความเสี่ยงด้านความปลอดภัยของเอเจนต์เบราว์เซอร์จะไม่แอบแฝงเข้ามาทำลายระบบของคุณ pipelineหรือการกระจายสิ่งประดิษฐ์
อย่าเชื่อแค่ส่วนหัว ตรวจสอบแหล่งที่มาให้แน่ใจ
ทุกๆ User-Agent ส่วนหัวของข้อมูลอาจไม่ถูกต้อง โปรแกรมปลอมแปลง User Agent ทุกตัวสามารถปลอมแปลงความถูกต้องได้ และความเสี่ยงด้านความปลอดภัยของ Browser Agent ทุกตัว มาจากการเชื่อถือสิ่งที่ไม่ได้รับการตรวจสอบ วิธีแก้ปัญหาไม่ได้อยู่ที่การลบส่วนหัวออก แต่เป็นการไม่เชื่อถือส่วนหัวนั้นในการตรวจสอบสิทธิ์หรือการบังคับใช้นโยบาย แทนที่จะใช้ส่วนหัว ให้ใช้คำขอที่ลงชื่อแล้ว บังคับใช้การตรวจสอบความถูกต้องของตัวตน และอื่นๆ ตรวจสอบไฟล์ CI/CD การจราจร สำหรับการปลอมแปลงรูปแบบ
ของไซเกนี Build Security ตรวจสอบความสมบูรณ์ของการสร้างผ่านการลงนามอาร์ติแฟกต์แบบไร้กุญแจและ SLSA provenanceดังนั้น คำขอหรือข้อมูลจึงถือว่าน่าเชื่อถือเพราะได้รับการรับรองทางด้านการเข้ารหัส ไม่ใช่เพราะส่วนหัวที่ส่งมาโดยบังเอิญ การตรวจจับความผิดปกติของไซเกนี ระบบนี้จะเพิ่มการตรวจสอบพฤติกรรมเข้าไป โดยจะแจ้งเตือนกิจกรรมที่ผิดปกติทั่วทั้งระบบ CI/CD โครงสร้างพื้นฐาน เช่น งานหรือตัวแทนที่กระทำการนอกเหนือจากรูปแบบปกติในเวลาจริง
อย่าเชื่อตามข้อสันนิษฐาน ตรวจสอบทุกแหล่งข้อมูลให้แน่ใจ เริ่มใช้งานฟรี ไม่ต้องใช้บัตรเครดิต
คำถามที่พบบ่อย
เหตุใดการเชื่อถือส่วนหัว User-Agent จึงเป็นความเสี่ยงด้านความปลอดภัย?
เนื่องจากเป็นเพียงสตริงธรรมดาที่ไคลเอนต์ส่งมา และไคลเอนต์ HTTP, ส่วนขยายเบราว์เซอร์ หรือสคริปต์ใดๆ ก็สามารถกำหนดค่าให้เป็นอะไรก็ได้ตามต้องการ มันไม่ได้พิสูจน์อะไรเกี่ยวกับตัวตนที่แท้จริงของผู้ส่งเลย
การใช้ regex หรือ allowlist สามารถป้องกันการปลอมแปลง User-Agent ได้หรือไม่?
ไม่ รายการที่อนุญาตจะตรวจสอบเพียงว่าสตริงตรงกับรูปแบบที่คาดไว้หรือไม่ และผู้โจมตีสามารถคัดลอกรูปแบบนั้นไปใช้ในคำขอของตนเองได้
ควรใช้สิ่งใดมาแทนที่การตรวจสอบความถูกต้องโดยอิงตาม User-Agent ใน CI/CD?
การตรวจสอบความถูกต้องของแหล่งที่มาด้วยวิธีการเข้ารหัส: TLS แบบสองทาง, คำขอที่ลงนามแล้ว (HMAC, JWT, AWS SigV4) และสิ่งประดิษฐ์การสร้างที่ลงนามแล้วพร้อมการรับรองแหล่งที่มา เช่น SLSA หรือ in-toto
