# APIs and Excessive Data Exposure

#### استخدام واجهات برمجة التطبيقات واكتشاف تعرض البيانات بشكل مفرط

**كشف تعرض البيانات بشكل مفرط**

تحدث ظاهرة تعرض البيانات بشكل مفرط عندما يرسل مزود API  كائن بيانات كامل، مما يتطلب من العميل تصفية المعلومات التي يحتاجها. تكمن المشكلة الأمنية في حساسية المعلومات المرسلة، وليس فقط في حجم البيانات.

**مكونات تعرض البيانات بشكل مفرط**

* استجابة تتضمن معلومات أكثر مما هو مطلوب.
* معلومات حساسة يمكن استخدامها في هجمات أكثر تعقيدًا.

  <figure><img src="https://114954437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfoyclHsS3E0AkBuajmOV%2Fuploads%2FWQVDYwe6vcR0gzAVYlUA%2Fimage.png?alt=media&#x26;token=90482739-ed21-4400-9939-b11d3985d593" alt="" width="418"><figcaption></figcaption></figure>

**أمثلة على تعرض البيانات**

إذا كان مزود API  يرسل كائن بيانات كامل، فإن أول شيء يمكن أن ينبهك إلى تعرض البيانات بشكل مفرط هو ببساطة حجم الاستجابة. إذا كان الطلب GET يعود بمعلومات عن المستخدم وبيانات إضافية عن المشرف، فهذا يشير إلى تعرض مفرط للبيانات.

**تحليل طلبات API**

بمجرد وصولك إلى API  الخاصة بـ crAPI، انظر إلى الطلبات. على سبيل المثال، طلب GET لـ `/identity/api/v2/user/dashboard` يمكن أن يكشف معلومات حساسة مثل "id" و"email" و"available\_credit".

**استخدام Burp Suite**

باستخدام Burp Suite، يمكنك التحقق من الطلبات والتقاط الاستجابات، مما قد يكشف عن معلومات حساسة. عند إجراء طلب GET إلى `/community/api/v2/community/posts/recent`، يمكن أن يكشف عن بيانات حساسة مثل أسماء المستخدمين والبريد الإلكتروني

**تحليل النقاط النهائية (Endpoints)**

الخطوة الأولى في عملية اختراق **ال**API  هي فهم كيفية استخدامها كما هو مقصود. بعد ذلك، يمكنك اكتشاف تعرض البيانات بشكل مفرط. سنقوم بمراجعة Documentationالخاصة **ال**API لاستخدامها في المصادقة وبدء تشكيل الطلبات.

**ال**API Documentation

على الرغم من أن Documentationالخاصة **ال**API  عادةً ما تكون واضحة، إلا أن هناك بعض العناصر التي يجب الانتباه لها. عادة ما يتضمن القسم الأول من Documentationنظرة عامة على كيفية الاتصال واستخدام API. كما يمكن أن تحتوي على معلومات حول المصادقة وحدود المعدل.

**الوظائف المطلوبة**

راجع Documentationلفهم الوظائف المتاحة، أي الإجراءات التي يمكنك اتخاذها باستخدام API المعطاة. ستظهر هذه الوظائف كمزيج من طريقة HTTP (GET، PUT، POST، DELETE) ونقطة النهاية (endpoint). يمكن أن تتضمن الوظائف user account management, options to upload and download data, different ways to request information.

**متطلبات الطلب**

عند إجراء طلب إلى endpoint، تأكد من ملاحظة متطلبات الطلب. يمكن أن تشمل هذه المتطلبات بعض أشكال authentication, parameters, path variables, headers, and information included in the body of the request. يجب أن تخبرك الوثائق بما يتطلبه منك وأن تذكر أي جزء من الطلب تتعلق به هذه المعلومات. إذا كانت Documentation تقدم أمثلة، استخدمها كمرجع.

**مؤشرات** Documentation

تساعدك معرفة مؤشرات Documentation في إنشاء طلبات صحيحة وحل المشكلات عندما لا تستجيب API  كما هو متوقع. بعض مؤشرات الوثائق تشمل:

* استخدام نقطتين أو أقواس معقوفة للإشارة إلى متغيرات المسار.
* الأقواس المربعة تشير إلى أن الإدخال اختياري.
* رموز مزدوجة تمثل قيمًا ممكنة مختلفة يمكن استخدامها.

<figure><img src="https://114954437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfoyclHsS3E0AkBuajmOV%2Fuploads%2FyBAkX7e9Xk7K5icc7pVO%2Fimage.png?alt=media&#x26;token=8d96e507-f944-42d1-8da0-36ab6a9b3fe9" alt="" width="563"><figcaption></figcaption></figure>

**استكشاف** endpoint

استخدم Swagger Editor لاستيراد مواصفات Swagger الخاصة API  (مثل crAPI). يمكنك من خلاله رؤية مجموعة منthe endpoint, parameters, request body, and example responses المختلفة، مما يوفر تمثيلًا بصريًا لنقاط النهاية الخاصة بالواجهة.

**إعداد متغيرات مجموعة Postman**

عند العمل مع مجموعة جديدة في Postman، من الجيد فحص متغيرات المجموعة للتأكد من أن قيمة `baseUrl` تتطابق مع عنوان URL الخاص بالهدف. تأكد من حفظ التحديثات التي تجريها في المحرر.

**تحديث تفويض مجموعة Postman**

لإجراء طلبات Authorization ، تحتاج إلى إضافة رمز Authorization صالح. يمكن فعل ذلك من خلال علامة التبويب Authorization في محرر المجموعة. بالنسبة لـ crAPI، سيكون هذا رمز Bearer.
