نظرات مطالب
بررسی روش آپلود فایل‌ها در ASP.NET Core
برنامه‌های هاست شده‌ی در IIS، از لحاظ خواندن و نوشتن فایل‌ها، تفاوتی با سایر برنامه‌های ویندوزی ندارند. هر برنامه‌ی ویندوزی بر اساس سطوح دسترسی کاربری که تحت مجوز آن اجرا می‌شود، یکسری از دسترسی‌ها را پیدا می‌کند، یا خیر. برای مثال به صورت پیش‌فرض کاربری که برنامه‌های ASP.NET، بر اساس آن اجرا می‌شوند، همان کاربر Application pool آن‌ها است و این کاربر هیچ نوع دسترسی نوشتنی را در هیچکدام از پوشه‌های سیستم، ندارد. به همین جهت حتی اگر سعی کنید در پوشه‌ی خود برنامه هم فایلی را آپلود کنید، با خطای access is denied متوقف خواهید شد. همان کاری را که برای دادن دسترسی نوشتن، به کاربر Application pool برنامه‌ی خود جهت آپلود فایل‌های فعلی انجام داده‌اید، باید برای هر پوشه‌ی دیگری که مدنظر شما است نیز انجام دهید و از این لحاظ تفاوتی نمی‌کند (مهم نیست که در این درایو باشد یا در آن درایو؛ مهم دسترسی نوشتن است):
Right click on the folder -> Properties -> Security tab -> Click at Edit button ->
Enter `IIS AppPool\DefaultAppPool` user (IIS AppPool\<app_pool_name>) -> Click at Check names -> OK ->
Then give it `write` or other permissions.
نظرات مطالب
EF Code First #9
من یک سری مدل به شکل زیر دارم:
    public class Context : DbContext
    {
        public Context():base("Server=.;Database=EfTest;Trusted_Connection=True;Integrated Security=true;")
        {
            
        }

        public DbSet<Student> Students { get; set; }
        public DbSet<Teacher> Teachers { get; set; }

    }


    public class Person
    {
        public int Id { get; set; }
        public DateTime InsertTime { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }

    }


    public class Student:Person
    {
        public string Student1 { get; set; }
    }

    public class Teacher:Person
    {
        public string Teacher1 { get; set; }

    }
بدون هیچ تنظیماتی، یعنی طبق تعاریف بالا الان باید حالت به شکل TPH باشد ولی در ساخت نهایی دو جدول دانش آموز و معلم تشکیل میشه. من در این مدتی که ef کار کردم روی این حالت بودم و راضی هستم ولی برای یکی از دوستان EF سعی داره جدولی به اسم People رو از روی Person تشکیل بده.
نظرات مطالب
بررسی فرمت کوکی‌های ASP.NET Identity
با سلام
آقای نصیری در آخرین سوال گفتید که باید از UpdateSecurityStampAsync استفاده بشه. من تو برنامم ، بر اساس هر Application_AuthenticateRequest میام چک میکنم که اگر کاربر حذف یا قفل یا ... بود به صورت خودکار Signout بشه. با توجه به نکته امنیتی که که شما گفتید باید اینجا هم از  UpdateSecurityStampAsync  استفاده بشه ، من به این صورت استفاده کردم :


   public class MvcApplication : HttpApplication
    {
        public MvcApplication()
        {
            var wrapper = new EventHandlerTaskAsyncHelper(AuthenticateRequest);
            AddOnAuthenticateRequestAsync(wrapper.BeginEventHandler, wrapper.EndEventHandler);
        }
        private async Task AuthenticateRequest(object sender, EventArgs e)
        {
            if (Context.User == null)
                return;

            //bla bla

            if (هرچیزی که مجاز نباشد)
            {
                var authenticationManager = ProjectObjectFactory.Container.GetInstance<IAuthenticationManager>();
                authenticationManager.SignOut
                (
                    DefaultAuthenticationTypes.ExternalCookie,
                    DefaultAuthenticationTypes.ApplicationCookie
                );
                FormsAuthentication.SignOut();
                await userService.UpdateSecurityStampAsync(userId);
            }
        }
    }

در عمل چک کردم جواب داد ، البته مجبور بودم از یک EventHandlerTaskAsyncHelper استفاده کنم چون نمیشد تو خود متد Application_AuthenticateRequest متدهای Async تعریف کرد.

سوال من اینه ، آیا اصلا نیاز هست در اینجا هم security stamp رو آپدیت کنیم ؟ یا اصلا این روشی که من رفتم از نظر امنیتی درست هست یا خیر.

با تشکر
نظرات مطالب
اعمال تزریق وابستگی‌ها به مثال رسمی ASP.NET Identity
- در سازنده‌ی کلاس ApplicationDbContext ، به connectionString1 اشاره شده که تعریف آن در فایل web.config برنامه موجود است. به عبارتی در این مثال چنین رشته‌ی اتصالی تعریف شده‌است:
<add name="connectionString1"
connectionString="Data Source=(local);Initial Catalog=TestDbIdentity;Integrated Security = true" 
providerName="System.Data.SqlClient" />
بنابراین بانک اطلاعاتی پیش فرض آن TestDbIdentity نام دارد (جهت اتصال به آن، برای مشاهده جداول و یا تغییر و ثبت اطلاعات). این رشته اتصالی هم مخصوص SQL Server تنظیم شده‌است که می‌توانید توسط management studio و یا سایر ابزارهای مشابه، همانند قبل به آن متصل شوید.
- «در پوشه App_Data حذف کردم» ... از مثال نهایی کامل شده استفاده کنید (^) و نیازی به تکرار این مراحل نیست تا خطای یافت نشدن dbcontext را دریافت نکنید.
- برای ReCreate فقط کافی هست که بانک اطلاعاتی TestDbIdentity را drop کنید. بعد برنامه را مجددا از نو اجرا کنید. چون مراحل migrations آن به حالت خودکار تنظیم شده‌است، بانک اطلاعاتی را به صورت خودکار ایجاد می‌کند یا تغییرات کلاس‌های دومین برنامه را به صورت خودکار به بانک اطلاعاتی اعمال خواهد کرد.
- برای آشنایی بیشتر با مباحث تعریف رشته اتصالی EF Code First و مباحث Migrations آن، سری EF Code First را در سایت یکبار مطالعه کنید.
نظرات مطالب
آشنایی با TransactionScope
برای قسمت اول مطالب شما باید عنوان کنم که برای Nested Transaction محدودیت خاصی تعیین نشده است. تا زمانی که Timeout رخ ندهد و همه تراکنش‌ها به درستی Commit شوند مشکلی پیش نخواهد آمد. ولی باید به این نکته دقت داشت که اگر هنگام استفاده از تراکنش‌ها تو درتو یکی از تراکنش‌ها به هر دلیلی موفقیت آمیز نباشد یا زمان آن سپری شود یا زمان انجام کل تراکنش به اتمام برسد Exceptionتولید خواهد شد و تمام عملیات RollBack می‌شوند.البته می‌توان برای مدیریت این تراکنش‌ها از TransactionScopeOption که در مطلب عنوان کردم استفاده کنید. اما در توضیح قسمت دوم مطالب شما باید عنوان کنم که برای اجرای تراکنش به این روش نیاز به مجوز اجرای تراکنش از راه دور است. این کار هم از طریق تنظیمات Remote Access MSDTC میسر می‌شود. برای انجام این کار از قسمت زیر استفاده کنید.
ComponentServieces/Computers/MyComputer/Distributed Transaction Coodrinator/Local DTC
بر روی Local DTC کلیک راست کنید و گزینه‌ی Properties رو بزنید. از برگه Security تیک قسمت‌های زیر رو بزنید.
1-Notwork DTC Access
2- Allow Remote Client
3- Allow Remote Administration
4-Allow Inbound
5-Allow OutBound
6 -No Authentication Required.
خود من به شخصه از این روش برای اجرای سرویس‌های WCF به صورت تراکنش استفاده می‌کنم.
نظرات مطالب
آشنایی با Refactoring - قسمت 4
در مورد Active Record موافقم و هرگز هم از این الگو استفاده نکرده‌ام. در مورد Attached Property هم با مکانیزم آن آشنا هستم و استفاده‌های متفاوت تری از Layouting همچون اعمال Security توسط AP بر روی یک المان را تجربه کردم که انصافاً طراحی هوشمندانه AP را برایم آشکار کرد اما تصور می‌کنم برخی از موارد مانند hiding و حتی overriding در مورد AP و Dependency Property ها رعایت نمی‌شود (شاید انتظار overriding درست نباشد جون AP و DP ففط مخصوص ذخیره‌سازی هستند). مثلا شما می‌توانید با دستور GetValue مقدار یک خصیصه از جنس DP یک شی را در خارج از آن شی به دست آورید در حالی که اگر بخواهید از خاصیت Binding استفاده کنید استفاده از DP توصیه شده. البته امتحان نکرده‌ام اما فکر می‌کنم با protected کردن متغییرهای static مربوط به DP به این حالت دست یافت اما فکر می‌کنم بازهم از سطح private محروم می‌مانیم.

در نهایت در مورد Active Record و Entity ها صحبتهایتان را با این جمله کامل کردید که: «این نوع کلاس‌ها فقط اهداف display / reference دارند و نه بیشتر ... این‌ کلاس‌ها (کلاسهایی که در پست تعریف شده بود/م) هیچکدام در رده تعریف POCO یا Plain old .Net classes قرار نمی‌گیرند.»
نظرات مطالب
مقایسه امنیت Oracle11g و SQL server 2008 از دید آمار در سال 2009
کم شدن باگ‌های امنیتی مایکروسافت در چند سال اخیر سه دلیل عمده داشته:
- استفاده بیشتر از دات نت فریم ورک در محصولات عمده خودش (اس کیوال سرور، exchange server، SharePoint و ...). برای مثال دات نت فریم ورک به حملات سرریز بافر (اگر کد خالص دات نتی باشد و از API ویندوز به صورت ناشیانه استفاده نکرده باشد) مقاوم است و خیلی مسایل دیگر که به صورت توکار در دات نت لحاظ شده.
- وضع کردن یک سری قوانین سفت و سخت در مورد کتابخانه‌ها و توابع C مورد استفاده در محصولات نوشته شده با سی و CPP
https://www.dntips.ir/2009/05/bannedh.html
- تهیه برنامه‌هایی که کار آنالیز خودکار فایل‌های باینری و همچنین سورس‌ کدهای سازمان آن‌را انجام می‌دهند. به این صورت قبل از اینکه دیگران از سیستم‌های آن‌ها باگ‌های متداول را درآورند، خودشان نسبت به اینکار اقدام می‌کنند.
http://blogs.msdn.com/bharry/archive/2009/10/02/two-free-security-tools-from-microsoft-sdl-team.aspx
https://www.dntips.ir/2009/11/blog-post.html
نظرات مطالب
خواندنی‌های 16 اردیبهشت
سلام
به خاطر کتاب خوبتون در رابطه با asp ممنونم
شرمنده از اینکه مزاحم شدم . یه مشکلی پیدا کردم که نمی تونم حلش کنم و هرچقدر هم سرچ کردم و توی دولوپرسنتر هم گذاشتم جوابمو پیدا نکردم برای همین هم مزاحم شما شدم
اگه لطف کنین و راهنمایی ام کنین ممنون میشم


من دارم یه فروشگاه الکترونیکی مینویسم و این فروشگاه دیتابیسی با جدول های زیر داره:
user
product
category
order

و در قسمت user علاوه بر مشخصات عمومی کاربر، username , pass , email شخص هم هست

از طرف دیگه میخوام از form_base security که توسط ویژوال استودیو فراهم میشه (asp.net configuration موجود در سلوشن اکسپلورر) استفاده کنم و این خودش باعث ایجاد یه دیتابیس دیگه میشه و برنامه من در حقیقت دارای دو تا دیتابیس میشه

حالا من باید چیکار کنم؟
منظورم اینه که pass , email در جدول مربوط به دیتابیس اصلی آیا باید حذف بشه و از اونایی که در دیتابیس دوم هست استفاده کنم و فیلد مربوط به username باید در هر دوتا باقی بمونه و با مقایسه اونا با هم متوجه بشم که کدام پسورد و ایمیل مال کدوم کاربره؟

یا فقط از دیتابیس دوم استفاده کنم و چهار تا جدول مربوط به دیتابیس اصلی را هم در همین دیتابیس دومی ادغام کنم(اگه بشه)؟



ممنون
نظرات مطالب
رمزنگاری کانکشن استرینگ در ASP.Net
سلام آقای نصیری.خوبین؟من چجوری میتونم مراتب تشکرم روبه شما اعلام کنم.فقط میتونم دعا کنم خدا کار شما رو همیشه راه بندازه.ان شا الله.
من برای انکریپشن از این کتابخونه استفاده میکنم:
http://www.codeproject.com/KB/security/SimpleEncryption.aspx
من برای ویندوز یه فایل ایکس ام ال برای پیکر بندی ایجاد میکنم(شبیه app.config) که مواردی که برای برنمم لازم هست رو با الگوریتم TripleDES و با یه رشته عجیب غریب که توش کاراکترهای عجیب غریب داره کد میکنم.الان موردی که هست اینه که من برای پروژه DAL ام باید این فایل رو باز کنم رشته کانکشن استرینگ مورد نظر رو دیکد کنم و بعد ازش استفاده کنم.آیا این قیمتیه که باید برای امنیت بدیم؟راه بهتری وجود داره؟یعنی میشه یه بار این رشته رو دیکد کرد و در حافظه نگه داشت؟اما خوب برای این کار باید همیشه یه نمونه از کلاس DAL وجود داشته باشه.
برای نت هم آیا به صرفه هست یه پروایدر دیگه برای دیکد بنویسیم که از غیر قابل برگشت بودن اون مظمئن بشیم؟
ممنون از لطف و محبت شما
همیشه موفق باشید
نیما
مطالب
فعال‌سازی HSTS در ASP.NET Core
برای فعال‌سازی SSL در ASP.NET Core می‌توانیم از ویژگی RequireHttps برای کنترلرها و همچنین اکشن‌متدها استفاده کنیم:
[RequireHttps]
public class AccountController : Controller
{
    public IActionResult Login()
    {
        return Content("Login Page");
    }
}
اکنون اگر پروژه را اجرا کنید، خروجی به صورت زیر خواهد بود و اگر به آدرس Account/Login مراجعه کنید، چیزی در خروجی نمایش داده نخواهد شد:

علت آن نیز این است که اگر درخواست HTTPS نباشد، یک Permanent Redirect به همان URL خواهیم داشت؛ زیرا بر روی پورتی که پروژه توسط آن اجرا شده‌است، هیچ certificateی نصب نشده‌است. در ادامه می‌خواهیم یک self-signed certificate تستی را برای اجرای پروژه ایجاد کنیم. 
توسط دستورات زیر می‌توانید یک certificate را برای localhost ایجاد کنید:
$ openssl genrsa -out key.pem 2048
$ openssl req -new -sha256 -key key.pem -out csr.csr
$ openssl req -x509 -sha256 -days 365 -key key.pem -in csr.csr -out certificate.pem
openssl pkcs12 -export -out localhost.pfx -inkey key.pem -in certificate.pem
با اجرای دستورات فوق، باید یک فایل جدید با نام localhost.pfx و تعدادی فایل دیگر، درون پروژه ایجاد شده باشند:

اکنون باید Kestrel را از وجود این certificate مطلع کنیم. برای انجام اینکار ابتدا باید پکیج زیر را نصب کنیم:
$ dotnet add package Microsoft.AspNetCore.Server.Kestrel.Https
سپس فایل Program.cs را به صورت زیر تغییر دهیم:
namespace testingSSL
{
    public class Program
    {
        public static void Main(string[] args)
        {
            BuildWebHost(args).Run();
        }

        public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseKestrel(options =>
                {
                    options.Listen(IPAddress.Any, 8080);
                    options.Listen(IPAddress.Any, 443,
                        listenOptions => listenOptions.UseHttps("localhost.pfx", "qwe123456"));
                })
                .UseStartup<Startup>()
                .Build();
    }
}
در این حالت با مراجعه به کنترلری که با ویژگی RequireHttps مزین شده‌است، به صورت خودکار، درخواست به نسخه HTTPS هدایت خواهد شد:

البته تا اینجا، هدف بررسی ویژگی RequireHttps بود؛ طبیعتاً به SSL در حین Development نیازی نخواهید داشت. در نتیجه می‌توانیم به صورت Global تمامی کنترلرها را در زمان Production به ویژگی گفته شده مزین کنیم:

private readonly IHostingEnvironment _env;
public Startup(IConfiguration configuration,
IHostingEnvironment env)
{
    Configuration = configuration;
    _env = env;
}

public IConfiguration Configuration { get; }

// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

    if (!_env.IsDevelopment())
        services.Configure<MvcOptions>(o => o.Filters.Add(new RequireHttpsAttribute()));
}


(Http Strict Transport Security (HSTS

هدایت کردن خودکار درخواست از حالت HTTP به HTTPS، توسط خیلی از سایت‌ها انجام می‌شود:

البته این روش بهتر از استفاده نکردن از SSL است؛ اما در نظر داشته باشید که همیشه اولین درخواست به صورت رمزنگاری نشده ارسال خواهد شد. فرض کنید در یک محیط پابلیک از طریق WiFi به اینترنت متصل شده‌ایم. شخصی (هکر) که بر روی مودم کنترل دارد، طوری WiFi را پیکربندی کرده‌است که به جای آدرس اصلی که در تصویر مشاهده می‌کنید، یک نسخه جعلی از سایت باز شود؛ به طوریکه URL همانند URL اصلی باشد. در این‌حالت کاربر به جای اینکه نام‌کاربری و کلمه‌عبور را وارد سایت اصلی کند، آن را درون سایت جعلی وارد خواهد کرد. برای حل این مشکل می‌توانیم وب‌سایت‌مان را طوری تنظیم کنیم که هدر Strict-Transport-Security را به هدر اولین responseی که توسط مرورگر دریافت می‌شود اضافه کند:

Strict-Transport-Security: max-age=31536000

بنابراین مرورگر وب‌سایت را درون یک لیست internal به مدت یکسال (مقدار max-age) نگهداری خواهد کرد؛ در طول این زمان به هیچ درخواست ناامنی اجازه داده نخواهد شد. به این قابلیت HSTS گفته می‌شود. البته ASP.NET Core به صورت توکار روشی را جهت اضافه کردن این هدر ارائه نداده است؛ اما می‌توانیم خودمان یک Middleware سفارشی را به pipeline اضافه کنیم تا اینکار را برایمان انجام دهد:

namespace testingSSL.Middleware
{
    public class HstsMiddleware
    {
        private readonly RequestDelegate _next;
        public HstsMiddleware(RequestDelegate next)
        {
            _next = next;
        }

        public Task Invoke(HttpContext context)
        {
            if (!context.Request.IsHttps)
                return _next(context);

            if (IsLocalhost(context))
                return _next(context);

            context.Response.Headers.Add("Strict-Transport-Security", "max-age=31536000");

            return _next(context);
        }
        private bool IsLocalhost(HttpContext context)
        {
            return string.Equals(context.Request.Host.Host, "localhost", StringComparison.OrdinalIgnoreCase);
        }
    }
}


یا اینکه می‌توانیم از کتابخانه NWebSec استفاده کنیم:

$ dotnet add package NWebsec.AspNetCore.Middleware

برای استفاده از آن نیز خواهیم داشت:

app.UseHsts(h => h.MaxAge(days: 365));


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

app.UseHsts(h => h.MaxAge(days: 365).Preload());

در اینحالت حتی اگر کسی به وب‌سایت شما مراجعه نکند، مرورگر می‌داند که باید از HTTPS استفاده کند. زیرا این لیست به صورت توکار درون مرورگر تعبیه شده‌است. بنابراین در این‌حالت مطمئن خواهیم شد که تمامی connectionها به سایت‌مان امن می‌باشند.


دریافت کدهای مطلب جاری (+)