در هر وبسایتی که فرمی برای ارسال اطلاعات به سرور موجود باشد، آن وب سایت مستعد ارسال اسپم و بمباران درخواستهای متعدد خواهد بود. در برخی موارد استفاده از کپچا میتواند راه خوبی برای جلوگیری از ارسالهای مکرر و مخرب باشد، ولی گاهی اوقات سناریوی ما به شکلی است که امکان استفاده از کپچا، به عنوان یک مکانیزم امنیتی مقدور نیست.
اگر شما یک فرم تماس با ما داشته باشید استفاده از کپچا یک مکانیزم امنیتی معقول میباشد و همچنین اگر فرمی جهت ارسال پست داشته باشید. اما در برخی مواقع مانند فرمهای ارسال کامنت، پاسخ، چت و ... امکان استفاده از این روش وجود ندارد و باید به فکر راه حلی مناسب برای مقابل با درخواستهای مخرب باشیم.
اگر شما هم به دنبال تامین امنیت سایت خود هستید و دوست ندارید که وب سایت شما (به دلیل کمبود پهنای باند یا ارسال مطالب نامربوط که گاهی اوقات به صدها هزار مورد میرسد) از دسترس خارج شود این آموزش را دنبال کنید.
برای این منظور ما از یک ActionFilter برای امضای ActionMethodهایی استفاده میکنیم که باید با ارسالهای متعدد از سوی یک کاربر مقابله کنند. این ActionFilter باید قابلیت تنظیم حداقل زمان بین درخواستها را داشته باشد و اگر درخواستی در زمانی کمتر از مدت مجاز تعیین شده برسد، به نحوی مطلوبی به آن رسیدگی کند.
پس از آن ما نیازمند مکانیزمی هستیم تا درخواستهای رسیدهی از سوی هرکاربر را به شکلی کاملا خاص و یکتا شناسایی کند. راه حلی که قرار است در این ActionFilter از آن استفاده کنم به شرح زیر است:
ما به دنبال آن هستیم که یک شناسهی منحصر به فرد را برای هر درخواست ایجاد کنیم. لذا از اطلاعات شیئ Request جاری برای این منظور استفاده میکنیم.
1) IP درخواست جاری (قابل بازیابی از هدر HTTP_X_FORWARDED_FOR یا REMOTE_ADDR)
2) مشخصات مرورگر کاربر (قابل بازیابی از هدر USER_AGENT)
3) آدرس درخواست جاری (برای اینکه شناسهی تولیدی کاملا یکتا باشد، هرچند میتوانید آن را حذف کنید)
اطلاعات فوق را در یک رشته قرار میدهیم و بعد Hash آن را حساب میکنیم. به این ترتیب ما یک شناسه منحصر فرد را از درخواست جاری ایجاد کردهایم.
مرحله بعد پیاده سازی مکانیزمی برای نگهداری این اطلاعات و بازیابی آنها در هر درخواست است. ما برای این منظور از سیستم Cache استفاده میکنیم؛ هرچند راه حلهای بهتری هم وجود دارند.
بنابراین پس از ایجاد شناسه یکتای درخواست، آن را در Cache قرار میدهیم و زمان انقضای آن را هم پارامتری که ابتدای کار گفتم قرار میدهیم. سپس در هر درخواست Cache را برای این مقدار یکتا جستجو میکنیم. اگر شناسه پیدا شود، یعنی در کمتر از زمان تعیین شده، درخواست مجددی از سوی کاربر صورت گرفته است و اگر شناسه در Cache موجود نباشد، یعنی درخواست رسیده در زمان معقولی صادر شده است.
باید توجه داشته باشید که تعیین زمان بین هر درخواست به ازای هر ActionMethod خواهد بود و نباید آنقدر زیاد باشد که عملا کاربر را محدود کنیم. برای مثال در یک سیستم چت، زمان معقول بین هر درخواست 5 ثانیه است و در یک سیستم ارسال نظر یا پاسخ، 10 ثانیه. در هر حال بسته به نظر شما این زمان میتواند قابل تغییر باشد. حتی میتوانید کاربر را مجبور کنید که در روز فقط یک دیدگاه ارسال کند!
قبل از پیاده سازی سناریوی فوق، در مورد نقش گزینهی سوم در شناسهی درخواست، لازم است توضیحاتی بدهم. با استفاده از این خصوصیت (یعنی آدرس درخواست جاری) شدت سختگیری ما کمتر میشود. زیرا به ازای هر آدرس، شناسهی تولیدی متفاوت خواهد بود. اگر فرد مهاجم، برنامهای را که با آن اسپم میکند، طوری طراحی کرده باشد که مرتبا درخواستها را به آدرسهای متفاوتی ارسال کند، مکانیزم ما کمتر با آن مقابله خواهد کرد.
برای مثال فرد مهاجم میتواند در یک حلقه، ابتدا درخواستی را به AddComment بدهد، بعد AddReply و بعد SendMessage. پس همانطور که میبینید اگر از پارامتر سوم استفاده کنید، عملا قدرت مکانیزم ما به یک سوم کاهش مییابد.
نکتهی دیگری که قابل ذکر است اینست که این روش راهی برای تشخیص زمان بین درخواستهای صورت گرفته از کاربر است و به تنهایی نمیتواند امنیت کامل را برای مقابله با اسپمها، مهیا کند و باید به فکر مکانیزم دیگری برای مقابله با کاربری که درخواستهای نامعقولی در مدت زمان کمی میفرستد پیاده کنیم (پیاده سازی مکانیزم تکمیلی را در آینده شرح خواهم داد).
اکنون نوبت پیاده سازی سناریوی ماست. ابتدا یک کلاس ایجاد کنید و آن را از ActionFilterAttribute مشتق کنید و کدهای زیر را وارد کنید:
و حال برای استفاده از این مکانیزم امنیتی ActionMethod مورد نظر را با آن امضا میکنیم:
همانطور که گفتم این مکانیزم تنها تا حدودی با درخواستهای اسپم مقابله میکند و برای تکمیل آن نیاز به مکانیزم دیگری داریم تا بتوانیم از ارسالهای غیرمجاز بعد از زمان تعیین شده جلوگیری کنیم.
به توجه به دیدگاههای مطرح شده اصلاحاتی در کلاس صورت گرفت و قابلیتی به آن اضافه گردید که بتوان مکانیزم اعتبارسنجی را کنترل کرد.
برای این منظور خصوصیتی به این ActionFilter افزوده شد تا هنگامیکه دادههای فرم معتبر نباشند و در واقع هنوز چیزی ثبت نشده است این مکانیزم را بتوان کنترل کرد. خصوصیت CheckResult باعث میشود تا اگر دادههای مدل ما در اعتبارسنجی، معتبر نبودند کلید افزوده شده به کش را حذف تا کاربر بتواند مجدد فرم را ارسال کند. مقدار آن به طور پیش فرض true است و اگر برابر false قرار بگیرد تا اتمام زمان تعیین شده در مکانیزم ما، کاربر امکان ارسال مجدد فرم را ندارد.
همچنین باید بعد از اتمام عملیات در صورت عدم موفقیت آمیز بودن آن به ViewBag یک خصوصیت به نام ExecuteResult اضافه کنید و مقدار آن را برابر false قرار دهید. تا کلید از کش حذف گردد.
نحوه استفاده آن هم به شکل زیر میباشد:
فایل ضمیمه را میتوانید از زیر دانلود کنید:
StopSpamAttribute.rar
اگر شما یک فرم تماس با ما داشته باشید استفاده از کپچا یک مکانیزم امنیتی معقول میباشد و همچنین اگر فرمی جهت ارسال پست داشته باشید. اما در برخی مواقع مانند فرمهای ارسال کامنت، پاسخ، چت و ... امکان استفاده از این روش وجود ندارد و باید به فکر راه حلی مناسب برای مقابل با درخواستهای مخرب باشیم.
اگر شما هم به دنبال تامین امنیت سایت خود هستید و دوست ندارید که وب سایت شما (به دلیل کمبود پهنای باند یا ارسال مطالب نامربوط که گاهی اوقات به صدها هزار مورد میرسد) از دسترس خارج شود این آموزش را دنبال کنید.
برای این منظور ما از یک ActionFilter برای امضای ActionMethodهایی استفاده میکنیم که باید با ارسالهای متعدد از سوی یک کاربر مقابله کنند. این ActionFilter باید قابلیت تنظیم حداقل زمان بین درخواستها را داشته باشد و اگر درخواستی در زمانی کمتر از مدت مجاز تعیین شده برسد، به نحوی مطلوبی به آن رسیدگی کند.
پس از آن ما نیازمند مکانیزمی هستیم تا درخواستهای رسیدهی از سوی هرکاربر را به شکلی کاملا خاص و یکتا شناسایی کند. راه حلی که قرار است در این ActionFilter از آن استفاده کنم به شرح زیر است:
ما به دنبال آن هستیم که یک شناسهی منحصر به فرد را برای هر درخواست ایجاد کنیم. لذا از اطلاعات شیئ Request جاری برای این منظور استفاده میکنیم.
1) IP درخواست جاری (قابل بازیابی از هدر HTTP_X_FORWARDED_FOR یا REMOTE_ADDR)
2) مشخصات مرورگر کاربر (قابل بازیابی از هدر USER_AGENT)
3) آدرس درخواست جاری (برای اینکه شناسهی تولیدی کاملا یکتا باشد، هرچند میتوانید آن را حذف کنید)
اطلاعات فوق را در یک رشته قرار میدهیم و بعد Hash آن را حساب میکنیم. به این ترتیب ما یک شناسه منحصر فرد را از درخواست جاری ایجاد کردهایم.
مرحله بعد پیاده سازی مکانیزمی برای نگهداری این اطلاعات و بازیابی آنها در هر درخواست است. ما برای این منظور از سیستم Cache استفاده میکنیم؛ هرچند راه حلهای بهتری هم وجود دارند.
بنابراین پس از ایجاد شناسه یکتای درخواست، آن را در Cache قرار میدهیم و زمان انقضای آن را هم پارامتری که ابتدای کار گفتم قرار میدهیم. سپس در هر درخواست Cache را برای این مقدار یکتا جستجو میکنیم. اگر شناسه پیدا شود، یعنی در کمتر از زمان تعیین شده، درخواست مجددی از سوی کاربر صورت گرفته است و اگر شناسه در Cache موجود نباشد، یعنی درخواست رسیده در زمان معقولی صادر شده است.
باید توجه داشته باشید که تعیین زمان بین هر درخواست به ازای هر ActionMethod خواهد بود و نباید آنقدر زیاد باشد که عملا کاربر را محدود کنیم. برای مثال در یک سیستم چت، زمان معقول بین هر درخواست 5 ثانیه است و در یک سیستم ارسال نظر یا پاسخ، 10 ثانیه. در هر حال بسته به نظر شما این زمان میتواند قابل تغییر باشد. حتی میتوانید کاربر را مجبور کنید که در روز فقط یک دیدگاه ارسال کند!
قبل از پیاده سازی سناریوی فوق، در مورد نقش گزینهی سوم در شناسهی درخواست، لازم است توضیحاتی بدهم. با استفاده از این خصوصیت (یعنی آدرس درخواست جاری) شدت سختگیری ما کمتر میشود. زیرا به ازای هر آدرس، شناسهی تولیدی متفاوت خواهد بود. اگر فرد مهاجم، برنامهای را که با آن اسپم میکند، طوری طراحی کرده باشد که مرتبا درخواستها را به آدرسهای متفاوتی ارسال کند، مکانیزم ما کمتر با آن مقابله خواهد کرد.
برای مثال فرد مهاجم میتواند در یک حلقه، ابتدا درخواستی را به AddComment بدهد، بعد AddReply و بعد SendMessage. پس همانطور که میبینید اگر از پارامتر سوم استفاده کنید، عملا قدرت مکانیزم ما به یک سوم کاهش مییابد.
نکتهی دیگری که قابل ذکر است اینست که این روش راهی برای تشخیص زمان بین درخواستهای صورت گرفته از کاربر است و به تنهایی نمیتواند امنیت کامل را برای مقابله با اسپمها، مهیا کند و باید به فکر مکانیزم دیگری برای مقابله با کاربری که درخواستهای نامعقولی در مدت زمان کمی میفرستد پیاده کنیم (پیاده سازی مکانیزم تکمیلی را در آینده شرح خواهم داد).
اکنون نوبت پیاده سازی سناریوی ماست. ابتدا یک کلاس ایجاد کنید و آن را از ActionFilterAttribute مشتق کنید و کدهای زیر را وارد کنید:
using System; using System.Linq; using System.Web.Mvc; using System.Security.Cryptography; using System.Text; using System.Web.Caching; namespace Parsnet.Core { public class StopSpamAttribute : ActionFilterAttribute { // حداقل زمان مجاز بین درخواستها برحسب ثانیه public int DelayRequest = 10; // پیام خطایی که در صورت رسیدن درخواست غیرمجاز باید صادر کنیم public string ErrorMessage = "درخواستهای شما در مدت زمان معقولی صورت نگرفته است."; //خصوصیتی برای تعیین اینکه آدرس درخواست هم به شناسه یکتا افزوده شود یا خیر public bool AddAddress = true; public override void OnActionExecuting(ActionExecutingContext filterContext) { // درسترسی به شئی درخواست var request = filterContext.HttpContext.Request; // دسترسی به شیئ کش var cache = filterContext.HttpContext.Cache; // کاربر IP بدست آوردن var IP = request.ServerVariables["HTTP_X_FORWARDED_FOR"] ?? request.UserHostAddress; // مشخصات مرورگر var browser = request.UserAgent; // در اینجا آدرس درخواست جاری را تعیین میکنیم var targetInfo = (this.AddAddress) ? (request.RawUrl + request.QueryString) : ""; // شناسه یکتای درخواست var Uniquely = String.Concat(IP, browser, targetInfo); //در اینجا با کمک هش یک امضا از شناسهی درخواست ایجاد میکنیم var hashValue = string.Join("", MD5.Create().ComputeHash(Encoding.ASCII.GetBytes(Uniquely)).Select(s => s.ToString("x2"))); // ابتدا چک میکنیم که آیا شناسهی یکتای درخواست در کش موجود نباشد if (cache[hashValue] != null) { // یک خطا اضافه میکنیم ModelState اگر موجود بود یعنی کمتر از زمان موردنظر درخواست مجددی صورت گرفته و به filterContext.Controller.ViewData.ModelState.AddModelError("ExcessiveRequests", ErrorMessage); } else { // اگر موجود نبود یعنی درخواست با زمانی بیشتر از مقداری که تعیین کردهایم انجام شده // پس شناسه درخواست جدید را با پارامتر زمانی که تعیین کرده بودیم به شیئ کش اضافه میکنیم cache.Add(hashValue, true, null, DateTime.Now.AddSeconds(DelayRequest), Cache.NoSlidingExpiration, CacheItemPriority.Default, null); } base.OnActionExecuting(filterContext); } } }
[HttpPost] [StopSpam(DelayRequest = 5)] [ValidateAntiForgeryToken] public virtual async Task<ActionResult> SendFile(HttpPostedFileBase file, int userid = 0) { } [HttpPost] [StopSpam(DelayRequest = 30, ErrorMessage = "زمان لازم بین ارسال هر مطلب 30 ثانیه است")] [ValidateAntiForgeryToken] public virtual async Task<ActionResult> InsertPost(NewPostModel model) { }
همانطور که گفتم این مکانیزم تنها تا حدودی با درخواستهای اسپم مقابله میکند و برای تکمیل آن نیاز به مکانیزم دیگری داریم تا بتوانیم از ارسالهای غیرمجاز بعد از زمان تعیین شده جلوگیری کنیم.
به توجه به دیدگاههای مطرح شده اصلاحاتی در کلاس صورت گرفت و قابلیتی به آن اضافه گردید که بتوان مکانیزم اعتبارسنجی را کنترل کرد.
برای این منظور خصوصیتی به این ActionFilter افزوده شد تا هنگامیکه دادههای فرم معتبر نباشند و در واقع هنوز چیزی ثبت نشده است این مکانیزم را بتوان کنترل کرد. خصوصیت CheckResult باعث میشود تا اگر دادههای مدل ما در اعتبارسنجی، معتبر نبودند کلید افزوده شده به کش را حذف تا کاربر بتواند مجدد فرم را ارسال کند. مقدار آن به طور پیش فرض true است و اگر برابر false قرار بگیرد تا اتمام زمان تعیین شده در مکانیزم ما، کاربر امکان ارسال مجدد فرم را ندارد.
همچنین باید بعد از اتمام عملیات در صورت عدم موفقیت آمیز بودن آن به ViewBag یک خصوصیت به نام ExecuteResult اضافه کنید و مقدار آن را برابر false قرار دهید. تا کلید از کش حذف گردد.
نحوه استفاده آن هم به شکل زیر میباشد:
[HttpPost] [StopSpam(AddAddress = true, DelayRequest = 20)] [ValidateAntiForgeryToken] public Task<ActionResult> InsertPost(NewPostModel model) { if (ModelState.IsValid) { var newPost = dbContext.InsertPost(model); if (newPost != null) { ViewBag.ExecuteResult = true; } } if (ModelState.IsValidField("ExcessiveRequests") == true)
{
ViewBag.ExecuteResult = false;
}
return View(); }
فایل ضمیمه را میتوانید از زیر دانلود کنید:
StopSpamAttribute.rar