HTTP Protocol Constraints در FortiWeb

این مقاله بر اساسFortiWeb 7.6.9نوشته شده است. ساختار اصلی HTTP Protocol Constraints در Patchهای 7.6 مشابه است، اما FortiWeb 7.6.9 سخت‌سازی بیشتری برای HTTP/2 و HTTP/3 اضافه کرده است و بعضی Field Nameها یا Constraintها میان 7.6.0 تا 7.6.9 تفاوت دارند. در FortiWeb 7.4 برخی کنترل‌های HTTP/3 وجود ندارند و در FortiWeb 8.0 گزینه‌ها توسعه یافته‌اند. قبل از Paste کردن CLI، داخل Context مربوطه ازset ?وshow full-configurationاستفاده کنید.

مروری بر این مقاله

1. حملات و ناهنجاری‌های پروتکل HTTP
2. FortiWeb Request را چگونه بررسی می‌کند؟
3. معماری Profile و Exception
4. Action، Severity، Threat Weight و Trigger
5. Content-Length و Transfer-Encoding
6. Header Constraints
7. URL، Parameter و Cookie Constraints
8. Method، Version، Range و Multipart
9. HTTP/2 و HTTP/3 Constraints
10. HTTP Cache Size و Request Buffer
11. دلایل رایج False Positive
12. روش جمع‌آوری Baseline
13. سناریوی عملی Portal، SSO، API و Upload
14. ساخت Exception در GUI
15. ساخت Constraint Profile در GUI
16. اتصال Profile به Web Protection Profile
17. پیکربندی کامل در CLI
18. روش انتقال از Alert به Block
19. روش تست امن
20. تحلیل Log و Tune کردن
21. Troubleshooting
22. Best Practice و چک‌لیست اجرایی

1. حملات و ناهنجاری‌های پروتکل HTTP

HTTP Request Smuggling

اینحملهزمانی ممکن می‌شود که دو مؤلفه زنجیره، مرز Request را متفاوت تشخیص دهند. مثال کلاسیک وجود هم‌زمانContent-LengthوTransfer-Encodingیا چند Content-Length متفاوت است. یک Proxy ممکن است یکی را مبنا قرار دهد و Backend دیگری را.

Oversized Header و Resource Exhaustion

Header یا Cookie بسیار بزرگ می‌تواند Memory و CPU Parser را مصرف کند. با این حال، SAML، Kerberos، JWT و Application Gatewayهای واقعی نیز ممکن است Header بزرگ تولید کنند؛ بنابراین Limit باید اندازه‌گیری شود.

Malformed Request

Request دارای Syntax ناقص، Character غیرمجاز، Chunk Size نامعتبر، Multipart Boundary خراب یا Header بدون ساختار صحیح است. بعضی Clientهای قدیمی Request غیرمعمول ولی عملیاتی تولید می‌کنند و می‌توانند False Positive ایجاد کنند.

Range-based DoS

تعداد زیاد Range یا Rangeهای هم‌پوشان می‌تواند Backend را مجبور به تولید پاسخ‌های پیچیده و مصرف Resource کند.

Parameter Pollution

وجود Parameterهای تکراری با یک نام می‌تواند میان Frameworkها رفتار متفاوت ایجاد کند؛ یک لایه اولین مقدار را بخواند و لایه دیگر آخرین مقدار را.

2. FortiWeb Request را چگونه بررسی می‌کند؟

FortiWeb بعد از دریافت Request، ساختار پروتکل را Parse می‌کند و Constraintهای فعال را بررسی می‌کند. نتیجه Match می‌تواند فقط Log شود یا Request را Block کند. Exception مشخص می‌کند بعضی Checkها برای Host، URL یا Source خاص اجرا نشوند.

جریان ساده پردازش

1. اتصال Client به Virtual Server یا Server Policy
2. تشخیص HTTP Version و Parse Request
3. بررسی HTTP Protocol Constraints
4. بررسی Exceptionهای Matchشده
5. اجرای Action برای Constraintهایی که Exception نشده‌اند
6. ادامه سایر کنترل‌های Web Protection Profile
7. ارسال Request مجاز به Backend

3. معماری Profile و Exception

Scopeهای Exception

• Protected Host
• URL به‌صورت Simple String یا Regular Expression
• Source IPv4، IPv6 یا IP Range در Buildهای پشتیبانی‌شده
• Constraintهای انتخاب‌شده برای Omit

4. Action، Severity، Threat Weight و Trigger

Severity برای اولویت Event و Threat Weight برای محاسبه Risk Score یا Triggerهای تجمعی استفاده می‌شود. Trigger Action می‌تواند Email، SNMP، FortiAnalyzer یا Integration دیگر را فعال کند.

5. Content-Length و Transfer-Encoding

• Illegal Content Length و CL/TE Coexistence معمولاً Candidate خوبی برای Block زودهنگام هستند.
• Body Length باید برای هر Application Class اندازه‌گیری شود.
• Upload Endpoint بهتر است Exception محدود داشته باشد، نه افزایش سراسری Limit.

6. Header Constraints

نکته SSO

SAML Response معمولاً داخل Body است، اما Cookie، Relay State، JWT یا Headerهای Reverse Proxy می‌توانند حجم زیادی ایجاد کنند. قبل از افزایش Header Limit، مشخص کنید کدام Header عامل افزایش است.

7. URL، Parameter و Cookie Constraints

URL Length

Search و Filterهای پیچیده ممکن است Query String طولانی داشته باشند. APIهای طراحی‌شده با GET برای Payload بزرگ بهتر است بازطراحی شوند، اما تغییر FortiWeb نباید بدون هماهنگی Application Team انجام شود.

Parameter Count و Length

Formهای Dynamic، Data Grid و GraphQL می‌توانند تعداد Parameter یا Body بزرگ تولید کنند. Constraint باید با Endpoint واقعی Tune شود.

Duplicate Parameter Name

بعضی Frameworkها Array را با نام تکراری ارسال می‌کنند؛ برای مثالitem=1&item=2. قبل از Block مشخص کنید این رفتار بخشی از طراحی برنامه است یا Parameter Pollution.

Null Character و Illegal Character

وجود Null Byte در URL یا Parameter معمولاً مشکوک است و می‌تواند در Bypass یا Truncation استفاده شود. این کنترل معمولاً Candidate خوبی برای Block است، مگر Application Legacy رفتار خاصی داشته باشد.

Cookie Count و Length

پرتال‌هایی که چند Application روی یک Domain دارند ممکن است Cookieهای زیادی ارسال کنند. Domain و Path Cookieها باید توسط Application Team اصلاح شود؛ افزایش نامحدود Limit راه‌حل بلندمدت نیست.

8. Method، Version، Range و Multipart

HTTP Method

Range

برای Video Streaming و Download Resume، Range لازم است. تعداد Range یا Overlap باید محدود شود، اما حذف کامل Range می‌تواند Streaming را مختل کند.

Multipart

Upload فایل ازmultipart/form-dataاستفاده می‌کند. Boundary نامعتبر، Header ناقص یا Part غیرعادی می‌تواند Malformed تشخیص داده شود. Endpointهای Upload باید با Browser، Mobile App و SDK واقعی تست شوند.

9. HTTP/2 و HTTP/3 Constraints

HTTP/2 و HTTP/3 Request را به Frame یا Stream تقسیم می‌کنند و محدودیت‌های متفاوتی نسبت به HTTP/1.1 دارند. FortiWeb 7.6.9 سخت‌سازی بیشتری برای این پروتکل‌ها ارائه می‌دهد.

موارد مهم HTTP/2

• Maximum Header List Size
• Maximum Frame Size
• Concurrent Streams
• Header Compression و Dynamic Table
• Protocol Error و Invalid Frame Sequence

موارد مهم HTTP/3

• QUIC Stream Limit
• Header/QPACK Limit
• Connection و Stream Behavior
• UDP Path، Load Balancer و Client Compatibility

10. HTTP Cache Size و Request Buffer

FortiWeb برای Parse و Scan بعضی Requestها به Buffer نیاز دارد. اگر Request بزرگ‌تر از Cache یا Scan Buffer باشد، ممکن است رفتار Check تغییر کند یا Request به‌صورت Malformed دیده شود.

• افزایش Buffer مصرف Memory را بالا می‌برد.
• مقدار باید با Model، Concurrent Connection و Request Size هماهنگ باشد.
• برای Upload بزرگ، Exception یا معماری Streaming ممکن است بهتر از افزایش سراسری Buffer باشد.
• قبل از تغییرHTTP-cachesizeمستندات CLI همان Build و ظرفیت Appliance را بررسی کنید.

11. دلایل رایج False Positive

12. روش جمع‌آوری Baseline

1. Flowهای برنامه را فهرست کنید.
2. حداقل یک چرخه کاری شامل Peak Business را مشاهده کنید.
3. Requestهای Chrome، Firefox، Edge، Mobile App و Integration را جمع‌آوری کنید.
4. برای هر URL حداکثر Header، Body، URL Length، Parameter Count و Cookie را ثبت کنید.
5. Requestهای خطادار واقعی را جدا از Traffic Attack دسته‌بندی کنید.
6. مقدار P95، P99 و Maximum را بررسی کنید.
7. Margin منطقی اضافه کنید، نه چند برابر نامحدود.

13. سناریوی عملی Portal، SSO، API و Upload

دامنهportal.example.comچهار Flow دارد

• Header Length: 16 KB
• Body Length عمومی: 10 MB
• Illegal Content Length: Alert
• CL/TE Coexistence: Alert
• Malformed Request: Alert
• Upload Exception: فقط Body Length

14. ساخت Exception در GUI

1. رویCreate Newکلیک کنید.
2. Name راPARTIAN-UPLOAD-BODY-EXCEPTIONقرار دهید.
3. یک Rule Entry بسازید.
4. Host Status را فعال کنید.
5. Protected Host برابرportal.example.comرا انتخاب کنید.
6. Request Type راSimple Stringانتخاب کنید.
7. Request URL را/upload/largeوارد کنید.
8. فقطMaximum HTTP Body Lengthرا فعال کنید.
9. تنظیم را ذخیره کنید.

15. ساخت Constraint Profile در GUI

1. Name راPARTIAN-HPC-MONITORوارد کنید.
2. Exception ساخته‌شده را انتخاب کنید.
3. برای هر Constraint ابتدا Status را فعال و Action را Alert قرار دهید.
4. Severity را بر اساس ریسک تنظیم کنید.
5. Trigger Action را برای Eventهای High یا Critical انتخاب کنید.
6. Limitهای Header، Body، URL، Parameter و Cookie را از Baseline وارد کنید.
7. Methodهای لازم را بر اساس Application مشخص کنید.
8. HTTP/2 و HTTP/3 را با Traffic واقعی تست کنید.
9. Profile را ذخیره کنید.

16. اتصال Profile به Web Protection Profile

1. Profile متصل به Server Policy واقعی را پیدا کنید.
2. در بخش Protocol، HTTP Protocol Constraints را فعال کنید.
3. PARTIAN-HPC-MONITORرا انتخاب کنید.
4. Profile را Save کنید.
5. در Server Policy تأیید کنید همین Web Protection Profile اعمال شده است.
6. از Revision یاBackupقبل از تغییر نگهداری کنید.

در Offline Protection نیز قابلیت می‌تواند استفاده شود، اما Actionهای قابل اجرا و رفتار Block با Mode استقرار متفاوت است. برای Enforcement واقعی، Inline Mode لازم است.

17. پیکربندی کامل در CLI

Exception محدود برای Upload

config waf HTTP-constraints-exceptions edit "PARTIAN-UPLOAD-BODY-EXCEPTION" config HTTP_constraints-exception-list edit 1 set host-status enable set host "portal.example.com" set request-type plain set request-file "/upload/large" set max-HTTP-body-length enable next end next end

Profile اولیه در Alert Mode

config waf HTTP-protocol-parameter-restriction edit "PARTIAN-HPC-MONITOR" set exception "PARTIAN-UPLOAD-BODY-EXCEPTION" set illegal-content-length-check enable set illegal-content-length-action alert set illegal-content-length-severity High set cl-te-coexist-check enable set cl-te-coexist-action alert set cl-te-coexist-severity High set max-HTTP-header-length-check enable set max-HTTP-header-length 16384 set max-HTTP-header-length-action alert set max-HTTP-header-length-severity Medium set max-HTTP-body-length-check enable set max-HTTP-body-length set max-HTTP-body-length-action alert set max-HTTP-body-length-severity Medium set block-malformed-request-check enable set block-malformed-request-action alert set block-malformed-request-severity High next end

اتصال به Inline Protection Profile

config waf web-protection-profile inline-protection edit "PARTIAN-INLINE-PROFILE" set HTTP-protocol-parameter-restriction "PARTIAN-HPC-MONITOR" next end

بررسی Optionهای Build

config waf HTTP-protocol-parameter-restriction edit "PARTIAN-HPC-MONITOR" set ? end end show waf HTTP-constraints-exceptions show waf HTTP-protocol-parameter-restriction show waf web-protection-profile inline-protection

انتقال کنترل‌های ساختاری به Block

config waf HTTP-protocol-parameter-restriction edit "PARTIAN-HPC-MONITOR" set illegal-content-length-action alert_deny set cl-te-coexist-action alert_deny set block-malformed-request-action alert_deny next end

18. روش انتقال از Alert به Block

1. Illegal Content-Length
2. CL/TE Coexistence
3. Illegal Chunk Size
4. Null Character
5. Illegal Header Character
6. Malformed Request پس از تحلیل
7. Length و Count Thresholdها بعد از Baseline

19. روش تست امن

تست Functional

• Login Local و SSO
• Upload کوچک، نزدیک Limit و بالاتر از Limit
• REST API با GET، POST، PATCH و DELETE
• CORS Preflight با OPTIONS
• Download Resume و Range
• Chrome، Firefox، Edge و Mobile App
• HTTP/1.1، HTTP/2 و HTTP/3

تست Negative در محیط مجاز

• Content-Length غیرعددی
• دو Content-Length متفاوت
• Content-Length همراه Transfer-Encoding
• Header بزرگ‌تر از Limit
• URL بزرگ‌تر از Limit
• Null Byte یا Character غیرمجاز
• Multipart Boundary خراب

20. تحلیل Log و Tune کردن

• Rule Name و Constraint Name
• Action و Severity
• Host و URL
• Client IP و X-Forwarded-For معتبر
• HTTP Method و Version
• Request Length و Limit
• User Agent و Client Type
• Timestamp و تعداد تکرار

21. Troubleshooting

22. Best Practice و چک‌لیست اجرایی

• تمام Flowهای Application فهرست شده‌اند.
• Baseline شامل Peak Business است.
• Browser، Mobile و Integration تست شده‌اند.
• HTTP/1.1، HTTP/2 و HTTP/3 بررسی شده‌اند.
• Profile ابتدا در Alert Mode اجرا شده است.
• Header، Body، URL، Parameter و Cookie اندازه‌گیری شده‌اند.
• Illegal Content-Length و CL/TE جداگانه بررسی شده‌اند.
• Malformed Request بدون تحلیل Block نشده است.
• Exception قبل از Profile ساخته شده است.
• Exception فقط Host و URL لازم را پوشش می‌دهد.
• فقط Constraint لازم Omit شده است.
• Regex غیرضروری استفاده نشده است.
• Rule Order بررسی شده است.
• Upload و SSO Scope جدا دارند.
• HTTP Cache Size با ظرفیت Model هماهنگ است.
• Block Period پشت NAT بدون بررسی استفاده نشده است.
• Attack Log و Trigger Action فعال‌اند.
• بعد از هر Release Regression Test انجام می‌شود.
• Backup و Rollback Plan وجود دارد.

برای ارزیابی پایداری، امنیت و نگهداری این زیرساخت، راهنمایپشتیبانی شبکهرا نیز مطالعه کنید.