وحید نصیری وحید نصیری
نظرات مطالب
بهبود سرعت نمایش صفحات در ASP.NET MVC با حذف View Engines اضافی
در نگارش‌های اول MVC، موتور View پردازش کننده‌ی صفحات aspx هم ارائه شده بود. این حذف در مطلب جاری، به همین مورد بر می‌گردد و تنها باقی نگه داشتن موتور razor ( برای مثال در تصویر سوم، به دنبال فایل‌های aspx هم می‌گردد که اضافی است). در ASP.NET Core اساسا موتور رسمی برای پردازش صفحات aspx ارائه نشده. بنابراین نیازی به مطلب فوق نیست.
‫۵ سال و ۴ ماه قبل، جمعه ۳ خرداد ۱۳۹۸، ساعت ۱۶:۰۱
مهدی ملائیان مهدی ملائیان
مسیرراه‌ها
بررسی زیرساخت DNTFrameworkCore

قسمت 1 - معرفی و نحوه استفاده از آن

قسمت 2 - طراحی موجودیت‌های سیستم

قسمت 3 - پیاده‌سازی سرویس‌های موجودیت‌ها

قسمت 4 - پیاده‌سازی CRUD API موجودیت‌ها

قسمت 5 - مکانیزم Eventing و استفاده از سرویس‌های موجودیت‌ها 

‎‎‎قسمت 6 - پیاده‌سازی عملیات CRUD موجودیت‌ها با استفاده از ASP.NET Core MVC

قالب‌های تهیه شده مبتنی‌بر DNTFrameworkCore

‎‎‎

- قالب Web API

‫۵ سال و ۷ ماه قبل، یکشنبه ۵ اسفند ۱۳۹۷، ساعت ۱۵:۱۱
وحید نصیری وحید نصیری
نظرات مطالب
IdentityServer قسمت اول
- در قسمت اول به واژه‌هایی مانند «شرکت»، «مرکزی»، «single sign-on»، و «چندین برنامه‌ی مختلف فقط با یک لاگین» که قرار نیست اطلاعات کاربران خودشان را داخل بانک‌های اطلاعاتی خودشان به صورت مجزایی قرار دهند، بیشتر دقت کنید.
- Identity Server برای انتقال و نگهداری اطلاعات موقتی خودش از ترکیب کوکی‌های رمزنگاری شده و همچنین JWT استفاده می‌کند. مثال کاملی در این مورد در سری جدید «امن سازی برنامه‌های ASP.NET Core توسط IdentityServer 4x» با تمام جزئیات ممکن، بررسی شده‌است.
‫۵ سال و ۱۰ ماه قبل، چهارشنبه ۲۱ آذر ۱۳۹۷، ساعت ۰۳:۱۲
مهران موسوی مهران موسوی
مطالب
آشنایی با چالش های امنیتی در توسعه برنامه‌های تحت وب، بخش اول
در پروژه‌های بزرگ نرم افزاری، از قدیم بحث تامین امنیت پروژه، یکی از چالش‌های مهم بوده است. از دیدگاه شخصی بنده، یک مدیر نرم افزار یا حتی یک توسعه دهنده‌ی برنامه‌های تحت وب، لازم است علاوه بر صرف وقت مطالعاتی و آشنایی و تسلط بر مباحث طراحی معماری سیستم‌های تحت وب، که از اهمیت بالا و مقیاس بزرگی برخوردارند آشنایی لازم را با چالش‌های امنیتی در پیاده سازی اینگونه سیستم‌ها داشته باشد. امنیت در یک سیستم بزرگ و ارائه دهنده خدمات، باعث می‌شود تا کاربر علاوه بر یک تجربه کاربری (user experience) خوب از سیستم که حاصل پیاده سازی صحیح سیستم می‌باشد، اعتماد ویژه‌ای به سیستم مذکور داشته باشد. گاها کاربران به علت بی اعتمادی به شرایط امنیتی حاکم بر یک سیستم، از تجربه کاربری خوب یک سیستم چشم پوشی می‌کنند. اهمیت این مسئله تا جاییست که غول‌های تکنولوژی دنیا همچون Google درگیر این چالش می‌باشند و همیشه سعی بر تامین امنیت کاربران علاوه بر ایجاد تجربه کاربری خوب دارند. پس عدم توجه به این موضوع میتواند خسارات وارده جبران ناپذیری را به یک سیستم از جهت‌های مختلف وارد کند.

در این سری از مقالات، بنده سعی دارم تا حد توان در رابطه با چالش‌های امنیتی موجود در زمینه توسعه برنامه‌های تحت وب، مطالبی را منتشر کنم. از این رو امیدوارم تا این سری از مقالات برای دوستان مفید واقع گردد.

در این سری از مقالات چالش‌های امنیتی زیر مورد بحث و بررسی واقع خواهند گردید 

XSS , LDAPi ,RFI ,LFI ,SQLi ,RFD ,LFD ,SOF ,BSQLI ,DNN ,BOF ,CRLF ,CSRF ,SSI ,PCI ,SCD ,AFD ,RCE

در بخش اول از این سری مقالات ، به بررسی آسیب پذیری Cross-site scripting میپردازیم .

واژه XSS مخفف Cross-site scripting، نوعی از آسیب پذیریست که در برنامه‌های تحت وب نمود پیدا میکند. به طور کلی و خلاصه، این آسیب پذیری به فرد نفوذ کننده اجازه تزریق اسکریپت‌هایی را به صفحات وب، می‌دهد که در سمت کاربر اجرا می‌شوند ( Client Side scripts ) . در نهایت این اسکریپت‌ها توسط سایر افرادی که از صفحات مورد هدف قرار گرفته بازدید می‌کنند اجرا خواهد شد.

هدف از این نوع حمله :

بدست آوردن اطلاعات کوکی‌ها و سشن‌های کاربران ( مرتبط با آدرسی که صفحه آلوده شده در آن قرار دارد ) است. سپس فرد نفوذ کننده متناسب با اطلاعات بدست آمده می‌تواند به اکانت شخصی کاربران مورد هدف قرار گرفته، نفوذ کرده و از اطلاعات شخصی آن‌ها سوء استفاده کند .

به صورت کلی دو طبقه بندی برای انواع حملات Cross-site scripting وجود دارند.

حملات XSS ذخیره سازی شده ( Stored XSS Attacks ) :

در این نوع ، کدهای مخرب تزریق شده، در سرور سایت قربانی ذخیره میشوند. محل ذخیره سازی می‌تواند دیتابیس سایت یا هر جای دیگری که داده‌ها توسط سایت یا برنامه تحت وب بازیابی می‌شوند و نمایش داده می‌شوند باشد. اما اینکه چگونه کدهای مخرب در منابع یاد شده ذخیره میشوند؟

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

حملات XSS منعکس شده ( Reflected XSS Attacks ) :

در این نوع از حمله، هیچ نوع کد مخربی در منابع ذخیره سازی وبسایت یا اپلیکیشن تحت وب توسط فرد مهاجم ذخیره نمی‌شود ! بلکه از ضعف امنیتی بخش‌هایی همچون بخش جستجو وب سایت، بخش‌های نمایش پیغام خطا و ... استفاده میشود ... اما به چه صورت؟

در بسیاری از سایت‌ها، انجمن‌ها و سیستم‌های سازمانی تحت وب، مشاهده می‌شود که مثلا در بخش جستجو، یک فیلد برای وارد کردن عبارت جستجو وجود دارد. پس از وارد کردن عبارت جستجو و submit فرم، علاوه بر نمایش نتایج جستجو، عبارت جستجو شده نیز به نمایش گذاشته میشود و بعضا در بسیاری از سیستم‌ها این عبارت قبل از نمایش اعتبار سنجی نمی‌شود که آیا شامل کدهای مخرب می‌باشد یا خیر. همین امر سبب میشود تا اگر عبارت جستجو شامل کدهای مخرب باشد، آن‌ها به همراه نتیجه‌ی جستجو اجرا شوند.

اما این موضوع چگونه مورد سوء استفاده قرار خواهد گرفت؟ مگر نه اینکه این عبارت ذخیره نمیشود پس با توضیحات فوق، کد فقط بر روی سیستم مهاجم که کد جستجو را ایجاد می‌کند اجرا می‌شود، درست است؟ بله درست است ولی به نقطه ضعف زیر توجه کنید ؟ 

www.test.com/search?q=PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpOzwvc2NyaXB0Pg==

این آدرس حاصل submit  شدن فرم جستجو وب‌سایت test (نام وب‌سایت واقعی نیست و برای مثال است )  و ارجاع به صفحه نتایج جستجو میباشد. در واقع این لینک برای جستجوی یک کلمه یا عبارت توسط این وبسایت تولید شده و از هر کجا به این لینک مراجعه کنید عبارت مورد نظر مورد جستجو واقع خواهد شد. در واقع عبارت جستجو به صورت Base64 به عنوان یک query String به وبسایت ارسال می‌شود؛ علاوه بر نمایش نتایج، عبارت جستجو شده نیز به کاربر نشان داده شده و اگر آسیب پذیری مورد بحث وجود داشته باشد و عبارت شامل کدهای مخرب باشد، کدهای مخرب بر روی مرورگر فردی که این لینک را باز کرده اجرا خواهد شد!

در این صورت کافیست فرد مهاجم لینک مخرب را به هر شکلی به فرد مورد هدف بدهد ( مثلا ایمیل و ... ). حال در صورتیکه فرد لینک را باز کند (با توجه به اینکه لینک مربوط به یک سایت معروف است و عدم آگاهی کاربر از آسیب پذیری موجود در لینک، باعث باز کردن لینک توسط کاربر می‌شود)، کدها بر روی مرورگرش اجرا شده و کوکی‌های سایت مذکور برای مهاجم ارسال خواهد شد ... به این نوع حمله XSS   ، نوع انعکاسی می‌گویند که کاملا از توضیحات فوق الذکر، دلیل این نامگذاری مشخص می‌باشد.

اهمیت مقابله با این حمله :

برای نمونه این نوع باگ حتی تا سال گذشته در سرویس ایمیل یاهو وجود داشت. به شکلی که یکی از افراد انجمن hackforums به صورت Private این باگ را به عنوان Yahoo 0-Day XSS Exploit در محیط زیر زمینی و بازار سیاه هکرها به مبلغ چند صد هزار دلار به فروش می‌رساند. کاربران مورد هدف کافی بود تا فقط یک ایمیل دریافتی از هکر را باز کنند تا کوکی‌های سایت یاهو برای هکر ارسال شده و دسترسی ایمیل‌های فرد قربانی برای هکر فراهم شود ... ( در حال حاظر این باگ در یاهو وجو ندارد ).

چگونگی جلوگیری از این آسیب پذیری

در این سری از مقالات کدهای پیرامون سرفصل‌ها و مثال‌ها با ASP.net تحت فریم ورک MVC و به زبان C# خواهند بود. هر چند کلیات مقابله با آسیب پذیری هایی از این دست در تمامی زبان‌ها و تکنولوژی‌های تحت وب یکسان میباشند.

خوشبختانه کتابخانه‌ای قدرتمند برای مقابله با حمله مورد بحث وجود دارد با نام AntiXSS که میتوانید آخرین نسخه آن را با فرمان زیر از طریق nugget به پروژه خود اضافه کنید. البته ذکر این نکته حائز اهمیت است که Asp.net و فریم ورک MVC به صورت توکار تا حدودی از بروز این حملات جلوگیری می‌کند. برای مثال به این صورت که در View ‌ها شما تا زمانی که از MvcHtmlString استفاده نکنید تمامی محتوای مورد نظر برای نمایش به صورت Encode شده رندر می‌شوند. این داستان برای Url ‌ها هم که به صورت پیش فرض encode میشوند صدق می‌کند. ولی گاها وقتی شما برای ورود اطلاعات مثلا از یک ادیتور WYSWYG استفاده می‌کنید و نیاز دارید داده‌ها را بدون encoding رندر کنید. آنگاه به ناچار مجاب بر اعمال یک سری سیاست‌های خاص‌تر بر روی داده مورد نظر برای رندر می‌شوید و نمی‌توانید از encoding توکار فوق الذکر استفاده کنید. آنگاه این کتابخانه در اعمال سیاست‌های جلوگیری از بروز این آسیب پذیری می‌تواند برای شما مفید واقع شود. 

 PM> Install-Package AntiXSS
این کتابخانه مجموعه‌ای از توابع کد کردن عبارات است که از مواردی همچون Html, XML, Url, Form, LDAP, CSS, JScript and VBScript پشتیبانی می‌کند. استفاده از آن بسیار ساده می‌باشد. کافیست ارجاعات لازم را به پروژه خود افزوده و به شکل زیر از توابع ارائه شده توسط این کتابخانه استفاده کنید:  
…
var reviewContent = model.UserReview;
reviewContent = Microsoft.Security.Application.Encoder.HtmlEncode(review);
…

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

‫۱۰ سال و ۱ ماه قبل، جمعه ۱۱ مهر ۱۳۹۳، ساعت ۱۲:۲۵
وحید نصیری وحید نصیری
مطالب
نمایش حجم ViewState برنامه‌های ASP.NET WebForms

امکان اندازه گیری دقیق حجم ViewState در برنامه‌های ASP.NET WebForms وجود دارد (+) ، اما خوب، این روش یک ایراد مهم هم دارد. چند نفر حاضرند تمام صفحات خود را ویرایش کرده و ارث بری ذکر شده را پیاده سازی کنند؟
یک روش دیگر اعمال آن به تمام صفحات، استفاده از پوشه‌ی استاندارد App_Browsers و سپس ایجاد فایلی مانند ViewStateManager.browser می‌باشد:
<!--Applies to all pages-->
<browsers>
<browser refID="Default">
  <controlAdapters>
    <adapter controlType="System.Web.UI.Page" adapterType="ViewStateManagerCore.SomeClass" />
  </controlAdapters>
</browser>
</browsers>
به این صورت ارث بری مورد نظر به صورت خودکار بر روی تمام صفحات اعمال خواهد شد.
علاوه بر این دو روش (ارث بری دستی و ارث بری خودکار)، افزونه‌ای هم برای فایرفاکس جهت نمایش حجم ViewState صفحات طراحی شده است که از آدرس زیر قابل دریافت می‌باشد :




این موضوع چه اهمیتی دارد؟
ممکن است کاربران سایت شما گاهی از اوقات در بعضی از صفحات با خطای "Validation of viewstate MAC failed" مواجه و متوقف شوند. عموما حجم بالای ViewState این مشکل را درست می‌کند. حجم ViewState بالا است (چند صد کیلوبایت ...)، ‌صفحه دیر رندر می‌شود یا هنوز کامل نشده، شخص صفحه را متوقف می‌کند. ASP.NET در این حالت اجازه‌ی ارسال اطلاعات از این صفحه‌ی ناقص را به دلایل امنیتی نمی‌دهد که خوب است (شاید جعل شده باشد؟).


پ.ن.
راه حل پیشنهادی مایکروسافت جهت حل این مشکل (شروع شده از سال 2007)، ارتقاء برنامه‌های شما به ASP.NET MVC می‌باشد :)

‫۱۳ سال و ۱۰ ماه قبل، یکشنبه ۱۹ دی ۱۳۸۹، ساعت ۱۳:۳۶
وحید نصیری وحید نصیری
نظرات مطالب
مهارت‌های تزریق وابستگی‌ها در برنامه‌های NET Core. - قسمت چهارم - پرهیز از الگوی Service Locator در برنامه‌های وب
ارتقاء به ASP.NET Core 3.0: محدود شدن امکان تزریق وابستگی‌ها در سازنده‌ی کلاس آغازین برنامه

یکی از تغییرات مهم ASP.NET Core 3.0 نسبت به نگارش‌های قبلی، جنریک شدن Host آن است (چون حالت‌های هاستینگ بیشتری را نسبت به حالت صرف MVC پشتیبانی می‌کند). به این ترتیب HostBuilder نگارش 2x:
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
                 WebHost.CreateDefaultBuilder(args)
                 .UseStartup<Startup>();
اکنون در نگارش 3x به این صورت در آمده‌است:
public static IHostBuilder CreateHostBuilder(string[] args) =>
               Host.CreateDefaultBuilder(args)
                     .ConfigureWebHostDefaults(webBuilder =>
                     {
                        webBuilder.UseStartup<Startup>();
                     });
این مورد، یک تغییر مهم را هم در وضعیت تزریق وابستگی‌های سفارشی در کلاس آغازین برنامه ایجاد کرده‌است: در نگارش 3x، فقط و فقط سرویس‌های IHostEnvironment ،IWebHostEnvironment و IConfiguration را می‌توانید به سازنده‌ی کلاس آغازین آن تزریق کنید.
علت اینجا است که در ASP.NET Core 3x، یک باگ بسیار مهم سیستم تزریق وابستگی‌های ASP.NET Core برطرف شده‌است: اکنون فقط یک dependency injection container به ازای کل برنامه‌ی ASP.NET Core 3x ساخته می‌شود. در نگارش‌های قبلی، یک container برای برنامه و یک container مجزا برای host تولید می‌شدند. در این حالت اگر یک سرویس Singleton را در فایل program.cs معرفی می‌کردید:
WebHost.CreateDefaultBuilder()
             .UseStartup<Startup>()
             .ConfigureServices(services => 
                     services.AddSingleton<MySingleton>())
             .Build()
             .Run();
برخلاف تصور، این سرویس Singleton رفتار نمی‌کرد؛ چون همانطور که عنوان شد، دو container، برنامه را مدیریت می‌کردند (یعنی دوبار توسط دو ظرف متفاوت نگهدارنده‌ی اشیاء، وهله سازی می‌شد) که اکنون در نگارش 3x به یک مورد کاهش یافته‌است.
در اینجا هرچند متد ConfigureServices وجود دارد، اما اگر از آن استفاده کنید، سرویس معرفی شده‌ی توسط آن، در سازنده‌ی کلاس Startup شناسایی نمی‌شود.
‫۵ سال و ۲ ماه قبل، یکشنبه ۲۷ مرداد ۱۳۹۸، ساعت ۰۰:۲۸
وحید نصیری وحید نصیری
اشتراک‌ها
آموزش 9 ساعته ASP.NET Core MVC

Learn ASP.NET Core MVC (.NET 8) - The Complete Guide

In this Complete Guide course, we will learn MVC (Model-View-Controller) with .NET 8.

When we are working with .NET Core Web Applications,  there are two common ways of building website.
1. MVC (Model-View-Controller) Web Application
2. Razor Pages Web Application

In this course we will learn the basics of .NET Core (.NET 8) and then learn basics of MVC and Razor Pages as we enhance MVC Application to a more complex final project!.

Topics Covered
- Fundamentals of .NET Core
- MVC Application
- Razor Pages
- Entity Framework Core
- Repository Pattern
- ViewBag
- ViewData
- TempData
- Taostr and sweet alerts in .NET Core
- Datatables in .NET Core
- Assignments
- Errors and how to solve them! 

آموزش 9 ساعته ASP.NET Core MVC
‫۱ سال و ۵ ماه قبل، چهارشنبه ۳۰ فروردین ۱۴۰۲، ساعت ۰۴:۰۳
وحید نصیری وحید نصیری
اشتراک‌ها
سری طراحی چند مستاجری با ASP.NET Core

ASP.NET Core Multi-tenancy: Creating theme-able applications
ASP.NET Core Multi-tenancy: Tenant lifetime
Building multi-tenant applications with ASP.NET Core (ASP.NET 5)
Using Google Analytics in Multi-tenant applications
Introducing SaasKit - Multi-tenancy made easy

سری طراحی چند مستاجری با ASP.NET Core
‫۸ سال و ۸ ماه قبل، دوشنبه ۲۶ بهمن ۱۳۹۴، ساعت ۰۴:۰۱