ابزارهای یکپارچگی

JDK مجموعه‌ای از ابزارها و قابلیت‌های داخلی دارد که به مدیران سیستم کمک می‌کند نصب‌های جاوا را ایمن نگه دارند. اگرچه این ابزارها معمولاً برای توسعه‌دهندگان باتجربه جاوا شناخته‌شده هستند، ممکن است همیشه برای مدیرانی که مسئول حفاظت از برنامه‌های جاوا هستند آشنا نباشند.

در این پست چند ابزار و قابلیت داخلی را بررسی می‌کنیم و اشاراتی به منابع بیشتر ارائه می‌دهیم. مدیران می‌توانند این اطلاعات را برای آماده شدن در شرایطی که باید اقدامات امنیتی برنامه‌های جاوا را بازنگری و اعمال کنند، بررسی کنند.

به‌زبان ساده، این مقاله توصیه‌های عمومی برای ایمن نگه داشتن برنامه‌های جاوا ارائه می‌دهد، نه توصیه‌هایی برای کاهش یک آسیب‌پذیری خاص.

ابزارهای خط فرمان JDK برای شناسایی کلاس‌های مورد استفاده برنامه

هنگام ایمن‌سازی یک برنامه جاوا، معمولاً ابتدا مشخص می‌کنید آیا یک کلاس خاص مورد استفاده قرار می‌گیرد یا خیر. JDK شامل ابزارهایی است که در این کار کمک می‌کنند.

ابزار jcmd

ابزار jcmd برای بازیابی System Properties یک برنامه در حال اجرا با اجرای jcmd $pid VM.system_properties استفاده می‌شود، که $pid شناسه فرآیند برنامه جاوا مورد بررسی است.

با استفاده از jcmd می‌توانید نام کتابخانه‌های بالقوه جالب را در مسیری روی Classpath پیدا کرده و سپس آن کتابخانه را بیشتر بررسی کنید.

شکل ۱: نمونه خروجی jcmd VM.system_properties (مسیر Class با هایلایت)

در JDK 9 و نسخه‌های بعد، jcmd می‌تواند فهرست سلسله‌مراتبی از تمام کلاس‌های بارگذاری‌شده توسط یک برنامه جاوا را با زیردستور VM.class_hierarchy چاپ کند:

jcmd $pid VM.class_hierarchy

شکل ۲: نمونه خروجی jcmd VM.class_hierarchy

در JDK 7 و بعد، زیردستور GC.class_histogram می‌تواند فهرستی از تمام کلاس‌های نمونه‌سازی‌شده (و مصرف حافظه آن‌ها) را ارائه دهد:

jcmd $pid GC.class_histogram

شکل ۳: نمونه خروجی jcmd GC.class_histogram (با هایلایت)

مدیران می‌توانند خروجی jcmd را برای پکیج‌های مورد نظر مانند com.example.foo.bar بررسی کنند تا مشخص شود برنامه آیا کلاس‌هایی از آن پکیج‌ها را بارگذاری یا نمونه‌سازی کرده است.

پکیج‌ها و کلاس‌هایی که هنوز بارگذاری یا نمونه‌سازی نشده‌اند در خروجی jcmd نمایش داده نمی‌شوند. غیبت آن‌ها به تنهایی نشان‌دهنده این نیست که برنامه نمی‌تواند آن‌ها را بعداً بارگذاری کند.

خلاصه

دستور	پشتیبانی از	توضیحات	عملکرد
jcmd <pid> VM.system_properties	JDK 7	تمام System Properties تنظیم‌شده را چاپ می‌کند	بررسی Classpath برای کتابخانه‌های خاص
jcmd <pid> GC.class_histogram	JDK 7	یک Class Histogram ایجاد و چاپ می‌کند	بررسی کلاس‌های نمونه‌سازی‌شده
jcmd <pid> VM.class_hierarchy	JDK 9	سلسله‌مراتب کلاس‌ها را چاپ می‌کند	بررسی کلاس‌های بارگذاری‌شده

jdeps

کلاس‌ها و پکیج‌ها ممکن است به‌عنوان Dependency در Runtime بارگذاری شوند. از JDK 8، توسعه‌دهندگان و مدیران سیستم می‌توانند از jdeps برای تحلیل استاتیک کتابخانه‌ها و کلاس‌های جاوا استفاده کنند تا درباره Dependency های سطح پکیج یا سطح کلاس بیشتر بیاموزند.

توسعه‌دهندگان می‌توانند از jdeps برای بررسی کتابخانه‌های JAR منفرد و جستجوی Dependency های پکیج‌های خاص با آپشن -p استفاده کنند:

jdeps -p com.example.foo.bar some.jar

jdeps همچنین می‌تواند Dependency های پکیجی را با عبارات باقاعده (Regex) فیلتر کند.

خلاصه

دستور	پشتیبانی از	توضیحات	عملکرد
jdeps -package <package-name> <jar>	JDK 8	کتابخانه‌ها و کلاس‌های جاوا را به‌صورت استاتیک تحلیل می‌کند	بررسی Dependency های سطح پکیج یا سطح کلاس

گزینه‌های پیکربندی Runtime

System Properties، متغیرهای محیطی و گزینه‌های خط فرمان

دلیل مهم دیگر به‌روز نگه داشتن Runtime های جاوا این است که Oracle قابلیت‌های Runtime را به‌طور مستمر بهبود می‌بخشد و اقدامات کاهشی مطابق بهترین شیوه‌ها ارائه می‌دهد.

بهترین شیوه‌های امنیتی به کاربران توصیه می‌کنند قابلیت‌هایی که برنامه‌هایشان به آن‌ها نیاز ندارند را غیرفعال کنند و سیستم‌هایشان را برای محدود کردن قابلیت‌های مورد نیاز تا حد ممکن پیکربندی کنند.

به‌عنوان مثال، چندین گزینه برای غیرفعال یا محدود کردن استفاده از JNDI از ژانویه ۲۰۱۷ معرفی شده‌اند، زمانی که بارگذاری کلاس از راه دور از طریق JNDI Object Factories به‌صورت پیش‌فرض غیرفعال شد. محدودیت‌های بیشتری از اکتبر ۲۰۱۸ به‌صورت پیش‌فرض فعال شده‌اند.

اگر برنامه شما از JNDI استفاده می‌کند و به Factory هایی برای ایجاد اشیای Java LDAP نیاز ندارد، مدیران باید از متغیر محیطی JAVA_TOOL_OPTIONS در زمان شروع استفاده کنند:

• jdk.jndi.object.factoriesFilter: این Property به شما امکان مشخص کردن یک Serial Filter را می‌دهد که مجموعه کلاس‌های Object Factory مجاز برای نمونه‌سازی اشیا را کنترل می‌کند.
• com.sun.jndi.ldap.object.trustSerialData: این Property امکان کنترل Deserialization اشیای جاوا از Attribute javaSerializedData LDAP را فراهم می‌کند.

خلاصه گزینه‌های پیکربندی

Command	Supported since	Description	Action
jdk.jndi.object.factoriesFilter	17, 11.0.11, 8u291, and 7u301	مجموعه کلاس‌های Object Factory مجاز برای نمونه‌سازی اشیا را کنترل می‌کند.	-Djdk.jndi.object.factoriesFilter=!* استفاده از هیچ Object Factory برای JNDI را مجاز نمی‌کند
com.sun.jndi.ldap.object.trustSerialData	17, 11.0.11, 8u291, and 7u301	امکان کنترل Deserialization اشیای جاوا از Attribute javaSerializedData LDAP را فراهم می‌کند.	-Dcom.sun.jndi.ldap.object.trustSerialData=false Deserialization از LDAP Attribute را جلوگیری می‌کند
jdk.serialFilter	9, 8u121, and 7u131	جریان‌های ورودی Object Serialization را فیلتر می‌کند تا امنیت و استحکام بهبود یابد.	راهنما و مثال‌های JDK 21، JDK 17، JDK 11، JDK 7 و 8

ایجاد Runtime اختصاصی با jlink

از JDK 9، توسعه‌دهندگان می‌توانند از ابزار jlink برای تولید تصویر Runtime JDK سفارشی برای برنامه خود استفاده کنند. این Runtime فقط قابلیت‌های JDK مورد نیاز کد و کتابخانه‌های وابسته آن را فراهم می‌کند.

مثلاً اگر برنامه رابط کاربری گرافیکی (GUI) نداشته باشد، می‌توان Runtime ای تولید کرد که ماژول java.desktop را شامل نشود و در نتیجه اندازه دانلود و سطح حمله بالقوه کاهش یابد.

برای ادامه مثال قبلی، اگر Runtime ای بخواهیم که از JNDI استفاده نکند، می‌توان Runtime سفارشی بدون ماژول java.naming ایجاد کرد. مجموعه تمام ماژول‌ها با دستور زیر قابل مشاهده است:

java --list-modules

شکل ۴: نمونه خروجی java --list-modules با jdk 11.0.13

توسعه‌دهندگان می‌توانند تصویر Runtime سفارشی با jlink ایجاد کنند. از JDK 11، jdeps آپشن –print-module-deps را ارائه می‌دهد که فهرستی جداشده با کاما از ماژول‌های JDK (و سایر ماژول‌ها) فراهم می‌کند و می‌توان آن را با آپشن –add-modules به jlink پاس داد.

مثال ساده با jlink:

$ jlink --module-path . --add-modules java.base,java.logging,java.net.http,java.xml --output my_runtime

$ my_runtime/bin/java --list-modules
java.base@11.0.13
java.logging@11.0.13
java.net.http@11.0.13
java.xml@11.0.13

تصاویر Runtime سفارشی ایجادشده با jlink زیرمجموعه‌ای تعریف‌شده از JDK هستند. مدیران سیستم باید همان نوع تست‌های یکپارچگی را روی آن‌ها اعمال کنند.

اگر ایجاد تصویر Runtime سفارشی امکان‌پذیر نیست، مدیران سیستم می‌توانند از آپشن –limit-modules Java در Runtime برای محدود کردن مجموعه ماژول‌های JDK قابل مشاهده توسط برنامه استفاده کنند.

اجرای کدی که انتظار دسترسی به API ها را در Runtime ای که آن‌ها را فراهم نمی‌کند دارد، ممکن است به Exception های Runtime منجر شود. هنگام استفاده از تصاویر Runtime سفارشی، تست‌های یکپارچگی مهم هستند.