علی سالمیان علی سالمیان
جلوگیری از ارسال Spam در ASP.NET MVC
اندازه‌ی قلم متن
تخمین مدت زمان مطالعه‌ی مطلب: هفت دقیقه
در هر وب‌سایتی که فرمی برای ارسال اطلاعات به سرور موجود باشد، آن وب سایت مستعد ارسال اسپم و بمباران درخواست‌های متعدد خواهد بود. در برخی موارد استفاده از کپچا می‌تواند راه خوبی برای جلوگیری از ارسال‌های مکرر و مخرب باشد، ولی گاهی اوقات سناریوی ما به شکلی است که امکان استفاده از کپچا، به عنوان یک مکانیزم امنیتی مقدور نیست.
اگر شما یک فرم تماس با ما داشته باشید استفاده از کپچا یک مکانیزم امنیتی معقول می‌باشد و همچنین اگر فرمی جهت ارسال پست داشته باشید. اما در برخی مواقع مانند فرمهای ارسال کامنت، پاسخ، چت و ... امکان استفاده از این روش وجود ندارد و باید به فکر راه حلی مناسب برای مقابل با درخواست‌های مخرب باشیم.
اگر شما هم به دنبال تامین امنیت سایت خود هستید و دوست ندارید که وب سایت شما (به دلیل کمبود پهنای باند یا ارسال مطالب نامربوط که گاهی اوقات به صدها هزار مورد می‌رسد) از دسترس خارج شود این آموزش را دنبال کنید.
برای این منظور ما از یک 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);
        }
    }
}
و حال برای استفاده از این مکانیزم امنیتی ActionMethod مورد نظر را با آن امضا می‌کنیم:
[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
‫۸ سال و ۹ ماه قبل، پنجشنبه ۱۹ آذر ۱۳۹۴، ساعت ۱۴:۰۵
۳۹۵۶
۱۲
MVCSecurity
مطالب مشابه
  • #
    وحید نصیری وحید نصیری
    ‫۸ سال و ۹ ماه قبل، پنجشنبه ۱۹ آذر ۱۳۹۴، ساعت ۱۴:۲۸
    با تشکر از شما. چند نکته از لاگ‌های استخراج شده‌ی سایت جاری:
    - این برنامه‌ها، user agent‌های متفاوتی را به ازای هر درخواست ارسال می‌کنند (عموما). بنابراین مورد دوم هم علاوه بر مورد سوم نباید بکار گرفته شود.
    - دو نوع هش در حالت کلی وجود دارند. هش‌های سریع و هش‌های امن. هش‌های امن سعی می‌کنند این تضمین را ارائه دهند که به ازای یک ورودی مشخص، خروجی منحصربفردی را تولید کنند؛ اما ... با قیمت کندتر بودن عملیات هش. هش‌های سریع، مانند xxHash، برای یک چنین مواردی که نیاز هست کلید کش تولید شود بکار گرفته می‌شوند. الزاما مانند هش‌های امن سعی در تولید خروجی‌های منحصربفردی نمی‌کنند، اما تا این اندازه دقیق هستند که در بانک‌های اطلاعاتی key-value store فوق سریعی مانند Redis از آن‌ها استفاده می‌شود. بنابراین در یک چنین مواردی مانند سناریوی جاری بهتر است از هش‌های سریع استفاده شود. البته اگر آدرس صفحه و همچنین UA را حذف کنیم، نیازی به هش کردن نخواهد بود؛ چون IP را می‌توان بعنوان کلید درنظر گرفت.
    - بررسی UA از دیدگاه دیگری به صورت جداگانه می‌تواند مفید باشد. تشخیص بات‌های شناخته شده و بستن دسترسی آن‌ها.
    • #
      علی سالمیان علی سالمیان
      ‫۸ سال و ۹ ماه قبل، پنجشنبه ۱۹ آذر ۱۳۹۴، ساعت ۱۴:۳۵
      با تشکر از نکاتی که ذکر کردین. همانطوری که اشاره کردم حذف آدرس درخواست جاری موجب میشه محدودیت کمتری اعمال بشه و بهتره اینکار صورت نگیره و در مورد UserAgent هم اکثر برنامه‌ها یک مورد کاملا Fake رو ارسال میکنن و یا در هر درخواست اون رو تغییر میدن و اونقدر متنوع اینکار صورت میگیره که اصلا بهتره توی این مکانیزم نباشه. البته روی IP هم زیاد نمیشه حساب کرد ولی مکانیزن تکمیلی که به زودی منتشر میکنم با ترکیب کوکی‌، فیلد مخفی و این مکانیزم کار بسیار سختی رو پیش روی مهاجم قرار میده هرچند اون رو کاملا متوقف نمیکنه ولی حداقل میشه فعالیت کاربر متخلف رو تشخیص و اون رو بلاک کرد.
      • #
        وحید نصیری وحید نصیری
        ‫۸ سال و ۹ ماه قبل، پنجشنبه ۱۹ آذر ۱۳۹۴، ساعت ۱۵:۳۸
        «... حذف آدرس درخواست جاری موجب میشه محدودیت کمتری اعمال بشه و بهتره اینکار صورت نگیره ...»
        محدودیت کمتر در پارامترهای بررسی، آن‌را عمومی‌تر می‌کند و کل سایت را پوشش می‌دهد؛ تا اگر در یک صفحه بلاک شد، نتواند سایر صفحات و آدرس‌ها را به ترتیب اسپم کند.
        • #
          علی سالمیان علی سالمیان
          ‫۸ سال و ۹ ماه قبل، پنجشنبه ۱۹ آذر ۱۳۹۴، ساعت ۲۳:۱۸
          بله کاملا حرف شما درسته ولی اگر سیستمی مانند شبکه اجتماعی داشته باشیم بهتره این پارامتر حذف نشه چون درخواست‌های همزمان به متدهای مختلف صورت میگیره ولی در حالت عادی دخیل نشه بهتره.
  • #
    امیرحسین مرجانی امیرحسین مرجانی
    ‫۸ سال و ۹ ماه قبل، پنجشنبه ۱۹ آذر ۱۳۹۴، ساعت ۲۲:۵۶
    سلام
    یک نکته اساسی که شما در این مطلب در نظر نگرفتید، بحث استفاده صحیح از منابع سرور هست.
    به دلیل اینکه کش‌ها در RAM  ذخیره می‌شوند، و شما می‌خواهید به ازای هر IP هر AGENT هر درخواست یک کش اضافه کنید، اگر سایت شما بازدید زیادی داشته باشد خیلی زود RAM شما پر می‌شود و عملا سایت با کندی شدیدی مواجه می‌شود.
    البته راهکار‌های دیگری هم برای این کار وجود دارد...
    • #
      علی سالمیان علی سالمیان
      ‫۸ سال و ۹ ماه قبل، پنجشنبه ۱۹ آذر ۱۳۹۴، ساعت ۲۳:۲۷
      ولی من فکر میکنم شما خیلی بدبینانه به کش نگاه می‌کنید!
      اول اینکه سیستم کش طوری طراحی شده که وقتی به یک حد معینی از منابع استفاده کرد خالی میشه.
      دوم اینکه اگر بر فرض مثال متوسط زمان فیلترگذاری ما 5 ثانیه باشه کش ما هر 5 ثانیه اون مورد رو حذف میکنه.
      یک حساب سرانگشتی ساده:
      سایز رشته تولید شده در MD5 همیشه ثابت و 16 بایت است.
      اگر خیلی به شما ارفاق کنم و سایتی که میگین پر بازدید هست در عرض 5 ثانیه 10،000،000 درخواست داشته باشه! تنها 150 مگابایت از حافظه صرف اینکار میشه.
      - برای یک وب سایت پربازدید 150 مگابایت اصلا چیزی نیست.
      - اگر با یک شبکه اجتماعی سر و کار داشته باشیم هم اینکه سیستم پایگاههای داده غیررابطه ای جایگزین مناسبی هست هم اینکه اصلا می‌تونیم یک حافظه کاملا اختصاصی برای اون داشته باشیم (واقعا میصرفه 16 گیگ! رم بخریم برای اینکار چون شبکه اجتماعی درآمد زیادی داره)
      به این نکته هم توجه داشه باشیم اگر پارامتر سوم رو حذف کنیم به ازای هر IP در هر 5 ثانیه فقط یک درخواست میتونیم داشته باشیم و این یعنی باید از 10 میلیون مکان مختلف درخواست حمله صورت بگیره.

      به نظر من استفاده از کش گزینه خیلی خوبی هست ولی میشه با ترکیب سایر روشها به این حساسیت پاسخ داد.
  • #
    امیرحسین جلوداری امیرحسین جلوداری
    ‫۸ سال و ۹ ماه قبل، جمعه ۲۰ آذر ۱۳۹۴، ساعت ۱۹:۱۰
    یه سوال :
    اگر برای فرمی 20 ثانیه تایمر بذاریم که نتونه دوباره درخواست بده :
    حالا کاربر فرمی که valid نیست تو فیلدهاش رو ثبت میکنه و تایمر 20 ثانیه ای آغاز میشه ! در اینجا کاربر معمولا در کمتر از 20 ثانیه فرم رو تصحیح میکنه و دکمه‌ی ثبت رو میزنه و با خطای زمان بین درخواست مواجه میشه درسته؟

    پس بهتر نیست اول متد OnActionExecuting اعتبار فرم رو بررسی کنیم و در صورت معتبر نبود return کنیم : 

    if(!filterContext.Controller.ViewData.ModelState.IsValid)
                return;
    • #
      علی سالمیان علی سالمیان
      ‫۸ سال و ۹ ماه قبل، شنبه ۲۱ آذر ۱۳۹۴، ساعت ۰۰:۱۱
      به نکته بسیار خوبی اشاره کردین ولی بهتره به جای چک کردن ModelState یک خصوصیت به جدید به ActionFilter خودمون اضافه کنیم و بعد در صورتیکه نتیجه عملیات موفقیت آمیز بود اون رو True کنیم در نهایت در خود ActionFilter پس از اجرای اکشن چک میکنیم اگر این خصوصیت false بود یعنی چیزی ثبت نشده و کلید رو از کش حذف می‌کنیم و کاربر میتونه باز فرم رو ارسال کنه و تنها زمانی محدود میشه که واقعا چیزی ثبت شده باشه.
      در کل روند رو می‌تونیم در دست خودمون بگیرم و هروقت که بخواهیم بگیم که محدودیت اعمال بشه یا خیر.
      با توجه به نکاتی که در کامنت‌ها ذکر شد در مکانیزم تغییراتی داده شد و به پست اصلی ضمیمه کردم.
    • #
      وحید نصیری وحید نصیری
      ‫۸ سال و ۹ ماه قبل، شنبه ۲۱ آذر ۱۳۹۴، ساعت ۰۰:۳۷
      متد cache.Add نال را به عنوان مقدار قبول نمی‌کند. در پارامتر دوم، عدد مثلا 1 را وارد کنید.
    • #
      علی سالمیان علی سالمیان
      ‫۸ سال و ۹ ماه قبل، شنبه ۲۱ آذر ۱۳۹۴، ساعت ۰۰:۳۹
      دلیل این خطا به خاطر مقداری هست که بصورت null به متد add پاس داده شده و مقدار آیتمی که توی کش قرار میدیم نباید null باشه به شکل زیر تصحیح کنید:
      cache.Add(hashValue, true, null, DateTime.Now.AddSeconds(DelayRequest), Cache.NoSlidingExpiration, CacheItemPriority.Default, null);
  • #
    حمیدرضا شجاعی حمیدرضا شجاعی
    ‫۷ سال و ۵ ماه قبل، دوشنبه ۱۴ فروردین ۱۳۹۶، ساعت ۲۲:۳۳
    به عنوان یک پیشنهاد، می‌توان پارامتری دیگری هم اضافه کرد تا در صورت لزوم، کاربر به آدرس دیگری منتقل شود.
    public string RedirectUrl {get; set; }

...
if(cache[hasValue] != null) {
      filterContext.Controller.ViewData.ModelState.AddModelError("...", ...);
      filterContext.HttpContext.Response.Redirect(RedirectUrl);
}