---
url: https://docs.ogmabox.com/th/guide/proxy-workflow.md
description: >-
  เรียนรู้เวิร์กโฟลว์พร็อกซีของ Ogma ตั้งแต่ต้นจนจบผ่านประวัติ HTTP การดักรับ
  การจับคู่และแทนที่ ประวัติ WebSocket แผนผังเว็บไซต์ การค้นหา
  และประเด็นที่ตรวจพบ
---

# เวิร์กโฟลว์พร็อกซี {#proxy-workflow}

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

## การจัดวางพื้นที่ทำงาน {#workspace-layout}

| ส่วน | มุมมอง |
| --- | --- |
| ภาพรวม | แผนผังเว็บไซต์, เอนด์พอยต์, ขอบเขต, ตัวกรอง |
| พร็อกซี | ดักรับ, ประวัติ HTTP, ประวัติ WS / SSE, จับคู่และแทนที่ |
| การทดสอบ | ส่งซ้ำ, ระบบอัตโนมัติ, เวิร์กโฟลว์, สภาพแวดล้อม |
| เครื่องมืออรรถประโยชน์ | เครื่องมือสแกน, OAST, ตัวถอดรหัส, เปรียบเทียบ, ตัววิเคราะห์ลำดับ, ภาวะแข่งขัน / ลักลอบส่งคำขอ, บันทึกย่อ และเครื่องมือโทเค็น |
| การวิเคราะห์ | ค้นหา, ประเด็นที่ตรวจพบ, รายการส่งออก |
| พื้นที่ทำงาน | ไฟล์, ปลั๊กอิน |

## ประวัติ HTTP {#http-history}

ประวัติ HTTP เป็นตารางหลักสำหรับหลักฐาน ใช้เพื่อ:

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

เวิร์กโฟลว์ที่แนะนำ:

1. จับทราฟฟิกจากเส้นทางการใช้งานที่เป็นตัวแทนของผู้ใช้
2. กรองให้เหลือขอบเขตที่เปิดใช้อยู่
3. เพิ่มแท็กให้คำขอเกี่ยวกับการยืนยันตัวตน การเปลี่ยนสถานะ การอัปโหลด การดูแลระบบ และ API
4. ส่งคำขอที่มีคุณค่าสูงไปยังส่งซ้ำ
5. บันทึกปัญหาที่ยืนยันแล้วเป็นประเด็นที่ตรวจพบ พร้อมเชื่อมโยงหลักฐาน

## ดักรับ {#intercept}

การดักรับจะพักทราฟฟิกที่ตรงเงื่อนไขไว้ก่อนส่งต่อ

ใช้ดักรับเมื่อต้องการ:

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

รักษาขนาดคิวให้มีขีดจำกัด หากคิวดักรับเต็ม Ogma จะปกป้องเวิร์กโฟลว์ด้วยการส่งต่อทราฟฟิกใหม่ แทนที่จะบล็อกไคลเอนต์อย่างไม่มีกำหนด

## จับคู่และแทนที่ {#match-replace}

จับคู่และแทนที่จะเปลี่ยนทราฟฟิกที่ผ่านพร็อกซีโดยอัตโนมัติ

การใช้งานทั่วไป:

* เพิ่มส่วนหัวสำหรับทดสอบ
* แทนที่โทเค็น Bearer หรือคุกกี้
* บังคับค่าของแฟล็กฟีเจอร์
* ปรับส่วนหัวที่มีความแตกต่างรบกวนการตรวจสอบให้เป็นรูปแบบสม่ำเสมอ
* แทรกส่วนหัวติดตามเพื่อเชื่อมโยงบันทึกเหตุการณ์

ใช้เกณฑ์การจับคู่ที่จำกัดเฉพาะเจาะจง กฎที่กว้างเกินไปอาจทำให้ทราฟฟิกที่ไม่เกี่ยวข้องเสียหายและทำให้ทำซ้ำประเด็นที่ตรวจพบได้ยากขึ้น

## WebSocket และ SSE {#websocket-and-sse}

Ogma ติดตามทราฟฟิก WebSocket และเหตุการณ์ที่ส่งจากเซิร์ฟเวอร์แยกจากแถวคำขอและการตอบกลับ HTTP

ใช้ **ประวัติ WS / SSE** เพื่อ:

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

## แผนผังเว็บไซต์และเอนด์พอยต์ {#sitemap-and-endpoints}

ใช้มุมมองภาพรวมเหล่านี้ตั้งแต่เริ่มและใช้อย่างสม่ำเสมอ:

* **แผนผังเว็บไซต์** แสดงโครงสร้างโฮสต์และพาธที่จับไว้
* **เอนด์พอยต์** แสดงพาธ API และเส้นทางที่ค้นพบจาก JavaScript การตอบกลับ และทราฟฟิกที่จับไว้

มุมมองเหล่านี้ช่วยระบุพื้นที่ที่ยังไม่ได้ทดสอบ ก่อนเริ่มการทดสอบแบบแอกทีฟ

## การค้นหาและตัวกรอง {#search-and-filters}

Ogma รองรับการกรองแบบ HTTPQL ใช้ตัวกรองที่บันทึกไว้สำหรับคำค้นเพื่อคัดแยกและประเมินเบื้องต้นที่ใช้ซ้ำได้

ตัวอย่าง:

```text
req.host:example.com AND resp.code:500
```

```text
req.path.cont:"/admin" OR req.path.cont:"/api/"
```

```text
resp.header["set-cookie"].exists
```

ดูไวยากรณ์ที่ [HTTPQL และ StreamQL](../reference/httpql.md)

## ประเด็นที่ตรวจพบ {#findings}

ประเด็นที่ตรวจพบเป็นส่วนสำหรับการรายงาน ประเด็นที่ดีควรมี:

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

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