د لټون انجنونه د منځپانګې د شاخص لپاره جوړ شوي وو. په هرصورت، برید کونکي ستاسو د غلطیو د شاخص کولو لپاره کاروي. پوښتنه allintextlogin د دوتنې ډول: لاګ ممکن بې ضرره ښکاري. په حقیقت کې، دا د افشا شوي لاګ فایلونو موندلو لپاره یو له ساده لارو څخه دی چې د تصدیق جریان، اسناد، ټوکنونه، او داخلي زیربنا ډیټا لري.
که ګوګل دا لاګونه لیدلی شي، برید کوونکي هم کولی شي. یوځل چې انډیکس شي، افشا کول ناگزیر کیږي. سربیره پردې، کله چې اسناد په عامه توګه د لاسرسي وړ فایل کې څرګند شي، سرغړونه دمخه په حرکت کې ده.
۱. ولې allintext:login د فایل ډول: لاګ د لیدلو په پرتله ډیر خطرناک دی
د ګوګل ډارک یوه د لټون پوښتنه ده چې د لټون انجنونو لخوا ترتیب شوي حساس یا غلط ترتیب شوي مینځپانګې موندلو لپاره پرمختللي آپریټرونه کاروي. دا ګوګل نه کاروي. پرځای یې، دا ستاسو د افشا کولو څخه ګټه پورته کوي.
دا پوښتنه دوه آپریټرونه سره یوځای کوي:
- allintext هغه پاڼې بیرته راګرځوي چیرې چې ټول اصطلاحات په متن کې ښکاري
- د دوتنې ډول: لاګ پایلې محدودوي تر
.logدوتنې
له همدې کبله:
مطلب: "هغه لاګ فایلونه راته وښایاست چې دا کلمه لري login. "
په لومړي نظر کې، دا کوچنی ښکاري. په هرصورت، په عمل کې، دا ډیری وختونه بیرته راځي:
- په عامه توګه ښکاره شوي ویب سرور لاګونه
- CI/CD لاګونه د هنري اثارو په توګه پورته شوي
- په ناڅاپي ډول د لاګونو ډیبګ کول commitزیرمو ته لیږل شوی
- د غوښتنلیک لاګونه د ساده متن اسنادو سره
دا د لټون انجن تېروتنه نه ده. پرځای یې، دا یو د معلوماتو د افشا کیدو زیانمنتیا د غلط ترتیب له امله رامنځته شوی. ګوګل په ساده ډول هغه څه لیست کړل چې په عامه توګه د لاسرسي وړ وو.
۲. هغه څه چې بریدګر په حقیقت کې په افشا شوي لاګ فایلونو کې موندلي دي
کله چې بریدګر منډه وهي allintextlogin د دوتنې ډول: لاګ، دوی په ناڅاپي ډول لټون نه کوي. دوی د تصدیق نښې لټوي.
۲.۱ ساده اسناد
په لوګونو کې ډیری وختونه داسې لیکنې شاملې وي لکه:
or
یا حتی د SMTP اسناد:
د لاګ کولو تصدیق کولو پایلوډونه د تولید اسنادو د لیکولو لپاره یو له ګړندۍ لارو څخه دی. په پایله کې، یو واحد افشا شوی لاګ فایل کولی شي ستاسو د لاسرسي کنټرول ټول ماډل باطل کړي.
۲.۲ د ناستې نښې او JWTs
حتی کله چې پاسورډونه ثبت شوي نه وي، ټوکنونه اکثرا ثبت شوي وي.
د مثال په توګه:
د JWT یا سیشن کوکی دننه یو معتبر .log فایل کولی شي فعال کړي:
- ناسته اغوا کول
- د استحقاق زیاتوالی
- په داخلي سیسټمونو کې اړخیز حرکت
په بل عبارت، په لاګونو کې ټوکنونه د ډیبګ کولو محصول د تصدیق بای پاس ویکتور ته اړوي.
2.3 CI/CD آثار
د لرګیو جوړول په ځانګړي ډول خطرناک دي. په حقیقت کې، CI/CD سیسټمونه ډیری وخت د جوړونې مرحلو په جریان کې د چاپیریال متغیرات چاپوي.
برید کوونکي ډیری وختونه کشف کوي:
په کې داسې کرښې شاملې دي:
If CI/CD اثار عامه دي، بیا رازونه عامه دي. د ګوګل ډارک په ساده ډول کشف ګړندی کوي.
۲.۴ د کلاوډ او زیربنا معلومات
ښکاره شوي لاګونه ډیری وختونه څرګندوي:
- د AWS لاسرسي کیلي
- د Azure ذخیره کولو اتصال تارونه
- د داخلي خدماتو URLونه
- د ډیټابیس اسناد
- د ریډیس پای ټکي
حتی که اسناد وروسته بدل شي، بریدګر اوس لري:
- د زیربناوو نقشه کول
- د نوم ورکولو کنوانسیونونه
- د راتلونکو بریدونو لپاره استخباراتي معلومات په نښه کړئ
له همدې امله، ښکاره لرګي لاسرسی او کشف دواړه چمتو کوي.
۳. دا لاګونه څنګه په لومړي ځای کې عامه کیږي
لاګونه په جادويي ډول په ګوګل کې نه ښکاري. دوی په انډیکس شوي دي ځکه چې دوی په عامه توګه د لاسرسي وړ وو.
۳.۱ ناسم تنظیم شوي ویب سرورونه
عام نمونې عبارت دي له:
/logs/د تصدیق پرته د لاسرسي وړ لارښودونه- د ډایرکټرۍ لیست فعال شو
- نګینکس یا اپاچي خام خدمت کوي
.logدوتنې
که چیرې یو لاګ د HTTP له لارې د لاسرسي وړ وي، نو دا د شاخص وړ دی.
3.2 CI/CD د هنري اثارو افشا کول
عادي تېروتنې:
- عامه اثار فعال شوي دي د ګیټ هب عملونه
- د S3 بالټونو د خلاصولو لپاره لوګونه اپلوډ شوي
- Pipeline نښې پرته له تصدیق څخه د لاسرسي وړ دي
A pipeline هغه چې لرګي په عامه بالټ کې ساتي په مؤثره توګه خپل رازونه خپروي.
۳.۳ په تولید کې د ډیبګ حالت
د چوکاټ ډیفالټ خطرناک کیدی شي:
برسیره پردې، د ډیرې غوښتنې ثبت کول ممکن چاپ شي:
- د سرکي
- ټوکن
- د بشپړې غوښتنې ادارې
په تولید کې د ډیبګ لاګنګ ستاسو غوښتنلیک په یو اعتباري صادرونکي بدلوي.
۳.۴ د ډاکر او کانټینر لاګونه
کانټینر شوي چاپیریالونه د افشا کیدو نوې لارې معرفي کوي:
- لاګونه په شریکو حجمونو کې نصب شوي
- سایډکارونه ناامنه پای نقطو ته لاګونه صادروي
- ننوتل dashboardد عامه لاسرسي سره
که چیرې د کانټینر لاګونه د HTTP یا خلاص ذخیره له لارې ښکاره شي، نو دوی د لټون وړ دي. په پای کې، دوی په انډیکس کې شامل کیږي.
۴. د برید حقیقي جریان: له ډارک څخه تر سرغړونې پورې
د برید یوه عادي لړۍ داسې ښکاري:
بریدګر منډې وهي:
- افشا شوي موندنې
.logد دوتنې - استخراج:
- د JWT نښه
- د اساسي تصدیق سرلیک
- د ډیټابیس د پیوستون تار
د دې په وړاندې د تصدیق هڅه کوي:
- د API پای ټکي
- د ادارې پینلونه
- داخلي خدمات
که چیرې تصدیق بریالی شي، بریدګر کولی شي:
- امتیازات زیات کړئ
- اړخ ته حرکت وکړئ
- ته لاسرسی CI/CD
- د اکمالاتو لړۍ سره جوړجاړی وکړئ
هغه څه چې د لټون پوښتنې په توګه پیل شول:
- ناسته اغوا کول
- د داخلي اسنادو ډکول
- Pipeline واک اخیستل
- د هنري اثارو مسمومیت
ټول د عامه لیست شوي لاګ فایل څخه.
۵. ولې "ډیر" ننوتل د AppSec ستونزه ده
د لرګیو پرې کول بې طرفه نه دي. پرځای یې، دا یو رامینځته کوي د ثانوي معلوماتو ذخیره.
که تاسو حساس معلومات ثبت کړئ، تاسو په مؤثره توګه د خپلو رازونو دوهم کاپي جوړوئ.
په هرصورت، لاګونه ډیری وختونه د ګواښ ماډلینګ څخه ایستل کیږي. د STRIDE لاندې، دا په روښانه توګه نقشه کوي:
د معلوماتو افشا کول
له همدې امله، خوندي SDLC کړنې باید د لاګونو سره داسې چلند وکړي:
- د امنیت اړوند اثار
- حساسې شتمنۍ
- د زیربناوو برخې چې ساتنې ته اړتیا لري
که ستاسو د ګواښ ماډل لاګونه له پامه غورځوي، نو دا نیمګړی دی.
۶. څنګه په لاګ فایلونو کې د اسنادو لیکیدو مخه ونیسو
۶.۱ د رازونو د ثبتولو مخه ونیسئ
هیڅکله ننوتل مه کوئ:
- شفرونه
- ټوکن
- د API کلیدونه
- د ناستې IDs
- د اجازې سرلیکونه
حتی په ډیبګ حالت کې.
هرکله چې امکان ولري، اتوماتیک اصلاح پلي کړئ.
۶.۲ جوړ شوی او خوندي لرګین کول
د ماسک کولو او فلټر کولو سره د جوړښت شوي ننوتلو څخه کار واخلئ.
بېلګه (Node.js):
بېلګه (پایتون):
اصلي اصل ساده دی: رازونه باید هیڅکله د لرګیو ډنډ ته ونه رسیږي.
۶.۳ د لاګ ذخیره بندول
امنیتي کنټرولونه باید شامل وي:
- د لارښود لیست غیر فعال کړئ
- ساتنه
/logs/د تصدیق سره لارې - د بالټ لاسرسی محدود کړئ
- د ساتلو پالیسۍ پلي کړئ
- په آرامۍ کې لاګونه کوډ کړئ
لاګونه باید هیڅکله د HTTP له لارې په عامه توګه د لاسرسي وړ نه وي.
6.4 CI/CD Guardrails
لاسي بیاکتنې کافي ندي. پرځای یې، اتومات کنټرولونه پلي کړئ:
- د هنري اثارو له خپرولو دمخه د لرګیو پټ سکین کول
- که ټوکنونه وموندل شي نو ناکامي رامینځته کیږي
- د اسنادو لرونکي هنري اثارو اپلوډونو مخه ونیسئ
- د هنري اثارو لپاره د هش تایید
CI/CD د انډیکس کولو دمخه باید د افشا کیدو مخه ونیسي.
۷. څنګه ژیګیني د allintext مخه نیسي:login د دوتنې ډول: log پیښې
ستونزه د ګوګل ډارک نه ده. ستونزه د افشا کولو ده. له همدې امله، مخنیوی باید د انډیکس کولو دمخه ترسره شي.
۷.۱ په لوګو او هنري اثارو کې پټ کشف
د زیګیني سکینونه:
- د غوښتنلیک لاګونه
- CI/CD د کار نښې
- هنري اثار جوړ کړئ
- د ډاکر پرتونه
- سریال شوي محصولات
که چیرې اسناد، ټوکنونه، یا حساس ارزښتونه په کې څرګند شي .log فایلونه، ژیګیني سمدلاسه یې په نښه کوي.
7.2 CI/CD Guardrails دا د افشا کیدو مخه نیسي
د دې پر ځای چې په لاسي بیاکتنو تکیه وکړئ، ژیګیني په کې امنیت ټینګوي pipeline کچه:
دا:
- کله چې رازونه په لوګونو کې څرګند شي نو جوړونه ناکامه کیږي
- د بلاکونو هنري اثارو خپرونه
- د ناڅاپي عامه افشا کیدو مخه نیسي
- اصلي ته د رسیدو دمخه ناامنه ادغامونه ودروي
که چیرې د CI دنده یو نښه چاپ کړي، نو pipeline ناکامي.
هیڅ شاخص نشته.
هیڅ افشا کول نشته.
کومه پېښه نه ده.
۷.۳ د ګوګل له لیدلو مخکې د شفټ-کیڼ اړخ ساتنه
وخت مهم دی.
د غبرګون ښودلو پر ځای:
ژیګیني دا مسله ودروي:
- At commit وخت
- په اوږدو کې pull request د اعتبار
- په اوږدو کې pipeline اعدام
- د هنري اثارو له خپرېدو مخکې
که چیرې لاګ هیڅکله عامه نشي، ګوګل هیڅکله یې انډیکس نه کوي.
وروستۍ پایله: که ګوګل کولی شي دا شاخص کړي، بریدګرو دمخه دا کار کړی دی
لاګونه بې ضرره نه دي. په حقیقت کې، دوی په ندرت سره لنډمهاله دي. په ډیفالټ ډول، دوی شخصي ندي. له همدې امله، د هر لاګ فایل باید د امنیت پورې اړوند شتمنۍ په توګه چلند وشي، نه یوازې د محصول ډیبګ کول.
که حساس معلومات a ته ورسیږي .log فایل شي او په عامه توګه د لاسرسي وړ شي، دا سمدلاسه د برید سطحې ته بدلیږي. سربېره پردې، کله چې د لټون انجن لخوا انډیکس شي، نو افشا کول ستاسو له کنټرول څخه بهر کیږي.
حل دا نه دی چې د ثبت بندول وشي. بلکې دا ده چې په مسؤلیت سره ثبت شي او د ذخیره کولو او توزیع شاوخوا سخت کنټرولونه پلي شي. په بل عبارت، امنیت باید د غوښتنلیک څخه هاخوا او د مشاهدې طبقې ته وغځول شي.
پرځای یې:
- د رازونو ثبتول بند کړئ
- د لرګیو ذخیره بنده کړئ
- نافذول pipeline guardrails
- اتومات کشف او د پالیسۍ پلي کول
په پای کې, مخنیوی د وخت په اړه دی. ځکه چې یو ځل allintextlogin د دوتنې ډول: لاګ ستاسو ډومین بیرته راولي، پیښه لا دمخه پیل شوې ده.
