Review Old Backup and Unreferenced Files for Sensitive Information (fa-IR)

مرور فایل های پشتیبان قدیمی و بدون مرجع برای اطلاعات حساس (فارسی)

خلاصه

در حالی که بیشتر فایل‌های داخل یک وب سرور مستقیماً توسط خود سرور مدیریت می‌شوند، یافتن فایل‌های ارجاع‌نشده یا فراموش‌شده‌ای که می‌توان از آنها برای به دست آوردن اطلاعات مهم در مورد زیرساخت یا اعتبارنامه‌ها استفاده کرد، غیرمعمول نیست.

رایج‌ترین سناریوها شامل وجود نسخه‌های قدیمی تغییر نام‌داده‌شده از فایل‌های اصلاح‌شده، فایل‌های گنجانده‌شده که به زبان انتخابی بارگیری می‌شوند و می‌توانند به عنوان منبع دانلود شوند، یا حتی پشتیبان‌گیری خودکار یا دستی در قالب بایگانی‌های فشرده است. فایل‌های پشتیبان را می‌توان به‌طور خودکار توسط سیستم فایلی که برنامه روی آن میزبانی می‌شود، تولید کرد، ویژگی که معمولاً به آن "عکس‌های فوری (snapshots)" می‌گویند.

همه این فایل‌ها ممکن است به آزمایش‌کننده اجازه دسترسی به کارهای داخلی، درهای پشتی، رابط‌های اداری، یا حتی اعتبار برای اتصال به رابط اداری یا سرور پایگاه داده را بدهند.

یک منبع مهم آسیب‌پذیری در فایل‌هایی نهفته است که هیچ ارتباطی با برنامه ندارند، اما در نتیجه ویرایش فایل‌های برنامه، یا پس از ایجاد نسخه‌های پشتیبان در جریان، یا با گذاشتن فایل‌های قدیمی یا بدون مرجع در درخت وب ایجاد می‌شوند. انجام ویرایش در محل یا سایر اقدامات مدیریتی بر روی سرورهای وب تولیدی ممکن است به طور ناخواسته نسخه‌های پشتیبان را برجای بگذارد، یا به‌طور خودکار توسط ویرایشگر هنگام ویرایش فایل‌ها یا توسط مدیری که مجموعه‌ای از فایل‌ها را فشرده می‌کند تا یک نسخه پشتیبان ایجاد کند، ایجاد می‌شود.

به راحتی می توان چنین فایل هایی را فراموش کرد و این ممکن است یک تهدید امنیتی جدی برای برنامه باشد. این اتفاق می‌افتد زیرا ممکن است نسخه‌های پشتیبان با پسوندهای فایل متفاوت از فایل‌های اصلی تولید شوند. یک بایگانی tar. یا zip. و یا gz. که ما تولید می کنیم (و فراموش می کنیم...) بدیهی است که پسوند متفاوتی دارد، و همین امر در مورد کپی های خودکار ایجاد شده توسط بسیاری از ویرایشگرها اتفاق می افتد (به عنوان مثال، emacs هنگام ویرایش file، یک نسخه پشتیبان بنام ~file ایجاد می کند). کپی کردن با دست ممکن است همان اثر را ایجاد کند (به کپی کردن file در file.old فکر کنید). سیستم فایل زیربنایی که برنامه روی آن قرار دارد می‌تواند بدون اطلاع شما در مقاطع مختلف زمانی از برنامه شما snapshots (عکس‌های فوری) تهیه کند، که ممکن است از طریق وب نیز قابل دسترسی باشد، که تهدیدی مشابه اما متفاوت با سبک backup file (فایل پشتیبان) برای برنامه شما ایجاد می‌کند.

در نتیجه، این فعالیت‌ها فایل‌هایی تولید می‌کنند که مورد نیاز برنامه نیستند و ممکن است متفاوت از فایل اصلی توسط وب سرور مدیریت شوند. برای مثال، اگر یک کپی از login.asp بنام login.asp.old ایجاد کنیم، به کاربران اجازه می‌دهیم کد منبع login.asp را دانلود کنند. این به این دلیل است که login.asp.old معمولاً به‌عنوان متن یا ساده ارائه می‌شود، نه اینکه به دلیل پسوند آن اجرا شود. به عبارت دیگر، دسترسی login.asp باعث اجرای کد سمت سرور login.asp می شود، در حالی که دسترسی login.asp.old باعث می شود محتوای login.asp.old (که دوباره کد سمت سرور است) به طور واضح به کاربر بازگردانده شود و در مرورگر نمایش داده شود. این ممکن است خطرات امنیتی ایجاد کند، زیرا ممکن است اطلاعات حساس فاش شود.

به طور کلی، افشای کد سمت سرور ایده بدی است. نه تنها منطق کسب و کار را به طور غیر ضروری افشا می کنید، بلکه ممکن است ناآگاهانه اطلاعات مربوط به برنامه را که ممکن است به مهاجم کمک کند (نام مسیرها، ساختارهای داده و غیره) فاش کنید. ناگفته نماند که اسکریپت های بسیار زیادی با نام کاربری و رمز عبور تعبیه شده در متن واضح وجود دارد (که یک عمل بی دقت و بسیار خطرناک است).

دلایل دیگر فایل‌های ارجاع‌نشده به دلیل انتخاب‌های طراحی یا پیکربندی است که اجازه می‌دهند انواع فایل‌های مرتبط با برنامه مانند فایل‌های داده، فایل‌های پیکربندی، فایل‌های گزارش، در فهرست‌های سیستم فایل ذخیره شوند که توسط وب سرور قابل دسترسی است. این فایل‌ها معمولاً دلیلی برای قرار گرفتن در یک فضای فایل سیستمی ندارند که می‌توان از طریق وب به آن‌ها دسترسی پیدا کرد، زیرا باید فقط در سطح برنامه، توسط خود برنامه (و نه توسط کاربر معمولی در حال مرور اطراف) به آنها دسترسی داشت.

تهدیدها (Threats)

فایل‌های قدیمی، پشتیبان‌گیری و بدون مرجع، تهدیدات مختلفی را برای امنیت یک برنامه وب ایجاد می‌کنند:

• فایل‌های بدون مرجع (unreferenced files) ممکن است اطلاعات حساسی را فاش کنند که می‌تواند حمله متمرکز علیه برنامه را تسهیل کند. برای مثال شامل فایل‌های حاوی اعتبار پایگاه داده، فایل‌های پیکربندی حاوی ارجاع به سایر محتوای پنهان، مسیرهای فایل مطلق و غیره باشد.
• صفحات بدون مرجع (unreferenced pages) ممکن است دارای عملکرد قدرتمندی باشند که می تواند برای حمله به برنامه استفاده شود. به عنوان مثال یک صفحه مدیریت که از محتوای منتشر شده پیوند داده نشده است، اما هر کاربری که می داند کجا آن را پیدا کند می تواند به آن دسترسی داشته باشد.
• فایل‌های قدیمی و پشتیبان ممکن است حاوی آسیب‌پذیری‌هایی باشند که در نسخه‌های اخیر برطرف شده‌اند. برای مثال viewdoc.old.jsp ممکن است حاوی یک آسیب‌پذیری پیمایش دایرکتوری (directory traversal vulnerability) باشد که در viewdoc.jsp رفع شده است، اما همچنان می‌تواند توسط هرکسی که نسخه قدیمی را پیدا کند مورد سوء استفاده قرار گیرد.
• فایل های پشتیبان ممکن است کد منبع صفحات طراحی شده برای اجرا در سرور را فاش کنند. برای مثال درخواست viewdoc.bak ممکن است کد منبع برای viewdoc.jsp را بازگرداند، که می‌توان آن را برای آسیب‌پذیری‌هایی که ممکن است با درخواست‌های کور به صفحه اجرایی یافتن آنها دشوار باشد، بررسی کرد. در حالی که این تهدید به وضوح در مورد زبان های اسکریپت شده مانند Perl، PHP، ASP، shell scripts، JSP و غیره اعمال می شود، همانطور که در مثال ارائه شده در گلوله بعدی نشان داده شده است، به آنها محدود نمی شود.
• آرشیوهای پشتیبان ممکن است حاوی کپی هایی از تمام فایل های داخل (یا حتی خارج) وبروت باشند. این به مهاجم اجازه می دهد تا به سرعت کل برنامه، از جمله صفحات بدون ارجاع، کد منبع، شامل فایل ها و غیره را برشمرد. به عنوان مثال، اگر فایلی به نام myservlets.jar.old فایل حاوی (کپی پشتیبان) کلاس های پیاده سازی servlet خود را فراموش کنید، موارد زیادی را در معرض نمایش قرار داده اید. اطلاعات حساسی که مستعد کامپایل کردن و مهندسی معکوس هستند.
• در برخی موارد کپی کردن یا ویرایش یک فایل پسوند فایل را تغییر نمی دهد، اما نام فایل را تغییر می دهد. این اتفاق برای مثال در محیط‌های ویندوز رخ می‌دهد، جایی که عملیات کپی کردن فایل، نام فایل‌هایی را با پیشوند "Copy of" یا نسخه‌های محلی این رشته تولید می‌کند. از آنجایی که پسوند فایل بدون تغییر باقی مانده است، این موردی نیست که یک فایل اجرایی به عنوان متن ساده توسط وب سرور برگردانده شود، و بنابراین موردی برای افشای کد منبع نیست. با این حال، این فایل‌ها نیز خطرناک هستند، زیرا این احتمال وجود دارد که دارای منطق منسوخ و نادرست باشند که در صورت فراخوانی، خطاهای برنامه را ایجاد کند، که در صورت فعال بودن نمایش پیام تشخیصی، ممکن است اطلاعات ارزشمندی را به مهاجم ارائه دهد.
• فایل‌های گزارش ممکن است حاوی اطلاعات حساسی درباره فعالیت‌های کاربران برنامه باشد، برای مثال داده‌های حساس ارسال شده در پارامترهای URL، شناسه‌های جلسه، نشانی‌های اینترنتی بازدید شده (که ممکن است محتوای غیر ارجاع‌نشده اضافی را فاش کند)، و غیره. سایر فایل‌های گزارش (مانند گزارش‌های ftp) ممکن است حاوی اطلاعات حساس در مورد نگهداری برنامه توسط مدیران سیستم باشند.
• عکس‌های فوری سیستم فایل (file system snapshots) ممکن است حاوی کپی‌هایی از کدهایی باشد که حاوی آسیب‌پذیری‌هایی هستند که در نسخه‌های اخیر برطرف شده‌اند. به عنوان مثال snapshot/monthly.1/view.php./ ممکن است حاوی یک آسیب‌پذیری پیمایش دایرکتوری باشد که در view.php/ رفع شده است، اما همچنان می‌تواند توسط هر کسی که نسخه قدیمی را پیدا می‌کند مورد سوء استفاده قرار گیرد.

اهداف آزمایش

• فایل های بدون مرجعی که ممکن است حاوی اطلاعات حساس باشند را پیدا و تجزیه و تحلیل کنید.

چگونه آزمایش کنیم

آزمایش جعبه سیاه (Black-Box Testing)

آزمایش فایل‌های بدون مرجع از هر دو تکنیک خودکار و دستی استفاده می‌کند و معمولاً ترکیبی از موارد زیر را شامل می‌شود:

استنتاج از طرح نامگذاری مورد استفاده برای محتوای منتشر شده (Inference from the Naming Scheme Used for Published Content)

تمام صفحات و عملکرد برنامه را برشمارید. این کار را می توان به صورت دستی با استفاده از یک مرورگر یا با استفاده از ابزار spidering برنامه انجام داد. اکثر برنامه‌ها از یک طرح نام‌گذاری قابل تشخیص استفاده می‌کنند و منابع را با استفاده از کلماتی که عملکرد آن‌ها را توصیف می‌کنند در صفحات و دایرکتوری‌ها سازماندهی می‌کنند. از طرح نامگذاری مورد استفاده برای محتوای منتشر شده، اغلب می توان نام و مکان صفحات بدون مرجع را استنباط کرد. به عنوان مثال، اگر یک صفحه viewuser.asp پیدا شد، سپس به دنبال edituser.asp، adduser.asp و deleteuser.asp نیز بگردید. اگر دایرکتوری app/user/ پیدا شد، به دنبال app/admin/ و app/manager/ نیز بگردید.

سایر سرنخ ها در محتوای منتشر شده (Other Clues in Published Content)

بسیاری از برنامه های وب سرنخ هایی را در محتوای منتشر شده به جا می گذارند که می تواند منجر به کشف صفحات مخفی و عملکرد شود. این سرنخ ها اغلب در کد منبع فایل های HTML و جاوا اسکریپت ظاهر می شوند. کد منبع برای تمام محتوای منتشر شده باید به صورت دستی بررسی شود تا سرنخ هایی در مورد سایر صفحات و عملکرد شناسایی شود. مثلا:

نظرات برنامه نویسان و بخش های نظر داده شده کد منبع ممکن است به محتوای پنهان اشاره داشته باشد:

<!-- <A HREF="uploadfile.jsp">Upload a document to the server</A> -->
<!-- Link removed while bugs in uploadfile.jsp are fixed          -->

جاوا اسکریپت ممکن است حاوی پیوندهای صفحه ای باشد که در شرایط خاص فقط در رابط کاربری گرافیکی کاربر ارائه می شوند:

var adminUser=false;
if (adminUser) menu.add (new menuItem ("Maintain users", "/admin/useradmin.jsp"));

صفحات HTML ممکن است حاوی فرم هایی باشند که با غیرفعال کردن عنصر SUBMIT پنهان شده اند:

<form action="forgotPassword.jsp" method="post">
    <input type="hidden" name="userID" value="123">
    <!-- <input type="submit" value="Forgot Password"> -->
</form>

منبع دیگر سرنخ ها در مورد دایرکتوری های بدون مرجع، فایل robots.txt/ است که برای ارائه دستورالعمل ها به ربات های وب استفاده می شود:

User-agent: *
Disallow: /Admin
Disallow: /uploads
Disallow: /backup
Disallow: /~jbloggs
Disallow: /include

حدس زدن کور (Blind Guessing)

در ساده‌ترین شکل، این شامل اجرای فهرستی از نام‌های فایل رایج از طریق موتور درخواست در تلاش برای حدس زدن فایل‌ها و دایرکتوری‌های موجود در سرور است. اسکریپت wrapper netcat زیر فهرست کلماتی را از stdin می خواند و یک حمله حدس اولیه را انجام می دهد:

#!/bin/bash

server=example.org
port=80

while read url
do
echo -ne "$url\t"
echo -e "GET /$url HTTP/1.0\nHost: $server\n" | netcat $server $port | head -1
done | tee outputfile

بسته به سرور، GET ممکن است با HEAD برای نتایج سریعتر جایگزین شود. فایل خروجی مشخص شده را می توان برای کدهای پاسخ "جالب (interesting)" گره زد. کد پاسخ 200 (OK) معمولاً نشان می دهد که یک منبع معتبر پیدا شده است (به شرطی که سرور یک صفحه سفارشی "یافت نشد (not found)" را با استفاده از کد 200 ارائه ندهد). اما همچنین به 301 (انتقال داده شده (Moved))، 302 (پیدا شده (Found))، 401 (غیر مجاز (Unauthorized))، 403 (ممنوع (Forbidden)) و 500 (خطای داخلی (Internal error)) توجه کنید، که ممکن است نشان دهنده منابع یا دایرکتوری هایی باشد که ارزش بررسی بیشتر را دارند.

حمله اولیه حدس زدن باید در برابر webroot و همچنین علیه تمام دایرکتوری هایی که از طریق تکنیک های دیگر شمارش شناسایی شده اند اجرا شود. حملات حدس زدن پیشرفته/موثرتر را می توان به صورت زیر انجام داد:

• پسوندهای فایل مورد استفاده در مناطق شناخته شده برنامه (مثلا jsp، aspx، html) را شناسایی کنید و از یک لیست اصلی کلمات اضافه شده به هر یک از این پسوندها استفاده کنید (یا اگر منابع اجازه می‌دهند از فهرست طولانی‌تری از پسوندهای رایج استفاده کنید).
• برای هر فایلی که از طریق تکنیک‌های دیگر شمارش شناسایی می‌شود، یک فهرست کلمات سفارشی مشتق شده از آن نام فایل ایجاد کنید. فهرستی از پسوندهای رایج فایل (از جمله ~، bak ،txt ،src ،dev ،old ،inc ،orig ،copy ،tmp ،swp و غیره) را دریافت کنید و از هر پسوند قبل، بعد و به جای پسوند نام فایل واقعی استفاده کنید.

توجه: عملیات کپی فایل‌های ویندوز نام فایل‌هایی را با پیشوند "Copy of" یا نسخه‌های بومی‌سازی شده این رشته تولید می‌کنند، بنابراین پسوند فایل را تغییر نمی‌دهند. در حالی که فایل‌های "Copy of" معمولاً هنگام دسترسی کد منبع را فاش نمی‌کنند، ممکن است در صورت ایجاد خطا در هنگام فراخوانی، اطلاعات ارزشمندی به دست آورند.

اطلاعات از طریق آسیب پذیری های سرور و پیکربندی نادرست به دست آمده است (Information Obtained Through Server Vulnerabilities and Misconfiguration)

واضح ترین روشی که یک سرور پیکربندی نادرست ممکن است صفحات بدون ارجاع را فاش کند، فهرست کردن دایرکتوری است. از همه دایرکتوری های برشمرده شده درخواست کنید تا هر دایرکتوری را که فهرست دایرکتوری ارائه می دهند شناسایی کنند.

آسیب‌پذیری‌های متعددی در وب سرورهای فردی یافت شده است که به مهاجم اجازه می‌دهد محتوای بدون مرجع را برشمرد، به عنوان مثال:

• آسیب پذیری فهرست دایرکتوری آپاچی ?M=D.
• آسیب پذیری های مختلف افشای منبع اسکریپت IIS.
• فهرست آسیب پذیری های IIS WebDAV.

استفاده از اطلاعات در دسترس عموم (Use of Publicly Available Information)

صفحات و عملکرد در برنامه‌های وب رو به اینترنت که از داخل خود برنامه ارجاع داده نمی‌شوند، ممکن است از سایر منابع عمومی ارجاع داده شوند. منابع مختلفی برای این مراجع وجود دارد:

• صفحاتی که قبلاً به آنها ارجاع داده می شد ممکن است همچنان در آرشیو موتورهای جستجوی اینترنتی ظاهر شوند. به عنوان مثال، 1998results.asp ممکن است دیگر از وب سایت یک شرکت پیوند داده نشود، اما ممکن است در سرور و پایگاه داده های موتورهای جستجو باقی بماند. این اسکریپت قدیمی ممکن است حاوی آسیب‌پذیری‌هایی باشد که می‌تواند برای به خطر انداختن کل سایت مورد استفاده قرار گیرد. اپراتور جستجوی گوگل :site ممکن است برای اجرای یک پرس و جو فقط در برابر دامنه انتخابی استفاده شود، مانند در: site:www.example.com. استفاده از موتورهای جستجو به این روش منجر به طیف گسترده ای از تکنیک ها شده است که ممکن است برای شما مفید باشد و در بخش Google Hacking این راهنما آن را بررسی کنید تا مهارت‌های آزمایشی خود را از طریق Google تقویت کنید. فایل های پشتیبان به احتمال زیاد توسط هیچ فایل دیگری ارجاع داده نمی شوند و بنابراین ممکن است توسط گوگل ایندکس نشده باشند، اما اگر در دایرکتوری های قابل مرور قرار داشته باشند، موتور جستجو ممکن است از آنها مطلع شود.
• علاوه بر این، گوگل و یاهو نسخه‌های ذخیره‌شده صفحاتی را که توسط ربات‌های خود پیدا می‌کنند نگهداری می‌کنند. حتی اگر 1998results.asp از سرور هدف حذف شده باشد، ممکن است نسخه ای از خروجی آن همچنان توسط این موتورهای جستجو ذخیره شود. نسخه ذخیره شده ممکن است حاوی ارجاعات یا سرنخ هایی در مورد محتوای مخفی اضافی باشد که هنوز روی سرور باقی مانده است.
• محتوایی که از داخل یک برنامه هدف ارجاع داده نمی شود، ممکن است توسط وب سایت های شخص ثالث به آن پیوند داده شود. برای مثال، برنامه‌ای که پرداخت‌های آنلاین را از طرف معامله‌گران شخص ثالث پردازش می‌کند، ممکن است دارای عملکردهای سفارشی متنوعی باشد که (به طور معمول) فقط با دنبال کردن پیوندهای درون وب‌سایت‌های مشتریانش قابل یافتن است.

دور زدن فیلتر نام فایل (Filename Filter Bypass)

از آنجایی که فیلترهای لیست انکار بر اساس عبارات منظم هستند، گاهی اوقات می‌توان از ویژگی‌های مبهم گسترش نام فایل سیستم‌عامل که به گونه‌ای کار می‌کنند که توسعه‌دهنده انتظارش را نداشت، استفاده کرد. آزمایش‌کننده گاهی اوقات می‌تواند از تفاوت‌ها در روش‌هایی که نام فایل‌ها توسط برنامه، وب سرور، و سیستم‌عامل زیربنایی و قراردادهای نام فایل آن تجزیه می‌شوند، سوء استفاده کند.

مثال: گسترش نام فایل ویندوز 8.3 c:\\program files می شود C:\\PROGRA\~1

• کاراکترهای ناسازگار را حذف کنید
• تبدیل فاصله ها (spaces) به زیرخط (underscores)
• شش کاراکتر اول نام اصلی را در نظر بگیرید
• افزودن <digit>~ که برای تشخیص فایل‌ها با نام با استفاده از همان شش کاراکتر اولیه استفاده می‌شود
• این قرارداد پس از 3 برخورد اول نام تغییر می کند
• پسوند فایل را به سه کاراکتر کوتاه کنید
• همه کاراکترها را با حروف بزرگ بنویسید

آزمایش جعبه خاکستری (Gray-Box Testing)

انجام آزمایش جعبه خاکستری در برابر فایل‌های قدیمی و پشتیبان نیازمند بررسی فایل‌های موجود در دایرکتوری‌های متعلق به مجموعه دایرکتوری‌های وب است که توسط سرور(های) وب زیرساخت برنامه وب ارائه می‌شود. از نظر تئوری معاینه باید با دست انجام شود تا کامل باشد. با این حال، از آنجایی که در بیشتر موارد کپی‌هایی از فایل‌ها یا فایل‌های پشتیبان با استفاده از قراردادهای نام‌گذاری یکسان ایجاد می‌شوند، جستجو را می‌توان به راحتی اسکریپت کرد. برای مثال، ویراستاران با نامگذاری آنها با پسوند یا پایان قابل تشخیص، نسخه‌های پشتیبان را به جای می‌گذارند و انسان‌ها تمایل دارند فایل‌هایی با پسوند old. یا پسوندهای قابل پیش بینی مشابه یک استراتژی خوب، برنامه‌ریزی دوره‌ای یک کار پس‌زمینه برای بررسی فایل‌هایی با پسوندهایی است که احتمالاً آن‌ها را به عنوان فایل‌های کپی یا پشتیبان شناسایی می‌کند و همچنین بررسی‌های دستی را بر اساس زمان طولانی‌تری انجام می‌دهد.

اصلاح

برای تضمین یک استراتژی حفاظتی مؤثر، آزمایش باید با یک سیاست امنیتی ترکیب شود که به وضوح اعمال خطرناک را ممنوع می کند، مانند:

• ویرایش فایل ها در محل روی سرور وب یا سیستم های فایل سرور برنامه. این یک عادت بد است، زیرا احتمالاً فایل‌های پشتیبان یا موقت را توسط ویرایشگرها ایجاد می‌کند. دیدن اینکه چقدر این کار حتی در سازمان های بزرگ انجام می شود شگفت انگیز است. اگر کاملاً نیاز به ویرایش فایل‌ها در یک سیستم تولیدی دارید، اطمینان حاصل کنید که چیزی را که به صراحت در نظر گرفته نشده است را پشت سر نگذارید و در نظر بگیرید که این کار را با مسئولیت خود انجام می‌دهید.
• هر فعالیت دیگری را که روی سیستم های فایلی که توسط وب سرور در معرض دید قرار می گیرند، مانند فعالیت های مدیریت نقطه ای، به دقت بررسی کنید. به عنوان مثال، اگر گهگاه نیاز به گرفتن عکس فوری از چند دایرکتوری دارید (که نباید در یک سیستم تولید انجام دهید)، ممکن است وسوسه شوید ابتدا آنها را فشرده کنید. مراقب باشید آن فایل های آرشیو را پشت سر نگذارید.
• سیاست‌های مدیریت پیکربندی مناسب باید از فایل‌های منسوخ و غیر مرجع جلوگیری کند.
• برنامه ها باید طوری طراحی شوند که فایل های ذخیره شده در زیر درختان فهرست وب که توسط وب سرور ارائه می شوند ایجاد نکنند (یا به آنها تکیه کنند). فایل‌های داده، فایل‌های گزارش، فایل‌های پیکربندی و غیره باید در دایرکتوری‌هایی ذخیره شوند که توسط وب سرور قابل دسترسی نیستند، تا با امکان افشای اطلاعات مقابله شود (اگر مجوزهای فهرست وب اجازه نوشتن را می‌دهد، تغییر داده‌ها را ذکر نکنیم).
• اگر ریشه سند روی یک سیستم فایل با استفاده از این فناوری باشد، عکس‌های فوری سیستم فایل نباید از طریق وب قابل دسترسی باشند. وب سرور خود را به گونه ای پیکربندی کنید که دسترسی به چنین دایرکتوری هایی را ممنوع کند، به عنوان مثال در Apache یک دستورالعمل مکان مانند این باید استفاده شود:

<Location ~ ".snapshot">
    Order deny,allow
    Deny from all
</Location>

ابزارها

ابزارهای ارزیابی آسیب‌پذیری معمولاً شامل بررسی‌هایی برای شناسایی فهرست‌های وب با نام‌های استاندارد (مانند "admin"، "test"، "backup"، و غیره) و گزارش هر فهرست وب است که امکان فهرست‌بندی را فراهم می‌کند. اگر نمی‌توانید فهرست فهرستی را دریافت کنید، باید سعی کنید پسوندهای پشتیبان احتمالی را بررسی کنید. برای مثال بررسی کنید

• Nessus
• Nikto2

ابزارهای عنکبوت وب (Web spider tools)

• wget
• Wget for Windows
• Sam Spade
• Spike proxy includes a web site crawler function
• Xenu
• curl

برخی از آنها نیز در توزیع های استاندارد لینوکس گنجانده شده اند. ابزارهای توسعه وب معمولاً شامل امکاناتی برای شناسایی لینک های شکسته و فایل های بدون مرجع هستند.