FlawOpen

flawopen.com/असुरक्षित डीसिरियलाइज़ेशन/TypeNameHandling

Newtonsoft.Json TypeNameHandling: अविश्वसनीय JSON के लिए सुरक्षित सेटिंग

CWE-502: Deserialization of Untrusted Dataसंदर्भ पृष्ठ
संक्षिप्त उत्तर

JSON डेटा बताता है; .NET प्रकार आपका कोड चुनता है। TypeNameHandling चालू होने पर $type डीसिरियलाइज़ेशन में प्रकार-निर्धारण प्रभावित कर सकता है। अविश्वसनीय इनपुट के लिए None रखें। बहुरूपता चाहिए तो सख्त ISerializationBinder से प्रकार जाँचें या कोड में घोषित सीमित discriminator mapping अपनाएँ।

कमज़ोर
var settings = new JsonSerializerSettings {
    // Any non-None mode needs a strict binder
    TypeNameHandling = TypeNameHandling.Auto,
    // No binder: input $type can resolve CLR types
};

var value = JsonConvert.DeserializeObject<Base>(
    untrustedJson, settings);
सुधारा गया
// Safest default for untrusted JSON
var settings = new JsonSerializerSettings {
    TypeNameHandling = TypeNameHandling.None,
};

// For polymorphism, dispatch over a closed set:
var token = JObject.Parse(json);
Base value = token["kind"]?.ToString() switch {
    "circle" => token.ToObject<Circle>(),
    "square" => token.ToObject<Square>(),
    _ => throw new JsonException("Unknown kind"),
};

// System.Text.Json also supports opt-in derived
// types through [JsonDerivedType] (.NET 7+).

डेवलपर TypeNameHandling क्यों चालू करते हैं

आम कारण बहुरूपी डेटा है: Shape collection को Circle या Square के रूप में सुरक्षित रखना पड़ सकता है। Json.NET $type से प्रकार नाम पढ़ और लिख सकता है। अविश्वसनीय इनपुट में ये metadata runtime type को प्रभावित कर सकते हैं; जोखिम अनुमत प्रकारों और व्यवहार पर निर्भर है। खतरनाक शृंखला के लिए side effect वाला पहुँच योग्य प्रकार चाहिए; केवल JSON पर्याप्त नहीं।

विश्वास-सीमा उलटी रखें: कोड सत्यापित discriminator के सीमित समूह से subtype चुनता है। System.Text.Json, [JsonDerivedType] जैसे attributes से opt-in बहुरूपता देता है; JSON के मनमाने CLR नाम सक्रिय नहीं करता। संबंधित सीमा के लिए BinaryFormatter मार्गदर्शन देखें।

क्या कस्टम ISerializationBinder पर्याप्त है?

बाहरी डेटा के लिए TypeNameHandling यदि None नहीं है तो सख्त ISerializationBinder आवश्यक है। केवल कुछ सटीक, ऐप-स्वामित्व वाले नामों को अनुमति दें और बाकी अस्वीकार करें। प्रकार, converters, constructors, setters और callbacks जाँचें। binder प्रकार-निर्धारण सीमित करता है, मनमाने प्रकार सुरक्षित नहीं बनाता। संभव हो तो None और स्पष्ट चयन अपनाएँ।

अक्सर पूछे जाने वाले प्रश्न

क्या TypeNameHandling.Auto अविश्वसनीय JSON के लिए सुरक्षित है?

अपने आप में नहीं। Auto डीसिरियलाइज़ेशन में $type पढ़ सकता है। TypeNameHandling.None या केवल समीक्षित प्रकारों को अनुमति देने वाला सख्त binder उपयोग करें।

क्या System.Text.Json सुरक्षित बहुरूपता देता है?

हाँ, opt-in तरीके से: discriminator और derived types कोड में घोषित होते हैं, जैसे .NET 7+ का [JsonDerivedType]। प्रकार समूह ऐप कोड सीमित करता है।

.NET ऐप का audit कैसे करें?

पूरे solution में TypeNameHandling, SerializationBinder और JsonConvert.DeserializeObject खोजें। ASP.NET startup और साझा settings जाँचें, बाहरी JSON के रास्ते trace करें और हर non-None path पर सख्त binder की पुष्टि करें।

संदर्भ

यह भी देखें असुरक्षित Deserialization: जोखिम और बचाव | flawopen.com PHP unserialize() और अविश्वसनीय इनपुट Python pickle.load(): अविश्वसनीय डेटा का जोखिम क्या Ruby YAML.load सुरक्षित है? Psych संस्करण और safe_load .NET BinaryFormatter: जोखिम और माइग्रेशन Java ObjectInputStream सुरक्षा: डीसिरियलाइज़ेशन जोखिम घटाएँ