खोज इन्जिनहरू सामग्री अनुक्रमणिका गर्न बनाइएका थिए। यद्यपि, आक्रमणकारीहरूले तपाईंको गल्तीहरू अनुक्रमणिका गर्न तिनीहरूलाई प्रयोग गर्छन्। क्वेरी allintext:login फाइल प्रकार: लग हानिरहित देखिन सक्छ। वास्तवमा, यो प्रमाणीकरण प्रवाह, प्रमाणहरू, टोकनहरू, र आन्तरिक पूर्वाधार डेटा समावेश गर्ने खुला लग फाइलहरू पत्ता लगाउने सबैभन्दा सरल तरिकाहरू मध्ये एक हो।
यदि गुगलले ती लगहरू देख्न सक्छ भने, आक्रमणकारीहरूले पनि देख्न सक्छन्। एक पटक अनुक्रमित भएपछि, एक्सपोजर अपरिहार्य हुन्छ। यसबाहेक, जब प्रमाणपत्रहरू सार्वजनिक रूपमा पहुँचयोग्य फाइलमा देखा पर्दछ, उल्लंघन पहिले नै गतिमा छ।
१. किन allintext:login फाइल प्रकार: लग यो देखिनु भन्दा बढी खतरनाक छ
गुगल डर्क भनेको एउटा खोज क्वेरी हो जसले खोज इन्जिनहरूद्वारा अनुक्रमित संवेदनशील वा गलत कन्फिगर गरिएको सामग्री पत्ता लगाउन उन्नत अपरेटरहरू प्रयोग गर्दछ। यसले गुगलको शोषण गर्दैन। बरु, यसले तपाईंको एक्सपोजरको शोषण गर्दछ।
यो क्वेरीले दुई अपरेटरहरूलाई संयोजन गर्दछ:
- allintext: मुख्य पाठमा सबै शब्दहरू देखा पर्ने पृष्ठहरू फर्काउँछ।
- फाइल प्रकार: लग परिणामहरूलाई सीमित गर्दछ
.logफाइलहरू
यसैले:
allintext:login filetype:log
अर्थ: “मलाई शब्द समावेश गर्ने लग फाइलहरू देखाउनुहोस्। login। "
पहिलो नजरमा, त्यो तुच्छ देखिन्छ। यद्यपि, व्यवहारमा, यो प्रायः फर्काउँछ:
- सार्वजनिक रूपमा खुलासा गरिएका वेब सर्भर लगहरू
- CI/CD लगहरू कलाकृतिको रूपमा अपलोड गरियो
- गल्तिले लगहरू डिबग गर्नुहोस् commitभण्डारहरूमा पठाइयो
- प्लेनटेक्स्ट क्रेडेन्सियलहरू सहितको एप्लिकेसन लगहरू
यो खोज इन्जिन बग होइन। बरु, यो एक डेटा एक्सपोजर भेद्यता गलत कन्फिगरेसनका कारण। गुगलले सार्वजनिक रूपमा पहुँचयोग्य कुराहरू मात्र अनुक्रमित गर्यो।
२. आक्रमणकारीहरूले खुला लग फाइलहरूमा वास्तवमा के फेला पार्छन्
आक्रमणकारीहरू भाग्दा allintext:login फाइल प्रकार: लग, तिनीहरू जथाभावी ब्राउज गरिरहेका छैनन्। तिनीहरू प्रमाणीकरण ट्रेसहरू खोजिरहेका छन्।
२.१ सादा पाठ प्रमाणहरू
लगहरूमा प्रायः निम्न जस्ता प्रविष्टिहरू हुन्छन्:
POST /login username=admin password=SuperSecret123
or
Authorization: Basic YWRtaW46cGFzc3dvcmQ=
वा SMTP प्रमाणपत्रहरू पनि:
smtp_user=mailer
smtp_pass=ProdMailPass!
लगिङ प्रमाणीकरण पेलोडहरू उत्पादन प्रमाणहरू चुहावट गर्ने सबैभन्दा छिटो तरिकाहरू मध्ये एक हो। फलस्वरूप, एउटा खुला लग फाइलले तपाईंको सम्पूर्ण पहुँच नियन्त्रण मोडेललाई अमान्य गर्न सक्छ।
२.२ सत्र टोकन र JWT हरू
पासवर्डहरू लग नगरिएको बेला पनि, टोकनहरू प्रायः लग हुन्छन्।
जस्तै:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Set-Cookie: session=abc123xyz789;
Generated API token: sk_live_ABC123SECRET
भित्र रहेको मान्य JWT वा सत्र कुकी .log फाइल सक्षम गर्न सक्छ:
- सत्र अपहरण
- विशेषाधिकार वृद्धि
- आन्तरिक प्रणालीहरूमा पार्श्व चाल
अर्को शब्दमा, लगहरूमा भएका टोकनहरूले डिबगिङ आउटपुटलाई प्रमाणीकरण बाइपास भेक्टरमा परिणत गर्छन्।
2.3 CI/CD कलाकृतिहरू
निर्माण लगहरू विशेष गरी खतरनाक हुन्छन्। वास्तवमा, CI/CD प्रणालीहरूले प्रायः निर्माण चरणहरूको क्रममा वातावरण चरहरू छाप्छन्।
आक्रमणकारीहरूले प्रायः पत्ता लगाउँछन्:
निम्न जस्ता रेखाहरू समावेश गर्दै:
AWS_ACCESS_KEY_ID=AKIA...
DATABASE_URL=postgres://admin:password@internal-db:5432/app
If CI/CD कलाकृतिहरू सार्वजनिक हुन्छन्, त्यसपछि गोप्य कुराहरू सार्वजनिक हुन्छन्। गुगल डर्कले खोजलाई तीव्र बनाउँछ।
२.४ क्लाउड र पूर्वाधार डेटा
खुला लगहरूले प्रायः प्रकट गर्दछ:
- AWS पहुँच कुञ्जीहरू
- Azure भण्डारण जडान स्ट्रिङहरू
- आन्तरिक सेवा URL हरू
- डाटाबेस प्रमाणहरू
- रेडिस एन्डपोइन्टहरू
यदि प्रमाणहरू पछि घुमाइए पनि, आक्रमणकारीसँग अब निम्न कुराहरू हुन्छन्:
- पूर्वाधार नक्साङ्कन
- नामकरण परम्पराहरू
- भविष्यका आक्रमणहरूको लागि लक्षित गुप्तचर
त्यसकारण, खुला लगहरूले पहुँच र जासूसी दुवै प्रदान गर्दछ।
३. यी लगहरू पहिलो स्थानमा कसरी सार्वजनिक हुन्छन्
लगहरू गुगलमा जादुई रूपमा देखा पर्दैनन्। तिनीहरू सार्वजनिक रूपमा पहुँचयोग्य भएकाले अनुक्रमित हुन्छन्।
३.१ गलत कन्फिगर गरिएका वेब सर्भरहरू
सामान्य ढाँचाहरूमा समावेश छन्:
/logs/प्रमाणीकरण बिना पहुँचयोग्य निर्देशिकाहरू- निर्देशिका सूचीकरण सक्षम पारियो
- Nginx वा Apache ले कच्चा सेवा दिइरहेको छ
.logफाइलहरू
यदि लग HTTP मार्फत पहुँचयोग्य छ भने, यो अनुक्रमणिका योग्य हुन्छ।
3.2 CI/CD कलाकृति एक्सपोजर
सामान्य गल्तीहरू:
- सार्वजनिक कलाकृतिहरू सक्षम पारियो GitHub कार्यहरू
- S3 बकेटहरू खोल्न लगहरू अपलोड गरियो
- Pipeline प्रमाणीकरण बिना पहुँचयोग्य ट्रेसहरू
A pipeline जसले सार्वजनिक बाल्टिनमा लगहरू भण्डारण गर्छ, प्रभावकारी रूपमा आफ्ना गोप्य कुराहरू प्रकाशित गर्छ।
३.३ उत्पादनमा डिबग मोड
फ्रेमवर्क पूर्वनिर्धारितहरू खतरनाक हुन सक्छन्:
APP_DEBUG=true
थप रूपमा, अत्यधिक अनुरोध लगिङले प्रिन्ट गर्न सक्छ:
- हेडरहरू
- टोकन
- पूर्ण अनुरोध निकायहरू
उत्पादनमा डिबग लगिङले तपाईंको अनुप्रयोगलाई प्रमाणपत्र निर्यातकर्तामा रूपान्तरण गर्दछ।
३.४ डकर र कन्टेनर लगहरू
कन्टेनराइज्ड वातावरणले नयाँ एक्सपोजर मार्गहरू परिचय गराउँछ:
- साझा भोल्युमहरूमा लगहरू माउन्ट गरियो
- असुरक्षित अन्त्य बिन्दुहरूमा लगहरू निर्यात गर्ने साइडकारहरू
- लग dashboardसार्वजनिक पहुँच भएको
यदि कन्टेनर लगहरू HTTP वा खुला भण्डारण मार्फत खुलासा गरियो भने, तिनीहरू खोजीयोग्य हुन्छन्। अन्ततः, तिनीहरू अनुक्रमित हुन्छन्।
४. यथार्थपरक आक्रमण प्रवाह: डर्कदेखि ब्रीचसम्म
एउटा सामान्य आक्रमण श्रृंखला यस्तो देखिन्छ:
आक्रमणकारी दौडन्छ:
allintext:login filetype:log
- खुलासा गरिएका खोजहरू
.logफाइल - अर्कहरू:
- JWT टोकन
- आधारभूत प्रमाणीकरण हेडर
- डाटाबेस जडान स्ट्रिङ
निम्न विरुद्ध प्रमाणीकरण प्रयास गर्दछ:
- API अन्त्यबिन्दुहरू
- व्यवस्थापक प्यानलहरू
- आन्तरिक सेवाहरू
यदि प्रमाणीकरण सफल भयो भने, आक्रमणकारीले निम्न गर्न सक्छ:
- विशेषाधिकारहरू बढाउनुहोस्
- पार्श्वतिर सर्नुहोस्
- पहुँच CI/CD
- आपूर्ति शृङ्खलामा सम्झौता गर्नुहोस्
खोज क्वेरीको रूपमा सुरु भएको कुरा यस्तो हुन्छ:
- सत्र अपहरण
- आन्तरिक प्रमाणपत्र भर्ने
- Pipeline टेकओभर
- कलाकृति विषाक्तता
सबै सार्वजनिक रूपमा अनुक्रमित लग फाइलबाट।
५. किन "धेरै" लगिङ एक AppSec समस्या हो?
लगिङ तटस्थ हुँदैन। बरु, यसले एउटा सिर्जना गर्छ माध्यमिक डेटा भण्डार.
यदि तपाईंले संवेदनशील डेटा लग गर्नुभयो भने, तपाईंले प्रभावकारी रूपमा आफ्नो गोप्य कुराहरूको दोस्रो प्रतिलिपि सिर्जना गर्नुहुन्छ।
यद्यपि, लगहरूलाई प्रायः खतरा मोडेलिङबाट बहिष्कृत गरिन्छ। STRIDE अन्तर्गत, यसले स्पष्ट रूपमा निम्न कुराहरूलाई नक्सा गर्छ:
जानकारी खुलासा
त्यसैले, सुरक्षित SDLC अभ्यासहरूले लगहरूलाई यसरी व्यवहार गर्नुपर्छ:
- सुरक्षा-सम्बन्धित कलाकृतिहरू
- संवेदनशील सम्पत्तिहरू
- सुरक्षा आवश्यक पर्ने पूर्वाधारका घटकहरू
यदि तपाईंको खतरा मोडेलले लगहरूलाई बेवास्ता गर्छ भने, यो अपूर्ण हुन्छ।
६. लग फाइलहरूमा प्रमाणपत्र चुहावट कसरी रोक्ने
६.१ लगिङ गोप्य कुराहरू रोक्नुहोस्
कहिल्यै लग नगर्नुहोस्:
- पासवर्ड
- टोकन
- एपीआई कुञ्जीहरू
- सत्र आईडीहरू
- प्राधिकरण हेडरहरू
डिबग मोडमा पनि।
सम्भव भएसम्म, स्वचालित सम्पादन लागू गर्नुहोस्।
६.२ संरचित र सुरक्षित लगिङ
मास्किङ र फिल्टरिङको साथ संरचित लगिङ प्रयोग गर्नुहोस्।
उदाहरण (नोड.जेएस):
const logger = require('pino')({
redact: ['req.headers.authorization', 'body.password']
});
उदाहरण (पाइथन):
class RedactFilter(logging.Filter):
def filter(self, record):
record.msg = record.msg.replace("password=", "password=***")
return True
मुख्य सिद्धान्त सरल छ: रहस्यहरू कहिल्यै पनि काठको भाँडोमा पुग्नु हुँदैन।
६.३ लग भण्डारण लक डाउन गर्नुहोस्
सुरक्षा नियन्त्रणहरूमा समावेश हुनुपर्छ:
- निर्देशिका सूची असक्षम पार्नुहोस्
- सुरक्षित
/logs/प्रमाणीकरण भएका मार्गहरू - बकेट पहुँच प्रतिबन्धित गर्नुहोस्
- अवधारण नीतिहरू लागू गर्नुहोस्
- बाँकी रहेका लगहरू इन्क्रिप्ट गर्नुहोस्
लगहरू कहिल्यै पनि HTTP मार्फत सार्वजनिक रूपमा पहुँचयोग्य हुनु हुँदैन।
6.4 CI/CD Guardrails
म्यानुअल समीक्षा अपर्याप्त छन्। बरु, स्वचालित नियन्त्रणहरू लागू गर्नुहोस्:
- कलाकृति प्रकाशन अघि लगहरूको गोप्य स्क्यानिङ
- टोकनहरू पत्ता लागेमा निर्माण असफल हुन्छ
- प्रमाणपत्रहरू समावेश गर्ने कलाकृति अपलोडहरू रोक्नुहोस्
- कलाकृतिहरूको लागि ह्यास प्रमाणीकरण
CI/CD अनुक्रमणिका हुनुभन्दा पहिले एक्सपोजरलाई रोक लगाउनु पर्छ।
७. Xygeni ले allintext लाई कसरी रोक्छ:login फाइल प्रकार: लग घटनाहरू
समस्या गुगल डर्क होइन। समस्या एक्सपोजर हो। त्यसैले, अनुक्रमणिका गर्नु अघि रोकथाम हुनुपर्छ।
७.१ लग र कलाकृतिहरूमा गोप्य पत्ता लगाउने
जाइजेनी स्क्यान:
- अनुप्रयोग लगहरू
- CI/CD जागिरका निशानहरू
- कलाकृतिहरू निर्माण गर्नुहोस्
- डकर तहहरू
- क्रमबद्ध आउटपुटहरू
यदि प्रमाणपत्र, टोकन, वा संवेदनशील मानहरू देखा पर्छन् भने .log फाइलहरू, Xygeni ले तुरुन्तै तिनीहरूलाई फ्ल्याग गर्छ।
7.2 CI/CD Guardrails त्यो ब्लक एक्सपोजर
म्यानुअल समीक्षामा भर पर्नुको सट्टा, Xygeni ले सुरक्षा व्यवस्था लागू गर्छ pipeline स्तर:
dotnet xygeni enforce --rules secrets,artifacts,logs --fail-on-risk
यो:
- लगहरूमा गोप्य कुराहरू देखा पर्दा निर्माण असफल हुन्छ
- ब्लक कलाकृति प्रकाशन
- आकस्मिक सार्वजनिक एक्सपोजरलाई रोक्छ
- मुख्यमा पुग्नु अघि असुरक्षित मर्जहरू रोक्छ
यदि CI कामले टोकन छाप्छ भने, pipeline असफल हुन्छ।
कुनै अनुक्रमणिका छैन।
कुनै एक्सपोजर छैन।
कुनै घटना छैन।
७.३ गुगलले हेर्नु अघि नै सिफ्ट-बायाँ सुरक्षा
समय महत्त्वपूर्ण छ।
प्रतिक्रिया जनाउनुको सट्टा:
allintext:login filetype:log
Xygeni ले मुद्दा रोक्छ:
- At commit समय
- समयमा pull request प्रमाणीकरण
- समयमा pipeline निष्पादन
- कलाकृति प्रकाशन अघि
यदि लग कहिल्यै सार्वजनिक भएन भने, गुगलले यसलाई कहिल्यै अनुक्रमणिका गर्दैन।
अन्तिम निष्कर्ष: यदि गुगलले यसलाई अनुक्रमणिका गर्न सक्छ भने, आक्रमणकारीहरूले पहिले नै गरिसकेका छन्
लगहरू हानिरहित छैनन्। वास्तवमा, तिनीहरू विरलै अस्थायी हुन्छन्। पूर्वनिर्धारित रूपमा, तिनीहरू निजी हुँदैनन्। त्यसकारण, प्रत्येक लग फाइललाई सुरक्षा-सान्दर्भिक सम्पत्तिको रूपमा व्यवहार गरिनु पर्छ, केवल डिबगिङ आउटपुटको रूपमा मात्र होइन।
यदि संवेदनशील डेटा a मा पुग्छ भने .log फाइल गर्छ र सार्वजनिक रूपमा पहुँचयोग्य हुन्छ, यो तुरुन्तै आक्रमणको सतहमा परिणत हुन्छ। यसबाहेक, एक पटक खोज इन्जिनद्वारा अनुक्रमित भएपछि, एक्सपोजर तपाईंको नियन्त्रणभन्दा बाहिर जान्छ।
समाधान लगिङ रोक्नु होइन। बरु, यो जिम्मेवारीपूर्वक लगिङ गर्नु र भण्डारण र वितरण वरिपरि कडा नियन्त्रणहरू लागू गर्नु हो। अर्को शब्दमा, सुरक्षा अनुप्रयोगभन्दा बाहिर र अवलोकनयोग्यता तहमा विस्तार हुनुपर्छ।
सट्टा:
- गोप्य कुराहरू रेकर्ड गर्न बन्द गर्नुहोस्
- लग भण्डारण लक गर्नुहोस्
- बल मा pipeline guardrails
- स्वचालित पहिचान र नीति कार्यान्वयन
अन्ततः, रोकथाम समयको बारेमा हो। किनभने एक पटक allintext:login फाइल प्रकार: लग तपाईंको डोमेन फिर्ता गर्छ भने, घटना पहिले नै सुरु भइसकेको छ।
