وحید نصیری وحید نصیری
بهبود امنیت CSP با استفاده از معرفی هش‌های اسکریپت‌های Inline
‫۱ سال قبل، دوشنبه ۱۳ شهریور ۱۴۰۲، ساعت ۱۶:۱۷
یک نکته‌ی تکمیلی: استفاده از nonce بجای هش

روش دیگری هم برای مشخص کردن اسکریپت‌ها و شیوه‌نامه‌های inline وجود دارد که nonce نامیده می‌شود. nonce، یک مقدار منحصربفرد است که باید به ازای هر درخواست، یکبار دیگر به صورت خودکار، مجددا تولید شود (اگر ثابت باشد، مهاجم می‌تواند مقدار مشخص آن‌را به اسکریپت‌های خودش اضافه کند):
script-src 'nonce-rAnd0m'
یعنی قبل از هرکاری باید میان‌افزاری که کار تولید CSP Headers فوق را انجام می‌دهد، این مقدار را تولید کند. سپس می‌توان این مقدار را به ویژگی nonce برای مثال تگ اسکریپت، اضافه کرد:
<script nonce="rAnd0m">
</script>
مزیت آن، عدم نیاز به محاسبه و یا درج هش این قطعه اسکریپت، مطابق نکات مطلب جاری است؛ اما باید به صورت پویا به ازای هر درخواستی، مجددا در سمت سرور، تولید شود. همچنین تولید مجدد این مقدار، با کش شدن اطلاعات صفحه در تضاد است و باید به آن دقت داشت.

اگر از کتابخانه‌ی NetEscapades.AspNetCore.SecurityHeaders استفاده می‌کنید، فراخوانی متد WithNonce آن:
builder.AddScriptSrc().Self().WithNonce()
به صورت خودکار هدر مرتبط را تولید می‌کند. همچنین مقدار تولیدی آن‌را نیز در HttpContext.Items، درج می‌کند: 
HttpContext.Items["NETESCAPADES_NONCE"]
به این روش، برای مثال یک Tag Helper و یا قسمت دیگری از برنامه که کار مقدار دهی nonce را به عهده دارد، می‌تواند به مقدار خودکار تولید شده‌ی توسط میان‌افزار، دسترسی داشته باشد (ابتدا میان‌افزار CSP اجرا می‌شود و سپس کار رندر صفحه به صورت جداگانه‌ای انجام می‌شود).
یک نکته: هنگام درج مقدار nonce در attributes، به HTML encoding آن دقت داشته باشید؛ این مقدار نباید encode شود (یا تغییر کند).
پروژه ای دارای چندین زیر سیستم مجزا می‌باشد که کلاسهای FluentValidator هر زیر سیستم در همان زیر سیستم نوشته شده است. 
در Starup اگر از دستور زیر استفاده کنم : 
 services.AddFluentValidation(config =>
 {
 config.RegisterValidatorsFromAssemblies(AppDomain.CurrentDomain.GetAssemblies());
 });
در حالت دیباگ لوکال درست عمل می‌کند ولی اگر environment ویژوال استودیو را بر روی stage,production و... قرار دهم و پروژه را اجر کنم خطای The invoked member is not supported in a dynamic assembly رخ میدهد.
با سلام؛ توکن از یک سرور احراز هویت دریافت میشه و در سمت کلاینت  (sessionStorage )  ذخیره می‌شود با درخواست‌های ajax مشکلی نیست  به هدر اضافه می‌شود ( headers: { Authorization: "Bearer " + sessionStorage.getItem("access_token") }, )
ولی برای خواست‌های غیر از ajax چطور توکن از sessionStorage به هدر اضافه کنیم.
سید امید موسوی سید امید موسوی
تنظیمات CORS در ASP.NET Core
‫۱ سال قبل، دوشنبه ۳۰ مرداد ۱۴۰۲، ساعت ۱۱:۱۵
علت این مشکل تنظیم Referrer-Policy برنامه با مقدار no-referrer بود. 
context.Response.Headers.Add("Referrer-Policy", "no-referrer");
با تغییر به strict-origin  مشکل برطرف شد.
 context.Response.Headers.Add("Referrer-Policy", "strict-origin");
وحید نصیری وحید نصیری
تنظیمات CORS در ASP.NET Core
‫۱ سال قبل، دوشنبه ۲۳ مرداد ۱۴۰۲، ساعت ۱۴:۲۲
- مطلب جاری هیچ ارتباطی به درخواست‌های درون برنامه‌ای ندارد و فقط مرتبط با تنظیمات امنیتی مرورگرها است. این مرورگرها هستند که عنوان می‌کنند، من اینکار خاص را تحت این شرایط ویژه انجام نمی‌دهم؛ اما برنامه‌ی شما در پشت صحنه و توسط HttpClient یا هر روش مشابه دیگری، چنین محدودیتی ندارد.
- موردی که عنوان کردید فقط مرتبط با تنظیمات HttpClient مورد استفاده‌است که چنین گزینه‌ای را تنظیم نکرده.
سید امید موسوی سید امید موسوی
تنظیمات CORS در ASP.NET Core
‫۱ سال قبل، دوشنبه ۲۳ مرداد ۱۴۰۲، ساعت ۱۴:۰۷
یک اپلیشکن mvc دارم که در درخواست‌های درون برنامه به صورت Post با origin : null تنظیم میشه علت این موضوع چی میتونه باشه ؟ 

این مشکل نیست. این توکن‌ها متکی به خود (self contained) هستند و همه چیز را جهت استفاده‌ی کامل از آن‌ها، درون خود دارند و تا زمانیکه یکسری از claims موجود در آن‌ها منقضی نشود (مانند طول عمر تنظیم شده‌ی آن‌ها) یا تغییر نکنند، از سمت سرور بدون هیچ مشکلی، اعتبارسنجی خواهند شد. زمانیکه logout می‌کنید، فقط این توکن‌ها را از کش‌های مختلف مرورگر حذف می‌کنید؛ اما ردی از حذف شدن و غیرمعتبر شدن آن، در سمت سرور ذخیره نمی‌شود و اگر کاربری قبلا این توکن را ذخیره کرده باشد، باز هم باتوجه به متکی به خود بودن آن، می‌تواند از آن استفاده‌ی مجدد کند. برای برگشت زدن توکن‌های متکی به خود، در سمت سرور، باید داخل آن‌ها یک claim سفارشی مانند serial number، قرار داد و همچنین در سمت سرور هم این serial number را ذخیره کرد. بعد در حین logout، این serial number را در بانک اطلاعاتی تغییر داد تا دفعه‌ی بعدی که قرار است از توکن متکی به خود استفاده شود، اعتبارسنجی ثانویه‌ای بر روی این claim دریافتی از کاربر و مقایسه‌ی آن با مقدار موجود در بانک اطلاعاتی در سمت سرور هم انجام شود (حالت پیش‌فرض اکثر سیستم‌های اعتبارسنجی، فاقد این مرحله است). اینکار در ASP.NET Core Identity تحت عنوان مفهوم security stamp پیاده سازی شده و وجود دارد؛ در JWTها توسط TokenValidatorService و در کوکی‌ها، توسط CookieValidatorService قابل پیاده سازی است. در نگارش‌های قبلی ASP.NET و حالت استفاده‌ی از Forms authentication، امکان بررسی سفارشی وضعیت کاربر جاری در authenticate request هم وجود دارد. مطلب جاری، به غنی‌سازی Validator Service‌های اشاره شده، می‌پردازد.