Identifying API endpoints

https://portswigger.net/web-security/api-testing

       شما همچنین می توانید با مرور برنامه هایی که از API استفاده می کنند، اطلاعات زیادی جمع آوری کنید. این کار اغلب ارزشمند است حتی اگر به API documentation  دسترسی داشته باشید، زیرا گاهی اوقات documentation ممکن است نادرست یا منسوخ شده باشد.

       شما می توانید از Burp Scanner برای crawl برنامه استفاده کنید، سپس به صورت دستی سطح interesting attack را با استفاده از مرورگر Burp بررسی کنید.

       در حالی که برنامه را مرور می کنید، به الگوهایی که نشان دهنده endpoints در ساختار URL  هستند، مانند  /api/، توجه کنید. همچنین به فایل های JavaScript توجه کنید. اینها می توانند ارجاعاتی (references) به API endpoints را شامل شوند که شما آنها را مستقیماً از طریق مرورگر وب فعال نکرده اید. Burp Scanner به طور خودکار برخی از endpoints را در حین crawl ، extract می کند، اما برای استخراج سنگین تر (more heavyweight extraction)، از JS Link Finder BApp استفاده کنید. شما همچنین می توانید به صورت دستی فایل های   JavaScript  را در Burp بررسی کنید.

Interacting with API endpoints

       پس از شناسایی API endpoints ، با استفاده از Burp Repeater و Burp Intruder با آنها interact کنید. این به شما این امکان را می دهد تا رفتار API را مشاهده کنید و سطح additional attack را discover کنید. به عنوان مثال، شما می توانید بررسی کنید که API چگونه به تغییر HTTP method و media type پاسخ می دهد.

       هنگامی که با API endpoints تعامل می کنید، پیام های خطا و سایر پاسخ ها را به دقت بررسی کنید. گاهی اوقات اینها شامل اطلاعاتی هستند که می توانید برای ساخت یک HTTP request معتبر از آنها استفاده کنید.

Identifying supported HTTP methods

       HTTP method  عملی را که باید روی یک منبع انجام شود، مشخص می کند. به عنوان مثال:

• GET - داده ها را از یک resource بازیابی می کند

• PATCH - تغییرات جزئی را در یک resource اعمال می کند

• OPTIONS - اطلاعات مربوط به انواع روش های درخواستی را که می توان در یک resource استفاده کرد، بازیابی می کند.

       یک نقطه پایانی API ممکن است از HTTP methods  مختلف پشتیبانی کند. بنابراین مهم است که هنگام بررسی API endpoints ، تمام potential methods را تست کنید. این ممکن است به شما امکان شناسایی قابلیت های additional endpoint را بدهد، که باز کردن سطح حمله بیشتری را فراهم می کند.

       برای مثال،  endpoint ،/api/tasks  ممکن است از روش های زیر پشتیبانی کند:

• GET /api/tasks - Retrieves a list of tasks.

• POST /api/tasks - Creates a new task.

• DELETE /api/tasks/1 - Deletes a task.

شما می توانید از لیست HTTP verbs ساخته شده در Burp Intruder برای گردش خودکار از طریق محدوده ای از روش ها استفاده کنید.

Note

       هنگام آزمایش HTTP methods مختلف، اهداف low-priority را هدف قرار دهید. این کمک می کند مطمئن شوید که از consequences ناخواسته جلوگیری می کنید، به عنوان مثال تغییر critical items یا ایجاد excessive records.

Identifying supported content types

       API endpoints اغلب انتظار داده در یک فرمت خاص را دارند. بنابراین ممکن است بسته به نوع محتوای ارائه شده در یک درخواست، رفتار متفاوتی داشته باشند. تغییر content type ممکن است به شما امکان دهد:

·         خطاهایی را فعال کنید که اطلاعات مفیدی را فاش می کنند.

·         دور زدن flawed defenses

·         از تفاوت ها در processing logic (منطق پردازش) بهره ببرید. به عنوان مثال، یک API ممکن است هنگام handling به داده های JSON امن باشد اما در مواجهه با حملات injection هنگام handling به XML آسیب پذیر باشد.

     برای تغییر نوع محتوا (content type)، هدر Content-Type را تغییر دهید، سپس request body را مطابق آن بازنویسی کنید. شما می توانید از Content type converter  BApp  برای تبدیل خودکار داده های ارسال شده در requests بین XML و JSON استفاده کنید.

Using Intruder to find hidden endpoints

       پس از شناسایی برخی از API endpoints اولیه، می توانید از Intruder برای کشف hidden endpoints استفاده کنید. به عنوان مثال، در نظر بگیرید که شما API endpoint زیر را برای به روزرسانی اطلاعات کاربر شناسایی کرده اید:

PUT /api/user/update

       برای شناسایی hidden endpoints ، می توانید از Burp Intruder برای پیدا کردن سایر resources با ساختار مشابه استفاده کنید. به عنوان مثال، می توانید یک payload را به موقعیت update/  مسیر اضافه کنید همراه با یک لیست از توابع رایج دیگر، مانند delete وadd.

       هنگام جستجو برای hidden endpoints ، از wordlists استفاده کنید که بر اساس قواعد رایج API naming و اصطلاحات صنعتی است. اطمینان حاصل کنید که بر اساس بررسی اولیه خود، اصطلاحات مرتبط با برنامه را نیز درج کرده اید.

Finding hidden parameters

       وقتی در حال انجام مجدد API هستید، ممکن است پارامترهای نادرستی را که API پشتیبانی می کند، پیدا کنید. شما می توانید سعی کنید از این موارد برای تغییر رفتار برنامه استفاده کنید. Burp شامل ابزارهای متعددی است که می تواند به شما کمک کند تا hidden parameters را شناسایی کنید:

·         Burp Intruder  به شما امکان می دهد تا به طور خودکار hidden parameters را کشف کنید، با استفاده از یک لیست کلمات از نام های متداول پارامتر برای جایگزینی پارامترهای موجود یا اضافه کردن پارامترهای جدید. اطمینان حاصل کنید که بر اساس بررسی اولیه خود، نام‌هایی را نیز وارد کرده‌اید که با برنامه مرتبط هستند

·         Param miner BApp  به شما امکان می دهد تا به طور خودکار تا 65,536 نام پارامتر در هر request را حدس بزنید.  Param miner به طور خودکار نام هایی را که مربوط به برنامه هستند، بر اساس اطلاعات گرفته شده از scope حدس می زند.

·         Content discovery tool به شما امکان می‌دهد محتوایی را که از محتوای قابل مشاهده پیوندی ندارد (isn't linked) ، از جمله پارامترها، کشف(discover)  کنید.

Mass assignment vulnerabilities

       Mass assignment (همچنین به عنوان auto-binding شناخته می شود) می تواند به طور ناخواسته hidden parameters ایجاد کند. این اتفاق ,وقتی می افتد که frameworks نرم افزاری به طور خودکار request parameters را به فیلدهای internal object متصل می کنند. بنابراین، mass assignment ممکن است منجر به پشتیبانی برنامه از پارامترهایی شود که هرگز قرار نبود توسط توسعه دهنده پردازش شوند.

Identifying hidden parameters

       از آنجا که mass assignment پارامترها را از object fields ایجاد می کند، شما اغلب می توانید این hidden parameters را با بررسی objects برگشت داده شده توسط API شناسایی کنید.

       برای مثال، در نظر بگیرید درخواست  PATCH /api/users/، که به کاربران امکان به روزرسانی نام کاربری و ایمیل خود را می دهد، و شامل JSON زیر است:

{

    "username": "wiener",

    "email": "[email protected]",

}

       یک درخواست همزمان GET /api/users/123 ،JSON  زیر را برمی گرداند: 

{

    "id": 123,

    "name": "John Doe",

    "email": "[email protected]",

    "isAdmin": "false"

}

       این ممکن است نشان دهد که hidden id و isAdmin parameters به internal user object متصل شده اند، در کنار updated username و email parameters.

Testing mass assignment vulnerabilities

       برای آزمایش اینکه آیا می توانید مقدار isAdmin parameter  شماره گذاری شده را تغییر دهید، آن را به درخواست PATCH اضافه کنید:

{

    "username": "wiener",

    "email": "[email protected]",

    "isAdmin": false,

}

       علاوه بر این، یک درخواست PATCH با مقدار نامعتبر isAdmin parameter ارسال کنید:

{

    "username": "wiener",

    "email": "[email protected]",

    "isAdmin": "foo",

}

       اگر برنامه به طور متفاوتی رفتار کند، این ممکن است نشان دهد که مقدار نامعتبر       (invalid value) بر query logic تأثیر می گذارد، اما مقدار معتبر(valid value) این کار را انجام نمی دهد. این ممکن است نشان دهد که parameter می تواند با موفقیت توسط کاربر update شود.

       سپس می توانید یک درخواست PATCH با مقدار isAdmin parameter تنظیم شده برای true  ارسال کنید، تا سعی کنید آسیب پذیری را اکسپلویت کنید:

{

    "username": "wiener",

    "email": "[email protected]",

    "isAdmin": true,

}

       اگر مقدار isAdmin در request به user object بدون اعتبارسنجی (validation) و sanitization کافی متصل شود، ممکن است به اشتباه به کاربر wiener امتیازات مدیریتی  (admin privileges) اعطا شود. برای تعیین اینکه آیا این مورد صادق است، برنامه را به عنوان wiener مرور کنید تا ببینید آیا می توانید به قابلیت های مدیریتی دسترسی داشته باشید.

Preventing vulnerabilities in APIs

       هنگام طراحی API ها، مطمئن شوید که امنیت از ابتدا در نظر گرفته شده است. به خصوص، مطمئن شوید که شما:

·         اگر قصد ندارید API شما به طور عمومی قابل دسترسی باشد، documentation خود را امن کنید.

·         مطمئن شوید که مستندات شما به روز می شود تا تسترهای معتبر دید کاملی از سطح حمله API داشته باشند.

·         یک لیست سفید از HTTP methods  مجاز را اعمال کنید.

·         اعتبار سنجی کنید که نوع محتوا برای هر در request یا response انتظار می رود.

·         از error messages عمومی استفاده کنید تا از دادن اطلاعاتی که ممکن است برای یک attacker مفید باشد، خودداری کنید.

·         از اقدامات محافظتی در تمام نسخه های API خود استفاده کنید، نه فقط نسخه تولید فعلی.

       برای جلوگیری از آسیب های mass assignment ، ویژگی هایی که می توانند توسط کاربر update شوند را در لیست سفید قرار دهید، و ویژگی های حساسی که نباید توسط کاربر update شوند را در لیست سیاه قرار دهید.