کلید API فقط‌خواندنی هنوز چه داده‌هایی را افشا می‌کند؟
کلید read-only سفارش ثبت نمی‌کند، اما ممکن است موجودی، پوزیشن و تاریخچه معامله را نشان دهد. راه‌های محدودکردن همین سطح افشا را بخوانید.
برچسب فقط‌خواندنی قدرت اقدام را محدود می‌کند، اما داده حساب را بی‌اهمیت یا عمومی نمی‌کند. بسته به صرافی و دامنه دسترسی انتخاب‌شده، یک کلید API فقط‌خواندنی ممکن است موجودی، پوزیشن باز، اهرم، قیمت ورود، سود و زیان، سفارش‌های قبلی، واریز، برداشت و الگوی فعالیت کاربر را نشان دهد. مهاجم حتی بدون امکان ثبت سفارش می‌تواند از همین تصویر برای فیشینگ هدفمند استفاده کند.
پاسخ کوتاه: وقتی ابزار فقط مشاهده می‌خواهد، فقط‌خواندنی انتخاب امن‌تری است؛ بااین‌حال خود اعتبارنامه و داده برگشتی همچنان محرمانه‌اند. اندپوینت‌های واقعی را تست کن، داده اضافی را نگیر، نگهداری را کوتاه نگه دار، دسترسی را محدود کن و بعد از پایان بررسی کلید را لغو کن.
نکات کلیدی
- فقط‌خواندنی بودن درباره «عملیات» است، نه بی‌ارزش بودن اطلاعات.
- موجودی، تاریخچه و پوزیشن‌ها می‌توانند استراتژی و نشانه‌های هویتی را آشکار کنند.
- نام دسترسی کافی نیست؛ رفتار واقعی اندپوینت مرز قابل اعتماد است.
- محصول باید فقط فیلد لازم برای هدف اعلام‌شده را دریافت کند.
- لاگ، بکاپ، اسکرین‌شات پشتیبانی و تحلیل داده مسیر ثانویه افشا هستند.
- DRKN باید حداقل داده لازم برای بررسی را ببیند و اجرا را به کاربر بسپارد.
کلید فقط‌خواندنی چه چیزهایی را می‌تواند ببیند؟
پاسخ دقیق به صرافی، نوع حساب و دامنه دسترسی بستگی دارد. اندپوینت‌های خواندنی معمولاً موجودی کیف پول، available مارجین، پوزیشن‌های فیوچرز، اهرم، سود و زیان محقق‌نشده، سفارش‌ها، پرشدن‌ها، کارمزد، فاندینگ و تاریخچه تراکنش را پوشش می‌دهند. بعضی صرافی‌ها کیف پول، پوزیشن و معامله تاریخچه را جدا می‌کنند و بعضی چند مجموعه را زیر یک گزینه کلی خواندن قرار می‌دهند.
همین داده‌ها عادت معامله‌گر را بازسازی می‌کنند. زمان تکراری ورود، ساعت فعالیت را نشان می‌دهد. تاریخچه پوزیشن، سبک و تحمل ریسک را آشکار می‌کند. موجودی، اندازه حساب را معلوم می‌کند و رکورد انتقال ممکن است بین چند حساب ارتباط بسازد. مهاجم می‌تواند در پیام جعلی پشتیبانی به جزئیات واقعی یک پوزیشن اشاره کند و لینک مخرب را باورپذیرتر نشان دهد.
چرا فقط‌خواندنی از دسترسی معامله امن‌تر است؟
اگر درست پیاده شود، یک دسته بزرگ از آسیب مستقیم را حذف می‌کند: کلید نباید سفارش بسازد یا لغو کند، دارایی انتقال دهد یا برداشت انجام دهد. افشای این کلید معمولاً از افشای کلیدی که قدرت معامله یا برداشت دارد کم‌خطرتر است.
اما «امن‌تر» با «بدون ریسک» فرق دارد. خطر محرمانگی باقی می‌ماند و برنامه متصل می‌تواند داده را بد نگهداری کند. نتیجه درست، کنار گذاشتن مشاهده مفید نیست؛ باید کنترل متناسب اعمال شود: دامنه دسترسی کم، اعتبارنامه اختصاصی، فهرست IP مجاز در صورت امکان، چرخش، monitoring و تست رد شدن عملیات ممنوع.
چطور دامنه دسترسی واقعی را راستی‌آزمایی کنیم؟
از مستندات به‌روز صرافی و صفحه دسترسی شروع کن، سپس با درخواست کنترل‌شده رفتار را بسنج. فهرستی از اندپوینت‌هایی بنویس که محصول می‌گوید لازم دارد. برای هر اندپوینت مشخص کن چه فیلدهایی برمی‌گردد و کاربرد هر فیلد چیست. اگر داده‌ای در تجربه محصول استفاده نمی‌شود، دریافت یا ذخیره‌اش توجیه ندارد.
آزمایش منفی انجام بده: ایجاد سفارش، transfer و برداشت باید رد شوند. در صورت وجود، این کار را در محیط آزمایشی انجام بده. وضعیت code و زمان را ثبت کن، اما کلید محرمانه و داده حساب را از گزارش حذف کن. بعد از تغییر دسترسی یا نسخه API، تست را تکرار کن؛ چون ممکن است نام دامنه دسترسی ثابت بماند ولی پوشش اندپوینت تغییر کند.
بررسی حساب با DRKN را با ذهنیت حداقل‌دسترسی انجام بده. دامنه دسترسی خواندن را خودت در صرافی بررسی کن و مجوز معامله، انتقال، برداشت و حضانت را بیرون از مسیر مقاله نگه دار.
داده بعد از دریافت از API کجا نشت می‌کند؟
API فقط مرز اول است. داده می‌تواند داخل application لاگ، error tracker، cache مرورگر، backup دیتابیس، export، session recording، اسکرین‌شات پشتیبانی یا تحلیل داده رویداد پخش شود. امن بودن کلید محرمانه، لاگ بیش‌ازحد پرجزئیات را جبران نمی‌کند.
از ارائه‌دهنده سؤال مشخص بپرس: کدام فیلدها ذخیره می‌شوند؟ چند روز؟ آیا کلید محرمانه جداگانه رمز می‌شود؟ شناسه حساب از لاگ حذف می‌شود؟ با حذف اتصال، داده مرتبط هم پاک می‌شود؟ کدام نقش‌های انسانی یا subprocessorها دسترسی دارند؟ عبارت کلی «رمزنگاری سطح بانکی» پاسخ این پرسش‌های عملیاتی نیست.
اصل data minimization هم احتمال افشا و هم هزینه حادثه را کاهش می‌دهد. سرویسی که تاریخچه کامل سفارش را نگه نمی‌دارد، بعداً نمی‌تواند نسخه دائمی آن را از دست بدهد.
بدون معامله دسترسی چه تهدیدی جدی است؟
فرض کن کاربر یک پوزیشن شورت بزرگ با فاصله کم تا لیکوییدیشن دارد. داده لو‌رفته اندازه پوزیشن، بازار مورد استفاده، ساعات فعال و حساسیت فعلی او را نشان می‌دهد. مجرم می‌تواند بنویسد: «روی پوزیشن شورت شما هشدار مارجین ثبت شده؛ برای تأیید وارد این صفحه شوید.» اشاره به اطلاعات واقعی، احتمال کلیک را بالا می‌برد.
برای تیم حرفه‌ای یا صندوق، موجودی، گردش معاملات و صرافی preference اطلاعات تجاری‌اند. بنابراین بررسی حریم خصوصی باید کنار بررسی دسترسی انجام شود. سؤال فقط «آیا این کلید معامله می‌کند؟» نیست؛ باید پرسید «کسی با تمام آنچه می‌بیند چه چیزی می‌تواند استنباط کند؟»
چک‌لیست اتصال فقط‌خواندنی چیست؟
پیش از اتصال:
1. هدف محصول و datasetهای لازم را مشخص کن. 2. کلید اختصاصی بساز و اعتبارنامه بات اجرایی را استفاده دوباره نکن. 3. فقط خواندن دامنه دسترسی لازم را فعال و سفارش، انتقال و برداشت را رد کن. 4. اگر یکپارچه‌سازی آدرس ثابت دارد، فهرست IP مجاز اعمال کن. 5. اندپوینت ممنوع را تست و نتیجه را بدون داده حساس ثبت کن. 6. سیاست نگهداری، لاگ، deletion و رخداد ارائه‌دهنده را بخوان. 7. دسترسی لاگ صرافی را زیر نظر بگیر و پس از پایان نیاز کلید را لغو کن.
بعد از قطع اتصال، لغو کلید در صرافی را جداگانه تأیید کن. برداشتن اتصال از رابط یک اپ همیشه به معنی حذف اعتبارنامه سمت صرافی نیست.
DRKN چگونه این مرز را درست توضیح می‌دهد؟
مرز را دقیق نگه دار: دیدن وضعیت حساب می‌تواند بررسی ریسک را بهتر کند، اما کنترل حساب دست خود معامله‌گر می‌ماند. فقط‌خواندنی مترادف «ریسک صفر» نیست؛ همچنان تویی که مسئول سطح دسترسی، نگهداری کلید، بررسی فعالیت و لغو به‌موقع آن هستی.
برای ساخت کنترل کامل‌تر، چرخه عمر کلید API را اجرا کن، دلیل جداسازی کلید بات و ابزار ریسک را بخوان و اثر زمینه حساب را در عدم تطابق حساب فالوئر ببین.
پرسش‌های متداول
آیا کلید فقط‌خواندنی می‌تواند برداشت کند؟
اگر دسترسی درست تنظیم و enforce شده باشد، خیر. دامنه دسترسی همان صرافی را بخوان و رد شدن اندپوینت برداشت را کنترل‌شده تست کن.
آیا کل موجودی حساب را می‌بیند؟
در بسیاری از صرافی‌ها بله؛ ممکن است موجودی اسپات، فیوچرز یا فاندینگ را نشان دهد. پوشش دقیق به صرافی بستگی دارد.
فهرست IP مجاز به‌تنهایی کافی است؟
خیر. محدودیت مبدا مفید است، اما جای storage امن، کمینه‌سازی داده، پایش، چرخش و لغو را نمی‌گیرد.
آیا DRKN برای بررسی به مجوز برداشت نیاز دارد؟
ابزار بررسی ریسک نباید چنین مجوزی بخواهد. کاربر باید برداشت را رد و دامنه دسترسی اتصال را مستقل بررسی کند.
منابع
- ده ریسک برتر امنیت API — OWASP — فهرست مرجع OWASP از رایج‌ترین ریسک‌های امنیتی رابط‌های برنامه‌نویسی.
- راهنمای امنیت API کراکن
- مستندات احراز هویت Coinbase Developer Platform
هشدار ریسک: این مقاله آموزشی است و تضمین امنیت یا توصیه مالی و حقوقی نیست. دامنه دسترسی و داده API در صرافی‌ها متفاوت و متغیر است؛ بازبینی انسانی پیش از انتشار و اتصال الزامی است.