<system.webServer>
...
<security>
<requestFiltering removeServerHeader ="true" />
</security>
...
</system.webServer> 
public string TestNoneAsync()
{
var webClient = new WebClient();
return webClient.DownloadString("http://www.google.com");
} public void TestAsync()
{
var webClient = new WebClient();
webClient.DownloadStringAsync(new Uri("http://www.google.com"));
webClient.DownloadStringCompleted += webClientDownloadStringCompleted;
}
void webClientDownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)
{
// use e.Result
} using System;
using System.Linq;
using System.Net;
using System.Windows.Forms;
namespace Async02
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void btnGetInfo_Click(object sender, EventArgs e)
{
var req = (HttpWebRequest)WebRequest.Create("http://www.google.com");
req.Method = "HEAD";
req.BeginGetResponse(
asyncResult =>
{
var resp = (HttpWebResponse)req.EndGetResponse(asyncResult);
var headersText = formatHeaders(resp.Headers);
txtResults.Text = headersText;
}, null);
}
private string formatHeaders(WebHeaderCollection headers)
{
var headerString = headers.Keys.Cast<string>()
.Select(header => string.Format("{0}:{1}", header, headers[header]));
return string.Join(Environment.NewLine, headerString.ToArray());
}
}
} An exception of type 'System.InvalidOperationException' occurred in System.Windows.Forms.dll but was not handled in user code Additional information: Cross-thread operation not valid: Control 'txtResults' accessed from a thread other than the thread it was created on.
private void btnGetInfo_Click(object sender, EventArgs e)
{
var sync = SynchronizationContext.Current;
var req = (HttpWebRequest)WebRequest.Create("http://www.google.com");
req.Method = "HEAD";
req.BeginGetResponse(
asyncResult =>
{
var resp = (HttpWebResponse)req.EndGetResponse(asyncResult);
var headersText = formatHeaders(resp.Headers);
sync.Post(delegate { txtResults.Text = headersText; }, null);
}, null);
} 
using System;
using System.Threading.Tasks;
namespace Async01
{
public class AsyncExample
{
public async Task DoWorkAsync(int parameter)
{
await Task.Delay(parameter);
Console.WriteLine(parameter);
}
}
} public async Task<double> GetNumberAsync()
{
var generator = new Random();
await Task.Delay(generator.Next(1000));
return generator.NextDouble();
} public async Task<double> GetSumAsync()
{
var leftOperand = await GetNumberAsync();
var rightOperand = await GetNumberAsync();
return leftOperand + rightOperand;
} public async Task<double> GetProductOfSumAsync()
{
var leftOperand = GetSumAsync();
var rightOperand = GetSumAsync();
return await leftOperand * await rightOperand;
} Operator '*' cannot be applied to operands of type 'System.Threading.Tasks.Task<double>' and 'System.Threading.Tasks.Task<double>'
public async Task<string> DownloadAsync()
{
var webClient = new WebClient();
return await webClient.DownloadStringTaskAsync("http://www.google.com");
} public void TestDownloadAsync()
{
Debug.WriteLine("Before DownloadAsync");
DownloadAsync();
Debug.WriteLine("After DownloadAsync");
} Before DownloadAsync After DownloadAsync
PM> Install-Package Microsoft.Bcl.Async
طی مقاله چک لیست تولید برنامه Asp.net mvc و بررسی امنیتی ای‌جکس هنگام استفاده در مورد چک لیست امنیتی
سایت سرفصل‌های مهم عنوان و بررسی شده است که یکی از موارد، مقاوم ساختن وب اپلیکشن در برابر حملات CSRF می‌باشد. اینگونه حملات بر پایه این استراتژی شکل می‌گیرند که با
ارسال درخواستی به نیابت از سمت سیستم/مرورگر کاربر تایید هویت شده، سایت مقصد را مجبور
به انجام عملی کند. برای مثال اگر شما در سایت a.com یک
کاربر تایید شده باشید و هم اکنون در سایت فوق نیز لاگین باشید، مهاجم با ارسال یک برنامه/صفحه یا موارد مشابه و در قالب src یک
عکس یا با ترغیب شما با کلیک بر روی یک لینک با href آلوده یا موارد
مشابه، از سمت مرورگر شما درخواستی را به سمت سایت a.com ارسال می‌کند .
این درخواست ممکن است شامل حذف اطلاعات، تغییر مشخصات، پرداخت هزینه یا موارد مشابه باشد. جهت مقابله با این حمله، یکی از موارد مهم، استفاده همیشگی از Html.AntiForgeryToken() در تمامی فرم‌های ورود اطلاعات است. همچنین استفاده همیشگی از متد Post و بررسی تایید مبدا درخواست‌های ایجکسی، بررسی http referrer ، محدود کردن طول عمر کوکی، استفاده از کپچهای قوی مانند کپچای گوگل می‌تواند تا حد زیادی وب اپلیکیشن را در مورد اینگونه حملات، مصون کند.
در این بین یکی از موارد دیگر، اضافه کردن AntiForgeryToken به درخواست‌های ایجکسی سایت می‌باشد. جهت حصول این منظور، راه‌های مختلفی موجود است. یکی از راه حل‌ها استفاده از یک هلپر جهت تولید توکن مورد نظر است.
ساختار
هلپر مورد نظر به شرح زیر است :
public static class AntiForgeryToken
{
public static MvcHtmlString AntiForgeryTokenForAjaxPost(this HtmlHelper helper)
{
var antiForgeryInputTag = helper.AntiForgeryToken().ToString();
// Above gets the following: <input name="__RequestVerificationToken" type="hidden" value="some value" />
var removedStart = antiForgeryInputTag.Replace(@"<input name=""__RequestVerificationToken"" type=""hidden"" value=""", "");
var tokenValue = removedStart.Replace(@""" />", "");
if (antiForgeryInputTag == removedStart || removedStart == tokenValue)
throw new InvalidOperationException("Oops! The Html.AntiForgeryToken() method seems to return something I did not expect.");
return new MvcHtmlString($@"{"__RequestVerificationToken"}:""{tokenValue}""");
}
} function AddToCart(pid) {
$.ajax({
url: '@Url.Action("AddToBasket","Shop")',
data: { 'pid': pid,@Html.AntiForgeryTokenForAjaxPost() },
type: 'post',
success:function(e) {
//do something
}
});
} 
Declare
@x int,
@y int
Set @x = 1
If (@x + @y = 1)
BEGIN
print 'yes!'
End
Set @y = (select sum(id) from Account)
If @x + @y = 1
BEGIN
print 'yes!'
End
در Blazor میتوان مسیریابی‌های پارامتری را به صورت زیر نیز تعریف کرد:
@page "/post/edit/{EditId:int}"
که در اینجا EditId، یک پارامتر مسیریابی از نوع int تعریف شده و به صورت زیر در کدهای صفحه‌ی مرتبط، قابل دسترسی است:
[Parameter] public int? EditId { set; get; }
int تعریف شده‌ی در این مسیریابی، یک routing constraint و یا یک قید مسیریابی محسوب میشود و استفاده‌ی از آن، چنین مزایایی را به همراه دارد:
- در این حالت فقط EditId های عددی پردازش می‌شوند و اگر رشته‌ای دریافت شود، کاربر با خروجی از نوع 404 و یا «یافت نشد»، مواجه خواهد شد.
- امکان اعتبارسنجی مقادیر دریافتی، پیش از ارسال آنها به صفحه و پردازش صفحه.
قیود پیش‌فرض تعریف شده‌ی در Blazor
اگر به مستندات مسیریابی Blazor مراجعه کنیم، به‌نظر فقط این موارد را میتوان به‌عنوان قیود پارامترهای مسیریابی تعریف کرد:
bool, datetime, decimal, double, float, guid, int, long, nonfile
و ... توضیحاتی در مورد اینکه آیا امکان بسط آنها وجود دارند یا خیر، فعلا در مستندات رسمی آن، ذکر نشده‌اند.
در Blazor 8x میتوان از قیود مسیریابی سفارشی ASP.NET Core نیز استفاده کرد!
ASP.NET Core سمت سرور، به همراه امکان سفارشی سازی قیودمسیریابی خود نیز هست که آن‌را میتوان به کمک اینترفیسIRouteConstraint پیاده سازی کرد:
namespace Microsoft.AspNetCore.Routing
{
public interface IRouteConstraint
{
bool Match(
HttpContext httpContext,
IRouter route,
string routeKey,
RouteValueDictionary values,
RouteDirection routeDirection);
}
}
جالب اینجا است که میتوان این نمونه‌های سفارشی را حداقل در نگارش جدید Blazor 8x SSR نیز استفاده کرد؛ هرچند در مستندات رسمی Blazor هنوز به آن اشاره‌ای نشده‌است.
در امضای متد Match فوق، دو پارامتر routeKey و values آن بیش از مابقی مهم هستند:
- routeKey مشخص می‌کند که الان کدام پارامتر مسیریابی (مانند EditId در این مطلب) در حال پردازش است.
- values، یک دیکشنری است که کلید هر عضو آن، پارامتر مسیریابی و مقدار آن، مقدار دریافتی از URL جاری است.
- اگر این متد مقدار true را برگرداند، یعنی مسیریابی وارد شده‌ی به آن، با موفقیت پردازش و اعتبارسنجی شده و میتوان صفحه‌ی مرتبط را نمایش داد؛ در غیراینصورت، کاربر پیام یافت نشدن آن صفحه و مسیر درخواستی را مشاهده می‌کند.
پیاده سازی یک قید سفارشی رمزگشایی پارامترهای مسیریابی
فرض کنید قصد ندارید که پارامترهای مسیریابی ویرایش رکوردهای خاصی را دقیقا بر اساس Id متناظر عددی آنها در بانک اطلاعاتی، نمایش دهید؛ برای مثال نمی‌خواهید دقیقا آدرس post/edit/1 را به کاربر نمایش دهید؛ چون نمایش این اعداد عموما ساده و ترتیبی، حدس زدن آنها را ساده کرده و ممکن است در آینده مشکلات امنیتی را به همراه داشته باشد.
می‌خواهیم از آدرس‌های متداول و ساده‌ی عددی زیر:
@page "/post/edit/{EditId:int}"
به آدرس رمزنگاری شده‌ی زیر برسیم:
@page "/post/edit/{EditId:encrypt}"
اگر به این آدرس جدید دقت کنید، در اینجا از نام قید جدیدی به نام encrypt استفاده شده‌است که جزو قیود پیش‌فرض سیستم مسیریابی Blazor نیست. روش تعریف آن به صورت زیر است:
using System.Globalization;
using DNTCommon.Web.Core;
namespace Blazor8xSsrComponents.Utils;
public class EncryptedRouteConstraint(IProtectionProviderService protectionProvider) : IRouteConstraint
{
public const string Name = "encrypt";
public bool Match(HttpContext? httpContext,
IRouter? route,
string routeKey,
RouteValueDictionary values,
RouteDirection routeDirection)
{
ArgumentNullException.ThrowIfNull(routeKey);
ArgumentNullException.ThrowIfNull(values);
if (!values.TryGetValue(routeKey, out var routeValue))
{
return false;
}
var valueString = Convert.ToString(routeValue, CultureInfo.InvariantCulture);
values[routeKey] = string.IsNullOrEmpty(valueString) ? null : protectionProvider.Decrypt(valueString);
return true;
}
}
توضیحات:
- در قیود سفارشی میتوان سرویس‌ها را به سازنده‌ی کلاس تزریق کرد و برای مثال از سرویس IProtectionProviderService که در کتابخانه‌ی DNTCommon.Web.Core تعریف شده، برای رمزگشایی اطلاعات رسیده، استفاده کرده‌ایم.
- یک نام را هم برای آن درنظر گرفته‌ایم که از این نام در فایل Program.cs به صورت زیر استفاده میشود:
builder.Services.Configure<RouteOptions>(opt =>
{
opt.ConstraintMap.Add(EncryptedRouteConstraint.Name, typeof(EncryptedRouteConstraint));
});
یعنی زمانیکه سیستم مسیریابی به قید جدیدی به نام encrypt می‌رسد:
@page "/post/edit/{EditId:encrypt}"
آن‌را در لیست ConstraintMap ای که به نحو فوق به سیستم معرفی شده، جستجو می‌کند. اگر این نام یافت شد، سپس کلاس EncryptedRouteConstraint متناظر را نمونه سازی کرده و در جهت پردازش مسیر رسیده، مورد استفاده قرار می‌دهد.
- در کلاس EncryptedRouteConstraint و متد Match آن، مقدار رشته‌ای EditId دریافت شده‌ی از طریق آدرس جاری درخواستی، رمزگشایی شده و بجای مقدار فعلی رمزنگاری شده‌ی آن درج میشود. همین اندازه برای مقدار دهی خودکار پارامتر EditId ذیل در صفحات مرتبط، کفایت می‌کند:
[Parameter] public string? EditId { set; get; }
یعنی دیگر نیازی نیست تا در صفحات مرتبط، کار رمزگشایی EditId، به صورت دستی انجام شود.
اول اینکه، کیفیت داده‌های ذخیره‌شده در دستگاه‌های تلفن همراه کاربر بیشتر شخصی میشود تا مواردی دیگر! به غیر از ایمیل، پیام‌های فوری، SMS / MMS ، لاگ تماس‌ها، عکس‌ها و پست صوتی وجود دارند که عموما توسعه دهندگان را دچار مشکل می‌کند.
برخی از گزینه‌های فوق بر روی یک کامپیوتر رومیزی هم وجود دارند، ولی اهمیت این داده‌ها بر روی اندروید و اجزای آن اهمیت فوق العاده‌ای دارد. اطلاعات روی دستگاه موبایل شما به احتمال زیاد از ارزش بیشتری برخوردار خواهد بود، چرا که آنها را در یک صفحه 4 - 5 اینچی به همراه خود حمل می‌کنید و با خود هر کجا می‌برید! این حالت، یک پلتفرم همگرا را بوجود می‌آورد؛ به این دلیل که سیستم رومیزی شما و تلفن همراه یک مجموعه غنی و کامل از اطلاعات حساس هستند که هردوی آنها شامل اطلاعات شخصی می‌باشند و برای شما اهمیت زیادی خواهند داشت. تصور کنید زمانیکه برای جلوگیری از نفوذ یا به سرقت رفتن شماره تلفن‌های خود، یک پشتیبان بر روی سیستم رو میزی خود تهیه می‌کنید و فایل پشتیبان شماره‌های تماس را بر روی سیستم شخصی نگه داری می‌کنید! آیا این همان پلتفرم همگرا نیست؟ آیا این دو سیستم مکمل هم نیستند؟حتی اگر همگام‌سازی را با یک مکان دوردست (Google Drive) انجام دهید، با این حال شما فقط در مقابل از دست دادن داده‌ها محافظت کرده‌اید و نه از دست دادن حریم خصوصی!
همچنین در نظر بگیرید که فرمت داده‌های ذخیره‌شده در دستگاه‌های تلفن همراه، تعیین و مشخص شوند! این کار اطلاعات حساس شما را به مرز سرقت نزدیکتر می‌کند. هر تلفن همراه SMS / MMS ، تماس‌ها، و پست صوتی خواهد داشت. مکان‌های ذخیره شده از روی GPS و مواردی دیگر که قطعا اطلاع دارید، تمامی اینها جزء مواردی هستند که خطرات امنیتی را در سیستم عامل اندروید شامل میشود. حالا در نظر بگیرید که این اطلاعات تا چه حد مهم است؟ برای کاربرانی که هیچ گونه پشتیبانی از اطلاعاتی از خود ندارند، از دست دادن داده‌ها قابل تصور نیست!
خطرناکترین نوع حملات بر روی پلتفرم اندروید انجام می‌شوند، در سکوت کامل و چندین هزار مایل دروتر از شما و فرد مهاجم نیازی به دسترسی فیزیکی و لمس تلفن همراه شما نخواهد داشت! این نوع حملات در هر زمانی ممکن است رخ دهد و اغلب می‌تواند به دلیل امنیت ضعیف در جای دیگری بر روی دستگاه رخ دهد.
در مطلب بعدی پیرامون امنیت معماری اندروید صبحت خواهیم کرد...
