सार्वजनिक फ़ॉर्म सबमिशन को निजी नेटवर्क में कैसे आयात करें

जो सार्वजनिक फ़ॉर्म निजी नेटवर्क से कभी बात नहीं करता, वह भी ऐसा डेटा बनाता है जिस पर निजी नेटवर्क को निर्णय लेना होता है। टनल केवल यह बदलती है कि कौन किससे संपर्क करता है। डाउनलोड के बाद का हर कदम आयात निर्णय है, और वह निजी पक्ष का है। यह विवरण एक सबमिशन को ब्राउज़र से स्थायी आंतरिक रिकॉर्ड तक ट्रैक करता है।

वहीं से शुरू करें जहाँ सबमिशन पहुँचता है

ब्राउज़र एक सार्वजनिक एंडपॉइंट पर पोस्ट करता है, जो नियंत्रित इनटेक स्टोर में एक पंक्ति लिखता है और स्वीकृति से अधिक कुछ नहीं लौटाता। वही स्टोर हैंडओवर बिंदु है, और सार्वजनिक परत जहाँ लिख सके वह केवल वही होना चाहिए। कच्चा पेलोड वहाँ अपरिवर्तित रखें, उसके आने के समय और स्थिर रिकॉर्ड पहचानकर्ता के साथ।

फिर एक निजी वर्कर टनल से लंबित पंक्तियाँ खींचता है और तय करता है कि हर एक के साथ क्या करना है। यह अपनी पहचान के अंतर्गत चलता है, और वही अगले खंड का विषय है।

curl --silent --fail \
  --cert /etc/importer/client.crt --key /etc/importer/client.key \
  "https://intake.corp.internal/api/pending?limit=20" \
  -o /var/lib/importer/pending.json

इम्पोर्टर को केवल वही अधिकार दें जिसकी उसे आवश्यकता है

सार्वजनिक वेब प्रक्रिया और आंतरिक एप्लिकेशन में लिखने वाली पहचान दो अलग प्रिंसिपल होने चाहिए। सार्वजनिक सर्वर को केवल इसलिए आंतरिक प्रशासन की आवश्यकता नहीं होती कि उसे फ़ॉर्म डेटा पहुँचाना है, और दोनों पक्षों के लिए एक साझा खाता किसी भी वेब बग को आंतरिक लेखन में बदल देता है। वर्कर को उसका अपना क्रेडेंशियल जारी करें, उसे उस एक आयात ऑपरेशन तक सीमित रखें, और दर्ज करें कि किस प्रिंसिपल ने कौन-सा आयात किया। यही पृथक्करण टनल की सीमा को सजावट नहीं बल्कि अर्थपूर्ण बनाता है।

यह भी सीमित करें कि वर्कर किस स्रोत से पढ़ सकता है। यदि कार्यान्वयन किसी कतार या स्थानांतरण सेवा का उपयोग करता है, तो वह सेवा अपना प्रमाणीकरण और प्रवेश नीति रखती है, क्योंकि VPN पेलोड के भीतर कुछ भी प्रमाणित नहीं करता।

अल्पकालिक फ़ंक्शन भी उसी समीक्षा से मुक्त नहीं है। जब तक वह चलता है, उसकी नेटवर्क स्थिति और उसके क्रेडेंशियल अधिकार देते हैं, और छोटा जीवनकाल केवल खिड़की को सँकरा करता है। जीवनकाल यह तय करने का विकल्प नहीं है कि पहचान कौन-से ऑपरेशन कर सकती है।

आंतरिक रूप से कुछ बदलने से पहले मान्य करें

सार्वजनिक फ़ॉर्म के फ़ील्ड तब तक हमलावर के नियंत्रण वाला पाठ हैं जब तक विपरीत सिद्ध न हो, और OWASP के इनपुट सत्यापन दिशानिर्देश ठीक इसी कारण बैकएंड फ़ीड को अविश्वसनीय स्रोतों में गिनते हैं। एन्क्रिप्टेड स्थानांतरण यह कहता है कि बाइट्स सुरक्षित पहुँचे, यह नहीं कि वे अनुमत अनुरोध का वर्णन करते हैं। किसी भी विशेषाधिकार प्राप्त कदम से पहले पार्स और सत्यापन करें, ताकि खराब पंक्ति कभी ऐसे कोड पथ तक न पहुँचे जो कार्य कर सके।

अनुमत फ़ील्ड, उनके प्रारूप, उनके आकार और वे व्यावसायिक नियम परिभाषित करें जिनका पालन होना चाहिए। कोई तिथि सही प्रारूप में हो सकती है और फिर भी अनुरोधित ऑपरेशन के लिए गलत हो सकती है, और आंतरिक खाते या स्वीकृति स्थिति का नाम लेने वाला पेलोड स्वयं को इनमें से कोई भी नहीं दे सकना चाहिए।

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

एक ही ऑपरेशन पर पुनः प्रयास बिंदु बनाएँ

यदि submission-1042 रिकॉर्ड दो बार खींचा जाता है क्योंकि पहली स्वीकृति खो गई, तो वर्कर को स्रोत रिकॉर्ड और उसके स्थायी परिणाम को पहचानने का टिकाऊ तरीका चाहिए। जो शेड्यूल कार्य को एक बार चलाता है वह यह सिद्ध नहीं करता कि हर पंक्ति एक बार लागू हुई। दोहरा वितरण सामान्य है, इसलिए डिज़ाइन को उसे समाहित करना होगा।

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

फिर इसे तीन परीक्षण फ़ाइलों से सिद्ध करें: एक मान्य पंक्ति, एक विकृत पंक्ति, और वही नियंत्रित स्रोत पहचानकर्ता दो बार वितरित। हर एक उसी एंडपॉइंट से गुज़रता है जिसका वर्कर उपयोग करता है।

for f in fixtures/valid-submission.json fixtures/bad-date.json; do
  curl --silent --fail --cert /etc/importer/client.crt \
    -X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
  -X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records

पहली दो पंक्तियों को भिन्न आंतरिक स्थितियों में समाप्त होना चाहिए, और तीसरी को उस स्रोत रिकॉर्ड के लिए पहले से स्थायी पहचानकर्ता लौटाना चाहिए, न कि दूसरा बनाना। इसके अतिरिक्त कुछ भी अर्थ है कि आयात अभी दोहराने योग्य नहीं है।