چسباندن یک فایل خام HAR در محیط چت هوش مصنوعی، یک گام برای عیبیابی نیست؛ بلکه نقض صریح مرزهای اعتماد است. اگر همین حالا برای حل یک مشکل فنی، فایلهای خروجی مرورگر را به مدلهای زبانی میدهید، احتمالاً کلیدهای دسترسی به حسابهای کاربری خود را در اختیار یک سرور خارجی قرار دادهاید.
طبق گزارشی که در ۶ سپتامبر ۲۰۲۶ در dev.to منتشر شد، بسیاری از توسعهدهندگان هنگام درخواست کمک از هوش مصنوعی برای حل حلقههای تکرار در ورود (Login Loops)، بهطور ناخواسته تمام «جار» نشستهای خود — شامل توکنهای JWT و کوکیهای چالش WAF — را لو میدهند. وقتی در DevTools روی Export HAR کلیک میکنید، در واقع یک خط زمانی از تمام تبادلات مرورگر را استخراج میکنید. این فایلها صرفاً ردپای خطا نیستند، بلکه شامل هر کوکی، توکن Bearer و حتی نامهای شناسایی زیرساختهای امنیتی شما هستند.
در دنیای توسعه، این دادهها شبیه به یک «جعبه ابزار باز» هستند که هر کسی آن را پیدا کند، میتواند خود را جای شما جا بزند. همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، دادههایی که از مرز استنتاج (Inference) — یعنی لحظهای که مدل واقعاً جواب تولید میکند، شبیه به آشپزی است نه دورهی آموزش آشپز — عبور میکنند، دیگر تحت کنترل شما نیستند. این اطلاعات در لاگهای پرامپت، گزارشات اپراتورهای GPU و نسخههای پشتیبان ذخیره میشوند و هرگز نمیتوان آنها را «پس گرفت».
بر اساس مستندات dev.to، امنیت این فرآیند به سه مرز اعتماد وابسته است:
۱. مرورگر به سرور: کوکیها باید از این مسیر و از طریق HTTPS عبور کنند.
۲. لپتاپ به مدل: کوکیها هرگز نباید از این مرز عبور کنند. نشت داده دقیقاً در همین مرحله و هنگام کپی-پیست رخ میدهد. ابزار پالایش (Redactor) باید دقیقاً روی لپتاپ شما نصب باشد.
۳. اپراتور مدل به حافظه: نقطهی بازگشتناپذیر جایی است که پرامپتها لاگ میشوند. چه از مدلهای رایگان ابری استفاده کنید و چه از سرورهای شخصی، نیاز به پالایش در مرز دوم تغییر نمیکند.
راهکار این نیست که به «ادب» مدل یا پرامپتهایی که از آن میخواهید اسرار را نادیده بگیرد اعتماد کنید. عاملهای هوش مصنوعی (AI Agents) — سیستمهایی که میتوانند بهطور مستقل ابزارها را اجرا کنند — خطر را بیشتر میکنند؛ چون فرض میکنند هر دادهای در بستر متن، بخشی از زمینه است و ممکن است آن را دوباره ارسال کنند. این چالشها نشان میدهد که امنیت عاملهای هوش مصنوعی باید از تستهای سادهی پرامپت به سمت کنترل دقیق ابزارها تغییر کند تا از نشتهای ناخواسته جلوگیری شود.
برای ساخت یک گیت پالایش موثر، باید روی یک «لیست سیاه خستهکننده» تمرکز کرد. هدف این است که فیلدهای پرخطر حذف شوند اما مسیرهای عمومی، کدهای وضعیت و زمانبندیها (مثلاً POST /login → 302) باقی بمانند تا مدل همچنان بتواند زنجیره تغییر مسیر را تحلیل کند. در واقع، ایجاد چنین گیتهایی برای تایید انسانی یا خودکار، مشابه رویکرد «تعلیق و بازگشت» برای مهار ریسکهای عملیاتی در وبهوکهاست که اجازه نمیدهد دادهها بدون پالایش به مرحله اجرا برسند.
برای شناسایی نشت داده بدون نیاز به مدل، میتوان از یک دستور تکخطی پایتون برای اسکن فایل HAR استفاده کرد:python3 -c "import json; h=json.load(open('fixtures/login-loop.har')); print([x for e in h['log']['entries'] for x in e['request']['headers'] if x['name'].lower() in ('cookie','authorization')])"
اگر خروجی این دستور هنوز شامل کلمه Cookie باشد، شما در حال کار با دادههای حساس محیط عملیاتی هستید و نباید آنها را در هیچ محیط چتی آپلود کنید.
برای حفظ مرز اعتماد، فیلدهای زیر باید بهطور سختگیرانه فیلتر شوند:
- هدرهای درخواست و پاسخ: شامل
Cookie،Set-Cookie،AuthorizationوX-Api-Key. - پارامترهای کوئری: هر چیزی که شامل
token،codeیاaccess_tokenباشد. - دادههای POST: هر متنی که شامل
password،otpیاclient_secretباشد. - زیرساختهای داخلی: هاستهایی که به
.internalیا.corpختم میشوند و رنجهای IP خصوصی (مانند10.0.0.0/8).
برای اطمینان از عملکرد پالایشگر، پیشنهاد میشود از رویکرد «فیکسچر مثبت و منفی» استفاده کنید. فیکسچر مثبت، یک فایل HAR مصنوعی است که حاوی کوکی است و باید توسط گیت رد شود. فیکسچر منفی، همان فایل پس از پالایش است که باید پذیرفته شود. بدون این دو، شما کنترل ندارید و فقط ادعا میکنید که سیستم امن است.
توسعهدهندگان میتوانند این سیستم را با پایتون ۳.۱۲ و pytest ۸.x پیاده کنند. برای کسانی که از MonkeyCode (یک پلتفرم متنباز توسعه هوش مصنوعی) استفاده میکنند، مسیر سرور رایگان اجازه میدهد لاگها را برای یافتن نشت داده بررسی کنند، اما در مدلهای ابری، تنها دفاع شما پیشگیری است. اگر فایلی را بدون پالایش ارسال کردید، فرض کنید نشست شما لو رفته است؛ راه حل، چرخش کوکیها و ابطال نشست در IdP است، نه درخواست از مدل برای «فراموش کردن» دادهها.
برای کسانی که سرور خودشان را مدیریت میکنند، تزریق یک «کوکی قناری» (Canary Cookie) — یک رشته تصادفی منحصربهفرد — توصیه میشود. اگر این رشته در لاگهای پرامپت ظاهر شود، مدرک قطعی نشت داده دارید. اما در مدلهای شخص ثالث، این قناری هرگز دیده نمیشود چون به لاگها دسترسی ندارید.
در نهایت، لایههای مختلف نیاز به پاسخهای متفاوتی دارند:
- لایه لپتاپ: استفاده از گیت پالایش پیش از کپی در کلیپبورد.
- هارنس عامل: رد کردن فایلهای
*.harمگر اینکه تاییدیه امنیتی بگیرند. - سرور مدیریتشده: حذف پرامپتهایی که شامل
Cookie:هستند و چرخش سریع کلیدها در صورت خطا. - سرور شخص ثالث: عدم ارسال فایل خام به هر قیمتی.
باید به خاطر داشت که این روش یک ابزار بازگشتی است و جایگزین سیستمهای جامع جلوگیری از نشت داده (DLP) نمیشود. این اسکریپتها ممکن است اسراری که در فیلدهای غیر استاندارد یا اسکرینشاتهای پنل Application مرورگر پنهان شدهاند را نبینند. برای دادههای حساس پزشکی یا دولتی، تنها راه، استفاده از مرورگرهای مدیریتشده و مسدود کردن مسیرهای کلیپبورد است.
گام بعدی شما
- تمام فایلهای HAR ذخیره شده در مخازن کد (Repo) خود را بررسی کنید و نسخههای خام را حذف نمایید.
- یک اسکریپت پالایش ساده بر اساس لیست سیاه ذکر شده در این مقاله برای گردشکار عیبیابی خود بنویسید.
- در صورت استفاده از مدلهای ابری، هرگز فایلهای خروجی DevTools را بدون بررسی دستی یا خودکار ارسال نکنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو