آموزش پیکربندی هدرهای امنیتی در ASP.NET Core

آموزش پیکربندی هدرهای امنیتی در ASP.NET Core یکی دیگر از آموزش های گروه آموزشی پرووید می باشد که در این قسمت آن را به شما معرفی می کنیم. این بسته آموزشی نیز یکی از دوره های آموزشی دیگر که در حوزه ی فارسی سازی آموزش های انگلیسی تنظیم شده است می باشد. عنوان این بسته آموزشی پیکربندی کردن هدر های امنیتی و یا Security Header ها در اپلیکیشن های ASP.NET و ASP.NET Core است که با نام اصلی Configuring Security Headers in ASP.NET and ASP.NET Core Applications از شرکت Pluralsight منتشر شده است.

اضافه کردن هدر سفارشی با استفاده از Attribute ها

اگر یک روش مناسب و قابل استفاده مجدد و یا همان reusable برای افزودن یک هدر سفارشی یکسان به چندین endpoint در Web API یا حتی در سطح controller می‌خواهیم، می‌توانیم یک attribute سفارشی برای رسیدن به این هدف تعریف کنیم. در configuration توصیه شده برای ASP.NET Core برنامه با استفاده از ASP.NET Core Module و Nginx یا Apache میزبانی می شود که سرورهای پروکسی و load balancer ها و سایر تجهیزات شبکه اغلب اطلاعات مربوط به request قبل از رسیدن به برنامه را مبهم می کنند و این عمل به این صور است که وقتی HTTP های request از طریق HTTP پروکسی می‌شوند، scheme اصلی که همان HTTPS است از بین می‌رود و باید از یک هدر انتقال داده شود و یا اصطلاحاً forwarded شود سپس از آنجا که یک برنامه درخواستی را از پروکسی دریافت می کند و منبع واقعی آن را در اینترنت یا شبکه شرکتی دریافت نمی کند، آدرس IP مشتری اصلی نیز باید در یک هدر ارسال شود که این اطلاعات ممکن است در پردازش request مهم باشد.

در برخی موارد، ممکن است امکان افزودن هدر های forwarded به request های پروکسی به برنامه وجود نداشته باشد. در واقع اگر پروکسی الزام می کند که external request public به صورت HTTPS ارسال شوند، می توانیم این scheme را قبل از استفاده از هر نوع middleware به صورت دستی تنظیم کنیم:

using Microsoft.AspNetCore.HttpOverrides;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders =
        ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseForwardedHeaders();
    app.UseHsts();
}
else
{
    app.UseDeveloperExceptionPage();
    app.UseForwardedHeaders();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

هدر Content-Security-Policy

این هدر کمک می کند که جلو حملات تزریق کد و یا همان code injection از قبیل cross-site scripting و clickjacking و یا جلو mode های ترکیبی HTTPS و HTTP گرفته شود. در صورت لزوم می‌توانیم اجرای اسکریپت‌ های درون‌ خطی را در صفحات وب غیرفعال کنیم و باید صریحاً می بایست یک rom را به عنوان یک Custom Source اضافه کنیم که در آن صفحات وب ما مجاز به بارگیری اسکریپت‌ ها و سایر محتواها هستند. اما این پیکربندی تا حد زیادی وابسته به نیازمندی خاص است و در مورد اینکه چه چیزی مجاز و چه چیزی غیر مجاز است نیز دارای انعطاف پذیری می باشد.

چهار کلمه کلیدی اصلی وجود دارد که ما معمولاً هنگام تعریف CSP از آنها استفاده می کنیم.

• ()None: به این معنی است که هیچ چیزی بارگذاری نخواهد شد.
• ()Self: به معنای بارگیری موارد از همان دامنه ای است که در page ارائه شده است، یعنی همان scheme یکسان و host و یا port یکسان.
• ()UnsafeInline: به این معنی است که اجرای اسکریپت ها و یا سبک های درون خطی احتمالاً ناامن را فعال می کند. اما استفاده از آن توصیه نمی شود.
• ()UnsafeEval: به معنی اجرای eval و سایر توابع خطرناک را امکان پذیر می کند. باز هم استفاده از این نیز توصیه نمی شود.

هدرهای امنیتی HTTP و نقش آن ها در محافظت از وب سایت

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

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

جلوگیری از حملات XSS و Clickjacking با تنظیمات امنیتی

حمله `Cross-Site Scripting` یا XSS زمانی رخ می دهد که مهاجم بتواند محتوای اسکریپتی مخرب را در زمینه اجرای یک وب سایت وارد کند. یکی از راهکارهای دفاعی در سطح مرورگر، استفاده از `Content-Security-Policy` یا CSP است. این سیاست به توسعه دهنده اجازه می دهد منابع مجاز برای بارگذاری اسکریپت ها و سایر محتواها را مشخص کند. با تنظیم دقیق CSP می توان سطح دسترسی محتوای اجرایی را محدود کرد، هرچند جلوگیری کامل از XSS همچنان به اعتبارسنجی ورودی ها و مدیریت صحیح خروجی ها نیاز دارد.

`Clickjacking` نوع دیگری از حمله است که در آن کاربر فریب داده می شود تا در صفحه ای ظاهراً عادی، روی محتوایی پنهان یا گمراه کننده کلیک کند. هدرهایی مانند `X-Frame-Options` و دستور `frame-ancestors` در CSP می توانند مشخص کنند که آیا صفحه اجازه دارد داخل یک Frame نمایش داده شود یا خیر. انتخاب تنظیم مناسب به نیاز برنامه برای نمایش در سایت های دیگر بستگی دارد. شناخت این تنظیمات به توسعه دهندگان کمک می کند از نمایش ناخواسته صفحات حساس در قاب های خارجی جلوگیری کنند.

کاربرد X-Content-Type-Options و Subresource Integrity

هدر `X-Content-Type-Options` با مقدار `nosniff` به مرورگر اعلام می کند که نباید نوع محتوای برخی منابع را برخلاف مقدار اعلام شده در هدر `Content-Type` حدس بزند. این تنظیم به کاهش خطرات ناشی از تفسیر نادرست محتوا کمک می کند و یکی از هدرهای امنیتی رایج در برنامه های وب است. برای استفاده صحیح از آن، سرور باید نوع محتوای منابع را نیز به درستی مشخص کند تا مرورگر بتواند فایل ها را مطابق نوع مورد انتظار پردازش کند.

`Subresource Integrity` یا SRI سازوکاری برای بررسی یکپارچگی فایل های خارجی مانند JavaScript و CSS است که از طریق HTML بارگذاری می شوند. در این روش، مقدار Hash مورد انتظار در ویژگی `integrity` قرار می گیرد و مرورگر محتوای دریافت شده را با آن مقایسه می کند. اگر محتوا با مقدار مورد انتظار مطابقت نداشته باشد، مرورگر می تواند از بارگذاری آن جلوگیری کند. این قابلیت به ویژه هنگام استفاده از منابع میزبانی شده در دامنه های دیگر اهمیت دارد و به تشخیص تغییرات ناخواسته در فایل های وابسته کمک می کند.

کاهش افشای اطلاعات سرور با تنظیم هدرهای HTTP

برخی پاسخ های HTTP ممکن است اطلاعاتی درباره فناوری یا نسخه نرم افزار سرور در اختیار کاربران قرار دهند. برای مثال، هدرهایی مانند `Server` یا `X-Powered-By` در بعضی پیکربندی ها می توانند اطلاعاتی درباره زیرساخت برنامه آشکار کنند. محدود کردن این اطلاعات می تواند به کاهش جزئیات قابل استفاده برای شناسایی فناوری های مورد استفاده کمک کند. با این حال، مخفی کردن نسخه نرم افزار جایگزین به روزرسانی امنیتی، پیکربندی صحیح سرور و رفع آسیب پذیری های شناخته شده نیست.

در ASP.NET و ASP.NET Core، کنترل هدرهای پاسخ باید با توجه به محل تولید آن ها انجام شود؛ زیرا برخی هدرها ممکن است توسط خود برنامه، وب سرور یا زیرساخت واسط اضافه شوند. به همین دلیل، صرفاً تغییر کد برنامه همیشه برای حذف تمام اطلاعات موردنظر کافی نیست. بررسی پاسخ های واقعی HTTP و شناخت اجزای دخیل در تولید آن ها به شما کمک می کند تنظیمات امنیتی را دقیق تر انجام دهید و از افشای غیرضروری اطلاعات فنی جلوگیری کنید.