پرش به محتویات

امضای کد (Code Signatures)

با انتشار نسخه 1.9.7، Bricks گام دیگری برای امنیت کد داخلی با معرفی code signatures برداشت.

یادداشت

Code signatures تضمین می‌کنند کدی که اجرا می‌کنید دست‌کاری نشده باشد. امضای معتبر اکنون الزامی‌است. هر کد بدون امضای معتبر اجرا نمی‌شود.

المان‌هایی که code signature می‌خواهند

این المان‌ها برای اجرا امضای معتبر می‌خواهند:

  • Code element با «Code execution» فعال
  • SVG element با «Source» روی «Code»
  • Query loop editor

نحوه تولید code signature

می‌توانید برای المان تکی در سازنده، کل صفحه در سازنده، یا سراسری از تنظیمات Bricks امضا تولید کنید.

تولید در سازنده

در سازنده، المان‌های با کد بدون امضا قرمز highlight می‌شوند. آیکون «fingerprint» قرمز بالای structure panel هم می‌بینید.

Code، SVG و Query editor با کد بدون امضا

Builder: Code, SVG, and Query editor with unsigned code

امضای کد برای المان تکی

دکمه Sign code در پنل سازنده

هنگام ویرایش المان، «Sign code» بالای code editor را بزنید. یا با focus در editor از میانبر «CMD/CRTL + R» استفاده کنید.

مشاهده و امضای bulk کد بدون امضا

با کلیک آیکون «fingerprint» بالای structure panel همه المان‌های بدون امضای صفحه فعلی را ببینید و امضا کنید. همان آیکون روی المان‌های بدون امضا در structure panel هم هست.

Popup امضای bulk کد بدون امضا

امضای سراسری از تنظیمات Bricks

برای کل سایت: Bricks > Settings > Custom code > Code signature در پیشخوان وردپرس.

Regenerate code signatures را بزنید. برای همه صفحات، قالب‌ها و غیره ساخته‌شده با Bricks امضا تولید می‌شود.

این قابلیت فقط وقتی code execution فعال است و برای کاربران با قابلیت code execution در دسترس است.

قفل کردن تولید code signature

در Bricks 1.11.1 ثابت BRICKS_LOCK_CODE_SIGNATURES برای محیط‌های high-security اضافه شد. وقتی true باشد، Bricks از تولید امضای جدید جلوگیری می‌کند — صرف‌نظر از مجوز کاربر. مفید وقتی پس از توسعه اولیه می‌خواهید امضا را lock کنید.

برای فعال‌سازی این خط را به functions.php اضافه کنید:

if ( ! defined( 'BRICKS_LOCK_CODE_SIGNATURES' ) ) {
    define( 'BRICKS_LOCK_CODE_SIGNATURES', true );
}

با true، هر تلاش برای تولید امضای جدید block می‌شود. جایگزین تنظیمات Bricks برای مدیریت دسترسی امضا در production با امنیت سخت‌گیرانه.

چه موقع امضاها را regenerate کنیم

مهم

هنگام به‌روزرسانی Bricks از نسخه‌ای قبل از 1.9.7، تولید code signature از طریق Bricks > Settings برای اجرای کد الزامی‌است، زیرا فقط کد با امضای معتبر اجرا می‌شود. لطفاً مطمئن شوید ابتدا یک «Code review» در همان صفحه انجام دهید.

پس از تغییر WordPress salt (secret keys): هر بار salts در wp-config.php عوض شود، باید code signatureها را regenerate کنید.

پس از migration سایت: هنگام انتقال به domain یا سرور جدید، اگر salts محیط جدید متفاوت باشد ممکن است regenerate لازم باشد.

چرا code signatures؟

قبل از توضیح منطق code signatures در Bricks، hashing و نقش WordPress salts را بدانید.

درک WordPress salts

در وردپرس، salts رشته‌های تصادفی برای عملیات رمزنگاری هستند.

در wp-config.php ذخیره می‌شوند و برای keyed hashing و encryption حیاتی‌اند. یکتا بودن hash امضای کد سایت را تضمین می‌کنند.

به‌طور ساده، salts مثل «ادویه مخفی» در دستور غذای سایت‌اند. کد با این ماده hash می‌شود و امضایی یکتا برای سایت شما می‌سازد.

بدون salts، کپی یا تغییر کد امضای یکسان نخواهد داشت و رد می‌شود.

درک تابع wp_hash

Bricks از wp_hash وردپرس با HMAC-MD5 برای hash یکتا استفاده می‌کند.

داده سایت با salts یکتا ترکیب می‌شود.

فرایند تأیید یکپارچگی کد Bricks

این hashها تضمین می‌کنند تغییر کد فقط با دسترسی به salts و code execution capability در Bricks ممکن باشد.

  1. تولید کد و امضا: هنگام sign، hash یکتا با salts وردپرس ساخته می‌شود.
  2. بازیابی برای اجرا: Bricks کد و hash ذخیره‌شده را از دیتابیس می‌خواند.
  3. تأیید: Bricks دوباره hash می‌کند و با امضای اصلی مقایسه می‌کند.
  4. تصمیم اجرا: تطابق = یکپارچگی تأیید و اجرا. عدم تطابق = تغییر احتمالی غیرمجاز و block اجرا.

Code signatures و Code review در 1.9.7 پیشرفت مهمی‌در امنیت و یکپارچگی سایت‌های Bricks است.

چرا چرخش منظم WordPress salts ایده بدی است

با چرخش salts در wp-config.php، همه code signatureهای Bricks نامعتبر می‌شوند. باید دستی از Bricks Settings > Custom code > Code signatures regenerate کنید. اگر می‌پرسید چرا automate نمی‌کنیم، بخش بعد را بخوانید.

برخی افزونه‌ها salt rotation خودکار با ادعای سخت‌تر شدن crack رمز عبور دارند — نادرست است. Salts وردپرس برای hash رمز کاربر استفاده نمی‌شوند. چرخش محافظت اضافه در برابر سرقت رمز یا brute-force نمی‌دهد.

آنچه salt rotation ایجاد می‌کند:

  • logout همه کاربران (invalidate کوکی احراز هویت)
  • شکستن nonceها (اختلال form و AJAX)
  • خرابی افزونه‌هایی که salts برای encryption/integrity استفاده می‌کنند
  • invalidate همه code signatureها

مگر سایت compromise شده باشد، دلیل عملی برای چرخش salts نیست. فقط breakage و ناپایداری اضافه می‌کند.

چرا کد خودکار sign نمی‌شود؟

Bricks امضای دستی می‌خواهد تا در breach، وضع بد بدتر نشود.

ریسک: دسترسی به دیتابیس (مثلاً از افزونه یا credential کاربر بدون code execution) — مهاجم کد مخرب در المان Bricks inject می‌کند. breach جدی است اما کنترل کامل سرور نیست.

با code signature وابسته به salts، مهاجم فقط با دیتابیس نمی‌تواند کد را executable کند — unsigned می‌ماند و Bricks block می‌کند.

اما اگر با باز شدن سازنده توسط کاربر با code execution خودکار sign شود، حفاظت فرو می‌ریزد: مهاجم کد را در DB می‌گذارد و منتظر می‌ماند — با load سازنده auto-sign و اجرا بدون اینکه ببینید.

امضای دستی checkpoint اجباری است: کد unsigned (قرمز) دیده می‌شود؛ بررسی و تصمیم trust با شماست. breach جزئی را محدود و از escalation به اجرای کامل جلوگیری می‌کند.