آموزش گام‌به‌گام امنیت وب‌سرویس‌ها و API در وردپرس

فرقی نمی‌کند فروشگاه باشید یا رسانه؛ دیر یا زود برنامه‌ای به سایت شما وصل می‌شود: اپلیکیشن موبایل، پنل رهگیری سفارش، افزونه‌ای که با سرویس بیرونی هم‌گام می‌شود یا وبهوکی که خبر تازه می‌آورد. همهٔ این‌ها از یک در می‌آیند که هیچ‌کس با آن وارد صفحهٔ ورود نمی‌شود: REST API وردپرس.

بحث امنیت وردپرس معمولاً از دروازهٔ انسان‌ها شروع می‌شود — رمز قوی، تأیید دومرحله‌ای، فهرست‌سیاه — و به همین دلیل لایهٔ ماشین‌ها کم‌نگهبانی می‌ماند. نقشهٔ کامل دفاع و بازگشت را در هاب امنیت و پشتیبان‌گیری نگه داشته‌ایم؛ این مقاله فقط درِ برنامه‌ها را باز می‌کند: چه کسی از API استفاده می‌کند، چه چیزی می‌بیند و چطور مرزش را می‌گذارید.

API وردپرس چیست و چرا سطح حملهٔ جداست؟

REST API، رابط استاندارد وردپرس برای ماشین‌هاست؛ همان مسیری که ویرایشگر بلوک خودِ وردپرس هم از آن استفاده می‌کند. هر چیزی که در پنل می‌بینید، از نوشته‌ها تا کاربران، از این مسیر هم قابل خواندن و نوشتن است. مشکل این‌جاست که این در، با هر نصب وردپرس باز است و بخش بزرگی از آن برای بازدیدکنندهٔ ناشناس هم خواندنی می‌ماند — از جمله مسیر کاربران که فهرست نویسندگان را می‌دهد و برای شناسایی حساب‌های مدیر، نقطهٔ شروعِ محبوب است.

سه ویژگی، این سطح را از صفحهٔ ورود جداست می‌کند. کلیدها عمر طولانی دارند و معمولاً کسی نمی‌پرسد آخرین بار کی ساخته شده‌اند؛ ترافیک بی‌چهره است — نه صفحهٔ ورود دارد نه اسم — پس حملاتش در ذهنِ مدیر ثبت نمی‌شود؛ و خطاها بی‌صدا تکرار می‌شوند، چون هیچ صفحهٔ قرمزی نمی‌بیند. به تجربهٔ ما سایت‌هایی که در صفحهٔ ورود محکم‌اند، در همین سطحِ بی‌چهره رها شده‌اند.

و یک توضیح برای آن‌ها که می‌پرسند «ما اپلیکیشن نداریم، مال ما چیست؟»: افزونه‌ها. هر افزونه‌ای که با سرویس بیرونی حرف می‌زند — فرم، پشتیبانی، بهینه‌ساز تصویر، درگاه — مصرف‌کنندهٔ همین مسیر است. یعنی مدیریت API مال همه است، نه فقط مال تیم‌های موبایل‌محور.

امنیت API وردپرس در چهار لایه

چهار لایه، چهار پرسش‌اند: کی دستور می‌دهد (احراز هویت)؛ تا کجا اجازه دارد (مجوز)؛ چقدر و از کجا (ترافیک)؛ و چه اتفاقی افتاد (پایش). تشبیه ساده‌اش: کلید، پروانهٔ کار، پاسبان و دوربین. هر لایه بدون بقیه ناقص است؛ کلیدِ قوی برای حسابی با دسترسی مدیر کل، یعنی همهٔ درها پشت یک نشت؛ و پایشِ بی‌سقفِ نرخ، یعنی دوربینی که حملات را با کیفیت عالی ضبط می‌کند.

این چارچوب مخصوص وردپرس هم نیست؛ هر سرویس وبی با همین چهار لایه اداره می‌شود. فرقِ سایت‌های منظم و شلوغ در تعداد ابزار نیست، در این است که چهار پرسش را از اول پرسیده‌اند و جواب‌ها را مکتوب نگه داشته‌اند: چه اتصال‌هایی داریم، هر کدام چه دسترسی‌ای، چه سقفی و چه لاگی.

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

لایهٔ اول؛ احراز هویت برنامه‌ها، نه انسان‌ها

لایهٔ اول، احراز هویت برنامه‌ای است: هر اتصال، کلید خودش را دارد، جدا از رمز انسان‌ها. در وردپرس، رمز برنامه‌ای (Application Password) همین کار را می‌کند — برای هر اتصال یک کلید صادر می‌شود که ابطالش جداست و عبور از صفحهٔ ورود را نمی‌دهد. قاعدهٔ عملیاتی: «یک اتصال، یک کلید». کلیدِ مشترک میان چند سرویس، وقتی مشکل می‌سازد هیچ‌کس نمی‌داند کدام مهمان کلید را لو داده.

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

این لایه مکملِ دروازهٔ انسان‌هاست، نه جایگزینش: صفحهٔ ورود و دو-مرحله‌ای‌کردنش موضوع مقالهٔ ایمن‌سازی صفحه ورود وردپرس است و موج‌زدن و قفل حساب‌ها را در جلوگیری از حمله brute force خوانده‌اید؛ آن‌جا برای آدم‌ها مرز می‌گذارید، این‌جا برای برنامه‌ها. دو در، دو نگهبان.

لایهٔ دوم؛ حداقل دسترسی و بستن درهای بی‌استفاده

لایهٔ دوم، حداقل دسترسی است: هر کلید فقط تا جایی که کار می‌خواهد ببیند و بنویسد. در عمل یعنی سه کار. اول، حسابِ اتصال را با نقشِ کمینه بسازید — اگر اتصال فقط نوشته می‌خواند، نویسنده‌اش نکنید. دوم، مسیرهای بی‌استفاده را ببندید: اگر سایت‌تان هیچ نیازی به پاسخ عمومیِ مسیر کاربران ندارد، بستنش هم فهرست نویسندگان را می‌گیرد هم بخشی از نقشهٔ مهاجم را. سوم، خروجی‌ها را بازبینی کنید: فیلدهایی مثل ایمیل نویسندگان در پاسخ‌های عمومی جایی ندارند.

برای سایت‌هایی که هیچ مصرف‌کنندهٔ بیرونی ندارند، تصمیم می‌تواند سخت‌گیرانه‌تر باشد: محدودکردن REST برای بازدیدکنندهٔ ناشناس تا جایی که ویرایشگر و افزونه‌های خودتان نمی‌شکنند. این تصمیم را با آزمون بگیرید، نه با حدس: ببندید، چند روز لاگ را ببینید، اگر چیزی شکست، بندِ شکسته را باز کنید نه همهٔ در را.

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

لایهٔ سوم؛ ترافیک، امضا و سقف نرخ

لایهٔ سوم، مهار ترافیک است. پایه‌اش رمزنگاری مسیر است: هر درخواست API باید روی HTTPS برود؛ کلیدی که روی مسیر رمزنشده سفر کند، در راه لو می‌رود و بعداً کل لایهٔ اول بی‌معنی می‌شود. بعدش سقف نرخ است: هر کلید و هر نشانی، در بازهٔ زمانی چند درخواست حق دارد؛ سقف، تفاوتِ «اتصال پرکار» و «پروبِ مهاجم» را از قبل می‌بندد. مکملش محدودکردن CORS است: فقط دامنه‌هایی که واقعاً مصرف‌کننده‌اند اجازهٔ فراخوانی مرورگری داشته باشند.

برای اتصال‌های حساس — وبهوک‌های سفارش، سرویس پرداخت — یک لایهٔ بالاتر بگذارید: امضای درخواست. الگوی رایج HMAC-SHA256 است: فرستنده و گیرنده راز مشترک دارند، فرستنده هشِ بدنه را با راز می‌سازد و گیرنده همان را دوباره محاسبه می‌کند؛ اگر نخواند، درخواست یا جعلی است یا دست‌کاری‌شده. برای دادهٔ ذخیره‌شدهٔ حساس هم رمزنگاری در حالت سکون — الگوی AES-256 — استاندارد کار است.

در زیرساخت سوئیت همین الگو اجرا شده است: ارتباط سرویس‌ها با امضای HMAC-SHA256 و رمزنگاری AES-256 انجام می‌شود و بیش از ۹۰۰ تست خودکار، هر انتشار را پیش از رسیدن به شما بازبینی می‌کنند؛ جزئیات این پوشش در صفحهٔ امنیت و زیرساخت سوئیت آمده. نکتهٔ عملی برای هر تیمی هم همان است: امضا و سقف، دیر یا زود لازم می‌شوند؛ زودتر بگذارید تا بعد از حادثه نگذاشته باشید.

لایهٔ چهارم؛ پایش، لاگ و پاسخ

لایهٔ چهارم، پایش است؛ چون سه لایهٔ قبلی نمی‌گویند چه شد، فقط جلوی آنچه می‌دانید را می‌گیرند. دو کار اصلی: لاگ درخواست‌های API — کی، از کجا، به کدام مسیر، با چه وضعیتی — و هشدارِ الگو: شکست‌های مکرر احراز هویت از یک نشانی، پرس‌وجوی انبوه مسیر کاربران، سقف‌نرخ‌هایی که پیوسته می‌خورند. این الگوها را باید در لحظه ببینید، نه در گزارش پایان فصل؛ تفاوتِ دوربینِ زنده و آرشیوِ خام همین است.

پایش را به چرخهٔ دفاع کلی وصل کنید: اسکن دوره‌ای، نشتِ پس‌ازنفوذ را پیدا می‌کند و موضوع مقالهٔ اسکن بدافزار وردپرس است؛ لاگِ API، نیتِ پیش از نفوذ را نشان می‌دهد. این دو را مکمل ببینید: یکی زندهٔ حین حمله، دیگری صادقانهٔ پس از آن. و خطِ آخرِ دفاع هم بکاپ است — وقتی چند لایه نشت کرده، برگشت‌پذیری تنها چیزی است که می‌ماند؛ قاعده‌ها و آزمونِ برگشت در بکاپ منظم وردپرس آمده.

یک تجربهٔ صادقانه برای پایان این لایه: پایش تا وقتی به پاسخ وصل نشود، فقط ثبت است. برای هر هشدار، پاسخ از پیش مکتوب داشته باشید — کدام هشدار، چه کسی، در چند دقیقه چه می‌کند. پاسخِ مکتوب، شب حادثه ناخدا پیدا می‌کند؛ پاسخِ نامکتوب، جلسهٔ بی‌نتیجه.

جمع‌بندی؛ چک‌لیست ماهانهٔ امنیت API

جمع‌بندی را به یک روتین ماهانه ببندید، نه به یک پروژهٔ یک‌بار. چک‌لیست بالا شش بند دارد و کل آن کمتر از یک ساعت کار است: ابطال کلیدهای بی‌استفاده، بازبینی endpointهای باز، بررسی سقف نرخ، مرور لاگ هفته‌ها، اعتبار گواهی HTTPS و آزمونِ برگشت بکاپ. این روتین، همان کاری است که سایت‌های منظم هر ماه می‌کنند و سایت‌های بی‌روتین بعد از حادثه، از نو یاد می‌گیرند.

اگر می‌خواهید این لایه‌ها بدون تیم فنی داخلی مدیریت شود، صفحهٔ امنیت و زیرساخت سوئیت تصویر زیرساخت سوئیت است: احراز هویت سرویس‌ها با امضا و رمزنگاری، تست خودکار هر انتشار و انتشار خودکارِ امن در پلن پیشرو — ۷٫۹ میلیون تومان در ماه — که نگهداشت را از دوش شما برمی‌دارد. دموی رایگان برای دیدن همین لایه‌ها بدون تعهد است.

حرف آخر: امنیت API وردپرس از سه پرسش ساده شروع می‌شود که همین امروز می‌توانید بپرسید — چه اتصال‌هایی به سایت ما وصله؟ هر کدام با کدام حساب؟ اگر فردا یک کلید لو برود، بدترین اتفاق چیست؟ جواب‌های مکتوبِ این سه سؤال، نصفِ راه است؛ نصفِ دیگرش، چهار لایهٔ همین مقاله‌اند که یکی‌یکی می‌بندیدشان.

رصد ما، رشد شما.