Skip to content

README-fa.md

Latest commit

 

History

History
84 lines (67 loc) · 11.2 KB

README-fa.md

File metadata and controls

84 lines (67 loc) · 11.2 KB

繁中版 | 简中版 | Português (Brasil) | Français | 한국어 | Nederlands | Indonesia | ไทย | Русский | Українська | Español | Italiano | 日本語 | Deutsch | Türkçe | Tiếng Việt | Монгол | हिंदी | العربية | Polski | Македонски | ລາວ | Ελληνικά | മലയാളം

چک‌لیست امنیتی API

چک‌لیستی از مهم‌ترین کارهای لازم برای حفظ امنیت در زمان طراحی، تست و انتشار API.

احراز هویت

  •       از Basic Auth یا همان اصالت‌سنجی برای دسترسی‌های اولیه استفاده نکنید. به جای آن از روش‌های استاندارد احراز هویت استفاده کنید (مثلا JWT یا OAuth).
  •       برای کارهایی مثل احراز هویت، تولید توکن و ذخیره پسوورد چرخ را دوباره اختراع نکنید. از استانداردها استفاده کنید.
  •       برای لاگین محدودیت‌های تعداد ماکسیمم تلاش مجدد و تعداد دفعات ورود را قرار بدید.
  •       همه‌ی داده‌های حساس را رمزگذاری کنید.

JWT (JSON Web Token)

  •       از یک کلید پیچیده‌ی تصادفی برای JWT Secret استفاده کنید تا حمله‌ی بروت‌فورس به توکن بسیار سخت باشد.
  •       الگوریتم را از هدر استخراج نکنید. در بک‌اند الگوریتم را تحمیل کنید (HS256 یا RS256).
  •       انقضای توکن (TTL یا RTTL) را تا حد ممکن کوتاه کن.
  •       اطلاعات حساس را در پی‌لود JWT ذخیره نکنید چون به راحتی قابل رمزگشایی است.
  •       از ذخیره بیش از حد داده ها خودداری کنید. JWT معمولاً در هدر به اشتراک گذاشته می شود و محدودیت اندازه دارند.

OAuth

  •       همیشه redirect_uri را در سمت سرور اعتبارسنجی کنید تا تنها به URLهای مجاز اجازه داده شود.
  •       همیشه تلاش کنید تا code را به جای token تبادل کنید (اجازه response_type=token را ندهید).
  •       از پارامتر state با یک هش تصادفی استفاده کنید تا از CSRF روی پروسه‌ی احراز هویت OAuth جلوگیری کنید.
  •       مقدار scope پیش‌فرض را تعریف کنید و پارامترهای scope را برای هر اپلیکیشن اعتبارسنجی کنید.

دسترسی

  •       رکوئست‌ها را محدود کنید (Throttling) تا از حملات DDos یا بروت‌فورس جلوگیری شود.
  •       در سمت سرور از HTTPS استفاده کنید تا از حملات مرد میانی جلوگیری شود.
  •       از هدر HSTS استفاده کنید تا از حمله‌ی SSL Strip جلوگیری شود.
  •       لیست های دایرکتوری را خاموش کنید.
  •       برای APIهای خصوصی، فقط از IPها/میزبانهای لیست سفید اجازه دسترسی داشته باشید.

ورودی

  •       از متد HTTP مناسب با توجه به نوع عملیات استفاده کنید: GET برای خواندن، POST برای ایجاد کردن، PUT/PATCH برای جایگزین یا بروزرسانی و DELETE برای حذف یک رکورد، و در صورتی‌که متد درخواستی برای منبع درخواست‌شده مناسب نباشد با 405 Method Not Allowed پاسخ بدهید.
  •       مقدار content-type را در هدر Accept رکوئست (مذاکره محتوا یا Content Negotiation) اعتبارسنجی کنید تا فقط به فرمت‌های مورد پشتیبانی اجازه داده شود (مثلا application/xml، application/json و ...). و در صورت عدم تطابق با یک پاسخ 406 Not Acceptable پاسخ دهید.
  •       مقدار content-type در داده‌ی پست‌شده را اعتبارسنجی کنید (مثلا application/x-www-form-urlencoded، multipart/form-data، application/json و ...).
  •       ورودی کاربر را اعتبارسنجی کنید تا از آسیب‌پذیری‌های معمول جلوگیری شود (مثلا XSS، SQL-Injection و Remote Code Execution).
  •       هیچ داده‌ی حساسی مثل (داده‌های اعتبارسنجی، پسوورد‌ها، توکن‌های امنیتی یا کلید‌های API) را داخل URL قرار ندهید و از هدر Authorization استاندارد استفاده کنید.
  •       فقط از رمزگذاری سمت سرور استفاده کنید.
  •       از یک سرویس API Gateway استفاده کنید تا کش‌کردن و سیاست‌های Rate Limit (مثلا Quota، Spike Arrest یا Concurrent Rate Limit) فعال شوند و منابع APIها را به صورت داینامیک دپلوی کنید.

پردازش

  •       چک کنید که تمامی endpointها توسط احراز هویت محافظت شوند تا از پروسه‌ی احراز هویت ناقص جلوگیری شود.
  •       از استفاده از ID ریسورس خود کاربر اجتناب کنید. به جای user/654321/orders از /me/orders استفاده کنید.
  •       از IDهای auto-increment استفاده نکنید. به جای آن از UUID استفاده کنید.
  •       اگر فایل‌های XML را parse می‌کنید مطمئن شوید تا entity parsing غیرفعال باشد تا از XXE (XML External entity attack) جلوگیری شود.
  •       اگر فایل‌های XML، YAML یا هر زبان دیگری را با استفاده از anchor ها و ref ها parse می‌کنید، مطمئن شوید تا entity expansion غیرفعال باشد تا از Billion Laughs/XML bomb توسط exponential entity expansion attack جلوگیری شود.
  •       از یک CDN برای آپلودهای فایل استفاده کنید.
  •       اگر با مقادیر بسیار حجیمی از داده سر و کار دارید، از Workerها و Queueها استفاده کنید تا حد الامکان پردازش در بک‌گراند انجام شود و سریع پاسخ را برگردانید تا از HTTP Blocking جلوگیری شود.
  •       خاموش کردن حالت DEBUG را فراموش نکنید.
  •       در صورت وجود از پشته های غیر قابل اجرا استفاده کنید.

خروجی

  •       هدر X-Content-Type-Options: nosniff را ارسال کنید.
  •       هدر X-Frame-Options: deny را ارسال کنید.
  •       هدر 'Content-Security-Policy: default-src 'none را ارسال کنید.
  •       هدرهایی که به نوعی اثرانگشت برجای می‌گذارند را حذف کنید، مثلا X-Powered-By، Server و ‍X-AspNet-Version.
  •       مقدار content-type را برای پاسخ اجباری کنید. اگر application/json برمیگردانید، پس content-type پاسخ، application/json است.
  •       اطلاعات حساس مثل داده‌های اعتبارسنجی، رمز های عبور و توکن‌های امنیتی را برنگردانید.
  •       با توجه به عملیات انجام‌شده، status code مناسب را برگردانِد. مثلا 200 OK، 400 Bad Request، 401 Unauthorized و 405 Method Not Allowed.

CI & CD

  •       طراحی و پیاده سازی خودتان را با پوشش تست‌های unit/integration بازرسی کنید.
  •       از یک پروسه‌ی مرور کد استفاده کنید و خود-تاییدی را نادیده بگیرید.
  •       مطمئن شوید تا تمامی اجزای سرویس‌هایتان، شامل کتابخانه‌های استفاده‌شده و دیگر وابستگی‌ها، قبل از انتشار در حالت production، به طور ایستا توسط نرم‌افزارهای آنتی‌ویروس اسکن شده‌اند.
  •       به صورت پیوسته روی کدتان تست‌های امنیتی (آنالیز ایستا و پویا)، اجرا کنید.
  •       وابستگی‌هایتان (نرم افزار و سیستم عامل، هردو) را برای آسیب‌پذیری‌های شناخته شده، چک کنید.
  •       برای دپلوی‌هایتان، یک راه‌حل با قابلیت عقبگرد (rollback) طراحی کنید.

نگاهی بیاندازید به:

مشارکت

برای همکاری و کمک می‌توانید به راحتی این مخزن را fork کنید، تغییرات مورد نظرت را اعمال کنید و یک pull request ثب کنید. اگر سوالی داشتید به آدرس team@shieldfy.io ایمیل بزنید.