سربرگ ETag برای ذخیره موثر منابع سرور توسط مشتری استفاده می شود. سرور یک سرصفحه ETag را در پاسخ HTTP به برخی رشته ارسال می کند و مشتری محتوای محتوای پاسخ را مخدوش می کند و رشته ای که در سربرگ ETag با آن قرار گرفته است. اگر مشتری بخواهد دوباره به همان منبع دسترسی پیدا کند، رشته داده شده را در برخی از If-None-Match در درخواست HTTP ارسال می کند و سرور تنها محتوای کامل را در صورت تغییر منبع و بازگشت در غیر این صورت به مشتری می گویند که محتوای ذخیره شده را می توان استفاده کرد. برای اطلاعات بیشتر به ویکیپدیا مراجعه کنید
این بدان معنی است که هر مشتری می تواند از یک سرور از جمله ETag دریافت کند، یعنی مقدار هدر رازدار نیست. بنابراین بر خلاف سوال شما، نشت این هدر به خودی خود مسئله نیست.
مشکل این است که اگر مقدار هدر (یعنی رشته) اطلاعاتی در مورد سرور ارائه می دهد که باید مخفی باشد. اغلب ارزش سرصفحه فقط یک محتوا بر روی محتویات منابع است که در همه مشکلی نیست. اما برای مثال سرور وب آپاچی می تواند ETag بر روی شماره یونیت، آخرین زمان اصلاح و / یا اندازه ی فایل را پایه گذاری کند. با استفاده از این اطلاعات متا، منحصر به فرد ETag می تواند بسیار سریعتر نسبت به محاسبه هش محتوا ایجاد شود. تنها حداقل حداقل مقدار inode اطلاعات داخلی به سرور محسوب می شود و نباید در معرض مشتری قرار گیرد. در حالی که در حملات قابل استفاده نمی باشد، به طور مستقیم می توان از تعداد زیادی از داده های inode برای به دست آوردن اطلاعات به عنوان مثال در مورد سیستم فایل پایه استفاده کرد که ممکن است در حملات بیشتر در برابر سرور کمک کند.
این بدان معنی است که تعداد inode نباید از سربرگ ETag قابل استخراج باشد زیرا باید مخفی باشد. این با آپاچی 1.3.27 (مدتها پیش) ثابت شده است، یعنی عدد inode هنوز هم برای محاسبه ETag استفاده می شود اما به طریقی که نمی توان از مقدار ETag استخراج کرد.
ویرایش: به عنوان مثال Rapid7 این را با شدت چهار می بینید.
نمره CVSS از چندین قسمت محاسبه می شود. جزئیات مربوط به این مشکل خاص را می توان در اینجا مشاهده کرد، اما اساسا به این می پردازد که استفاده بی اهمیت است، می تواند در شبکه انجام شود، نیازی به احراز هویت و ارائه اطلاعات داخلی در مورد سرور ندارد.
