ابقَ آمنًا

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

حماية حسابات المطوّرين

يتم تحميل رمز الإضافة وتحديثه من خلال حسابات Google. إذا كان المطوّرون الحسابات هي قد يدفع المهاجم التعليمات البرمجية الضارة إلى جميع المستخدمين مباشرةً. يمكنك حماية هذه الحسابات من خلال إنشاء حسابات مطوّرين تحديدًا وتفعيل المصادقة الثنائية، ويُفضّل استخدام مفتاح أمان .

إبقاء المجموعات انتقائية

في حال استخدام النشر الجماعي، يجب حصر المجموعة بالمطوّرين الموثوق بهم. لا تقبل طلبات الانضمام من أشخاص غير معروفين.

عدم استخدام HTTP مطلقًا

عند طلب البيانات أو إرسالها، تجنَّب اتصال HTTP. افترض أنّ أي اتصالات HTTP ستتحكّم فيها جهات خارجية أو ستتضمّن تعديلات. يجب دائمًا تفضيل HTTPS، لأنّه يتضمّن ميزات أمان مدمجة تمنع معظم هجمات الرجل في المنتصف.

طلب الحد الأدنى من الأذونات

يحدّ متصفّح Chrome من وصول الإضافة إلى الأذونات التي تم طلبها صراحةً في بيان الإضافة. يجب أن تقلِّل الإضافات من أذونات الوصول التي تطلبها من خلال تسجيل واجهات برمجة التطبيقات والمواقع الإلكترونية التي تعتمد عليها فقط. يجب الحدّ الأدنى من الرموز العشوائية.

يؤدي الحدّ من امتيازات الإضافات إلى الحدّ من ما يمكن لمهاجم محتمل استغلاله.

طلب XMLHttpRequest من مصادر متعددة

لا يمكن للإضافة استخدام XMLHttpRequest إلا للحصول على الموارد من نفسها ومن النطاقات المحدّدة في الأذونات.

{
  "name": "Very Secure Extension",
  "version": "1.0",
  "description": "Example of a Secure Extension",
  "permissions": [
    "/*",
    "https://*.google.com/"
  ],
  "manifest_version": 2
}

تطلب هذه الإضافة الوصول إلى أي محتوى على developer.chrome.com والنطاقات الفرعية لشركة Google من خلال إدراج "/*" و"https://*google.com/" في الأذونات. في حال اختراق الإضافة، سيظلّ لديها الإذن بالتفاعل مع المواقع الإلكترونية التي تستوفي نمط المطابقة فقط. لن يتمكن المهاجم من الوصول إلى "https://user_bank_info.com" أو التفاعل مع "https://malicious_website.com".

الحدّ من حقول البيان

يؤدي تضمين عمليات تسجيل غير ضرورية في البيان إلى إنشاء ثغرات أمنية وجعل الإضافة أكثر ظهورًا. يجب حصر حقول البيان بالحقول التي تعتمد عليها الإضافة ومنح تسجيل حقل معيّن.

قابل للربط خارجيًا

استخدِم الحقل externally_connectable للإشارة إلى الإضافات وصفحات الويب الخارجية التي تبادل المعلومات مع الإضافة. يمكنك تقييد الجهات التي يمكن للإضافة التواصل معها خارجيًا لتصبح مصادر موثوق بها.

{
  "name": "Super Safe Extension",
  "externally_connectable": {
    "ids": [
      "iamafriendlyextensionhereisdatas"
    ],
    "matches": [
      "/*",
      "https://*google.com/"
    ],
    "accepts_tls_channel_id": false
  },
  ...
}

المراجع المتوفّرة على الويب

ستؤدي إتاحة الوصول إلى الموارد على الويب، ضمن web_accessible_resources إلى حدوث الإضافة التي يمكن للمواقع الإلكترونية والمهاجمين رصدها.

{
  ...
  "web_accessible_resources": [
    "images/*.png",
    "style/secure_extension.css",
    "script/secure_extension.js"
  ],
  ...
}

وكلما زادت الموارد المتاحة على الويب، زادت الطرق التي يمكن للمهاجم المحتمل استغلالها. يجب الحدّ من استخدام هذه الملفات.

أن تتضمّن سياسة أمان المحتوى الصريح

ضمِّن سياسة أمان المحتوى للإضافة في البيان لمنع الروابط من مواقع إلكترونية متعددة. هجمات البرمجة النصية. إذا كانت الإضافة تحمِّل الموارد من تلقاء نفسها فقط، سجِّل ما يلي:

{
  "name": "Very Secure Extension",
  "version": "1.0",
  "description": "Example of a Secure Extension",
  "content_security_policy": "default-src 'self'"
  "manifest_version": 2
}

إذا كانت الإضافة تحتاج إلى تضمين نصوص برمجية من مضيفات معيّنة، يمكن تضمينها:

{
  "name": "Very Secure Extension",
  "version": "1.0",
  "description": "Example of a Secure Extension",
  "content_security_policy": "default-src 'self' https://extension.resource.com"
  "manifest_version": 2
}

تجنُّب واجهات برمجة التطبيقات القابلة للتنفيذ

يجب استبدال واجهات برمجة التطبيقات التي تنفّذ الرموز البرمجية ببدائل أكثر أمانًا.

Document.write() وinnerHTML

على الرغم من أنّه قد يكون من الأسهل إنشاء عناصر HTML ديناميكيًا باستخدام document.write() وinnerHTML، فإنه يترك الملحق وصفحات الويب التي يعتمد عليها الملحق مفتوحة للمهاجمين الذين يُدخلون نصوصًا برمجية ضارة. بدلاً من ذلك، يمكنك إنشاء عُقد DOM يدويًا واستخدام innerText لإدراج محتوى ديناميكي.

function constructDOM() {
  let newTitle = document.createElement('h1');
  newTitle.innerText = host;
  document.appendChild(newTitle);
}

eval()

تجنَّب استخدام eval() كلما أمكن ذلك لمنع الهجمات، لأنّ eval() سينفذ أي رمز يتم تمريره فيه، وقد يكون ضارًا.

var xhr = new XMLHttpRequest();
xhr.open("GET", "https://api.example.com/data.json", true);
xhr.onreadystatechange = function() {
  if (xhr.readyState == 4) {
    // WARNING! Might be evaluating an evil script!
    var resp = eval("(" + xhr.responseText + ")");
    ...
  }
}
xhr.send();

بدلاً من ذلك، يُفضَّل استخدام طرق أكثر أمانًا وسرعة، مثل JSON.parse().

var xhr = new XMLHttpRequest();
xhr.open("GET", "https://api.example.com/data.json", true);
xhr.onreadystatechange = function() {
  if (xhr.readyState == 4) {
    // JSON.parse does not evaluate the attacker's scripts.
    var resp = JSON.parse(xhr.responseText);
  }
}
xhr.send();

استخدام النصوص البرمجية للمحتوى بحذر

على الرغم من أنّ النصوص البرمجية للمحتوى متوفّرة في عالم منعزل، فهي ليست محصنة من الهجمات:

• النصوص البرمجية للمحتوى هي الجزء الوحيد من الإضافة الذي يتفاعل مباشرةً مع صفحة الويب. ولهذا السبب، قد تلاعب صفحات الويب المعادية بأجزاء من نموذج DOM الذي يعتمد عليه نص المحتوى، أو تستغل سلوكًا مفاجئًا لمعايير الويب، مثل العناصر المُسمّاة.
• للتفاعل مع نموذج DOM لصفحات الويب، يجب تنفيذ نصوص برمجية المحتوى في عملية عرض المحتوى نفسها التي تتم فيها معالجة صفحة الويب. ما يجعل النصوص البرمجية للمحتوى عرضة لتسرُّب البيانات عن طريق هجمات القنوات الجانبية. (مثال: Spectre)، والتعرّض للاختراق من قِبل مهاجم إذا اخترقت صفحة ويب ضارة عملية عرض المحتوى.

يجب تنفيذ المهام الحسّاسة في عملية مخصّصة، مثل الرمز البرمجي في الخلفية الخاص بالإضافة. تجنَّب السماح للنص البرمجي للمحتوى بالوصول إلى امتيازات الإضافة عن طريق الخطأ:

• لنفترض أنّ الرسائل من نص برمجي للمحتوى قد تكون من إنشاء مهاجم (على سبيل المثال، التحقّق من صحة جميع الإدخالات وتصحيحها وحماية النصوص البرمجية من النصوص البرمجية على مواقع إلكترونية متعددة)
• افترض أن أي بيانات يتم إرسالها إلى النص البرمجي للمحتوى قد تتسرب إلى صفحة الويب. لا ترسِل بيانات حسّاسة (مثل الأسرار من الإضافة والبيانات من مصادر ويب أخرى وسجلّ التصفّح) إلى محتوى النصوص البرمجية.
• الحد من نطاق الإجراءات المميّزة التي يمكن أن تبدأها نصوص برمجية للمحتوى لا تسمح للنصوص البرمجية للمحتوى ببدء طلبات إلى عناوين URL عشوائية أو تمرير مَعلمات عشوائية إلى واجهات برمجة تطبيقات الإضافات (على سبيل المثال، لا تسمح بتمرير عناوين URL عشوائية إلى واجهة برمجة التطبيقات fetch أو chrome.tabs.create).

تسجيل المدخلات وتنقيتها

يمكنك حماية الإضافة من النصوص البرمجية الضارة عن طريق حصر المستمعين بما تتوقعه الإضافة فقط، والتحقّق من مُرسِلي البيانات الواردة، وتطهير جميع الإدخالات.

يجب أن تُسجَّل الإضافة في runtime.onRequestExternal فقط، في حال كانت من المتوقّع أن الاتصالات من موقع ويب خارجي أو إضافة. تأكَّد دائمًا من أنّ المُرسِل يطابق مصدرًا موثوقًا.

// The ID of an external extension
const kFriendlyExtensionId = "iamafriendlyextensionhereisdatas";

chrome.runtime.onMessageExternal.addListener(
  function(request, sender, sendResponse) {
    if (sender.id === kFriendlyExtensionId)
      doSomething();
});

حتى الرسائل الواردة من خلال حدث runtime.onMessage من الإضافة نفسها يجب فحصها للتأكّد من أنّ مُرسِل الرسالة ليس من نص محتوى مُخترَق.

chrome.runtime.onMessage.addListener(function(request, sender, sendResponse) {
  if (request.allowedAction)
    console.log("This is an allowed action.");
});

منع إضافة من تنفيذ نص برمجي للمهاجم من خلال تطهير إدخالات المستخدمين والبيانات القادمة، حتى من الإضافة نفسها والمصادر الموافَق عليها تجنُّب واجهات برمجة التطبيقات القابلة للتنفيذ.

function sanitizeInput(input) {
    return input.replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/"/g, '&quot;');
}