टेंट चेकिंग: Difference between revisions

From Vigyanwiki
(Created page with "टेंट चेकिंग कुछ कंप्यूटर प्रोग्रामिंग प्रोग्रामिंग भाषा , जैस...")
 
No edit summary
 
(9 intermediate revisions by 5 users not shown)
Line 1: Line 1:
टेंट चेकिंग कुछ [[कंप्यूटर प्रोग्रामिंग]] [[ प्रोग्रामिंग भाषा ]], जैसे कि [[पर्ल]], में एक विशेषता है।<ref name="perlsec">{{cite web|title=पर्लसेक - पर्ल सुरक्षा|accessdate=2012-05-20|publisher=Perl 5 development team|url=http://perldoc.perl.org/perlsec.html}}</ref> [[रूबी प्रोग्रामिंग भाषा]]<ref>{{cite book|title=प्रोग्रामिंग रूबी --- व्यावहारिक प्रोग्रामर गाइड|year=2001|publisher=Addison Wesley Longman|pages=253 (Ch. 20)|url=http://www.ruby-doc.org/docs/ProgrammingRuby/html/taint.html}}</ref> या [[बैलेरिना (प्रोग्रामिंग भाषा)]]<ref>{{Cite web|last=Inc|first=WSO2|title=बैलेरिना - टेंट चेकिंग|url=https://ballerina.io/1.0/learn/by-example/taint-checking.html|access-date=2022-02-15|website=ballerina.io}}</ref> दुर्भावनापूर्ण उपयोगकर्ताओं को होस्ट कंप्यूटर पर कमांड निष्पादित करने से रोककर सुरक्षा बढ़ाने के लिए डिज़ाइन किया गया। दागी जांच मुख्य रूप से उन वेब साइटों से जुड़े विशिष्ट सुरक्षा जोखिमों को उजागर करती है जिन पर SQL इंजेक्शन या [[ बफ़र अधिकता ]] दृष्टिकोण जैसी तकनीकों का उपयोग करके हमला किया जाता है।
'''टेंट चेकिंग''' कुछ कंप्यूटर प्रोग्रामिंग भाषाओं में एक सुविधा है,<ref name="perlsec">{{cite web|title=पर्लसेक - पर्ल सुरक्षा|accessdate=2012-05-20|publisher=Perl 5 development team|url=http://perldoc.perl.org/perlsec.html}}</ref> जैसे कि पर्ल रूबी या बैलेरिना,<ref>{{cite book|title=प्रोग्रामिंग रूबी --- व्यावहारिक प्रोग्रामर गाइड|year=2001|publisher=Addison Wesley Longman|pages=253 (Ch. 20)|url=http://www.ruby-doc.org/docs/ProgrammingRuby/html/taint.html}}</ref> जिसे दुर्भावनापूर्ण उपयोगकर्ताओं<ref>{{Cite web|last=Inc|first=WSO2|title=बैलेरिना - टेंट चेकिंग|url=https://ballerina.io/1.0/learn/by-example/taint-checking.html|access-date=2022-02-15|website=ballerina.io}}</ref> को होस्ट कंप्यूटर पर कमांड निष्पादित करने से रोककर सुरक्षा बढ़ाने के लिए डिज़ाइन किया गया है। टेंट चेकिंग मुख्य रूप से उन वेब साइटों से जुड़े विशिष्ट सुरक्षा कठिन परिस्थिति को उजागर करती हैं जिन पर एसक्यूएल इंजेक्शन या बफर ओवरफ्लो अटैक दृष्टिकोण जैसी तकनीकों का उपयोग करके हमला किया जाता है।
 
== सिंहावलोकन ==
टेंट चेकिंग के पीछे की अवधारणा यह है कि कोई भी वेरिएबल जिसे किसी बाहरी उपयोगकर्ता द्वारा संशोधित किया जा सकता है (उदाहरण के लिए [[ प्रपत्र (वेब) ]] में किसी फ़ील्ड द्वारा सेट किया गया वेरिएबल) एक संभावित सुरक्षा जोखिम पैदा करता है। यदि वह [[चर (प्रोग्रामिंग)]] एक अभिव्यक्ति में प्रयोग किया जाता है जो एक दूसरे चर को सेट करता है, तो वह दूसरा चर अब भी संदिग्ध है। दागी जाँच उपकरण तब चर द्वारा चर को आगे बढ़ा सकता है जो चर की एक सूची बनाते हैं जो संभावित रूप से बाहरी इनपुट से प्रभावित होते हैं। यदि इनमें से किसी भी चर का उपयोग खतरनाक कमांड (जैसे SQL डेटाबेस या होस्ट कंप्यूटर [[ सूत्र ]] को सीधे कमांड) को निष्पादित करने के लिए किया जाता है, तो दागी परीक्षक चेतावनी देता है कि प्रोग्राम संभावित रूप से खतरनाक दागी चर का उपयोग कर रहा है। कंप्यूटर प्रोग्रामर खतरनाक इनपुट के चारों ओर एक सुरक्षित दीवार खड़ी करने के लिए प्रोग्राम को फिर से डिज़ाइन कर सकता है।
 
दागी जाँच को [[गैर-हस्तक्षेप (सुरक्षा)]] | गैर-हस्तक्षेप या [[सूचना प्रवाह (सूचना सिद्धांत)]] की अधिक सामान्य अवधारणा के पूर्ण सत्यापन के रूढ़िवादी अनुमान के रूप में देखा जा सकता है।<ref>A. Sabelfeld and A. C. Myers, "Language-based information-flow security", ''IEEE Journal on Selected Areas in Communications'', 2003.</ref> क्योंकि किसी सिस्टम में सूचना प्रवाह को उस सिस्टम के एकल निष्पादन ट्रेस की जांच करके सत्यापित नहीं किया जा सकता है,<ref>J. Ligatti, L. Bauer, D. Walker. "Edit automata: Enforcement mechanisms for run-time security policies". ''International Journal of Information Security'', 2005</ref> दागी विश्लेषण के परिणाम आवश्यक रूप से उस प्रणाली की सूचना प्रवाह विशेषताओं के बारे में अनुमानित जानकारी को दर्शाएंगे जिस पर इसे लागू किया गया है।<ref>T. Terauchi and A. Aiken. "Secure information flow as a safety problem". In ''12th International Static Analysis Symposium'', September 2005.</ref>


== अवलोकन ==
टेंट चेकिंग के पीछे की अवधारणा यह है कि कोई भी वेरिएबल जिसे किसी बाहरी उपयोगकर्ता द्वारा संशोधित किया जा सकता है (उदाहरण के लिए प्रपत्र (वेब) में किसी फ़ील्ड द्वारा सेट किया गया वेरिएबल) एक संभावित सुरक्षा कठिन परिस्थिति उत्पन्न करता है। यदि वह वेरिएबल एक अभिव्यक्ति में प्रयोग किया जाता है जो एक दूसरे वेरिएबल को सेट करता है, तो वह दूसरा वेरिएबल अब भी संदिग्ध है। टेंट चेकिंग उपकरण तब वेरिएबल द्वारा वेरिएबल को आगे बढ़ा सकता है जो वेरिएबल की एक सूची बनाते हैं जो संभावित रूप से बाहरी इनपुट से प्रभावित होते हैं। यदि इनमें से किसी भी वेरिएबल का उपयोग खतरनाक कमांड (जैसे एसक्यूएल डेटाबेस या होस्ट कंप्यूटर [[ सूत्र |सूत्र]] को सीधे कमांड) को निष्पादित करने के लिए किया जाता है, तो टेंट परीक्षक चेतावनी देता है कि प्रोग्राम संभावित रूप से खतरनाक टेंट वेरिएबल का उपयोग कर रहा है। कंप्यूटर प्रोग्रामर खतरनाक इनपुट के चारों ओर एक सुरक्षित दीवार खड़ी करने के लिए प्रोग्राम को फिर से डिज़ाइन कर सकता है।


टेंट चेकिंग को गैर-हस्तक्षेप (सुरक्षा) या सूचना प्रवाह (सूचना सिद्धांत) की अधिक सामान्य अवधारणा के पूर्ण सत्यापन के रूढ़िवादी अनुमान के रूप में देखा जा सकता है।<ref>A. Sabelfeld and A. C. Myers, "Language-based information-flow security", ''IEEE Journal on Selected Areas in Communications'', 2003.</ref> क्योंकि किसी सिस्टम में सूचना प्रवाह को उस सिस्टम के एकल निष्पादन ट्रेस की जांच करके सत्यापित नहीं किया जा सकता है,<ref>J. Ligatti, L. Bauer, D. Walker. "Edit automata: Enforcement mechanisms for run-time security policies". ''International Journal of Information Security'', 2005</ref> टेंट विश्लेषण के परिणाम आवश्यक रूप से उस प्रणाली की सूचना प्रवाह विशेषताओं के बारे में अनुमानित जानकारी को दर्शाएंगे जिस पर इसे प्रयुक्त किया गया है।<ref>T. Terauchi and A. Aiken. "Secure information flow as a safety problem". In ''12th International Static Analysis Symposium'', September 2005.</ref>
== उदाहरण ==
== उदाहरण ==


निम्न खतरनाक पर्ल कोड के मान की जाँच न करके एक बड़ी SQL इंजेक्शन भेद्यता खोलता है <code>$name</code> चर:
निम्नलिखित खतरनाक पर्ल कोड<code>$name</code> वैरिएबल के मान की जाँच न करके एक बड़ी एसक्यूएल इंजेक्शन भेद्यता को खोलता है:


<syntaxhighlight lang="perl">
<syntaxhighlight lang="perl">
Line 18: Line 16:
$dbh->execute("SELECT * FROM users WHERE name = '$name';"); # Execute an SQL query
$dbh->execute("SELECT * FROM users WHERE name = '$name';"); # Execute an SQL query
</syntaxhighlight>
</syntaxhighlight>
यदि टेंट चेकिंग चालू है, तो पर्ल कमांड चलाने से मना कर देगा और एक त्रुटि संदेश के साथ बाहर निकल जाएगा, क्योंकि SQL क्वेरी में एक दूषित चर का उपयोग किया जा रहा है। दागी जांच के बिना, एक उपयोगकर्ता प्रवेश कर सकता था <code>foo'; DROP TABLE users --</code>, जिससे एक कमांड चल रहा है जो संपूर्ण डेटाबेस तालिका को हटा देता है। $name के दागी मान को SQL स्ट्रिंग शाब्दिक में एन्कोड करना और SQL क्वेरी में परिणाम का उपयोग करना अधिक सुरक्षित होगा, यह गारंटी देता है कि कोई खतरनाक कमांड एम्बेडेड नहीं है <code>$name</code> मूल्यांकन किया जाएगा। इसे प्राप्त करने का दूसरा तरीका एक क्वेरी के लिए सभी चर इनपुट को साफ करने के लिए एक तैयार कथन का उपयोग करना है।


ध्यान देने वाली एक बात यह है कि [[पर्ल डीबीआई]] को सेट करने के लिए एक की आवश्यकता होती है <code>TaintIn</code> एक डेटाबेस हैंडल की विशेषता के साथ-साथ किसी के SQL स्ट्रिंग्स की जांच करने के लिए टेंट मोड को सक्षम करना।<ref>{{cite web|url=https://metacpan.org/pod/DBI#TaintIn |title=डीबीआई - पर्ल के लिए डाटाबेस स्वतंत्र इंटरफेस|accessdate=2020-08-29}}</ref>


यदि टैंट चेकिंग चालू है, तो पर्ल कमांड चलाने से मना कर देगा और एक त्रुटि संदेश के साथ बाहर निकल जाएगा, क्योंकि एसक्यूएल क्वेरी में एक टैंटेड वेरिएबल का उपयोग किया जा रहा है। टेंट चेकिंग के बिना, एक उपयोगकर्ता <code>foo'; DROP TABLE users --</code>,अंकित कर सकता है, जिससे एक कमांड चल रहा है जो संपूर्ण डेटाबेस तालिका को हटा देता है। $name के दूषित मान को एसक्यूएल स्ट्रिंग शाब्दिक में एनकोड करना और एसक्यूएल क्वेरी में परिणाम का उपयोग करना अधिक सुरक्षित होगा, यह आश्वासन देते हुए कि <code>$name</code> में एम्बेडेड किसी भी खतरनाक कमांड का मूल्यांकन नहीं किया जाएगा। इसे प्राप्त करने का दूसरा विधि किसी क्वेरी के लिए सभी परिवर्तनीय इनपुट को स्वच्छ करने के लिए तैयार कथन का उपयोग करना है।


ध्यान देने वाली बात यह है कि पर्ल डीबीआई को किसी डेटाबेस हैंडल की <code>TaintIn</code>विशेषता सेट करने के साथ-साथ किसी के एसक्यूएल स्ट्रिंग्स की जांच करने के लिए टैंट मोड सक्षम करने की आवश्यकता होती है।<ref>{{cite web|url=https://metacpan.org/pod/DBI#TaintIn |title=डीबीआई - पर्ल के लिए डाटाबेस स्वतंत्र इंटरफेस|accessdate=2020-08-29}}</ref>
== इतिहास ==
== इतिहास ==
पर्ल ने कम से कम संस्करण 3.0 (1989 में जारी) से [[ निर्धारित समय ]] में दागी होने का समर्थन किया,<ref name="perlhist">{{cite web|url=https://perldoc.perl.org/perlhist.html |title=पर्लहिस्ट - पर्ल इतिहास रिकॉर्ड|publisher=Perl 5 development team |accessdate=2020-08-29}}</ref> हालांकि यह संस्करण 5.0 तक नहीं था (1994 में जारी)<ref name="perlhist" />कि <code>-T</code> बदलना<ref name="perlsec" />टैनिंग को एक ही रनटाइम में एकीकृत करते हुए पेश किया गया था।
पर्ल ने कम से कम संस्करण 3.0 (1989 में प्रसारित) से [[ निर्धारित समय |निर्धारित समय]] में टेंट होने का समर्थन किया,<ref name="perlhist">{{cite web|url=https://perldoc.perl.org/perlhist.html |title=पर्लहिस्ट - पर्ल इतिहास रिकॉर्ड|publisher=Perl 5 development team |accessdate=2020-08-29}}</ref> चूँकि यह संस्करण 5.0 तक नहीं था (1994 में प्रसारित)<ref name="perlhist" />कि <code>-T</code> बदलना<ref name="perlsec" /> टैनिंग को एक ही रनटाइम में एकीकृत करते हुए प्रस्तुत किया गया था।


1996 में, [[नेटस्केप]] ने नेटस्केप नेविगेटर 3 में [[जावास्क्रिप्ट]] के लिए डेटा टैनिंग लागू किया।<ref>{{cite book |last1=Flanagan |first1=David |title=JavaScript: The Definitive Guide |date=1997 |publisher=O'Reilly & Associates |isbn=9781565922341 |page=321 |edition=2nd |quote=[...] the data-tainting security model is experimental in Navigator 3.0, and is not enabled by default. It is expected to be the default security model in version 4.0 of Navigator, however.}}</ref> हालांकि, चूंकि समर्थन को प्रायोगिक माना गया था, इसलिए इसे अक्षम (सक्रिय करने के लिए उपयोगकर्ता के हस्तक्षेप की आवश्यकता होती है) और इससे लाभान्वित होने के लिए स्क्रिप्ट को संशोधित करने के लिए पृष्ठ लेखकों की आवश्यकता होती है। अन्य ब्राउज़र विक्रेताओं ने कार्यक्षमता को कभी लागू नहीं किया।
1996 में, [[नेटस्केप]] ने नेटस्केप नेविगेटर 3 में [[जावास्क्रिप्ट]] के लिए डेटा टैनिंग प्रयुक्त किया।<ref>{{cite book |last1=Flanagan |first1=David |title=JavaScript: The Definitive Guide |date=1997 |publisher=O'Reilly & Associates |isbn=9781565922341 |page=321 |edition=2nd |quote=[...] the data-tainting security model is experimental in Navigator 3.0, and is not enabled by default. It is expected to be the default security model in version 4.0 of Navigator, however.}}</ref> चूँकि, समर्थन को प्रायोगिक माना गया था, इसलिए इसे अक्षम (सक्रिय करने के लिए उपयोगकर्ता के हस्तक्षेप की आवश्यकता होती है) और इससे लाभान्वित होने के लिए स्क्रिप्ट को संशोधित करने के लिए पृष्ठ लेखकों की आवश्यकता होती है। अन्य ब्राउज़र विक्रेताओं ने कार्यक्षमता को कभी प्रयुक्त नहीं किया गया था।
 
==संदर्भ                                     ==
==संदर्भ==
{{reflist}}
{{reflist}}


Line 36: Line 33:
*[http://perldoc.perl.org/perlsec.html perlsec] - Perl security documentation
*[http://perldoc.perl.org/perlsec.html perlsec] - Perl security documentation


{{DEFAULTSORT:Taint Checking}}[[Category: स्थैतिक कार्यक्रम विश्लेषण]] [[Category: कंप्यूटर प्रोग्रामिंग]]
{{DEFAULTSORT:Taint Checking}}
 
 


[[Category: Machine Translated Page]]
[[Category:Created On 15/06/2023|Taint Checking]]
[[Category:Created On 15/06/2023]]
[[Category:Machine Translated Page|Taint Checking]]
[[Category:Pages with script errors|Taint Checking]]
[[Category:Templates Vigyan Ready]]
[[Category:कंप्यूटर प्रोग्रामिंग|Taint Checking]]
[[Category:स्थैतिक कार्यक्रम विश्लेषण|Taint Checking]]

Latest revision as of 11:09, 30 August 2023

टेंट चेकिंग कुछ कंप्यूटर प्रोग्रामिंग भाषाओं में एक सुविधा है,[1] जैसे कि पर्ल रूबी या बैलेरिना,[2] जिसे दुर्भावनापूर्ण उपयोगकर्ताओं[3] को होस्ट कंप्यूटर पर कमांड निष्पादित करने से रोककर सुरक्षा बढ़ाने के लिए डिज़ाइन किया गया है। टेंट चेकिंग मुख्य रूप से उन वेब साइटों से जुड़े विशिष्ट सुरक्षा कठिन परिस्थिति को उजागर करती हैं जिन पर एसक्यूएल इंजेक्शन या बफर ओवरफ्लो अटैक दृष्टिकोण जैसी तकनीकों का उपयोग करके हमला किया जाता है।

अवलोकन

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

टेंट चेकिंग को गैर-हस्तक्षेप (सुरक्षा) या सूचना प्रवाह (सूचना सिद्धांत) की अधिक सामान्य अवधारणा के पूर्ण सत्यापन के रूढ़िवादी अनुमान के रूप में देखा जा सकता है।[4] क्योंकि किसी सिस्टम में सूचना प्रवाह को उस सिस्टम के एकल निष्पादन ट्रेस की जांच करके सत्यापित नहीं किया जा सकता है,[5] टेंट विश्लेषण के परिणाम आवश्यक रूप से उस प्रणाली की सूचना प्रवाह विशेषताओं के बारे में अनुमानित जानकारी को दर्शाएंगे जिस पर इसे प्रयुक्त किया गया है।[6]

उदाहरण

निम्नलिखित खतरनाक पर्ल कोड$name वैरिएबल के मान की जाँच न करके एक बड़ी एसक्यूएल इंजेक्शन भेद्यता को खोलता है:

#!/usr/bin/perl
my $name = $cgi->param("name");  # Get the name from the browser
...
$dbh->{TaintIn} = 1;
$dbh->execute("SELECT * FROM users WHERE name = '$name';"); # Execute an SQL query


यदि टैंट चेकिंग चालू है, तो पर्ल कमांड चलाने से मना कर देगा और एक त्रुटि संदेश के साथ बाहर निकल जाएगा, क्योंकि एसक्यूएल क्वेरी में एक टैंटेड वेरिएबल का उपयोग किया जा रहा है। टेंट चेकिंग के बिना, एक उपयोगकर्ता foo'; DROP TABLE users --,अंकित कर सकता है, जिससे एक कमांड चल रहा है जो संपूर्ण डेटाबेस तालिका को हटा देता है। $name के दूषित मान को एसक्यूएल स्ट्रिंग शाब्दिक में एनकोड करना और एसक्यूएल क्वेरी में परिणाम का उपयोग करना अधिक सुरक्षित होगा, यह आश्वासन देते हुए कि $name में एम्बेडेड किसी भी खतरनाक कमांड का मूल्यांकन नहीं किया जाएगा। इसे प्राप्त करने का दूसरा विधि किसी क्वेरी के लिए सभी परिवर्तनीय इनपुट को स्वच्छ करने के लिए तैयार कथन का उपयोग करना है।

ध्यान देने वाली बात यह है कि पर्ल डीबीआई को किसी डेटाबेस हैंडल की TaintInविशेषता सेट करने के साथ-साथ किसी के एसक्यूएल स्ट्रिंग्स की जांच करने के लिए टैंट मोड सक्षम करने की आवश्यकता होती है।[7]

इतिहास

पर्ल ने कम से कम संस्करण 3.0 (1989 में प्रसारित) से निर्धारित समय में टेंट होने का समर्थन किया,[8] चूँकि यह संस्करण 5.0 तक नहीं था (1994 में प्रसारित)[8]कि -T बदलना[1] टैनिंग को एक ही रनटाइम में एकीकृत करते हुए प्रस्तुत किया गया था।

1996 में, नेटस्केप ने नेटस्केप नेविगेटर 3 में जावास्क्रिप्ट के लिए डेटा टैनिंग प्रयुक्त किया।[9] चूँकि, समर्थन को प्रायोगिक माना गया था, इसलिए इसे अक्षम (सक्रिय करने के लिए उपयोगकर्ता के हस्तक्षेप की आवश्यकता होती है) और इससे लाभान्वित होने के लिए स्क्रिप्ट को संशोधित करने के लिए पृष्ठ लेखकों की आवश्यकता होती है। अन्य ब्राउज़र विक्रेताओं ने कार्यक्षमता को कभी प्रयुक्त नहीं किया गया था।

संदर्भ

  1. 1.0 1.1 "पर्लसेक - पर्ल सुरक्षा". Perl 5 development team. Retrieved 2012-05-20.
  2. प्रोग्रामिंग रूबी --- व्यावहारिक प्रोग्रामर गाइड. Addison Wesley Longman. 2001. pp. 253 (Ch. 20).
  3. Inc, WSO2. "बैलेरिना - टेंट चेकिंग". ballerina.io. Retrieved 2022-02-15. {{cite web}}: |last= has generic name (help)
  4. A. Sabelfeld and A. C. Myers, "Language-based information-flow security", IEEE Journal on Selected Areas in Communications, 2003.
  5. J. Ligatti, L. Bauer, D. Walker. "Edit automata: Enforcement mechanisms for run-time security policies". International Journal of Information Security, 2005
  6. T. Terauchi and A. Aiken. "Secure information flow as a safety problem". In 12th International Static Analysis Symposium, September 2005.
  7. "डीबीआई - पर्ल के लिए डाटाबेस स्वतंत्र इंटरफेस". Retrieved 2020-08-29.
  8. 8.0 8.1 "पर्लहिस्ट - पर्ल इतिहास रिकॉर्ड". Perl 5 development team. Retrieved 2020-08-29.
  9. Flanagan, David (1997). JavaScript: The Definitive Guide (2nd ed.). O'Reilly & Associates. p. 321. ISBN 9781565922341. [...] the data-tainting security model is experimental in Navigator 3.0, and is not enabled by default. It is expected to be the default security model in version 4.0 of Navigator, however.


बाहरी संबंध