أمان منصة جافا البرمجية

توفر منصة برامج Java عددًا من الميزات المصممة لتعزيز أمان تطبيقات Java. ويشمل ذلك فرض قيود وقت التشغيل من خلال استخدام **آلة جافا الافتراضية (JVM)**، و **مدير [[أمن التطبيقات|أمان]](Security Manager)** الذي يعزل التعليمات البرمجية غير الموثوق بها عن بقية نظام التشغيل، بالإضافة إلى مجموعة من '''واجهات برمجة التطبيقات''' **الأمنية (Security APIs)** التي يمكن لمطوري Java الاستفادة منها. ومع ذلك، فقد وُجهت انتقادات إلى لغة البرمجة Java وشركة **Oracle** بسبب الزيادة في البرامج الخبيثة التي استغلت ثغرات أمنية في JVM، والتي لم تعالجها Oracle بشكل فعال وفي الوقت المناسب.

## ميزات الأمان

### JVM
إن الشكل الثنائي للبرامج التي تعمل على منصة Java ليس تعليمات برمجية آلية أصلية، بل هو **كود ثنائي وسيط (bytecode)**. تقوم **آلة Java الافتراضية (JVM)** بتنفيذ عملية تحقق على هذا الكود الثنائي قبل تشغيله لمنع البرنامج من تنفيذ عمليات غير آمنة، مثل الانتقال إلى مواقع ذاكرة غير صحيحة قد تحتوي على بيانات بدلاً من التعليمات البرمجية. كما يتيح ذلك لـ JVM فرض قيود وقت التشغيل، مثل التحقق من حدود المصفوفات. ونتيجة لذلك، فإن برامج Java أقل عرضة بشكل كبير للإصابة بعيوب تتعلق بسلامة الذاكرة، مثل **[[تجاوز سعة المخزن المؤقت]]** **(buffer overflows)**، مقارنة بالبرامج المكتوبة بلغات مثل C التي لا توفر مثل هذه الضمانات المتعلقة بسلامة الذاكرة.

تحظر منصة Java على البرامج تنفيذ عمليات معينة تعتبر غير آمنة، مثل عمليات حسابات المؤشر أو عمليات تحويل النوع غير الصريحة. كما تتولى المنصة إدارة عملية تخصيص الذاكرة وتهيئتها، وتوفر آلية '''جمعًا تلقائيًا للقمامة''' **(automatic garbage collection)**، مما يخفف في العديد من الحالات (ولكن ليس كلها) العبء الواقع على المطور في إدارة الذاكرة يدويًا. ويساهم هذا بشكل كبير في ضمان '''سلامة النوع''' **(type safety)** و **سلامة الذاكرة (memory safety)**.

### مدير الأمن
توفر منصة Java **مدير أمان (Security Manager)** يسمح للمستخدمين بتشغيل تعليمات برمجية غير موثوقة في بيئة "محمية" مصممة لحمايتهم من البرامج الضارة أو التعليمات البرمجية المكتوبة بشكل سيئ. ويتم ذلك عن طريق منع التعليمات البرمجية غير الموثوقة من الوصول إلى ميزات و **واجهات برمجة تطبيقات (APIs)** معينة في المنصة. على سبيل المثال، قد يُمنع الكود غير الموثوق به من قراءة أو كتابة الملفات على نظام الملفات المحلي، أو تنفيذ أوامر عشوائية بامتيازات المستخدم الحالي، أو الوصول إلى شبكات الاتصالات، أو الوصول إلى الحالة الداخلية الخاصة للكائنات باستخدام **الانعكاس (reflection)**، أو حتى التسبب في إنهاء عمل **آلة Java الافتراضية (JVM)**.

يتيح **مدير الأمان (Security Manager)** أيضًا إمكانية **التوقيع الرقمي المشفر (cryptographic signing)** لبرامج Java. وبذلك، يمكن للمستخدمين اختيار السماح بتشغيل التعليمات البرمجية التي تحمل توقيعًا رقميًا صالحًا صادرًا عن جهة موثوق بها بمنحها امتيازات كاملة، في الحالات التي قد لا تعتبر فيها موثوقة لولا هذا التوقيع.

يمكن للمستخدمين أيضًا تحديد **سياسات دقيقة للتحكم في الوصول (fine-grained access control policies)** للبرامج القادمة من مصادر مختلفة. على سبيل المثال، قد يقرر المستخدم منح الثقة الكاملة لفئات النظام فقط، والسماح للتعليمات البرمجية الواردة من جهات موثوقة محددة بقراءة ملفات معينة، مع تطبيق قيود أمان كاملة على جميع التعليمات البرمجية الأخرى.

### واجهات برمجة التطبيقات الأمنية
توفر **مكتبة فئات جافا(Java Class Library)** مجموعة من **واجهات برمجة التطبيقات (APIs)** المتعلقة بالأمان، والتي تتضمن خوارزميات التشفير القياسية، وآليات المصادقة، وبروتوكولات الاتصال الآمنة.

## المصادر المحتملة للثغرات الأمنية في تطبيقات Java
توجد عدة مصادر محتملة للثغرات الأمنية في تطبيقات Java، بعضها يشترك مع تطبيقات غير Java، والبعض الآخر خاص بمنصة Java نفسها. (تجدر الإشارة إلى أن هذه القائمة تشير إلى مصادر محتملة للثغرات الأمنية التي ينبغي على المبرمجين المهتمين بالأمان أخذها في الحسبان؛ ولا يُقصد بها أن تكون قائمة بالثغرات الأمنية الفعلية الموجودة.)

من الأمثلة على المصادر المحتملة للثغرات الأمنية المشتركة بين تطبيقات Java والتطبيقات المكتوبة بلغات أخرى:

* نقاط الضعف في آليات الحماية التي يوفرها الجهاز أو نظام التشغيل الذي يعتمد عليه التطبيق لأمنه
* الثغرات الموجودة في المكتبات الأصلية، مثل مكتبة C القياسية ، والتي يمكن استخدامها لتنفيذ التطبيق و/أو وقت التشغيل
* الثغرات الأمنية الناجمة عن أخطاء في برامج المستخدم (على سبيل المثال، البناء غير الصحيح لاستعلامات SQL مما يؤدي إلى ثغرات حقن SQL )

غير أن جانبًا كبيرًا من النقاش الدائر حول أمان Java يركز على نقاط الضعف المحتملة التي تنفرد بها منصة Java. وتتضمن هذه النقاط:

* نقاط ضعف في آلية الحماية التي تسمح للبايت كود غير موثوق به بالالتفاف على القيود التي يفرضها مدير الأمان
* الثغرات الأمنية في مكتبة فئة Java التي يعتمد عليها التطبيق من أجل أمانه

إن اكتشاف ثغرة أمنية في منصة Java لا يعني بالضرورة أن جميع تطبيقات Java معرضة للخطر. فعند الإعلان عن الثغرات الأمنية وتوفر التحديثات، كما هو الحال من قبل شركة Oracle، يتضمن الإعلان عادةً تفصيلاً لأنواع التطبيقات التي تتأثر بتلك الثغرة (مثال: قد تؤثر ثغرة معينة فقط على التطبيقات التي تستخدم مكونًا معينًا من مكتبة فئات جافا).

على سبيل المثال، إذا كان هناك خلل أمني افتراضي يؤثر فقط على آلية الحماية الخاصة بمدير الأمان في تطبيق JVM معين، فإن ذلك يعني أن تطبيقات Java التي تقوم بتشغيل بايت كود عشوائي غير موثوق به فقط هي التي ستكون عرضة للاختراق. أما التطبيقات التي يثق فيها المستخدم تمامًا ويتحكم في جميع وحدات البايت كود التي يتم تنفيذها فلن تتأثر. وهذا يعني، على سبيل المثال، أن مكونًا إضافيًا لمتصفح الويب يعتمد على JVM سيكون عرضة للبرامج الضارة التي يتم تنزيلها من مواقع الويب العامة، ولكن تطبيق ويب يعمل على جانب الخادم على نفس إصدار JVM حيث يتمتع المسؤول بتحكم كامل في مسار الفئات لن يتأثر. وكما هو الحال مع التطبيقات غير المكتوبة بلغة Java، يمكن أن تنشأ نقاط الضعف الأمنية من أجزاء في المنصة قد لا تبدو في البداية مرتبطة بالأمان. على سبيل المثال، في عام 2011، أصدرت شركة Oracle إصلاحًا أمنيًا لخلل في طريقة `Double.parseDouble`. تقوم هذه الطريقة بتحويل سلسلة نصية مثل "12.34" إلى رقم الفاصلة العائمة المضاعف المكافئ. تسبب هذا الخطأ في دخول هذه الطريقة في حلقة لا نهائية عند استدعائها بإدخال معين. كان لهذا الخطأ آثار أمنية، لأنه على سبيل المثال، إذا قام خادم ويب بتحويل سلسلة أدخلها المستخدم إلى نموذج باستخدام هذه الطريقة، فقد يتمكن مستخدم خبيث من إدخال سلسلة تؤدي إلى حدوث الخطأ. سيؤدي هذا إلى دخول مؤشر ترابط خادم الويب الذي يعالج الطلب الخبيث في حلقة لا نهائية ويصبح غير متاح لخدمة طلبات المستخدمين الآخرين. إن تكرار هذه العملية على خادم ويب ضعيف سيشكل هجومًا سهلاً للحرمان من الخدمة (Denial-of-Service attack): حيث ستتعطل جميع مؤشرات ترابط خادم الويب المسؤولة عن الاستجابة لطلبات المستخدمين في حلقة لا نهائية ولن يتمكن خادم الويب من خدمة أي مستخدمين شرعيين على الإطلاق.

## انتقادات لمدير الأمن
لقد تعرض **مدير الأمان (Security Manager)** في منصة Java (والذي، كما ذكر سابقًا، صُمم لتمكين المستخدمين من تشغيل البايت كود غير الموثوق به بأمان) لانتقادات في السنوات الأخيرة لأنه جعل المستخدمين عرضة للبرامج الضارة ، خاصة في سياق **المكونات الإضافية لمتصفح الويب (browser plug-ins)** التي تنفذ تطبيقات Java تم تنزيلها من مواقع الويب العامة، والتي تُعرف بشكل غير رسمي باسم "**Java في المتصفح (Java in the browser)**".

م أدت الجهود التي بذلتها شركة Oracle لمعالجة هذه الثغرات الأمنية إلى تأخير إصدار **Java 8**.

### 2012
استغل حصان طروادة OS X المعروف باسم Flashback ثغرة أمنية في Java لم تقم ابل بتصحيحها، على الرغم من أن اوراكل كانت قد أصدرت بالفعل تصحيحًا لها. وفي أبريل من ذلك العام (2012)، أصدرت Apple لاحقًا أداة إزالة للمستخدمين الذين يعملون بنظام Lion بدون تثبيت Java  ومع تحديث Java 7 Update 4، بدأت Oracle في إصدار Java مباشرة لنظام التشغيل Lion والإصدارات الأحدث منه.

في أكتوبر من عام 2012، أصدرت شركة ابل تحديثًا أدى إلى إزالة البرنامج الإضافي جافا من جميع المتصفحات الويب على نظام OS X. وقد اعتُبرت هذه الخطوة بمثابة توجه من ابل لإبعاد نظام التشغيل OS X عن الاعتماد على Java.

### 2013
في شهر يناير من عام 2013، تم اكتشاف ثغرة أمنية في جميع إصدارات Java 7، بما في ذلك أحدث إصدار آنذاك وهو Java 7 Update 10، وقد تبين بالفعل استغلال هذه الثغرة في هجمات واقعية. وقد نشأت هذه الثغرة الأمنية نتيجة لتصحيح كان يهدف في الأصل إلى إصلاح ثغرة أمنية سابقة. ورداً على ذلك، قامت شركة Apple بإضافة أحدث إصدار من المكون الإضافي Java إلى قائمتها السوداء للمكونات غير الآمنة. وأصدرت شركة Oracle تصحيحًا لهذه الثغرة (التحديث 11) خلال ثلاثة أيام فقط. كما أصدرت شركة مايكروسوفت أيضًا تصحيحًا لإصدارات متصفح Internet Explorer 6و 7 و 8 للتعامل مع هذه المشكلة.

تم اكتشاف التجسس الإلكتروني المعروف باسم Red October وهو يستغل ثغرة أمنية في Java كانت قد صُححت في أكتوبر 2011. بالإضافة إلى ذلك، تعرض الموقع الإلكتروني لمنظمة مراسلون بلا حدود للاختراق بسبب ثغرة أمنية أخرى في Java، وتحديدًا في الإصدارات التي سبقت التحديث 11.

بعد إصدار التحديث 11، بدأت ثغرة أمنية أخرى في الانتشار عبر الإنترنت،  والتي تم تأكيدها لاحقًا. كما تبين أيضًا أن وضع الأمان الخاص بـ Java نفسه كان عرضة للخطر بسبب وجود خلل. ورداً على ذلك، قامت شركة Mozilla بتعطيل Java (بالإضافة إلى Adobe Reader وMicrosoft Silverlight) في متصفح Firefox بشكل افتراضي،  بينما قامت شركة Apple بإدراج أحدث مكونات Java الإضافية في قائمتها السوداء مرة أخرى.

في شهر فبراير من عام 2013، أعلنت شركة Twitter أنها أحبطت هجومًا إلكترونيًا. ونصحت Twitter مستخدميها بتعطيل Java، على الرغم من أنها لم توضح السبب في حينه. وفي وقت لاحق من الشهر نفسه، أعلن موقع Facebook أنه تعرض للاختراق باستخدام هجوم يستغل ثغرة Java غير معروفة سابقًا (يوم الصفر). كما أفادت شركة Apple أيضًا عن تعرضها لهجوم مماثل. وتبين أن عملية اختراق منتدى مطوري iPhone كانت هي نقطة الانطلاق لاستغلال ثغرة Java لمهاجمة Twitter وFacebook وApple. ولم يكن المنتدى نفسه على علم بهذا الاختراق في البداية. وبعد الإعلانات من Twitter وFacebook وApple، أعلنت شركة Microsoft أيضًا أنها تعرضت لهجوم مماثل استغل ثغرة في Java. .

تم اكتشاف ثغرة أمنية أخرى سمحت بتجاوز صندوق الأمان الخاص بـ Java بالكامل في الإصدار الأصلي من Java 7، بالإضافة إلى التحديثين 11 و15. وفي شهر مارس من عام 2013، تم العثور على حصان طروادة يسمى McRat يستغل ثغرة أمنية في Java. وعلى إثر ذلك، أصدرت شركة Oracle تصحيحًا آخر لمعالجة هذه الثغرة الأمنية.

## انظر أيضا

* نقد جافا

## مراجع

## روابط خارجية

* أمان Java SE . شركة أوراكل. تم التحميل بتاريخ 2013-04-24.
* إرشادات الترميز الآمن للغة البرمجة Java . شركة أوراكل. تم التحميل بتاريخ 2013-04-24.
* كيف يساعد مدير الأمان في التشغيل بمبدأ الحد الأدنى من الامتيازات .

تصنيف:أمن الحاسوب
تصنيف:منصة جافا
تصنيف:صفحات بترجمات غير مراجعة