Tuning WAF برای API؛ از Baseline تا Exception قابل دفاع

پیاده‌سازی WAF برای API با محافظت از چند صفحه وب ساده فرق دارد. APIها payload ساخت‌یافته، endpointهای زیاد، احراز هویت، rate limit، token، headerهای خاص و رفتارهای غیرمرئی برای کاربر دارند. اگر WAF بدون شناخت baseline روی API فعال شود، احتمال false positive بالا می‌رود؛ اگر هم برای رفع مشکل همه چیز را باز کنیم، WAF عملاً بی‌اثر می‌شود.

Baseline یعنی رفتار عادی API را بفهمیم

قبل از block، باید رفتار عادی API دیده شود. کدام endpointها پرترافیک هستند؟ کدام‌ها فقط توسط سیستم داخلی صدا زده می‌شوند؟ چه payloadهایی مجازند؟ کدام headerها لازم‌اند؟ چه response codeهایی طبیعی‌اند؟ بدون این baseline، هر alert شبیه حمله به نظر می‌رسد یا هر حمله شبیه رفتار عادی رد می‌شود.

OWASP API Security Top 10 یادآوری می‌کند که ریسک API فقط injection نیست. احراز هویت، کنترل سطح دسترسی، مصرف بیش از حد منابع، exposure داده و endpointهای فراموش‌شده هم مهم‌اند. WAF بخشی از این تصویر است، نه کل راه‌حل.

Exception باید محدود و قابل توضیح باشد

وقتی false positive رخ می‌دهد، ساده‌ترین کار خاموش کردن signature یا باز کردن مسیر است. این معمولاً بدترین کار است. exception خوب باید دقیق باشد: برای کدام URL، کدام پارامتر، کدام method، کدام content-type و با چه دلیل. اگر exception قابل توضیح نیست، احتمالاً یا baseline ناقص است یا اپلیکیشن باید اصلاح شود.

• Exception را روی کل سایت اعمال نکنید مگر واقعاً لازم باشد.
• برای endpointهای upload، search و auth حساسیت جدا تعریف کنید.
• لاگ قبل و بعد از exception را نگه دارید تا اثر تغییر مشخص باشد.
• تیم توسعه باید بداند کدام رفتار اپلیکیشن باعث exception شده است.

Rate و Bot را جدا از Signature ببینید

در APIها، بعضی ریسک‌ها با signature حل نمی‌شوند. endpoint ورود، ارسال کد، جست‌وجو، قیمت‌گیری، پرداخت یا دریافت گزارش ممکن است از نظر payload سالم باشد اما از نظر نرخ درخواست یا الگوی مصرف مشکوک باشد. WAF یا ابزارهای کنار آن باید بتوانند rate، reputation، geo، token failure و الگوی خطا را هم ببینند.

FortiWeb و F5 ASM در مسیر API

در FortiWeb، مسیر monitor تا block و تحلیل لاگ request اهمیت زیادی دارد. در F5 ASM یا Advanced WAF هم یادگیری policy، signature staging، parameter handling و exception دقیق مهم است. انتخاب ابزار مهم است، اما مهم‌تر از آن فرآیند tuning است. بدون فرآیند، بهترین ابزار هم یا زیاد block می‌کند یا زیاد اجازه می‌دهد.

اتصال به مسیر خدمات

اگر مسئله شما طراحی یا tuning WAF است، صفحه مشاوره و پیاده‌سازی WAF مسیر اصلی خدمات است. برای FortiWeb، صفحه FortiWeb و برای معماری F5، صفحه F5 Load Balancer مکمل‌های فنی همین خوشه هستند.

از log خام تا تصمیم tuning

لاگ WAF وقتی مفید است که بتوان از آن تصمیم ساخت. هر false positive باید حداقل چند چیز را نشان دهد: endpoint، method، پارامتر یا بخش payload، signature یا policy trigger، IP یا هویت مصرف‌کننده، و اثر روی کاربر. اگر این اطلاعات کنار هم دیده نشوند، tuning تبدیل به خاموش کردن کورکورانه ruleها می‌شود.

برای APIهای حساس، بهتر است exceptionها در بازبینی دوره‌ای مرور شوند. exceptionی که برای رفع مشکل فوری ساخته شده، ممکن است چند ماه بعد دیگر لازم نباشد یا ریسک جدیدی ایجاد کند. به همین دلیل exception باید owner و تاریخ بازبینی داشته باشد.

مسیر امن رفتن به block

• ابتدا monitor برای شناخت رفتار عادی.
• بعد staging یا alert برای signatureهای پرریسک.
• سپس exceptionهای محدود و مستند.
• در نهایت block مرحله‌ای برای endpointهای تست‌شده.

چه زمانی WAF کافی نیست؟

اگر مشکل اصلی در مجوزدهی اشتباه، نشت داده از منطق API یا طراحی نادرست نقش‌ها باشد، WAF فقط می‌تواند بخشی از نشانه‌ها را ببیند. در این حالت باید کنار tuning، اصلاح اپلیکیشن و تست امنیتی هم انجام شود. WAF ابزار کاهش ریسک است، نه جایگزین طراحی امن API.