refactoring 028 – شناسه های متوالی را با کلیدهای تاریک جایگزین کنید

امنیت را تقویت کرده و خطرات خراش را با استفاده از شناسه های شیء کاهش دهید

TL ؛ DR: برای جلوگیری از آسیب پذیری های idor و دلسرد کردن خراش ، شناسه های متوالی را در مدل های خود با UUID جایگزین کنید.

1. تمام کاربردهای عمومی شناسه های متوالی را در API ، URL یا عناصر UI مشخص کنید
2. برای هر رکورد در هنگام مهاجرت یا ایجاد داده ها UUID ایجاد کنید
3. شناسه های متوالی در معرض UUID ها را در رابط های خارجی جایگزین کنید
4. با استفاده از یک جدول یا سرویس جستجوی خصوصی ، UUID را در داخل به شناسه های اصلی نقشه کنید
5. اطمینان حاصل کنید که UUID ها به طور مداوم در خدمات و پایگاه داده ها استفاده می شوند

قبل

class Invoice {
    public int $id;
    // The external identifier is never an essential
    // responsibilty for an object

    public string $customerName;
    public array $items;

    public function __construct(
      int $id, string $customerName, array $items) {
        $this->id = $id;
        $this->customerName = $customerName;
        $this->items = $items;
    }
}

بعد از

class Invoice {
    // 1. Identify all public uses of sequential IDs
    // in APIs, URLs, or UI elements   

    private string $customerName;
    private array $items;

    public function __construct(
      string $customerName, array $items) {
        $this->customerName = $customerName;
        $this->items = $items;
    }
}

// 2. Generate UUIDs
// for each record during data migration or creation    
// 3. Replace exposed sequential IDs 
// with UUIDs in external-facing interfaces    

// 4. Map UUIDs internally to the original IDs 
// using a private lookup table or service    
$uuid = generate_uuid();

// 5. Ensure UUIDs are used 
// consistently across services and databases
$invoices[$uuid] =new Invoice(
    customerName: 'Roger Penrose',
    items: [
        new InvoiceItem(description: 'Laptop', price: 1200),
        new InvoiceItem(description: 'Black Hole', price: 50)
    ]
);

// Step 4: Keep the map internal
// Step 5: Share only UUID with the client

اگر این کار به صورت تدریجی با تست های مناسب و سازگاری به عقب در هنگام انتقال انجام شود ، این بازپرداخت بی خطر است.

شما باید به طور موقت دسترسی دوگانه (UUID و ID) را به طور موقت انجام دهید تا به روزرسانی های مرحله ای اجازه دهید.

بازپرداخت با از بین بردن شناسه های قابل پیش بینی از حملات IDOR جلوگیری می کند.

شما شناسه های قابل پیش بینی را از دسترسی عمومی حذف می کنید

این امر به دلیل کلیدهای غیر توالی ، خطر خرابی خودکار را کاهش می دهد.

این تکنیک همچنین با نگه داشتن شناسه داخلی ، محصور کردن را بهبود می بخشد و از طریق نقشه برداری صریح ، طراحی API پاک کننده را ترغیب می کند.

این امر به ویژه در API های استراحت ، برنامه های وب و خدمات میکروسرویس که در آن شناسه های شیء به صورت عمومی در معرض دید قرار می گیرند ، مفید است.

هنگامی که مهاجم شما سعی می کند شناسه ها را حدس بزند ، می توانید محدودیت کنترل نرخ را برای 404 منابع شکست خورده فعال کنید.

هنگامی که شناسه های خود را با مفاهیم دنیای واقعی به جای ردیف های پایگاه داده الگوبرداری می کنید ، از افشای جزئیات اجرای تصادفی خودداری می کنید.

این زندگی را به نهاد تجاری نزدیک می کند و از نشت ساختار فنی جلوگیری می کند.

فاکتور دنیای واقعی در این مثال یک شناسه داخلی را در معرض دید قرار نمی دهد.

در عوض ، از طریق شرایط تجارت یا منابع مات به آن اشاره شده است.

این اصلاح مجدد قسمت تصادفی را از بین می برد و جوهر اساسی فاکتور را بازیابی می کند.

شما نشانگرها را کنترل می کنید. اشاره گر شما را کنترل نمی کند.

این اصلاح مجدد شما را ملزم می کند تا تمام ادغام های مشتری را به روز کنید. برخی از سیستم ها هنوز هم ممکن است دسترسی به شناسه های عددی را فرض کنند.

شما باید شناسه های داخلی را برای پایداری ، ممیزی یا پشتیبانی از میراث حفظ کنید.

پیشنهاد سریع: 1. شناسایی کلیه کاربردهای عمومی از شناسه های پی در پی در API ها ، URL ها یا عناصر UI.

ویکی پدیا

تصویر توسط کریس در Pixabay

این مقاله بخشی از سری Refactoring است.