SARIF SDK और इसकी त्रुटियां

आज, हम एक अन्य Microsoft उच्च-गुणवत्ता वाली परियोजना का परीक्षण कर रहे हैं, जिसमें हम अभी भी पीवीएस-स्टूडियो का उपयोग करके त्रुटियों के लिए वीरतापूर्वक खोज करने का प्रयास करते हैं। SARIF का अर्थ है स्टेटिक एनालिसिस रिजल्ट्स इंटरचेंज फॉर्मेट। यह एक मानक (फाइल फॉर्मेट) है जो अन्य टूल के साथ स्टैटिक एनालाइजर के परिणामों की परस्पर क्रिया और विनिमय के लिए है: IDEs, व्यापक कोड सत्यापन और विश्लेषण टूल (उदाहरण के लिए, सोनारक्यूब), निरंतर एकीकरण प्रणाली आदि SARIF SDK, क्रमशः SARIF को सपोर्ट करने के लिए .NET डेवेलपर टूल के साथ-साथ फाइल को सपोर्ट करता है।
SARIF Microsoft में उत्पन्न हुआ और अब OASIS (खुले मानकों में लगे एक गैर-लाभकारी संघ) द्वारा विकसित एक मानक है। SARIF को न केवल विश्लेषक के परिणामों को प्रसारित करने के लिए डिज़ाइन किया गया है, बल्कि उपकरण के बारे में मेटाडेटा, साथ ही साथ यह कैसे लॉन्च किया गया था, टाइमस्टैम्प, और इसी तरह के डेटा। मानक के बारे में अधिक जानकारी OASIS वेबसाइट पर देखी जा सकती है। SARIF SDK सोर्स कोड GiHub पर रिपॉजिटरी से डाउनलोड किया जा सकता है। प्रोजेक्ट होम पेज यहां उपलब्ध है ।

परियोजना के बारे में

SARIF SDK प्रोजेक्ट छोटा था: 799 .cs फाइलें (कोड की लगभग 98,000 गैर-खाली लाइनें)। परियोजना में परीक्षण शामिल हैं, जिन्हें मैं हमेशा सत्यापन से बाहर रखता हूं। इस प्रकार, कोड का वह भाग जो हमें रुचिकर था 642 .cs फाइलें (कोड की लगभग 79,000 गैर-खाली लाइनें)। यह, ज़ाहिर है, पर्याप्त नहीं है। लेकिन सत्यापन और विश्लेषण चीजों के बीच त्वरित और आसान था, जिसे मैंने लेख की शुरुआत में चित्र में प्रतिबिंबित करने की कोशिश की थी। फिर भी, कुछ दिलचस्प त्रुटियां पाई गईं। आइए उन पर नजर डालते हैं।

त्रुटियों

V3070 [CWE-457] 'डिफॉल्ट' वेरिएबल को इनिशियलाइज़ करते समय Uninitialized चर 'बाइनरी' का उपयोग किया जाता है। MimeType.cs 90

public static class MimeType { .... /// <summary>The MIME type to use when no better MIME type is known.</summary> public static readonly string Default = Binary; .... /// <summary>The MIME type for binaries.</summary> public static readonly string Binary = "application/octet-stream"; .... } 

डिफ़ॉल्ट फ़ील्ड को किसी अन्य फ़ील्ड के मान के साथ आरंभीकृत किया जाता है जिसे अभी तक कोई मान नहीं मिला है। नतीजतन, डिफ़ॉल्ट प्रकार स्ट्रिंग - नल के लिए डिफ़ॉल्ट मान प्राप्त करेगा। संभवतः, त्रुटि पर ध्यान नहीं दिया गया था, क्योंकि डिफ़ॉल्ट फ़ील्ड का उपयोग कहीं भी नहीं किया गया है। लेकिन सब कुछ बदल सकता है, और फिर डेवलपर एक अप्रत्याशित परिणाम या प्रोग्राम क्रैश का सामना करेगा।

V3061 पैरामीटर 'लॉजिकललोकेशनटॉइंडेक्सपेज़' का उपयोग करने से पहले हमेशा विधि निकाय में लिखा जाता है। PrereleaseCompatibilityTransformer.cs 1963

 private static JArray ConvertLogicalLocationsDictionaryToArray( .... Dictionary<LogicalLocation, int> logicalLocationToIndexMap, ....) { .... logicalLocationToIndexMap = new Dictionary<LogicalLocation, int>(LogicalLocation.ValueComparer); .... } 

लॉजिकललोकेशनटॉइंडएक्सपाइप पैरामीटर का उपयोग किसी भी तरह से नहीं किया जाता है, इसके लिए एक और मूल्य लिख रहा है। उत्सुकता से, पुराने मूल्य बिल्कुल वही खाली शब्द है जो कॉलिंग विधि में बनाया गया है:

 private static bool ApplyChangesFromTC25ThroughTC30(....) { .... Dictionary<LogicalLocation, int> logicalLocationToIndexMap = null; .... logicalLocationToIndexMap = new Dictionary<LogicalLocation, int>(LogicalLocation.ValueComparer); run["logicalLocations"] = ConvertLogicalLocationsDictionaryToArray( ...., logicalLocationToIndexMap, ....); } 

अजीब और संदिग्ध कोड।

V3008 [CWE-563] 'run.Tool' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। जाँच लाइनें: 116, 114. ExportRulesMetadataCommandBase.cs 116

 public partial class Run { .... public Tool Tool { get; set; } .... } public partial class Tool : .... { .... public Tool() { } .... } private void OutputSarifRulesMetada(....) { .... var run = new Run(); run.Tool = new Tool(); run.Tool = Tool.CreateFromAssemblyData(....); // <= .... } 

रन.टूल संपत्ति को दो बार एक मान दिया जाता है। टूल ऑब्जेक्ट बनाते समय, और टूल प्रॉपर्टी पर लिखते समय, कोई अतिरिक्त कार्य नहीं किया जाता है। इसलिए, पुनर्मूल्यांकन संदिग्ध लग रहा है।

V3042 [CWE-476] संभावित NullReferenceException। '?' और '' ऑपरेटरों का उपयोग 'loc' ऑब्जेक्ट WhereComparer.cs 152 के सदस्यों तक पहुँचने के लिए किया जाता है

 private static Uri ArtifactUri(ArtifactLocation loc, Run run) { return loc?.Uri ?? loc.Resolve(run)?.Uri; } 

यदि स्थानीय चर शून्य हो जाता है, तो संचालक के दाईं ओर से मान लौटाने का प्रयास किया जाएगा, जिसके परिणामस्वरूप एक अशक्त संदर्भ तक पहुंच होगी।

V3042 [CWE-476] संभावित NullReferenceException। '?' और '' ऑपरेटरों का उपयोग 'FormatString' ऑब्जेक्ट InsertOptionalDataVisitor.cs 194 के सदस्यों तक पहुँचने के लिए किया जाता है

 public override Message VisitMessage(Message node) { .... node.Text = node.Arguments?.Count > 0 ? string.Format(...., formatString.Text, ....) : formatString?.Text; .... } 

सशर्त विवरण की दो समानांतर शाखाओं में ?: वे असुरक्षित और सुरक्षित पहुंच विकल्पों का उपयोग करते हुए एक संभावित अशक्त स्वरूपण संदर्भ का उपयोग करते हैं।

V3042 [CWE-476] संभावित NullReferenceException। '?' और '' ऑपरेटरों का उपयोग 'messageText' ऑब्जेक्ट FortifyFprConverter.cs 1210 के सदस्यों तक पहुँचने के लिए किया जाता है

V3042 [CWE-476] संभावित NullReferenceException। '?' और '' ऑपरेटरों का उपयोग 'messageText' ऑब्जेक्ट FortifyFprConverter.cs 1216 के सदस्यों तक पहुँचने के लिए किया जाता है

 private void AddMessagesToResult(Result result) { .... string messageText = (rule.ShortDescription ?? rule.FullDescription)?.Text; .... if (....) { // Replace the token with an embedded hyperlink. messageText = messageText.Replace(....); } else { // Replace the token with plain text. messageText = messageText.Replace(....); } .... } 

यहां, विश्लेषक ने तुरंत संदेश के माध्यम से संभव पहुंच के बारे में दो चेतावनी जारी कीं। यह तुच्छ दिखता है, लेकिन इसमें से त्रुटि एक त्रुटि नहीं है।

V3080 [CWE-476] संभावित अशांति । 'FileDataVersionOne.Uri' के निरीक्षण पर विचार करें। SarifCurrentToVersionOneVisitor.cs 1030

 private IDictionary<string, FileDataVersionOne> CreateFileDataVersionOneDictionary() { .... FileDataVersionOne fileDataVersionOne = CreateFileDataVersionOne(v2File); if (fileDataVersionOne.Uri.OriginalString.Equals(key)) { .... } .... } 

विश्लेषक को संदेह था कि फ़ाइलडैटो वर्जनऑन.यूरी लिंक के साथ काम करते समय NullReferenceException संभव थी । आइए देखें कि यह चर कहां से आता है, और क्या विश्लेषक सही है। ऐसा करने के लिए, CreateFileDataVersionOne विधि के मुख्य भाग की जाँच करें:

 private FileDataVersionOne CreateFileDataVersionOne(Artifact v2FileData) { FileDataVersionOne fileData = null; if (v2FileData != null) { .... fileData = new FileDataVersionOne { .... Uri = v2FileData.Location?.Uri, .... }; .... } return fileData; } public partial class FileDataVersionOne { .... public Uri Uri { get; set; } .... } 

दरअसल, जब FileDataVersionOne की एक कक्षा बनाते हैं, तो उरी संपत्ति को शून्य करने के लिए सेट किया जा सकता है। डेटा प्रवाह विश्लेषण और इंटरप्रोसेरुरल विश्लेषण तंत्र के सहयोग का एक अच्छा उदाहरण है।

V3080 [CWE-476] संभावित अशांति । '_JsonTextWriter' के निरीक्षण पर विचार करें। SarifLogger.cs 242

 public virtual void Dispose() { .... if (_closeWriterOnDispose) { if (_textWriter != null) { _textWriter.Dispose(); } if (_jsonTextWriter == null) { _jsonTextWriter.Close(); } // <= } .... } 

यह एक टाइपो है। जाहिर है, ब्लॉक होने पर दूसरे की हालत _jsonTextWriter! = Null होनी चाहिए। इस कोड का खतरा यह है कि यह सबसे अधिक दुर्घटना की संभावना नहीं है, क्योंकि _jsonTextWriter बिल्कुल शून्य नहीं है। लेकिन एक ही समय में, प्रवाह खुला रहता है।

V3083 [CWE-367] 'RuleRead', NullReferenceException घटना के असुरक्षित आह्वान संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। FxCopConverter.cs 897

 private void ReadRule(....) { .... if (RuleRead != null) { RuleRead(....); } .... } 

वे घटना के साथ सुरक्षित रूप से काम नहीं कर रहे हैं। एक गैर-महत्वपूर्ण त्रुटि जो आसानी से तय की जा सकती है, उदाहरण के लिए, विज़ुअल स्टूडियो के संकेत के बाद। यहाँ एक प्रतिस्थापन IDE प्रस्ताव है:

 private void ReadRule(....) { .... RuleRead?.Invoke(....); .... } 

यह कुछ सेकंड के लिए काम करता है, लेकिन विश्लेषक अब शपथ नहीं लेता है, और आईडीई कोड को उजागर नहीं करता है। इसी तरह की एक और त्रुटि:

• V3083 [CWE-367] इवेंट 'ResultRead' का असुरक्षित आमंत्रण, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। FxCopConverter.cs 813

V3095 [CWE-476] शून्य के खिलाफ सत्यापित होने से पहले 'v1Location' ऑब्जेक्ट का उपयोग किया गया था। जाँच लाइनें: 333, 335. SarifVersionOneToCurrentVisitor.cs 333

 internal Location CreateLocation(LocationVersionOne v1Location) { .... string key = v1Location.LogicalLocationKey ?? v1Location.FullyQualifiedLogicalName; if (v1Location != null) { .... } .... } 

कोड के लेखक ने सुझाव दिया कि v1Location लिंक शून्य हो सकता है, इसलिए उसने उचित चेक जोड़ा। उसी समय, कोड में थोड़ा अधिक है, किसी कारण से यह बिना किसी चेक के इस लिंक के साथ काम करता है। रिफैक्टरिंग करते समय असावधानी? कहना कठिन है।

V3125 [CWE-476] 'v1StackFrame' ऑब्जेक्ट का उपयोग नल के खिलाफ सत्यापित होने के बाद किया गया था। चेक लाइनें: 1182, 1171। SarifVersionOneToCurrentVisitor.cs 1182

 internal StackFrame CreateStackFrame(StackFrameVersionOne v1StackFrame) { StackFrame stackFrame = null; if (v1StackFrame != null) { stackFrame = new StackFrame { .... }; } stackFrame.Location = CreateLocation(v1StackFrame.FullyQualifiedLogicalName, v1StackFrame.LogicalLocationKey, ....); return stackFrame; } 

परंपरागत रूप से, विपरीत सच है। सबसे पहले, v1StackFrame लिंक को अशक्त करने के लिए जाँच की जाती है, और फिर वे जांचना भूल गए। लेकिन एक महत्वपूर्ण चेतावनी है: v1StackFrame और stackFrame चर तार्किक रूप से संबंधित हैं। देखें, यदि v1StackFrame = null है , तो StackFrame ऑब्जेक्ट नहीं बनाया जाएगा, और stackFrame = null रहेगा। इस मामले में, प्रोग्राम स्टैकफ्रेम.लोकेशन के लिए कॉल पर पड़ेगा , क्योंकि यहां कोई चेक नहीं हैं। यही है, v1StackFrame का खतरनाक उपयोग, जिसे विश्लेषक ने इंगित किया, वह भी बिंदु तक नहीं पहुंचेगा। यह कोड केवल तभी काम करता है जब गैर-शून्य v1StackFrame मान CreateStackFrame विधि को पास किया जाता है । मुझे संदेह था कि यह कॉलिंग कोड में किसी तरह नियंत्रित किया गया था। CreateStackFrame कॉल इस तरह दिखती हैं:

 Frames = v1Stack.Frames?.Select(CreateStackFrame).ToList() 

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

निष्कर्ष

लेख छोटा हो गया, लेकिन किसी के पास ऊबने का समय नहीं था :) मैं आपको याद दिलाता हूं कि आप हमेशा अपने या अन्य लोगों की परियोजनाओं में त्रुटियों की खोज करने के लिए हमारे विश्लेषक को डाउनलोड कर सकते हैं।

और अंत में, एक छोटी सी घोषणा: मेरा अगला लेख 2019 में सी # परियोजनाओं में मुझे और मेरे सहयोगियों को मिली सबसे दिलचस्प त्रुटियों के बारे में होगा। हमारे ब्लॉग को फॉलो करें। जल्द मिलते हैं!

नए ब्लॉग पोस्ट के बारे में जानने के लिए, आप निम्नलिखित चैनलों की सदस्यता ले सकते हैं:

• ट्विटर: @pvsstudio_rus
• VK.com: PVS-Studio विश्लेषक
• टेलीग्राम: @pvsstudio_rus
• इंस्टाग्राम: pvsstudio_rus
• अच्छा पुराना RSS: viva64-blog-en

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: सर्गेई ख्रेनोव। SARIF SDK और इसके त्रुटियां ।