اینترنت از زمان ابداع آن دنیایی ناامن بوده و پروتکل هایی که در بستر آن شکل گرفته اند، اکثرا آسیب پذیری هایی داشته اند. در این مقاله به بررسی آسیب پذیری های جدید، ناشناخته و کمتر شناخته شده ی دنیای برنامه های تحت وب می پردازیم.
آسیب پذیری NoSQL Injection، به هکرها اجازه می دهد تا با استفاده از ورودی های کاربر، روی پایگاه داده هدف کنترل داشته باشند. هکرها با استفاده از این آسیب پذیری می توانند:
یکی از پایگاه داده هایی که ساختار آن NoSQL است و آسیب پذیری NoSQL Injection در آن وجود دارد، MongoDB می باشد.
فرض کنید برنامه ای بر پایه پلتفرم Meteor نوشته ایم که نام کاربری و رمز عبور Hash شده را از کاربری که قصد ورود به سیستم دارد را می گیرد. برای اعتبارسنجی پارامترهای واردشده، آنها را با مقادیر پایگاه داده ی MongoDB مطابقت می دهیم:
اگر کاربر مقادیر درست را وارد کند تابع login صفحه مربوط به کاربر را برمیگرداند.
حال فرض کنید نوع متغیرهای username و hashedPassword از نوع string بوده ولی ما نوع این متغیرها را به طور static تعریف نمیکنیم تا کاربر هر نوع داده ای بتواند به این تابع بدهد مانند string, number و حتی object.
در این مثال، ما مقادیر admin و {$gte: ""} به ترتیب به تابع login ارسال کرده ایم. تابع login به پایگاه داده چنین query را ارسال می کند:
این query اولین صفحه ای که نام کاربری آن admin باشد و رمز hash شده آن بزرگتر از string خالی باشد را برمیگرداند. با این روش، هکر ما به راحتی به صفحه ای که نباید دسترسی داشته باشد، بدون داشتن رمز عبور می تواند دسترسی داشته باشد.
اگر پارامتر های ورودی تابع login type checking شوند می توان جلوی این آسیب پذیری را گرفت. در پلتفرم Meteor کتابخانه ای به نام Check برای چک کردن نوع آرگمان های ورودی وجود دارد که آن را به صورت زیر می توانیم به کار ببریم:
اگر در آرگمان های تابع Login نوع هایی بجز نوع مشخص شده در تابع check وجود داشته باشد با exception مواجه خواهد شد و اجرای تابع متوقف خواهد شد و هکر نمی تواند با آسیب پذیری NoSQL Injection به صفحات غیرمجاز دسترسی داشته باشد.
در وب سرورها معمولا آدرس IP وب سایت ها و برنامه های تحت وب یک میزبان یکسان است. به همین دلیل در header پروتکل HTTP باید Host مشخص شود. اگر ما به Host مقداری Invalid ارسال کنیم وب سرور معمولا آن درخواست را به Virtual Host منتقل می کند. همچنین می توانیم با استفاده از X-Forwarded-Host، درخواست هایی که هدر Host آنها Invalid است را به آدرسی که در هدر X-Forwarded-Host نوشته ایم بفرستیم:
بسیاری از وب سرورها به هدر Host برای شناسایی Host تکیه می کنند. متاسفانه آنچه که برنامه نویسان متوجه آن نیستند، این است که هدر Host می تواند توسط کاربر کنترل شود. همانطور که می دانید، در امنیت برنامه های تحت وب، ورودی های کاربر باید همیشه ناامن تلقی شود و نباید به ورودی های کاربر اعتماد کرد.
استفاده از هدر Host بیشتر در برنامه های تحت وب PHP رایج است. مثال زیر یک استفاده خطرناک از هدر Host است:
هکر می تواند کد زیر را با تغییر هدر host طوری تغییر دهد که کد html زیر تولید شود:
دو نوع حمله که با آسیب پذیری Host Header می توان انجام داد، Web-Cache Poisoning و Password Reset Poisoning می باشد:
نوعی حمله است که در آن هکر، با دستکاری محتوای Web-Cache می تواند محتوای مسموم را به کسانی که به آن صفحه درخواست می دهند را نشان دهد. برای این کار، هکر باید یا Cache proxy که داخل وبسایت اجرا می شود را مسموم کند یا CDN ها را مسموم کند یا هرنوع مکانیزم Caching که بین Client و سرور وجود دارد را مسموم کند. با این کار Client با درخواست به این سرورها محتوای مسموم دریافت خواهد کرد که هیچ کنترلی روی آن ندارد.
قطعه کد زیر نشان می دهد که چگونه یک هکر می تواند با آسیب پذیری host header حمله Web Cache Poisoning انجام دهد:
یک روش رایج برای پیاده سازی بازیابی رمز عبور، تولید یک توکن مخفی و ارسال آن به ایمیل با لینکی که حاوی آن توکن است می باشد. حال چه اتفاق میفتد اگر هکر درخواست بازیابی رمز عبور را با هدر Host ای توسط خود هکر کنترل می شود بدهد؟
اگر برنامه تحت وب، از مقادیر هدر Host برای ارسال لینک بازیابی رمز عبور ارسال کند، هکر می تواند لینک بازیابی رمز عبور را مسموم کند و به کاربر هدف بفرستد. اگر کاربر هدف بر روی لینک بازیابی رمز عبور کلیک کند، هکر می تواند توکن مخفی را به دست آورد و رمز وی را ریسیت کند و با آن وارد Web Application شود.
جلوگیری از این حمله ساده است. به هدر Host نباید اعتماد کرد و توسعه دهنده نباید از آن به طوری که به هکر اجازه سوءاستفاده از آن را بدهد، استفاده کند.
این نوع آسیب پذیری وقتی به میان می آید که هدر http توسط کاربر به صورت dynamic تولید می شود. از جمله حملاتی که در این آسیب پذیری انجام داده می شود، می توان به HTTP response splitting , Session fixation با هدر ست کوکی, XSS و Malicious Redirect با هدر Location اشاره کرد.
در این نوع حملات، هکر با آسیب پذیری موجود در سیستم می تواند session identifier شخص دیگری را برای خود یا هر کس دیگری set کند.
نمونه ای از این حمله را در زیر شبیه سازی کرده ایم:
فرض کنید علی در یک بانک که برنامه تحت وب آن آسیب پذیر است، حساب دارد http://unsafe.example.com . رضا میخواهد تا به حساب علی از بانک خودش دسترسی داشته باشد. و همچنین فرض کنید علی هر لینکی که رضا به او میفرستد را باز خواهد کرد.
رضا فهمیده است که آدرس http://unsafe.example.com هر نوع Session Identifier ای را قبول می کند و اعتبارسنجی روی آن انجام نمی دهد. پس این سایت امن نیست.
رضا به علی ایمیلی با محتویات زیر می فرستد:
رضا با این کار میخواهد که علی با SID روبرو I_WILL_KNOW_THE_SID وارد حساب خود شود.
حال علی روی لینک کلیک می کند و به حساب خود Login می کند.
در نهایت رضا با وارد شدن به آدرس http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID به حساب علی می تواند دسترسی داشته باشد!
بهترین راه حل Identity Confirmation می باشد. وقتی که کاربر وارد سایت می شود (Login می کند) Session ID وی را تغییر دهیم. به همین سادگی می توان به طور گسترده ای جلوی این نوع حملات را گرفت.
آسیب پذیری جعل درخواست سمت سرور نوعی حمله است که در آن هکر، می تواند از یک عملکرد سیستم سوءاستفاده کند و به اطلاعات سرور دسترسی داشته باشد یا آنها را دستکاری کند. به طور مستقیم این امکان برای هکر وجود ندارد اما با استفاده از این آسیب پذیری، این نوع حمله محقق می شود.
این حفره امنیتی به هکر اجازه انجام کارهای زیر را می دهد:
توصیه می شود برای جلوگیری از دسترسی هکر به منابع سرور، حتما whitelist ای از منابع قابل دسترس تعریف شود تا هکر نتواند به منابع حساس سیستم دسترسی داشته باشد.
این آسیب پذیری روی همه برنامه هایی که با ایمیل سرور ها ارتباط دارند می تواند تاثیر بگذارد. حمله IMAP/SMTP Injection زمانی که ایمیل سرور به طور مستقیم از اینترنت قابل دسترس نیست، موثرتر است. چون عموما سیستم های داخلی که ایمیل سرور متصل اند از امنیت بالایی برخوردار نیستند، ایمیل سرورها از آسیب پذیری بالایی برخوردارند.
در شکل بالا عبور ترافیک از کاربر به ایمیل سرور نشان داده شده است. در مرحله 1 و 2 کاربر با کلاینت webmail در ارتباط است در حالی که در مرحله '2 کاربر با رد کردن کلاینت WebMail به طور مستقیم با ایمیل سرور در ارتباط است.
این آسیب پذیری امکان وقوع حملات زیادی را از سوی هکر به وجود می آورد. برای مثال چند حمله زیر با آسیب پذیری IMAP/SMTP Injection انجام شده اند:
نوعی حمله بر اساس XML است که در آن برنامه ای که XML پارس میکند مورد هجوم قرار گرفته شود. این همه از طریق ورودی های XML انجام می گیرد. زمانی که ورودی های XML ارجاعی به یک موجودیت خارجی داشته باشد و هنگامی که آن ارجاع توسط یک XML Parser ضعیف پردازش شود، این حملات می تواند آسیب پذیر باشند. این حمله به هکر اجازه می دهد به داده های هویتی و حساس دسترسی داشته باشد، حمله DoS انجام دهد و ...
درخواست زیر حاوی External Entity می باشد که با رنگ قرمز مشخص شده اند و اصطلاحا به آن Evil Entity نیز می گویند:
در سناریوی زیر هکر با استفاده از درخواست بالا به راحتی می تواند به برنامه نفوذ کند و عملیات مخربانه خود را انجام دهد:
اکثر XML Parser ها در مقابل حملات XXE آسیب پذیرند. با بستن ارجاع به موجودیت های خارجی می توان جلوی این حمله را گرفت:
هنگامی که داده ها ذخیره می شوند یا انتقال داده می شوند بیت ها آن داده Serialize می شوند تا بعدا به ساختار داده اصلی آن بازگردانده شود. Deserialization به فرایند تبدیل بیت های داده به یک فایل یا یک شی می گویند. اگر الگوریتم Deserialization امن نباشد، داده های Deserialize شده قابل اصلاح خواهند بود. مثلا می توان کد های مخرب داخل آن داده ها قرار داد که باعث آسیب رسیدن به برنامه می شود.
فرض کنید وبسایتی که با php پیاده شده است از یک فرایند serialization برای ذخیره یک کوکی که حاوی اطلاعات هویتی کاربر است استفاده می کند:
هکر می تواند با دستکاری شی serialize شده به خودش دسترسی ادمین بدهد!
استفاده از الگوریتم های رمزگذاری برای شی های Serialize شده می تواند جلوی دستکاری آن را توسط هکر بگیرد.
هکر در این نوع آسیب پذیری سعی می کند تگ های Script ای را به صفحه خود اضافه کند که به منبع دیگری اشاره می کند. با منترل توابع , , هکر می تواند اطلاعاتی در مورد نحوه پاسخ سرور به درخواست های GET را به دست آورد.
برای مثال فرض کنید دیرکتوری admin/ زمانی که شما login کرده باشید کد وضعیت 200 را بر میگرداند. و هنگامی که لاگین نباشید کد وضعیت 401 را برمیگرداند.
برای انجام حمله شرایط زیر مورد نیاز است:
برای جلوگیری از این حمله کافی است یکی از شرایط بالا نقض شوند. برای مثال اگر در هدر HTTP، مقدار X-Content-Type-Options: nosniff برگردانده شود این حمله کار نخواهد کرد.
این آسیب پذیری باعث می شود که منابع یک برنامه تحت وب در یک دامنه خاص یا حتی در کل دامنه اش در معرض دسترسی قرار گرفته شود. و همچنین باعث می شود کلاینت برای یک منبعی در دامنه ای بجز دامنه اصلی درخواست AJAX بفرستد.
این آسیب پذیری از پیکربندی نادرست CORS به وجود می آید. بسیاری از وبسایت ها از CORS برای اجازه دسترسی به زیردامنه ها و دیگر اشخاص ثالث معتبر استفاده می کنند. اگر پیاده سازی CORS به اشتباه صورت گیرد یا از امنیت آن مطمئن نشوند، باعث به وجود آمدن آسیب پذیری در آن وبسایت خواهد شد.
هنگامی که یک کلاینت درخواست منبعی را از دامنه دیگری می کند، هدر HTTP آن به این صورت است:
کلاینت با استفاده از هدر Origin به سرور دامنه مرجع خود را اعلام می کند. سرور یا برنامه تحت وب به این درخواست اینگونه پاسخ می دهد:
وب سرور در پاسخ به کلاینت در هدر Access-Control-Allow-Origin، دامنه های مجاز را به وی اطلاع می دهد. در این مثال "*" به این معنی است که تمامی دامنه ها مجاز هستند.
آسیب پذیری این ویژگی اینجاست که کلاینت می تواند هر مقداری را در هدر Origin که به سرور درخواست می دهد، قرار دهد تا برنامه تحت وب را وادار کند محتوایی که می خواهد را در پاسخ به وی ارسال کند. اگر کلاینت Browser باشد که این هدر توسط Browser کنترل می شود اما با استفاده از کلاینت های دیگر مانند Putty می توان مقادیر هدر Origin را تغییر داد. برای همین بهتر است از هدر Origin برای اعتبارسنجی درخواست هایی که به سایت شما می آید استفاده نکنید.
بسیاری از آسیب پذیری های یاد شده با رعایت حداقل نکات امنیتی قابل پیشگیری می باشند. این آسیب پذیری ها اکثرا با اشتباهات خود برنامه نویس ها رخ می دهند و به هکرها اجازه سوءاستفاده از برنامه خود را می دهند. حملاتی که با به وجود آمدن این آسیب پذیری ها رخ می دهند به مراتب می تواند آسیب های جبران ناپذیری را به افراد منابع و... وارد کنند. پس امنیت در دنیای اینترنت مخصوصا برنامه های تحت وب بسیار ضروری است.
[1] OWASP
[2] Acunetix
