گناهان مرگبار امنیت وب سایت: آنچه از آمار اسکنر آسیب پذیری در سال آموختیم

حدود یک سال پیش، ما در DataLine راه اندازی شد خدمات برای جستجو و تجزیه و تحلیل آسیب پذیری ها در برنامه های IT. این سرویس مبتنی بر راه حل ابری Qualys است که در مورد عملکرد آن است قبلا گفته ایم. در طول یک سال کار با این راه حل، ما 291 اسکن برای سایت های مختلف انجام دادیم و آماری از آسیب پذیری های رایج در برنامه های وب جمع آوری کردیم. 

در مقاله زیر دقیقاً به شما نشان خواهم داد که چه حفره هایی در امنیت وب سایت در پشت سطوح مختلف بحران پنهان است. بیایید ببینیم اسکنر به خصوص اغلب چه آسیب‌پذیری‌هایی را پیدا می‌کند، چرا ممکن است رخ دهند و چگونه از خود محافظت کنیم. 

Qualys تمام آسیب پذیری های برنامه های وب را به سه سطح بحرانی تقسیم می کند: کم، متوسط ​​و زیاد. اگر با "شدت" به توزیع نگاه کنید، به نظر می رسد که همه چیز چندان بد نیست. آسیب پذیری های کمی با سطح بحرانی بالا وجود دارد، اکثراً همه غیر بحرانی هستند: 

اما غیرانتقادی به معنای بی ضرر نیست. آنها همچنین می توانند آسیب جدی ایجاد کنند. 

برترین آسیب‌پذیری‌های «غیر بحرانی».

1. آسیب پذیری های محتوای مختلط

   استاندارد امنیت وب سایت، انتقال داده بین مشتری و سرور از طریق پروتکل HTTPS است که از رمزگذاری پشتیبانی می کند و از اطلاعات در برابر رهگیری محافظت می کند. 

   برخی از سایت ها استفاده می کنند محتوای مخلوط: برخی از داده ها از طریق پروتکل HTTP ناامن منتقل می شوند. بیشتر اوقات اینگونه منتقل می شود محتوای منفعل - اطلاعاتی که فقط بر نمایش سایت تأثیر می گذارد: تصاویر، سبک های css. اما گاهی اوقات به این صورت منتقل می شود محتوای فعال: اسکریپت هایی که رفتار سایت را کنترل می کنند. در این حالت، با استفاده از نرم‌افزار ویژه، می‌توانید اطلاعاتی را با محتوای فعال که از سرور می‌آید تجزیه و تحلیل کنید، پاسخ‌های خود را در لحظه تغییر دهید و کاری کنید که دستگاه به گونه‌ای کار کند که سازندگان آن در نظر گرفته نشده‌اند. 

   نسخه‌های جدید مرورگرها به کاربران هشدار می‌دهند که سایت‌هایی با محتوای ترکیبی ناامن هستند و محتوا را مسدود می‌کنند. توسعه دهندگان وب سایت همچنین هشدارهای مرورگر را در کنسول دریافت می کنند. به عنوان مثال، ظاهر آن اینگونه است فایرفاکس: 

   
   
   چرا خطرناک است؟: مهاجمان از یک پروتکل ناامن برای رهگیری اطلاعات کاربر، جایگزینی اسکریپت ها و ارسال درخواست به سایت از طرف او استفاده می کنند. حتی اگر یک بازدید کننده سایت داده ها را وارد نکرده باشد، این از او محافظت نمی کند فیشینگ - به دست آوردن اطلاعات محرمانه با استفاده از روش های متقلبانه. به عنوان مثال، با استفاده از یک اسکریپت، می توانید کاربر را به یک سایت ناامن هدایت کنید که به عنوان سایتی آشنا برای کاربر ظاهر می شود. در برخی موارد، سایت مخرب حتی بهتر از نسخه اصلی به نظر می رسد و کاربر می تواند خود فرم را پر کرده و داده های محرمانه را ارسال کند. 

   آنچه که یک توسعه دهنده وب باید به خاطر بسپارد: حتی اگر مدیر سایت یک گواهی SSL/TLS را نصب و پیکربندی کرده باشد، ممکن است یک آسیب پذیری به دلیل خطای انسانی ایجاد شود. به عنوان مثال، اگر در یکی از صفحات نه یک پیوند نسبی، بلکه یک پیوند مطلق از http قرار دهید و علاوه بر این، تغییر مسیر از http به https را تنظیم نکرده باشید. 

   می‌توانید محتوای ترکیبی را در یک سایت با استفاده از مرورگر شناسایی کنید: کد منبع صفحه را جستجو کنید، اعلان‌ها را در کنسول برنامه‌نویس بخوانید. با این حال، توسعه‌دهنده باید برای مدت طولانی و به‌طور خسته‌کننده، کد را سرهم کند. شما می توانید با ابزارهای تجزیه و تحلیل خودکار سرعت فرآیند را افزایش دهید، به عنوان مثال: بررسی SSL، نرم افزار رایگان Lighthouse یا نرم افزار پولی Screaming Frog SEO Spider.

   همچنین، این آسیب‌پذیری ممکن است به دلیل مشکلات مربوط به legacy-code ایجاد شود - کدی که به ارث رسیده است. به عنوان مثال، اگر برخی از صفحات با استفاده از یک قالب قدیمی تولید شوند، که انتقال سایت ها به https را در نظر نمی گیرد.    

2. کوکی‌هایی بدون پرچم «HTTPOnly» و «امن».

   ویژگی "HTTPOnly" از کوکی ها در برابر پردازش توسط اسکریپت هایی که مهاجمان برای سرقت داده های کاربر استفاده می کنند محافظت می کند. پرچم "امن" اجازه نمی دهد کوکی ها به صورت متن واضح ارسال شوند. ارتباط تنها در صورتی مجاز خواهد بود که از پروتکل امن HTTPS برای ارسال کوکی ها استفاده شود. 

   هر دو ویژگی در ویژگی های کوکی مشخص شده اند:

   Set-Cookie: Secure; HttpOnly

   چرا خطرناک است؟: اگر توسعه دهنده سایت این ویژگی ها را مشخص نکرده باشد، مهاجم می تواند اطلاعات کاربر را از کوکی رهگیری کرده و از آن سوء استفاده کند. اگر از کوکی ها برای احراز هویت و مجوز استفاده شود، او می تواند جلسه کاربر را ربوده و از طرف او اقداماتی را در سایت انجام دهد. 

   آنچه که یک توسعه دهنده وب باید به خاطر بسپارد: به عنوان یک قاعده، در چارچوب های محبوب، این ویژگی ها به طور خودکار تنظیم می شوند. اما همچنان پیکربندی وب سرور را بررسی کنید و پرچم را تنظیم کنید: Set-Cookie HttpOnly; امن است.

   در این حالت، ویژگی «HTTPOnly» کوکی‌ها را برای جاوا اسکریپت شما نامرئی می‌کند.  

3. آسیب پذیری های مبتنی بر مسیر

   اگر اسکنر یک فایل در دسترس عموم یا فهرست وب سایت با اطلاعات محرمانه بالقوه پیدا کند، چنین آسیب پذیری را گزارش می کند. برای مثال، فایل‌های پیکربندی سیستم یا دسترسی به کل سیستم فایل را شناسایی می‌کند. این وضعیت در صورتی امکان پذیر است که حقوق دسترسی به اشتباه در سایت تنظیم شود.

   چرا خطرناک است؟: اگر سیستم فایل «خارج شود»، مهاجم می‌تواند به رابط سیستم عامل بیفتد و سعی کند پوشه‌هایی را که پسورد آن‌ها در متن واضح ذخیره شده‌اند پیدا کند (این کار را نکنید!). یا می‌توانید هش‌های رمز عبور را بدزدید و رمز عبور را به زور انجام دهید، و همچنین سعی کنید امتیازات را در سیستم افزایش دهید و به زیرساخت عمیق‌تر بروید.  

   آنچه که یک توسعه دهنده وب باید به خاطر بسپارد: حقوق دسترسی را فراموش نکنید و پلت فرم، وب سرور، برنامه وب را پیکربندی کنید تا "فرار" از فهرست وب غیرممکن باشد.

4. فرم‌هایی برای وارد کردن داده‌های حساس با پر کردن خودکار فعال است.

   اگر کاربر اغلب فرم‌ها را در وب‌سایت‌ها پر می‌کند، مرورگر او این اطلاعات را با استفاده از ویژگی تکمیل خودکار ذخیره می‌کند. 

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

   چرا خطرناک است؟: اگر مرورگر کاربر اطلاعات حساس را ذخیره کند، مهاجم می تواند بعداً آن را رهگیری کند، مثلاً از طریق فیشینگ. در اصل، یک توسعه دهنده وب که این تفاوت های ظریف را فراموش کرده است، کاربران خود را راه اندازی می کند. 

   آنچه که یک توسعه دهنده وب باید به خاطر بسپارد: در این مورد، ما یک تضاد کلاسیک داریم: راحتی در مقابل امنیت. اگر یک توسعه دهنده وب به تجربه کاربری فکر می کند، می تواند آگاهانه تکمیل خودکار را انتخاب کند. به عنوان مثال، اگر مهم است که دنبال کنید دستورالعمل های دسترسی به محتوای وب - توصیه هایی برای دسترسی به محتوا برای کاربران دارای معلولیت. 

   برای اکثر مرورگرها، می توانید تکمیل خودکار را با ویژگی autocompete="off" غیرفعال کنید، به عنوان مثال:

    <body>
       <form action="/fa/form/submit" method="get" autocomplete="off">
         <div>
           <input type="text" placeholder="First Name">
         </div>
         <div>
           <input type="text" id="lname" placeholder="Last Name" autocomplete="on">
         </div>
         <div>
           <input type="number" placeholder="Credit card number">
         </div>
         <input type="submit">
       </form>
     </body>

   اما برای کروم کار نخواهد کرد. این با استفاده از جاوا اسکریپت دور زده می شود، یک نوع دستور غذا را می توان یافت اینجا. 

5. هدر X-Frame-Options در کد سایت تنظیم نشده است. 

   این هدر بر تگ‌های فریم، iframe، embed یا object تأثیر می‌گذارد. با کمک آن می توانید به طور کامل از قرار دادن سایت خود در یک قاب جلوگیری کنید. برای این کار باید مقدار X-Frame-Options: deny را مشخص کنید. یا می توانید X-Frame-Options: sameorigin را مشخص کنید، سپس جاسازی در iframe فقط در دامنه شما در دسترس خواهد بود.

   چرا خطرناک است؟: عدم وجود چنین هدر می تواند در سایت های مخرب استفاده شود کلیک جک کردن. برای این حمله، مهاجم یک قاب شفاف در بالای دکمه ها ایجاد می کند و کاربر را فریب می دهد. به عنوان مثال: کلاهبرداران صفحات شبکه های اجتماعی را در یک وب سایت قاب می کنند. کاربر فکر می کند که روی دکمه ای در این سایت کلیک می کند. در عوض، کلیک رهگیری می شود و درخواست کاربر به شبکه اجتماعی که در آن جلسه فعال است ارسال می شود. اینگونه است که مهاجمان از طرف کاربر هرزنامه ارسال می کنند یا مشترکین و لایک ها را به دست می آورند. 

   اگر این ویژگی را غیرفعال نکنید، مهاجم می تواند دکمه برنامه شما را روی یک سایت مخرب قرار دهد. او ممکن است به برنامه ارجاع شما یا کاربران شما علاقه مند باشد.  

   آنچه که یک توسعه دهنده وب باید به خاطر بسپارد: اگر X-Frame-Options با مقدار متناقض روی سرور وب یا متعادل کننده بار تنظیم شده باشد، آسیب پذیری ممکن است رخ دهد. در این حالت، سرور و متعادل کننده به سادگی هدر را بازنویسی می کنند، زیرا اولویت بیشتری نسبت به کد باطن دارند.  

   مقادیر انکار و یکسان مبدا هدر X-Frame-Options با عملکرد نمایشگر وب Yandex تداخل خواهد داشت. برای اجازه دادن به استفاده از iframe برای نمایشگر وب، باید یک قانون جداگانه در تنظیمات بنویسید. به عنوان مثال، برای nginx می توانید آن را به صورت زیر پیکربندی کنید:

   http{
   ...
    map $http_referer $frame_options {
    "~webvisor.com" "ALLOW-FROM http://webvisor.com";
    default "SAMEORIGIN";
    }
    add_header X-Frame-Options $frame_options;
   ...
   }
   
   

6. آسیب پذیری PRSSI (وارد کردن شیوه نامه مربوط به مسیر).  

   این یک آسیب پذیری در استایل سایت است. اگر از پیوندهای نسبی مانند href="/fa/somefolder/styles.css/" برای دسترسی به فایل های سبک استفاده شود، این اتفاق می افتد. اگر مهاجم راهی برای هدایت کاربر به یک صفحه مخرب پیدا کند، از این مزیت استفاده خواهد کرد. صفحه یک پیوند نسبی را در آدرس اینترنتی خود وارد می کند و یک فراخوانی سبک را شبیه سازی می کند. شما درخواستی مانند badsite.ru/…/somefolder/styles.css/ دریافت خواهید کرد که می تواند اقدامات مخربی را تحت پوشش یک سبک انجام دهد. 

   چرا خطرناک است؟: یک کلاهبردار در صورت یافتن حفره امنیتی دیگری می تواند از این آسیب پذیری سوء استفاده کند. در نتیجه، امکان سرقت اطلاعات کاربر از کوکی ها یا توکن ها وجود دارد.

   آنچه که یک توسعه دهنده وب باید به خاطر بسپارد: سربرگ X-Content-Type-Options را روی: nosniff تنظیم کنید. در این صورت، مرورگر نوع محتوا را برای استایل ها بررسی می کند. اگر نوع آن غیر از text/css باشد، مرورگر درخواست را مسدود می کند.

آسیب پذیری های بحرانی

1. صفحه ای با فیلد رمز عبور از سرور از طریق یک کانال ناامن منتقل می شود (فرم HTML حاوی فیلد(های) رمز عبور از طریق HTTP ارائه می شود).

   پاسخ سرور از طریق یک کانال رمزگذاری نشده در برابر حملات "مردی در وسط" آسیب پذیر است. یک مهاجم می‌تواند ترافیک را رهگیری کند و زمانی که صفحه از سرور به مشتری می‌رود، خود را بین مشتری و سرور قرار دهد. 

   چرا خطرناک است؟: کلاهبردار می تواند صفحه را جایگزین کرده و فرمی را برای اطلاعات محرمانه برای کاربر ارسال کند که به سرور مهاجم می رود. 

   آنچه که یک توسعه دهنده وب باید به خاطر بسپارد: برخی از سایت ها به جای رمز عبور، یک کد یکبار مصرف از طریق ایمیل/تلفن برای کاربران ارسال می کنند. در این مورد، آسیب پذیری چندان مهم نیست، اما مکانیسم آن زندگی کاربران را پیچیده می کند.

2. ارسال فرم با لاگین و رمز عبور از طریق یک کانال ناامن (فرم ورود از طریق HTTPS ارسال نمی شود).

   در این حالت فرمی با لاگین و رمز عبور از طریق یک کانال رمزگذاری نشده از کاربر به سرور ارسال می شود.

   چرا خطرناک است؟: برخلاف مورد قبلی، این آسیب‌پذیری در حال حاضر یک آسیب‌پذیری حیاتی است. رهگیری داده های حساس آسان تر است زیرا برای انجام این کار حتی نیازی به نوشتن کد ندارید. 

3. استفاده از کتابخانه های جاوا اسکریپت با آسیب پذیری های شناخته شده.

   در طول اسکن، بیشترین استفاده از کتابخانه جی کوئری با تعداد زیادی نسخه بود. هر نسخه حداقل یک یا حتی بیشتر آسیب پذیری شناخته شده دارد. تأثیر می تواند بسته به ماهیت آسیب پذیری بسیار متفاوت باشد.

   چرا خطرناک است؟: برای آسیب پذیری های شناخته شده سوء استفاده هایی وجود دارد، به عنوان مثال:

   
   
   آنچه که یک توسعه دهنده وب باید به خاطر بسپارد: به طور منظم به چرخه بازگردید: آسیب پذیری های شناخته شده را جستجو کنید - رفع - بررسی کنید. اگر از کتابخانه های قدیمی عمدا استفاده می کنید، به عنوان مثال برای پشتیبانی از مرورگرهای قدیمی یا صرفه جویی در هزینه، به دنبال فرصتی برای رفع یک آسیب پذیری شناخته شده باشید. 

4. اسکریپت بین سایتی (XSS). 
   Cross-Site Scripting (XSS) یا cross-site scripting، حمله ای به یک برنامه وب است که منجر به ورود بدافزار به پایگاه داده می شود. اگر Qualys چنین آسیب‌پذیری را پیدا کند، به این معنی است که یک مهاجم بالقوه می‌تواند یا قبلاً اسکریپت js خود را برای انجام اقدامات مخرب وارد کد سایت کرده است.

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

   XSS منعکس شده است از آنجایی که یک اسکریپت مخرب می تواند به یک درخواست HTTP تزریق شود، آسان تر است. برنامه یک درخواست HTTP دریافت می کند، داده ها را تایید نمی کند، آن را بسته بندی می کند و بلافاصله ارسال می کند. اگر یک مهاجم ترافیک را رهگیری کند و اسکریپتی مانند

   <script>/*+что+то+плохое+*/</script> 

   سپس یک درخواست مخرب از طرف مشتری ارسال می شود.

   نمونه بارز XSS: sniffers js که صفحات را برای وارد کردن CVC، تاریخ انقضای کارت و غیره شبیه‌سازی می‌کند. 

   آنچه که یک توسعه دهنده وب باید به خاطر بسپارد: در سربرگ Content-Security-Policy، از ویژگی script-src استفاده کنید تا مرورگر مشتری را مجبور کنید که فقط کد را از یک منبع مطمئن دانلود و اجرا کند. به عنوان مثال، script-src 'self' همه اسکریپت ها را فقط از سایت ما در لیست سفید قرار می دهد. 
   بهترین روش کد Inline است: فقط جاوا اسکریپت درون خطی را با استفاده از مقدار ناامن-inline مجاز کنید. این مقدار اجازه استفاده از js/css درون خطی را می دهد، اما گنجاندن فایل های js را ممنوع نمی کند. در ترکیب با script-src 'self' ما اجرای اسکریپت های خارجی را غیرفعال می کنیم.

   مطمئن شوید که همه چیز را با استفاده از Report-uri وارد کرده اید و به تلاش ها برای پیاده سازی آن در سایت نگاه کنید.

5. تزریق SQL
   این آسیب پذیری نشان دهنده امکان تزریق کد SQL به وب سایتی است که مستقیماً به پایگاه داده وب سایت دسترسی دارد. تزریق SQL در صورتی امکان‌پذیر است که داده‌های کاربر غربال نشوند: صحت آن بررسی نمی‌شود و بلافاصله در پرس و جو استفاده می‌شود. به عنوان مثال، اگر فرمی در یک وب سایت بررسی نکند که آیا ورودی با نوع داده مطابقت دارد یا خیر، این اتفاق می افتد. 

   چرا خطرناک است؟: اگر مهاجم یک پرس و جوی SQL را در این فرم وارد کند، می تواند پایگاه داده را خراب کند یا اطلاعات محرمانه را فاش کند. 

   آنچه که یک توسعه دهنده وب باید به خاطر بسپارد: به آنچه از مرورگر می آید اعتماد نکنید. شما باید از خود در سمت مشتری و سرور محافظت کنید. 

   در سمت کلاینت، اعتبار فیلد را با استفاده از جاوا اسکریپت بنویسید. 

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

   تعیین کنید که تعامل با پایگاه داده دقیقاً در کجای برنامه وب انجام می شود. 

   تعامل زمانی رخ می دهد که ما هر گونه اطلاعاتی را دریافت می کنیم: یک درخواست با یک شناسه (تغییر شناسه)، ایجاد یک کاربر جدید، یک نظر جدید یا ورودی های جدید در پایگاه داده. این جایی است که تزریق SQL می تواند رخ دهد. حتی اگر رکوردی را از پایگاه داده حذف کنیم، تزریق SQL امکان پذیر است.

توصیه های عمومی

چرخ را دوباره اختراع نکنید - از چارچوب های اثبات شده استفاده کنید. به عنوان یک قاعده، چارچوب های محبوب امن تر هستند. برای . - فنر MVC.

به‌روزرسانی‌های فروشنده را دنبال کنید و مرتباً به‌روزرسانی کنید. آنها یک آسیب پذیری پیدا می کنند، سپس یک اکسپلویت می نویسند، آن را در دسترس عموم قرار می دهند و همه چیز دوباره اتفاق می افتد. مشترک به‌روزرسانی‌های نسخه‌های پایدار از فروشنده نرم‌افزار شوید.

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

از کلون ها، سایت های آزمایشی استفاده کنید و سپس از آنها برای تولید استفاده کنید. این اولاً به جلوگیری از اشتباهات و اشتباهات در یک محیط مولد کمک می کند: یک محیط مولد پول می آورد، یک محیط مولد ساده بسیار مهم است. هنگام افزودن، رفع یا بستن هر مشکلی، ارزش دارد که در یک محیط آزمایشی کار کنید، سپس عملکرد و آسیب پذیری های یافت شده را بررسی کنید و سپس برای کار با محیط تولید برنامه ریزی کنید. 

از برنامه وب خود محافظت کنید فایروال برنامه وب و گزارش های اسکنر آسیب پذیری را با آن یکپارچه کنید. به عنوان مثال، DataLine از Qualys و FortiWeb به عنوان مجموعه ای از خدمات استفاده می کند.

منبع: www.habr.com