گزارش abuse برای رجیسترارها، ارائهدهندگان میزبانی و CDNها، به‌صورت ایمیل و JSON بسازید.
جدید
تولیدکنندهٔ security.txt
اجرای محلی
خود ابزار به زبان انگلیسی است؛ این صفحه آن را به زبان شما توضیح میدهد.
از تولیدکنندهٔ security.txt استفاده کنید
کارکرد
یک فایل security.txt بسازید تا پژوهشگران و کسانی که فیشینگ با جعل برند شما را گزارش میکنند بدانند چگونه با شما تماس بگیرند. نتیجه را با نام /.well-known/security.txt ذخیره کنید.
این کاملاً در مرورگر شما اجرا میشود: هیچ‌یک از اطلاعاتی که وارد می‌کنید بارگذاری نمیشود.
چگونه از تولیدکنندهٔ security.txt استفاده کنیم
- یک مخاطب وارد کنید. در بخش «تماس» نحوه دسترسی به تیم امنیتی خود را، هر مورد در یک خط، وارد کنید: mailto:security@example.com، یک آدرس ایمیل برای ارسال گزارش، یا یک شماره تلفن. یک آدرس ایمیل ساده به mailto: تبدیل میشود.
- تاریخ انقضا را تعیین کنید. در Expires یک تاریخ انتخاب کنید. پیشفرض یک سال پس از امروز است؛ RFC 9116 کمتر از یک سال را توصیه میکند، پس تاریخ زودتری انتخاب کنید.
- فیلدهای اختیاری را اضافه کنید. اگر Preferred-Languages (بهطور پیشفرض en)، Canonical، Policy، Encryption، Acknowledgments و Hiring را دارید، آن‌ها را پر کنید. فیلدهای خالی در فایل نمی‌آیند.
- تولید و کپی کنید. دکمهٔ Generate را بزنید و نتیجه را در کادر خروجی بخوانید. همهٔ آدرس‌ها را یک بار دیگر بررسی کنید، چون ابزار آن‌ها را همان‌طور که نوشته‌اید کپی میکند، سپس دکمهٔ Copy (کپی) را بزنید.
- منتشر و تمدید کنید. متن را با نام /.well-known/security.txt روی سایت خود و از طریق HTTPS ذخیره کنید، در صورت تمایل آن را با gpg --clearsign امضا کنید و تاریخی را برای تمدید آن پیش از انقضا یادداشت کنید.
مثال
فایل حداقلی
mailto:security@example.comContact: mailto:security@example.com
Expires: 2027-10-20T23:59:59.000Z
Preferred-Languages: enProduces Contact: mailto:security@example.com, یک خط Expires یک سال آینده در 23:59:59Z و Preferred-Languages: en، دو فیلد الزامی به‌علاوه یک سرنخ زبانی، با یادآوری اینکه RFC 9116 توصیه میکند تاریخ Expires کمتر از یک سال آینده باشد.
آنچه بررسی میکند
| سیگنال | معنای آن |
|---|---|
| Contact: | برای هر تماس یک خط، به ترتیبی که تایپ کرده‌اید. هر خط باید یک URI از نوع mailto:، https:// یا tel: مطابق RFC 9116 باشد؛ http:// و مقادیر نادرست به جای فایل خطا نمایش می‌دهند. |
| Expires: | تاریخ انتخاب‌شده در ساعت 23:59:59 UTC، همراه با میلی‌ثانیه، مثلاً 2027-03-31T23:59:59.000Z. اگر فیلد تاریخ را پاک کنید، Generate دیگر فایل جدیدی تولید نمی‌کند. |
| Preferred-Languages: | بهطور پیشفرض en. کدهای زبان را با ویرگول جدا کنید، مانند en, de، یا فیلد را خالی کنید تا این خط حذف شود. |
| Canonical: | آدرس کامل https:// محل این فایل، تا نسخه‌ای که از جای دیگری ارائه میشود قابل تشخیص باشد. |
| Encryption: | لینکی به کلید عمومی OpenPGP شما، تا گزارش‌دهندگان بتوانند جزئیات حساس را رمزگذاری کنند. |
| Policy، Acknowledgments، Hiring | لینک‌هایی به سیاست افشای شما، صفحه‌ای برای قدردانی از گزارش‌دهندگان و فرصت‌های شغلی امنیتی. همه اختیاری‌اند و ابزار کارکرد لینک‌ها را بررسی نمی‌کند. |
| آدرس نقش‌محور در Contact | از آدرس یا فرمی استفاده کنید که یک تیم آن را زیر نظر دارد، مانند security@ در دامنهٔ شما، نه صندوق ایمیل یک فرد، تا وقتی افراد شغلشان را عوض میکنند گزارش‌ها همچنان برسند. |
| Error: Contact is required | وقتی تماس خالی باشد نمایش داده میشود. هر خطایی خروجی را جایگزین میکند و یادآوری میکند که تا زمانی که فیلدها اصلاح نشوند، هیچ چیزی تولید نخواهد شد. |
نمونه‌های بیشتر
فرم وب همراه با زبان‌ها و سیاست
Contact https://example.org/report-security, Expires 2027-03-31, Preferred-Languages en, de, Canonical https://example.org/.well-known/security.txt, Policy https://example.org/security-policyپنج خط به این ترتیب: Contact: https://example.org/report-security، Expires: 2027-03-31T23:59:59.000Z، Preferred-Languages: en, de، Canonical: https://example.org/.well-known/security.txt، Policy: https://example.org/security-policy.
مخاطب ایمیلی با کلید، بدون زبان
Contact mailto:abuse@example.net, Expires 2027-06-30, Preferred-Languages cleared, Encryption https://example.net/pgp-key.txtسه خط: Contact: mailto:abuse@example.net، Expires: 2027-06-30T23:59:59.000Z و Encryption: https://example.net/pgp-key.txt.
فیلد Contact خالی مانده است
All fields filled except Contactخطا: فیلد «تماس» الزامی است و یادآوری‌ای مبنی بر اینکه هیچ چیزی تولید نشده است. سایر فیلدها مقادیر خود را حفظ میکنند، بنابراین فیلد «تماس» را پر کرده و دوباره دکمه «تولید» را فشار دهید.
سوالات متداول
کدام فیلدها الزامی‌اند؟
RFC 9116 حداقل یک فیلد Contact و دقیقاً یک فیلد Expires را الزامی می‌داند؛ بقیه اختیاری هستند. هر خط Contact باید یک URI از نوع mailto:، https:// یا tel: باشد (در صورت خالی بودن آدرس ایمیل، mailto: به آن اضافه میشود)، فیلد Expires باید تاریخ آینده باشد و Generate در صورت وجود خطا بهجای نمایش فایل، خطا را نشان میدهد.
Expires را روی چه تاریخی بگذارم؟
تاریخ بهطور پیشفرض روی یک سال از امروز تنظیم میشود، در حالی که RFC 9116 کمتر از یک سال را توصیه میکند؛ بنابراین برای پیروی از آن تاریخ زودتری را انتخاب کنید. صفحه زمانی که تاریخ بیش از یک سال آینده باشد به شما یادآوری میکند. قبل از آن تاریخ فایل را تمدید کنید، زیرا RFC میگوید security.txt منقضیشده باید بهعنوان قدیمی در نظر گرفته شود.
آیا چیزی بارگذاری یا امضا میشود؟
خیر. فایل در مرورگر شما ساخته میشود و چیزی به جایی فرستاده نمیشود. فایل امضا نمیشود؛ RFC 9116 امضای OpenPGP از نوع cleartext را توصیه میکند که میتوانید پیش از انتشار با gpg --clearsign اضافه کنید.
آیا میتوانم بیش از یک مخاطب درج کنم؟
بله. RFC 9116 اجازه میدهد چندین خط تماس داشته باشید که بر اساس ترتیب اولویت خوانده میشوند. در فیلد «تماس» برای هر خط یک تماس وارد کنید؛ موارد تکراری تنها یکبار ثبت میشوند.
فایل دقیقاً کجا قرار می‌گیرد؟
در https://your-domain/.well-known/security.txt، که از طریق HTTPS و به‌صورت متن ساده ارائه میشود. یک نسخه یا هدایت (redirect) در /security.txt اختیاری است.
آیا یک فایل زیردامنه‌های من را هم پوشش میدهد؟
خیر. طبق RFC 9116، فایل security.txt فقط برای میزبانی معتبر است که از آن دریافت شده، نه برای زیردامنه‌ها یا دامنهٔ والد آن. روی هر میزبانی که ممکن است مردم به آن سر بزنند، مانند www و shop، یک نسخه منتشر کنید.
security.txt چگونه در برابر فیشینگی که برند من را کپی میکند کمک میکند؟
کسانی که سایتی مشابه یا ایمیلی جعلی به نام شما پیدا میکنند، اغلب میخواهند به شما هشدار دهند. یک خط Contact کارآمد آن گزارش را بهجای صف عمومی پشتیبانی به تیم امنیتی شما میرساند، تا بتوانید زودتر دربارهٔ دامنهٔ مشابه اقدام کنید.