Swift अनुप्रयोग सुरक्षा: व्यवहार में शीर्ष 10 कमजोरियाँ

Swift अनुप्रयोग सुरक्षा: व्यवहार में शीर्ष 10 कमजोरियाँ

iOS और macOS के लिए मोबाइल एप्लिकेशन विकसित करने में सुरक्षा पर विशेष ध्यान देने की आवश्यकता होती है। Swift एक शक्तिशाली और आधुनिक भाषा है, लेकिन यह भी डेवलपर को सामान्य गलतियों से नहीं बचाती जो डेटा लीक, हैक या वित्तीय नुकसान का कारण बन सकती हैं। इस लेख में, हम वास्तविक कोड उदाहरणों और उन्हें ठीक करने के व्यावहारिक सुझावों के साथ Swift अनुप्रयोगों की शीर्ष 10 कमजोरियों पर चर्चा करेंगे।

1. Core Data और SQLite के माध्यम से SQL इंजेक्शन

कई डेवलपर SQLite के साथ कच्चे SQL क्वेरी का उपयोग करते हैं। यदि उपयोगकर्ता से डेटा को एस्केप नहीं किया जाता है, तो हमलावर डेटाबेस में मनमानी क्वेरी निष्पादित कर सकता है।

// ❌ कमजोर कोड\nlet query = "SELECT * FROM users WHERE name = '\\(userInput)'"\n\n// ✅ सुरक्षित कोड (पैरामीटराइज़्ड क्वेरी का उपयोग)\nlet query = "SELECT * FROM users WHERE name = ?"\nvar statement: OpaquePointer?\nsqlite3_prepare_v2(database, query, -1, &statement, nil)\nsqlite3_bind_text(statement, 1, (userInput as NSString).utf8String, -1, nil)\n

पैरामीटराइज़्ड क्वेरी या प्रेडिकेट के साथ Core Data का उपयोग करें - यह इंजेक्शन को समाप्त करता है।

2. Keychain में असुरक्षित डेटा भंडारण

Keychain एक सुरक्षित स्थान है, लेकिन कई डेवलपर एक्सेस विशेषताओं को गलत तरीके से कॉन्फ़िगर करते हैं। उदाहरण के लिए, यदि kSecAttrAccessible निर्दिष्ट नहीं किया गया है, तो बैकअप के बाद डेटा एक्सेस किया जा सकता है।

// ❌ कमजोर कोड (बैकअप के बाद एक्सेस योग्य)\nlet query: [String: Any] = [\n    kSecClass as String: kSecClassGenericPassword,\n    kSecAttrAccount as String: "token",\n    kSecValueData as String: tokenData\n]\n\n// ✅ सुरक्षित कोड (केवल जब डिवाइस अनलॉक हो)\nlet query: [String: Any] = [\n    kSecClass as String: kSecClassGenericPassword,\n    kSecAttrAccount as String: "token",\n    kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly,\n    kSecValueData as String: tokenData\n]\n

3. SSL/TLS जाँच का अभाव (Man-in-the-Middle)

विकास के दौरान, परीक्षण के लिए प्रमाणपत्र जाँच अक्सर बंद कर दी जाती है, लेकिन रिलीज़ में सेटिंग्स वापस लाना भूल जाते हैं। यह हमलावर को ट्रैफ़िक को इंटरसेप्ट करने की अनुमति देता है।

// ❌ कमजोर कोड (प्रोडक्शन के लिए खतरनाक)\nlet session = URLSession(configuration: .default, delegate: self, delegateQueue: nil)\n// डेलीगेट में:\nfunc urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {\n    completionHandler(.useCredential, URLCredential(trust: challenge.protectionSpace.serverTrust!))\n}\n\n// ✅ सुरक्षित कोड — मानक जाँच का उपयोग करें\nlet session = URLSession.shared\n// या Info.plist में ATS (App Transport Security) का उपयोग करें\n

App Transport Security (ATS) चालू करें और इसे रिलीज़ बिल्ड में बंद न करें।

4. लॉग और Crashlytics के माध्यम से डेटा लीक

डेवलपर अक्सर डिबगिंग के लिए संवेदनशील डेटा (टोकन, पासवर्ड) लॉग करते हैं। यदि लॉग किसी तृतीय-पक्ष सेवा (जैसे Firebase Crashlytics) में चला जाता है, तो डेटा लीक हो जाता है।

// ❌ कमजोर कोड\nprint("User token: \\(userToken)")\n\n// ✅ सुरक्षित कोड\n#if DEBUG\n    print("User token: [REDACTED]")\n#endif\n// या गोपनीयता स्तर के साथ os_log का उपयोग करें\nos_log("User token: %{private}@", log: .default, type: .debug, userToken)\n

प्रोडक्शन में कभी भी संवेदनशील डेटा लॉग न करें। मास्किंग या सशर्त संकलन का उपयोग करें।

5. कोड में असुरक्षित रहस्य भंडारण

API कुंजी, टोकन और पासवर्ड को सीधे स्रोत कोड में संग्रहीत करना एक गंभीर गलती है। भले ही कोड अस्पष्ट हो, बाइनरी फ़ाइल से स्ट्रिंग आसानी से निकाली जा सकती हैं।

// ❌ कमजोर कोड\nlet apiKey = "sk-1234567890abcdef"\n\n// ✅ सुरक्षित कोड — सर्वर प्रमाणीकरण का उपयोग करें\n// या CryptoKit के साथ कुंजियों को एन्क्रिप्ट करें\nimport CryptoKit\nlet key = SymmetricKey(data: "server_