हेडर्स के रूप में बैग
HTTP लॉगिंग फ्रेमवर्क्स किसी अनुरोध के हेडर्स को एक बैग ऑफ की-वैल्यू पेयर्स के रूप में मानते हैं। लॉगिंग API पूरे बैग को उजागर करता है। ऑपरेटर्स हेडर लॉगिंग को डीबगिंग के लिए सक्षम करते हैं: जब एक अनुरोध विफल होता है, तो हेडर्स की कहानी बताते हैं। निर्मित डेन्यूइस्ट नहीं। क्रेडेंशियल फिल्टरिंग दस्तावेज़ में नहीं। पूरे हेडर्स डिस्क पर।
सामान्य अनुरोध में क्रेडेंशियल हेडर्स:
- Authorization: Bearer eyJhbGciOiJIUzI1NiJ9... (JWT या OAuth टोकन)
- Cookie: session=abc123; auth=xyz789
- X-API-Key: sk-live-abc123...
- X-Auth-Token: ghp_abc123... (GitHub व्यक्तिगत एक्सेस टोकन पैटर्न)
इन मानों के साथ अनुरोध को प्रमाणित किया जाता है। लॉग फ़ाइल में लिखने के बाद, वे किसी भी अनुरोध को प्रमाणित करते हैं।
क्रेडेंशियल पाइपलाइन
क्रेडेंशियल को लॉग फ़ाइल में लिखा जाता है, वह एक स्थान पर नहीं रहता। वह यात्रा करता है:
1. वेब सर्वर लिखता है /var/log/nginx/access.log
2. लॉग रोटेशन एजेंट (logrotate) कॉपी करता है /var/log/nginx/access.log.1
3. लॉग शिपर (Fluentd, Filebeat, Logstash) पढ़ता है और शिप करता है एकाग्रितकर्त्री को
4. लॉग एकाग्रितकर्त्री (Elasticsearch, Splunk, Datadog) इंडेक्स करती है और स्टोर करती है
5. 30-90 दिनों के लिए मानक नीति के तहत संरक्षित किया जाता है
क्रेडेंशियल पांच स्थानों पर एक साथ मौजूद होता है। सत्र टोकन को रद्द करने से लॉग एकाग्रितकर्त्री में क्रेडेंशियल को हटा नहीं जाता है। यह पूरी संरक्षित खिड़की के लिए खोजे, निर्यात और किसी को भी लॉग एक्सेस दिया जाता है, जो लॉग एकाग्रितकर्त्री में पहुंचता है।
खुलासा खिड़की
मेमोरी में क्रेडेंशियल की खुलासा खिड़की: max(session दुर्लभता, प्रक्रिया जीवनकाल)। सत्र: घंटों से दिनों तक। प्रक्रिया: घंटों से हफ्तों तक।
लॉग में क्रेडेंशियल की खुलासा खिड़की: max(session दुर्लभता, लॉग संरक्षित)। सत्र: घंटों से दिनों तक। संरक्षित: 30-90 दिन।
मेमोरी से चुराए गए क्रेडेंशियल की आवश्यकता थ कि हमलावर सत्र खिड़की के दौरान मौजूद हो। लॉग से चुराए गए क्रेडेंशियल की आवश्यकता होती है केवल लॉग एकाग्रितकर्त्री तक पहुंच, पूर्ववर्ती रूप से, पूरी संरक्षित अवधि के लिए।
MOAD-0003 vs MOAD-0004
MOAD-0003 (Leaked Context): एक क्रेडेंशियल मेमोरी में होता है और गलत अनुरोध हैंडलर को लीक करता है। इसे केवल प्रक्रिया खिड़की के दौरान उपलब्ध होता है, थ्रेड पूल के माध्यम से। स्थायी।
MOAD-0004 (Logged Secret): एक डिस्क पर क्रेडेंशियल लॉग रोटेशन, लॉग शिपिंग और लॉग एग्रीगेशन के माध्यम से स्थायी रहता है। प्रतिक्रियात्मक रूप से, 30-90 दिनों के लिए किसी को भी लॉग एक्सेस मिल सकता है। स्थायी।
संरचनात्मक अंतर: अस्थायी vs स्थायी। सुधार एक अलग स्तर पर काम करता है।
अस्थायी vs स्थायी
अस्थायी/स्थायी अंतर संभावित जोखिम की सतह, सुधार के स्तर और घटना प्रतिक्रिया आवश्यकताओं को निर्धारित करता है।
सीरियलाइजेशन स्तर पर क्रेडेंशियल निषेधसूची
सुधार: सीरियलाइजेशन स्तर पर क्रेडेंशियल निषेधसूची। किसी भी हेडर वैल्यू को लॉग आउटपुट तक पहुंचने से पहले हेडर नाम को निषेधसूची के खिलाफ जांचें। मान [REDACTED] के साथ मान को बदलें।
CREDENTIAL_HEADERS = {
'authorization',
'cookie',
'x-api-key',
'x-auth-token',
'x-csrf-token',
'proxy-authorization',
}
def sanitize_headers(headers: dict) -> dict:
return {
k: '[REDACTED]' if k.lower() in CREDENTIAL_HEADERS else v
for k, v in headers.items()
}निषेध सूची सीरियलाइजेशन स्तर पर होनी चाहिए, नहीं कि लॉग क्वेरी स्तर पर। लॉग क्वेरी गोपनीयता: क्रेडेंशियल डिस्क पर पहुंचने के बाद लागू होती है; निर्जल वैल्यू अभी भी मौजूद है, बस प्रदर्शन से छुपा हुआ। सीरियलाइजेशन स्तर की गोपनीयता: क्रेडेंशियल कभी डिस्क पर नहीं पहुंचता। लॉग फ़ाइल, लॉग शिपर, या लॉग एसोसिएटर में वैल्यू कभी प्रवेश नहीं करती।
निषेध सूची का परीक्षण
तीन परीक्षण पैटर्न:
- सकारात्मक: Authorization: Bearer token123 वाली एक अनुरोध प्राप्त करता है जो Authorization: [REDACTED] वाली लॉग एंट्री प्राप्त करता है
- नकारात्मक: Content-Type: application/json वाला अनुरोध लॉग एंट्री के साथ मूल्य को निर्बाध करता है
- केस-इनसेंसिटिव: AUTHORIZATION: Bearer token123 भी [REDACTED] प्राप्त करता है (HTTP हेडर नाम केस-इनसेंसिटिव हैं)
निषेध सूची की आवश्यकता होती है: नई क्रेडेंशियल हेडर पैटर्न (उदाहरण के लिए, कस्टम X-Service-Auth हेडर) के लिए विशेषतया जोड़ने की आवश्यकता होती है। ठेका संरचनात्मक है, लेकिन स्वयं-संभाल नहीं करता है।
निषेध सूची का लागू करें
एक टीम अपने Nginx एक्सेस लॉग फ़ॉर्मेट को निर्माण के लिए सभी अनुरोध हेडर्स को शामिल करने के लिए सेट करती है। निर्माण:
log_format debug_format '$remote_addr - $request - $http_authorization - $http_cookie';
access_log /var/log/nginx/debug.log debug_format;वे निर्माण की घटना को हल करते हैं और डिबगिंग कॉन्फ़िगरेशन को हटलेने का इरादा करते हैं, लेकिन परिवर्तन प्रोडक्शन में पहुंचने से पहले अगले डिप्लॉयमेंट साइकिल (7 दिन बाद) तक पहुंचता है।