بازگشت به وبلاگ

چه چیزی دستیار هوش مصنوعی شما به بیرون ارسال می‌کند: بررسی ترافیک با استفاده از mitmproxy

تحلیل ترافیک GitHub Copilot نشان داد: مشتری تا 20 فایل زمینه، تفاوت‌های ویرایش و محتوای فایل .env باز شده را جمع‌آوری می‌کند - همه به سرور به عنوان متن معمولی ارسال می‌شود و تاریخچه محلی چت بدون رمزنگاری ذخیره می‌شود. دستورالعمل مرحله به مرحله برای راه‌اندازی mitmproxy در حالت محلی، گرفتن کاناری در بدنه درخواست و اینکه چرا استثنای محتوای استاندارد در حالت عامل نجات نمی‌دهد.

📅۲۴ مرداد ۱۴۰۵
چه چیزی دستیار هوش مصنوعی شما به بیرون ارسال می‌کند: بررسی ترافیک با استفاده از mitmproxy
```html

۱۱ اوت ۲۰۲۶ در Hacker News تحلیلی منتشر شد که هر کسی که یک دستیار AI در IDE کاری خود دارد باید آن را بخواند: یک محقق VS Code را با GitHub Copilot به یک پروکسی نفوذی متصل کرد و مشاهده کرد که چه چیزی به سرورها ارسال می‌شود. مشخص شد که در درخواست، به وضوح بیشتر از خطی که شما اضافه می‌کنید، شامل محتویات فایل .env به صورت خام می‌شود.

خبر خوب: هر کسی می‌تواند این را بررسی کند و نه تنها بر روی Copilot. در زیر یک دستورالعمل کاری وجود دارد که چگونه در ۲۰–۳۰ دقیقه ترافیک دستیار خود را بررسی کنید، چه چیزی را در درخواست‌های نفوذی جستجو کنید و چه محدودیت‌هایی در مکانیزم‌های پیش‌فرض استثنای فایل وجود دارد.

چرا باید خودتان این کار را انجام دهید

مستندات فروشنده سیاست‌ها را توصیف می‌کند، نه رفتار واقعی مشتری. بین «ما از کد شما برای آموزش استفاده نمی‌کنیم» و «مشتری کد شما را به سرور ارسال نمی‌کند» فاصله زیادی وجود دارد: برای تولید یک پیشنهاد، مدل باید زمینه را دریافت کند و تنها سوال این است که مشتری این زمینه را به چه اندازه گسترده جمع‌آوری می‌کند.

بررسی لازم است اگر شما:

  • بر اساس NDA کار می‌کنید یا با داده‌های شخصی مشتریان سر و کار دارید و موظفید بدانید چه چیزی از مرز خارج می‌شود؛
  • در مخزن خود اسرار، پیکربندی‌های ایستگاه‌ها، آدرس‌های داخلی و توکن‌ها را نگه می‌دارید؛
  • مسئول انطباق در تیم هستید و به یک لاگ واقعی از درخواست‌ها نیاز دارید، نه یک اسکرین‌شات از تنظیمات؛
  • فقط می‌خواهید بفهمید چرا دستیار به طور ناگهانی «می‌داند» درباره فایلی که شما باز نکرده‌اید.

چه چیزی در ترافیک Copilot پیدا شد

تحلیلی که در مورد آن صحبت می‌شود، به کلاسیک mitmproxy تکیه داشت: VS Code به یک پروکسی محلی در پورت ۸۰۸۰ هدایت شد و بررسی دقیق گواهی را غیرفعال کرد. یافته‌های کلیدی:

  • زمینه گسترده‌تر از یک فایل است. در تکمیل‌های درون‌خطی، مشتری تا ۲۰ فایل، ۸ خلاصه از آخرین ویرایش‌ها و ۳ خط زمینه در اطراف هر تغییر جمع‌آوری می‌کند، به علاوه متن کامل فایل جاری و فایل‌های اخیراً ویرایش شده به صورت دیف.
  • اسرار مخفی نمی‌شوند. در بدنه درخواست، فیلد prompt شامل رشته‌ای به شکل TEST_ENV_VAR_SECRET="mysecretenvvar" بود — به این معنی که متغیرهای محیطی از فایل باز به صورت متن عادی ارسال می‌شدند.
  • پایگاه محلی نیز باز است. فایل session-store.db user_message و assistant_response را بدون رمزنگاری و ویرایش ذخیره می‌کند: در آن توکن‌ها، کلیدهای ارائه‌دهندگان ابری و رمزهای عبور از رشته‌های اتصال که شما زمانی در چت وارد کرده‌اید، ذخیره می‌شوند.
  • فراخوانی‌های خدماتی. علاوه بر خود تکمیل‌ها، مشتری /models، /agents/swe/models، /models/session/intent و نقاط پایانی OAuth GitHub را فراخوانی می‌کند — از این طریق به وضوح می‌توان دید که دستیار درخواست شما را قبل از تولید پاسخ چگونه طبقه‌بندی می‌کند.

به طور جداگانه باید به یاد داشت: مشتری URL مخزن جاری را به سرور ارسال می‌کند تا سیاست استثنای قابل اجرا را دریافت کند. این واقعیت به خودی خود بی‌ضرر است، اما به این معنی است که ترکیب درخت کاری شما نیز یک سیگنال است.

گام به گام: راه‌اندازی نفوذ

  1. mitmproxy را نصب کنید و آن را راه‌اندازی کنید. وب‌اینترفیس کافی است: mitmweb. به طور پیش‌فرض پروکسی به پورت ۸۰۸۰ گوش می‌دهد و کنسول در مرورگر باز می‌شود. برای CI و جلسات طولانی‌تر، mitmdump راحت‌تر است.
  2. گواهی ریشه را نصب کنید. در اولین راه‌اندازی mitmproxy یک CA در دایرکتوری ~/.mitmproxy ایجاد می‌کند (فایل mitmproxy-ca-cert.cer). باید آن را به فهرست مورد اعتماد اضافه کنید — در غیر این صورت مشتری اتصال TLS را قطع می‌کند. در زمان بررسی، اعتماد در سطح کاربر کافی است؛ بعد از آن — گواهی را حذف کنید و CA خارجی را در سیستم «به هر دلیلی» رها نکنید.
  3. حالت نفوذ را انتخاب کنید. سه حالت وجود دارد و انتخاب صحیح یک ساعت کار را صرفه‌جویی می‌کند:
    • regular — پروکسی معمولی، مشتری به طور صریح تنظیم می‌شود. پیش‌بینی‌پذیرترین گزینه.
    • local — نفوذ شفاف برنامه‌ها در همین ماشین، بدون ویرایش تنظیمات برنامه: mitmproxy --mode local:Code فقط فرآیند VS Code را می‌گیرد، --mode local:42 — فرآیند با PID مشخص، --mode local:!curl — همه چیز به جز curl. این بهترین راه برای شنود دستیار است که تنظیم پروکسی ندارد.
    • upstream — زنجیره‌ای که در آن mitmproxy پشت پروکسی خودتان قرار دارد: mitmdump --mode upstream:http://host:8081 و نام کاربری و رمز عبور با گزینه --set upstream_auth=user:pass تعیین می‌شود.
  4. IDE را به پروکسی هدایت کنید (برای حالت regular). در VS Code در settings.json:
    • "http.proxy": "http://127.0.0.1:8080"
    • "http.proxySupport": "override"
    • "http.proxyStrictSSL": false — فقط در زمان بررسی. این پرچم به طور کامل بررسی گواهی‌ها را غیرفعال می‌کند و نباید آن را در پیکربندی کاری نگه دارید.
  5. مشکل گواهی را به طور حرفه‌ای حل کنید. افزونه Copilot بر روی Node کار می‌کند، بنابراین راه صحیح این است که بررسی را غیرفعال نکنید، بلکه PEM را با CA‌های ریشه و گواهی mitmproxy جمع‌آوری کنید و آن را از طریق متغیر محیطی NODE_EXTRA_CA_CERTS مشخص کنید. IDE باید دوباره راه‌اندازی شود: متغیر در زمان شروع فرآیند خوانده می‌شود.
  6. جریان را به فایل بنویسید. تماشا کردن به صورت زنده بی‌فایده است — درخواست‌ها ده‌ها در دقیقه هستند. --set save_stream_file=flows.dump را فعال کنید و برای اینکه همه چیز را جمع‌آوری نکنید، نمونه‌برداری را از طریق --set save_stream_filter=... محدود کنید. سپس فایل به آرامی به صورت آفلاین بررسی می‌شود.
  7. در بدنه درخواست جستجو کنید، نه در URL. یک روش عملی: یک فایل کاناری با رشته منحصر به فرد (به عنوان مثال، CANARY_9f3c_DO_NOT_SEND) در مخزن آزمایشی قرار دهید، آن را در ویرایشگر باز کنید، در فایل کناری کار کنید — و کاناری را در بدنه‌های نفوذی جستجو کنید. اینگونه شما دامنه واقعی جمع‌آوری زمینه را در نسخه مشتری خود خواهید دید.

دام‌های پنهان

مجوز ممکن است نفوذ را مسدود کند. در برنامه‌های شرکتی، Copilot خطایی از نوع «مجوز فعلی Copilot شما از اتصالات پروکسی با گواهی‌های خودامضا پشتیبانی نمی‌کند» را می‌دهد. این یک اشکال پروکسی نیست — مشتری عمداً از کار کردن از طریق CA خودامضا امتناع می‌کند. این مشکل با گواهی معتبر در سطح سیستم یا ساخت PEM برای Node حل می‌شود؛ اگر سیاست سازمان این را ممنوع کند، بررسی باید با مدیر هماهنگ شود، نه اینکه دور زده شود.

پینینگ و QUIC. برخی از مشتریان از HTTP/3 بر روی QUIC استفاده می‌کنند که پروکسی معمولی نمی‌تواند آن را ببیند. اگر پس از فعال کردن نفوذ، برنامه «کار می‌کند، اما در لاگ خالی است» — تقریباً همیشه دلیل آن همین است: UDP/443 را برای فرآیند آزمایشی مسدود کنید و مشتری به HTTP/2 برمی‌گردد.

تلمتری و بار مفید از مسیرهای مختلف می‌روند. بر اساس یک نقطه پایانی نتیجه‌گیری «هیچ چیزی ارسال نمی‌شود» نکنید: به کل لیست میزبان‌هایی که فرآیند به آن‌ها دسترسی دارد نگاه کنید، نه فقط آنچه در مستندات ذکر شده است.

چارچوب قانونی. نفوذ به ترافیک می‌تواند بر روی ماشین خود و در حساب خود انجام شود. شنود کردن لپ‌تاپ کاری دیگران بدون اطلاع صاحب آن — این یک داستان دیگر است و هیچ «امنیتی» آن را توجیه نمی‌کند.

با نتایج چه کار کنیم

اگر بررسی نشان داد که فایل‌های اضافی به درخواست‌ها وارد می‌شوند، ابزارهای پیش‌فرض به این شکل هستند — و هر کدام محدودیت‌های قابل توجهی دارند.

  • استثنای محتوا. مکانیزم رسمی GitHub که به Copilot اجازه نمی‌دهد مسیرهای مشخص شده را استفاده کند. فقط در برنامه‌های Business و Enterprise در دسترس است، توسط مدیر در تنظیمات Copilot تنظیم می‌شود و در VS Code، Visual Studio و JetBrains پشتیبانی می‌شود؛ در Xcode، Eclipse و Vim/Neovim — فقط برای پیشنهادات درون‌خطی.
  • سوراخ اصلی — حالت عامل. مستندات به وضوح می‌گوید که استثناها در حالت‌های Edit و Agent در Copilot Chat و همچنین در Copilot CLI پشتیبانی نمی‌شوند. یعنی دقیقاً در جایی که دستیار خود به فایل‌ها می‌رود، پیکربندی‌ها را می‌خواند و دستورات را اجرا می‌کند، فیلترینگ پلتفرم اعمال نمی‌شود. اگر به استثنای محتوا به عنوان تنها مانع تکیه می‌کنید — در حالت عامل مانع وجود ندارد.
  • .gitignore محافظت نمی‌کند. یک تصور غلط رایج: استثنا از ایندکس Git به معنای استثنا از زمینه دستیار نیست.
  • حداقل سازمانی. اسرار باید در مدیر اسرار قرار گیرند، نه در .env کنار کد؛ چت دستیار مکان مناسبی برای وارد کردن رشته‌های اتصال نیست؛ پایگاه محلی تاریخچه باید به همان اندازه که تاریخچه shell را تمیز می‌کنید، تمیز شود.

اینجا پروکسی کجاست و چرا به آن نیاز دارید

نفوذ ادامه کاربردی دارد. اول از همه، حالت upstream اجازه می‌دهد که تمام ترافیک دستیار را از طریق یک گره خروجی کنترل شده عبور دهید: شما همزمان درخواست‌ها را مشاهده می‌کنید و کنترل می‌کنید که از کدام آدرس ارسال می‌شوند. این زمانی لازم است که API دستیار از منطقه شما در دسترس نیست یا زمانی که سیاست شرکتی نیاز به یک IP خروجی ثابت دارد — برای چنین سناریویی پروکسی‌های داده‌مرکزی با آدرس ثابت مناسب هستند.

دوم، همان ایستگاه برای اشکال‌زدایی اتوماسیون مفید است: زمانی که عامل AI خود به سایت‌ها می‌رود، نفوذ نشان می‌دهد که چه هدرهایی را واقعاً ارسال می‌کند و چه چیزی او را می‌گیرد. ما این ترکیب را در مطلبی درباره پروکسی برای عوامل AI در Playwright و MCP بررسی کردیم — در آنجا درباره انتخاب نوع آدرس برای سناریوهای عاملی که به IP مسکونی نیاز دارند، صحبت شده است.

اگر قبلاً mitmproxy را راه‌اندازی نکرده‌اید، با تنظیمات پایه نفوذ HTTPS شروع کنید — که به تفصیل در راهنمای ما برای نفوذ به ترافیک از طریق mitmproxy توضیح داده شده است و سپس حالت‌های local و upstream را بر روی آن اضافه کنید.

نتیجه‌گیری

بررسی ترافیک دستیار AI یک پارانویا نیست، بلکه یک بهداشت مهندسی طبیعی است که یک شب و یک بار طول می‌کشد. تحلیل Copilot تصویر روشنی را نشان داد: مشتری زمینه را به طور گسترده جمع‌آوری می‌کند، اسرار به این زمینه به همان اندازه کد وارد می‌شوند، تاریخچه محلی به صورت متن باز ذخیره می‌شود و استثنای پیش‌فرض در خطرناک‌ترین حالت — حالت عامل — کار نمی‌کند.

مستندات را نه، بلکه ترافیک را بررسی کنید. mitmproxy را در حالت local راه‌اندازی کنید، یک کاناری در مخزن قرار دهید، جریان را به فایل جمع‌آوری کنید و با چشمان خود ببینید که چه چیزی از ماشین شما خارج می‌شود. سپس تصمیم ساده است: یا شما به طور آگاهانه این حجم انتقال را می‌پذیرید، یا اسرار را قبل از اینکه سرور خارجی آن‌ها را ببیند، از درخت کاری خود خارج می‌کنید.

```