وحید محمدطاهری وحید محمدطاهری
اشتراک‌ها
Visual Studio 2019 version 16.4.6 منتشر شد

Top Issues Fixed in Visual Studio 2019 version 16.4.6

Security Advisory Notice

  • CVE-2020-0793 & CVE-2020-0810 Diagnostics Hub Standard Collector Service Elevation of Privilege Vulnerability
  • CVE-2020-0884 Spoofing vulnerability when creating Outlook Web -Add-in
  • CVE-2020-0789 Visual Studio Extension Installer Service Denial of Service Vulnerability
Visual Studio 2019 version 16.4.6 منتشر شد
‫۴ سال و ۷ ماه قبل، چهارشنبه ۲۱ اسفند ۱۳۹۸، ساعت ۰۳:۰۱
وحید محمدطاهری وحید محمدطاهری
اشتراک‌ها
18.Visual Studio 2017 15.9 منتشر شد

Issues Fixed in 15.9.18

  • May allow mitigation of a Per-Monitor awareness related crash in Visual Studio

Security Advisory Notices

18.Visual Studio 2017 15.9 منتشر شد
‫۴ سال و ۱۰ ماه قبل، چهارشنبه ۲۰ آذر ۱۳۹۸، ساعت ۱۸:۲۶
وحید محمدطاهری وحید محمدطاهری
اشتراک‌ها
Visual Studio 2019 version 16.2.2 منتشر شد

Top Issues Fixed in Visual Studio 2019 version 16.2.2

Security Advisory Notices

CVE-2019-1211 Git for Visual Studio Elevation of Privilege Vulnerability

An elevation of privilege vulnerability exists in Git for Visual Studio when it improperly parses configuration files. An attacker who successfully exploited the vulnerability could execute code in the context of another local user. To exploit the vulnerability, an authenticated attacker would need to modify Git configuration files on a system prior to a full installation of the application. The attacker would then need to convince another user on the system to execute specific Git commands. The update addresses the issue by changing the permissions required to edit configuration files. 

Visual Studio 2019 version 16.2.2 منتشر شد
‫۵ سال و ۲ ماه قبل، پنجشنبه ۲۴ مرداد ۱۳۹۸، ساعت ۰۲:۵۰
وحید محمدطاهری وحید محمدطاهری
اشتراک‌ها
12.Visual Studio 2017 15.9 منتشر شد

Issues Fixed in 15.9.12

These are the customer-reported issues addressed in 15.9.12:

Security Advisory Notices

12.Visual Studio 2017 15.9 منتشر شد
‫۵ سال و ۵ ماه قبل، چهارشنبه ۲۵ اردیبهشت ۱۳۹۸، ساعت ۰۲:۴۰
معین تاجیک معین تاجیک
اشتراک‌ها
API نویسی اصولی و حرفه ای در ASP.NET Core

Professional REST API design with ASP.NET Core and WebAPI

This project is an example of lightweight and extensible infrastructure for building RESTful Web API with ASP.NET Core.

This example contains a number of tricks and techniques which I've learned while building APIs in ASP.NET Core.

Techniques and Features

  •  JWT Authentication
  • Secure JWT using Encryption (JWE)
  • Logging to File, Console and Database using Elmah & NLog
  • Logging to sentry.io (Log Management System)
  • Exception Handling using Custom Middleware
  • Automatic Validation
  • Standard API Resulting
  • Dependency Injection using Autofac
  • Map resources using AutoMapper
  • Async/Await Best Practices
  • Versioning Management
  • Using Swagger (Swashbuckle)
  • Auto Document Generator for Swagger
  • Integrate Swagger and Versioning
  • Integrate Swagger and JWT/OAuth Authentication
  • Best Practices for Performance and Security 
API نویسی اصولی و حرفه ای در ASP.NET Core
‫۵ سال و ۷ ماه قبل، شنبه ۱۱ اسفند ۱۳۹۷، ساعت ۲۰:۰۶
س علیزاده س علیزاده
اشتراک‌ها
استفاده از MongoDB .NET Driver با NET Core Web API.

Source could be also accessed from GitHub -> https://github.com/fpetru/WebApiMongoDB.

Problem / solution format brings an easier understanding on how to build things, giving an immediate feedback. Starting from this idea, the blog post will present step by step how to build

a web application to store your ideas in an easy way, adding text notes, either from desktop or mobile, with few characteristics: run fast, save on the fly whatever you write, and be reasonably reliable and secure.

This blog post will implement just the backend, WebApi and the database access, in the most simple way. Next blog post will cover the front end, using Angular. Then, there will be an additional article on how to increase the performance and the security. 

استفاده از MongoDB .NET Driver با NET Core Web API.
‫۷ سال و ۱۱ ماه قبل، شنبه ۲۲ آبان ۱۳۹۵، ساعت ۱۳:۳۰
صابر فتح الهی صابر فتح الهی
اشتراک‌ها
پیاده سازیِ سیاست دسترسی به داده ها توسط ویژگی RLS در SQL Server 2016

در بسیاری موارد (مانند سیستم‌های Multi Tenant) لازم هست تا مانع از این شویم که داده‌های کاربران با هم تداخل پیدا کند و یا آن‌ها بتوانند به داده‌های هم دسترسی داشته باشند. مثلا می‌خواهیم کاربران هر شعبه از سازمان، تنها به اطلاعات شعبه خودشان دسترسی داشته باشند. یک کار ساده، پردردسر و بسیار بد آن است که از برنامه نویس‌ها بخواهیم در هر کوئری عبارتی را اضافه کنند که سطح دسترسی را چک کند. اما اگر برنامه نویس جایی فراموش کرد چی؟ اگر سیاست دسترسی پیچیده‌تر بود و مبنی بر پارامتر‌های مختلف محاسبه می‌شد چه خواهد شد؟ این راهکار در حجم بزرگ غیر مطمئن و غیرقابل نگهداری است.

در EF6 قابلیتی به نام Interception وجود دارد که با استفاده از آن می‌توان سیاست دسترسی به داده را در لایه‌های پایینی طراحی کرد. در این روش برنامه نویس لایه هایی بالا، بدون آنکه درگیر مفاهیمی مانند Tenant و سیاست‌ها بشود، می‌تواند به راحتی کوئری هایش را تولید کند. سپس EF به طور خودکار تغییری در کوئری‌ها خواهد داد تا دسترسی‌های لازم رعایت کرده باشد. برای اینکار می‌توانید از کتابخانه EntityFramework.DynamicFilters استفاده کنید.

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

در SQL Server 2016 قابلیتی به نام Row Level Security وجود دارد، که به ما اجازه می‌دهد سیاست‌های دسترسی با داده را در لایه پایگاه داده متمرکز کنیم. در این صورت اپلیکشن‌ها هیچگونه آگاهی ایی نسبت به سیاست‌ها نخواهند داشت و درگیر این مفاهیم در سطح کد نخواهیم بود. همچنین در صورت لزوم به تغییر سیاست ها، فقط لازم است تغییراتی را در پایگاه داده بدهیم. با این روش، به هر طریقی و از هر ابزاری که به پایگاه داده کوئری هایمان را ارسال کنیم، سیاست‌های دسترسی به داده اعمال خواهند شد و امنیت بالا و البته ریزدانه ای (granular) را خواهیم داشت.

در مثال زیر خواهیم دید که چگونه می‌توان با استفاده از EF6 از ویژگی RLS بهره برد. این مثال یکی دیگر از کاربرد‌های Interception را نیز توضیح می‌دهد.
 

پیاده سازیِ سیاست دسترسی به داده ها توسط ویژگی RLS در SQL Server 2016
‫۸ سال و ۳ ماه قبل، دوشنبه ۱۱ مرداد ۱۳۹۵، ساعت ۱۳:۰۹
وحید نصیری وحید نصیری
نظرات مطالب
غیرمعتبر کردن توکن و یا کوکی سرقت شده در برنامه‌های مبتنی بر ASP.NET Core
این مشکل نیست. این توکن‌ها متکی به خود (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‌های اشاره شده، می‌پردازد.
‫۱ سال و ۱ ماه قبل، چهارشنبه ۱۸ مرداد ۱۴۰۲، ساعت ۱۴:۰۳
هدایتگر هدایتگر
نظرات مطالب
اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 بدون استفاده از سیستم Identity
سلام.
پروژه اعتبارسنجی jwt را مطابق همین پست انجام دادم و روی لوکال روی پورت 4983 اجرا شده است.  پروژه فرانت انگولار روی لوکال پورت 4200 در حال اجراست. و برای لاگین مستقیما به 4983 ریکوئست میفرستد و توکن دریافت میکند. سورس اصلی بکند روی پروژه دیگری روی لوکال پورت 7744 در حال اجراست. فرانت بعد از لاگین دیگر ارتباطی با 4983 ندارد و از این به بعد همه ریکوئست‌ها را به پورت 7744 ارسال میکند. در واقع 4983 فقط پروژه jwt به تنهایی است. فرانت وقتی ریکوئستی را به 7744 میفرستد نیاز به ولید شدن توکن دارد و باید توکن را برای بررسی به 4983 ارسال کند. و در startup 7744 این کد نوشته شده است:
            services.AddAuthentication(options =>
            {
                options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
            })
            .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>
            {
                options.Authority = "http://localhost:4983/";
                options.Audience = "Any";
                options.RequireHttpsMetadata = false;
                options.Events = new JwtBearerEvents();
                options.Configuration = new OpenIdConnectConfiguration();
                options.Events.OnTokenValidated = async context =>
                {
                    IEnumerable<Claim> userClaims = await ReadClaimsFromCacheAsync(context);

                    if (ThereIsNoCache(userClaims))
                    {
                        userClaims = await GetUserInfoAsync(context, authority);
                        await StoreInCacheAsync(userClaims, context);
                    }

                    context.Principal = new ClaimsPrincipal(new ClaimsIdentity(userClaims, "jwt", JwtClaimTypes.Subject, "roles"));
                };
                options.Events.OnAuthenticationFailed = async context =>
                {
                    await TestInvalid(context);
                };
            });
که خطای زیر را دریافت میکنم:
IDX10500: Signature validation failed. No security keys were provided to validate the signature.
ممنون میشم راهنمایی بفرمایید. (نکته: یک کنترلر تستی روی 4983 نوشته ام که بعد از لاگین مستقیم از فرانت کال کردم و بدون مشکل توکن ولید شد و به کنترلر و اکشن موردنظر دسترسی پیدا کرد. ولی وقتی اعتبارسنجی از طریق 7744 صورت میگیرد خطا میدهد.)
‫۲ سال و ۸ ماه قبل، شنبه ۹ بهمن ۱۴۰۰، ساعت ۱۷:۴۲
میثم سلی میثم سلی
نظرات مطالب
تنظیمات کش توزیع شده‌ی مبتنی بر SQL Server در ASP.NET Core
با سلام در زمان نصب پکیج Microsoft.Extensions.Caching.SqlConfig.Tools   با پیام خطای زیر مواجه میشم  
SeverityCodeDescriptionProjectFileLineSuppression State
ErrorPackage 'Microsoft.Extensions.Caching.SqlConfig.Tools 2.0.2' has a package type 'DotnetCliTool' that is not supported by project 'mvc-dsqlcache'.
یکم دست به سرچ شدم منتها یه جایی دیدم میگه نیاز به نصب این بسته تو نسخه جدید ندارید.
بنابراین اومدم از دستور زیر استفاده کردم تا بانک اطلاعاتی ایجاد بشه 
 dotnet sql-cache create "Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=sql_cache;Integrated Security=True;" "dbo" "AppSqlCache"
منتها در اینجا هم به پیغام خطای زیر مواجه میشم. ممنون میشم راهنمایی بفرمائید
dotnet : An error occurred. Cannot open database "sql_cache" requested by the login. The login failed.
At line:1 char:1
+ dotnet sql-cache create "Data Source=.;Initial Catalog=sql_cache;Inte ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (An error occurr...e login failed.:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError
 
Login failed for user 'MicrosoftAccount\soleymani.meysam@hotmail.com'.

‫۳ سال و ۲ ماه قبل، چهارشنبه ۲۳ تیر ۱۴۰۰، ساعت ۲۰:۳۶