जावा एप्लेट और जावा सुरक्षा के कुछ सूक्ष्मता पर हस्ताक्षर

समस्या कथन:

एक WYSIWYG XML संपादक के रूप में, हमारा एप्लिकेशन जावा एपलेट ऑक्सीजन ऑथर कंपोनेंट का उपयोग करता है। क्लाइंट पर इस एप्लेट को लोड करते समय, जावा को असुरक्षित कोड के बारे में कोई भयावह चेतावनी नहीं देनी चाहिए, लेकिन उपयोगकर्ता को बिना तनाव दिए और भारी जिम्मेदारी न लेते हुए एप्लेट को चुपचाप और चुपचाप लोड करें। आखिरकार, हमारे पास एक ठोस आवेदन है।

प्रस्तावना

लेख वैज्ञानिक रूप से सत्यापित और सटीक होने का दिखावा नहीं करता है; मैं परिभाषाओं में कुछ गलतियाँ स्वीकार करता हूं। मैंने विकिपीडिया नहीं खोला, मैं लिख रहा हूं, इसलिए दिल से, लेकिन टिप्पणियों को स्वीकार किया जाता है।

उंगलियों पर एपलेट कैसे काम करता है

जब किसी HTML पृष्ठ में एक टैग का पता लगाया जाता है, तो ब्राउज़र एपलेट लोडिंग के नियंत्रण को संबंधित जावा प्लग-इन में स्थानांतरित कर देता है, जो बदले में, क्लाइंट मशीन पर स्थापित JRE पर नियंत्रण स्थानांतरित करता है। एप्लेट को डाउनलोड करने के दो तरीके हैं (एप्लेट से हमारा मतलब एक निश्चित जावा एप्लिकेशन से है, जो जार-ओके का एक सेट है, जहां मेन क्लास के साथ एक मुख्य जार है, एप्लेट क्लास को लागू करने के लिए):

• एप्लेट टैग में, एप्लेट की जार फाइलें जिन्हें डाउनलोड करने की आवश्यकता होती है और जहां से उन्हें लोड करना है उन्हें स्थानांतरित किया जाता है (कोडबेस)
• jnlp फ़ाइल का उपयोग करना जिसमें यह जानकारी इंगित की गई है, साथ ही कई अन्य विकल्प और तर्क भी

हमारे मामले में, हम jnlp का उपयोग करते हैं। दूसरों के बीच, jnlp दृष्टिकोण का लाभ यह है कि एप्लेट लोड करने के लिए कुछ मापदंडों को बदलना (उदाहरण के लिए, कोडबेस), आपको ऐप्पल लोड करने के लिए जिम्मेदार HTML या जावास्क्रिप्ट कोड को बदलने की आवश्यकता नहीं है। बस jnlp बदलें। कोडबेस को बदलना (कोडबेस यूरल एड्रेस है, जहां जार एप्लेट्स स्थित हैं) एक अप्रिय समस्या है, क्योंकि आपको एक पूर्ण URL निर्दिष्ट करने की आवश्यकता है, जिसका अर्थ है कि एपलेट किस सर्वर के आधार पर चल रहा है, यह कोडबेस होना चाहिए । स्थानीय मशीन पर, यह एक पता है, क्यूए पर एक और खड़ा है, तीसरा उत्पादन पर, इसलिए एप्लिकेशन का निर्माण करते समय, आपको स्पष्ट रूप से संदर्भ पथ को निर्दिष्ट करना होगा, अर्थात, वेब एप्लिकेशन का पूर्ण पता जिस पर यह काम करेगा।
Jnlp फ़ाइल का उपयोग करने से इस समस्या का हल निकलता है कि एक विशेष सर्वलेट है, जिसका सार गतिशील रूप से उड़ान भरने पर होता है, जब क्लाइंट jnlp फ़ाइल को लोड करता है तो कोडबेस को वर्तमान में बदल देता है।

चलो चलते हैं

तो, एप्लेट को लोड करना jnlp फ़ाइल को लोड करने के साथ शुरू होता है, जो कि आवश्यक जार फाइलों की सूची और उनके कोडबेस के अलावा, java तर्क भी शामिल है (यह एक बहुत ही महत्वपूर्ण बिंदु है, आपको पता चल जाएगा नीचे क्यों) जिससे यह जावा क्लाइंट मशीन पर शुरू होना चाहिए। जावा जार लोड करना शुरू करता है और सुरक्षा के लिए उनकी जांच करता है। यह वह जगह है जहां जावा सुरक्षा तंत्र आता है, जो कक्षाओं को लोड करने से पहले डाउनलोड करने योग्य फ्राइंग की जांच करना शुरू कर देता है। यह तंत्र बल्कि जटिल और बहुआयामी है: क्लाइंट (अनुमति अनुदान) पर एप्लेट्स और जावा सुरक्षा नीति को लोड करते समय सुरक्षा के सामान्य स्तर को सेट करना, स्वयं जार के प्रकट होने में सुरक्षा पैरामीटर, जार के डिजिटल हस्ताक्षर का सत्यापन, सत्यापन आदि। मैं गहराई में नहीं जाना चाहता हूं और केवल उन पहलुओं को छूऊंगा जो वर्णित समस्या में महत्वपूर्ण हैं।

संदर्भ के लिए: एक एप्लेट पर हस्ताक्षर करने का अर्थ है जार फाइलों पर हस्ताक्षर करना। एक जार पर हस्ताक्षर करना java कमांड साइनजर का निष्पादन है, जिसके परिणामस्वरूप एन्क्रिप्टेड रूप में हस्ताक्षरित कुंजी के बारे में जानकारी जार में दिखाई देती है, साथ ही प्रत्येक संसाधन पैक जार को इस कुंजी के साथ एन्क्रिप्ट किया गया एक कोड सौंपा गया है जो इस की सामग्री के बारे में जानकारी देता है संसाधन। इस प्रकार, यदि आप हस्ताक्षर किए गए फ्राइंग को बदलने की कोशिश करते हैं, उदाहरण के लिए वहां कुछ वर्ग फेंकना, या पुराने को बदलना, तो ऐसा फ्राइंग अमान्य हो जाएगा और यह सुरक्षा जांच पास नहीं करेगा और लोड नहीं किया जाएगा।


तो, एक एप्लेट पर हस्ताक्षर नहीं किए जा सकते, स्व-हस्ताक्षरित, या एक विश्वसनीय प्रमाण पत्र द्वारा हस्ताक्षरित। क्लाइंट जावा के संस्करण के आधार पर, जिस पर एप्लेट लोड किया गया है, एप्लेट का सदस्यता स्तर प्रभावित करता है कि एप्लेट को लोड या अवरुद्ध किया जाएगा या नहीं, लेकिन चेतावनी और संदेशों के एक समूह के साथ "यदि आप इस एप्लेट को चलाने के लिए सहमत हैं, तो एक वैश्विक तबाही होगी और सामान्य रूप से सब कुछ गायब हो जाएगा।" इसलिए अपने जोखिम पर दौड़ें ”



या एक सुंदर और डराने वाले संदेश के साथ डाउनलोड किया गया जिसे आप भविष्य में उपयुक्त चेकमार्क पर क्लिक करके दोहरा नहीं सकते। यहाँ हम वास्तव में, कार्य के लिए मिला है। वर्णित समस्या को हल करने के समय, हमारे ऑक्सीजन एप्लेट स्व-हस्ताक्षरित थे। यही है, हस्ताक्षर था, लेकिन नकली - कीटूल उपयोगिता की मदद से कुंजी हमारे द्वारा उत्पन्न की गई थी।
स्वाभाविक रूप से, इस तरह के एप्लेट को लोड करते समय, जावा ने पंखे में मल फेंक दिया और शाप दिया, हालांकि इसने एपलेट को लंबे समय में लोड किया। लेकिन हमें इन संदेशों से छुटकारा पाने की आवश्यकता थी, इसलिए हमें एक विश्वसनीय प्रमाणीकरण प्राधिकरण (ट्रस्टेड सर्टिफिकेट अथॉरिटी) से एक प्रमाण पत्र की आवश्यकता थी।

इसलिए हमें एक विश्वसनीय केंद्र से एक प्रमाण पत्र की आवश्यकता है। इसे कैसे प्राप्त करें? आसान लेकिन मज़ा सस्ता नहीं है। एक साल के लिए एक प्रमाण पत्र के लिए लगभग 500 अमेरिकी खर्च होंगे। हमने केंद्र की सेवाओं का उपयोग किया www.verisign.com । आपको अपने उपनाम और प्रकाशक के बारे में अन्य जानकारी (कीटूल उपयोगिता का उपयोग करके) के साथ एक कीस्टोर बनाने और एक विशेष अनुरोध बनाने की आवश्यकता है (और, निश्चित रूप से, भुगतान)। जवाब में, सीए चाबियाँ भेजता है। हमारा भेजा 3 टुकड़ों के रूप में भेजा गया: कोड हस्ताक्षर प्रमाण पत्र, मध्यवर्ती CA प्रमाणपत्र और pkcs7 प्रारूप में प्रमाण पत्र। जेकेएस प्रमाणपत्र प्रकार के लिए, हमें मध्यवर्ती और कोड हस्ताक्षर प्रमाणपत्र की आवश्यकता है। सबसे पहले, एक मध्यवर्ती प्रमाण पत्र पहले बनाए गए कीस्टोर में जोड़ा जाता है, और फिर मुख्य कोड हस्ताक्षर प्रमाण पत्र। परिणामी कीस्टोर और जार पर हस्ताक्षर करने के लिए उपयोग किया जाएगा।

यदि आपके फ्राई पर पहले हस्ताक्षर किए गए थे (और मेरे मामले में उन पर हस्ताक्षर किए गए थे, या स्व-हस्ताक्षरित थे), तो उन्हें फिर से हस्ताक्षर करने से पहले, आपको पहले पुराने हस्ताक्षर हटाने होंगे। यदि आप नहीं करते हैं, तो जब आप एप्लेट डाउनलोड करते हैं, तो जावा बहुत पहले फ्राइंग पर चोक करेगा और आपको नरक में भेज देगा। आप हस्ताक्षर को हटा सकते हैं, उदाहरण के लिए, हाथ से .RSA (या .DSA) और .SF फ़ाइलों को META-INF फ़ोल्डर से हटाएं, साथ ही मैनिफ़ेस्ट फ़ाइल से सभी डाइजेस्ट संसाधन हस्ताक्षर हटाएं।
मैं लगभग भूल गया: जार पर हस्ताक्षर करने से पहले, आपको सुरक्षा विशेषताओं को प्रकट करने की आवश्यकता है:

Permissions: all-permissions Codebase: * Caller-Allowable-Codebase: * Application-Library-Allowable-Codebase: * 

अपडेट 51 से शुरू होने पर, सुरक्षा विशेषताओं में शामिल नहीं होने वाले सभी जार स्वचालित रूप से अवरुद्ध हो जाएंगे।
और यहाँ इसके लिए एक एंटी स्क्रिप्ट है:

  <target name="addSecurityProperty"> <jar file="${jarFile}" update="true"> <manifest> <attribute name="Permissions" value="all-permissions"/> <attribute name="Codebase" value="*"/> <attribute name="Application-Library-Allowable-Codebase" value="*"/> <attribute name="Caller-Allowable-Codebase" value="*"/> </manifest> </jar> </target> <target name="addSecurityProperties" if="hasForEach"> <foreach target="addSecurityProperty" param="jarFile"> <path> <fileset dir="lib" includes="**/*.jar, **/*.zip"/> </path> </foreach> </target> 

महत्वपूर्ण: आपको इस स्क्रिप्ट में फ़ॉरेस्ट का उपयोग करने में सक्षम होने के लिए एंटीकंट्रिब की आवश्यकता होगी।

तो, हम फ्राइंग को साफ करते हैं, मैनिफ़ेस्ट, साइन, लॉन्च और ... में आवश्यक विशेषताओं को जोड़ते हैं फिर से हम चेतावनी देखते हैं!



फिर क्या? यह पता चला है कि आपको न केवल तलना, बल्कि jnlp फ़ाइल पर भी हस्ताक्षर करने की आवश्यकता है। इस पर हस्ताक्षर कैसे करें? और ऐसा है । पढ़ने के लिए बहुत आलसी: jnlp फ़ाइल को JNLP-INF निर्देशिका में आपके मुख्य जार में फेंक दिया जाता है और फ़ाइल का नाम इस तरह होना चाहिए: APPLICATION.JNLP। यह एक प्रश्न नहीं है, हम अपनी चींटी स्क्रिप्ट में जोड़ते हैं जो मुख्य जार और संकेत जार बनाता है, सीधी कोड जो हमारे स्रोत jnlp पर हस्ताक्षरित jnlp की प्रतिलिपि बनाता है।

  <target name="compile"> <mkdir dir="classes"/> <javac srcdir="src" destdir="classes" includeantruntime="false" debug="on"> <classpath> <fileset dir="lib"> <include name="*.jar"/> </fileset> </classpath> </javac> <mkdir dir="classes/JNLP-INF"/> <copy file="author-component-dita.jnlp" tofile="classes/JNLP-INF/APPLICATION.JNLP" overwrite="true"/> </target> 

पिता इसका सही पता लगा लेंगे, लेकिन मैं अभी भी समझाता हूं कि इस लक्ष्य-निर्धारण में क्या होता है। पहले भाग में, सब कुछ स्पष्ट है - हम एक वर्ग निर्देशिका बनाते हैं और वहां अपना एप्लेट कोड संकलित करते हैं। कृपया ध्यान दें कि संकलन के दौरान, लिबर फ़ोल्डर को क्लास पास में जोड़ा जाता है, जिसमें जार-ओके का एक गुच्छा होता है, एप्लेट की आवश्यकता होती है और उन सभी को हस्ताक्षर करने की आवश्यकता होती है। अगला, JNLP-INF फ़ोल्डर वहां बनाया गया है, और हमारे मूल एक को वहां कॉपी किया गया है।
लेखक घटक-dita.jnlp।
अगला, हम इसे एक जार में पैक करते हैं (यह हमारा मुख्य जार है) और इसे जार के बाकी हिस्सों के बगल में एक ही काम के फ़ोल्डर में छोड़ दें।
यह पता चला है कि अब हमारे पास 2 jnlp फाइलें हैं: मूल लेखक-घटक-dita.jnlp और APPLICATION.JNLP जार में पैक किया गया है। यह मुझे थोड़ा परेशान करता है, ठीक है। मैंने एप्लेट लॉन्च किया - त्रुटि!



इस बार क्या? यह पता चला है कि ये jnlp फाइलें मेल नहीं खाती हैं, लेकिन होनी चाहिए। मूल jnlp का उपयोग एप्लेट को डाउनलोड करने के लिए किया जाता है, और पैक किए गए एक का उपयोग हस्ताक्षर को सत्यापित करने के लिए किया जाता है और उन्हें अलग नहीं होना चाहिए। लेकिन वे अलग क्यों हैं, क्या वे प्रतियां हैं? और यहां हम अपने अद्भुत सर्वलेट ( JnlpDownloadServlet ) को याद करते हैं, जिसका उपयोग आपके वेब एप्लिकेशन की तैनाती को सुविधाजनक बनाने के लिए किया जाता है - मैंने पहले ही इसका उल्लेख किया था। इसके साथ, आप jnlp के लिए एक विशिष्ट कोडबेस नहीं लिख सकते हैं (उदाहरण के लिए, लोकलहोस्ट: 8888 / ऑक्सीजन-एडिटर /), लेकिन $$CODEBASE चर का उपयोग करें, और $$CODEBASE सर्वलेट स्वयं आवश्यक चर मानों को प्रतिस्थापित करके jnpp को संशोधित करता है। यही कारण है कि डाउनलोड करने योग्य jnlp हस्ताक्षर किए गए से मेल नहीं खाता है। क्या करें? विभिन्न सर्वर पतों के लिए विभिन्न ब्रुअर्स तैनात करें? यह हमारा तरीका नहीं है। यह सरल है: आपको APPLICATION.JNLP के बजाय APPLICATION-TEMPLATE.JNLP का उपयोग करने की आवश्यकता है। APPLICATION-TEMPLATE.JNLP टेम्पलेट का उपयोग करना इस मायने में अलग है कि यह मूल jnlp से भिन्न हो सकता है यदि आप विशिष्ट पैरामीटर मानों के बजाय "*" निर्दिष्ट करते हैं, उदाहरण के लिए, कोडबेस = "*"। चलो हमारे एंटोव build.xml को संशोधित करें:

 <target name="compile"> <mkdir dir="classes"/> <javac srcdir="src" destdir="classes" includeantruntime="false" debug="on"> <classpath> <fileset dir="lib"> <include name="*.jar"/> </fileset> </classpath> </javac> <mkdir dir="classes/JNLP-INF"/> <copy file="author-component-dita.jnlp" tofile="classes/JNLP-INF/APPLICATION-TEMPLATE.JNLP" overwrite="true"/> <replace file="classes/JNLP-INF/APPLICATION-TEMPLATE.JNLP" token="@@CODEBASE@@" value="*"/> <replace file="classes/JNLP-INF/APPLICATION-TEMPLATE.JNLP" token="@@HREF@@" value="*"/> </target> 

तो, क्या वास्तव में यह सब है और मैं आखिरकार ऐप्पल को लंबे समय से प्रतीक्षित उपयोगकर्ता के अनुकूल संदेश को नीले शील्ड के साथ लोड करते समय देखूंगा कि ऐपलेट विश्वसनीय, विश्वसनीय और संदिग्ध नहीं है? मेरी खुशी में विश्वास नहीं, कांपते हाथों से, मैंने एप्लिकेशन लॉन्च किया, एप्लेट डाउनलोड किया और ...



हुर्रे! यह हुआ! मैंने आखिरकार इस संदेश को नीले शील्ड के साथ देखा! और खुशी की बूंदों को छिड़कते हुए, मैं चेकबॉक्स "हमेशा इस प्रकाशक पर भरोसा करता हूं" पर क्लिक करता हूं, यह बंद हो जाता है, एप्लेट लोड करना शुरू कर देता है और ... फिर ऐसा लगता है:



क्या ...? तेजी से भूरे बालों वाली, मैं इसे कोड में बांधना शुरू कर देता हूं - इतनी गैर-सुरक्षा क्या है? सामान्य तौर पर, मैंने इस लाइन को jnlp फ़ाइल में खोजने के लिए 2 दिन और मार दिए:

 <j2se java-vm-args="-Xmx512m -XX:MaxPermSize=80m -Xss4m -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5021" version="1.6+" /> 

ये जावा तर्क हैं जिनके साथ एप्लेट लॉन्च किया गया है। इसलिए, डीबग तर्क गैर-सुरक्षा हैं । और अगर आपके एप्लेट पर हस्ताक्षर किए गए हैं, और एक विश्वसनीय प्रमाण पत्र के साथ, ये तर्क निषिद्ध हैं। दिलचस्प बात यह है कि यदि आपका एपलेट स्व-हस्ताक्षरित है, तो एप्लेट को गंजापन के साथ भी चलाएं, क्योंकि क्लाइंट को चेतावनी दी जाती है कि निष्पादन योग्य एप्लिकेशन अज्ञात है, जिसका अर्थ है कि यह शुरू में खतरनाक है।

यहाँ प्रतिबंधित तर्कों की पूरी सूची है:

 // note: this list MUST correspond to native secure.c file private static String[] secureVmArgs = { "-d32", /* use 32-bit data model if available */ "-client", /* to select the "client" VM */ "-server", /* to select the "server" VM */ "-verbose", /* enable verbose output */ "-version", /* print product version and exit */ "-showversion", /* print product version and continue */ "-help", /* print this help message */ "-X", /* print help on non-standard options */ "-ea", /* enable assertions */ "-enableassertions", /* enable assertions */ "-da", /* disable assertions */ "-disableassertions", /* disable assertions */ "-esa", /* enable system assertions */ "-enablesystemassertions", /* enable system assertions */ "-dsa", /* disable system assertione */ "-disablesystemassertions", /* disable system assertione */ "-Xmixed", /* mixed mode execution (default) */ "-Xint", /* interpreted mode execution only */ "-Xnoclassgc", /* disable class garbage collection */ "-Xincgc", /* enable incremental gc. */ "-Xbatch", /* disable background compilation */ "-Xprof", /* output cpu profiling data */ "-Xdebug", /* enable remote debugging */ "-Xfuture", /* enable strictest checks */ "-Xrs", /* reduce use of OS signals */ "-XX:+ForceTimeHighResolution", /* use high resolution timer */ "-XX:-ForceTimeHighResolution", /* use low resolution (default) */ "-XX:+PrintGCDetails", /* Gives some details about the GCs */ "-XX:+PrintGCTimeStamps", /* Prints GCs times happen to the start of the application */ "-XX:+PrintHeapAtGC", /* Prints detailed GC info including heap occupancy */ "-XX:PrintCMSStatistics", /* If > 0, Print statistics about the concurrent collections */ "-XX:+PrintTenuringDistribution", /* Gives the aging distribution of the allocated objects */ "-XX:+TraceClassUnloading", /* Display classes as they are unloaded */ "-XX:SurvivorRatio", /* Sets the ratio of the survivor spaces */ "-XX:MaxTenuringThreshol", /* Determines how much the objects may age */ "-XX:CMSMarkStackSize", "-XX:CMSMarkStackSizeMax", "-XX:+CMSClassUnloadingEnabled",/* It needs to be combined with -XX:+CMSPermGenSweepingEnabled */ "-XX:+CMSIncrementalMode", /* Enables the incremental mode */ "-XX:CMSIncrementalDutyCycleMin", /* The percentage which is the lower bound on the duty cycle */ "-XX:+CMSIncrementalPacing", /* Automatic adjustment of the incremental mode duty cycle */ "-XX:CMSInitiatingOccupancyFraction", /* Sets the threshold percentage of the used heap */ "-XX:+UseConcMarkSweepGC", /* Turns on concurrent garbage collection */ "-XX:-ParallelRefProcEnabled", "-XX:ParallelGCThreads", /* Sets the number of parallel GC threads */ "-XX:ParallelCMSThreads", "-XX:+DisableExplicitGC", /* Disable calls to System.gc() */ "-XX:+UseCompressedOops", /* Enables compressed references in 64-bit JVMs */ "-XX:+UseG1GC", "-XX:GCPauseIntervalMillis", "-XX:MaxGCPauseMillis" /* A hint to the virtual machine to pause times */ }; 

आपका ध्यान देने के लिए धन्यवाद, मुझे उम्मीद है कि यह लेख उपयोगी होगा।