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 शून्य है , तो StackFrame ऑब्जेक्ट नहीं बनाया जाएगा, जबकि stackFrame सुस्त रहेगा । स्टैकफ्रेम.लोकेशन की एक कॉल के कारण प्रोग्राम क्रैश द्वारा पीछा किया गया, क्योंकि यहां कोई चेक नहीं हैं। तो यह खतरनाक v1StackFrame उपयोग के लिए भी नहीं आएगा, जो विश्लेषक द्वारा इंगित किया गया है। यह कोड केवल तभी काम करता है जब आप Nonnull v1StackFrame मान CreateStackFrame विधि से पास करते हैं। मुझे शक था कि कॉलर कोड किसी तरह इसे नियंत्रित करता है। CreateStackFrame इस तरह से कॉल करता है:

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

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

निष्कर्ष

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

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

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

• ट्विटर: @ कोड_अनलिसिस
• Fb: @StaticCodeAnalyzer
• टेलीग्राम: pvsstudio_en
• इंस्टाग्राम: pvs-studio
• अच्छा पुराना RSS: viva64-blog-en