OWASP | در جهان دیجیتال پیشرفته امروز، امنیت برنامه‌های وب امری حیاتی است. با توجه به تحولات فناورانه، شناخت دقیق از خطرات امنیتی ضروری است. در اینجا، با معرفی لیست 10 خطر امنیتی برتر سال 2021، با مواردی همچون Broken Access Control و Vulnerable Components آشنا خواهید شد.
OWASP Top 10 2021
- Broken Access Control (A01 – کنترل دسترسی شکسته شده): نقض کنترل دسترسی ممکن است به دسترسی غیرمجاز به منابع سیستم و اطلاعات حساس منجر شود.
- Cryptographic Failures (A02 – خطاهای رمزنگاری): مشکلات در استفاده از رمزنگاری ممکن است اطلاعات حساس را در معرض خطر قرار دهد.
- Injection (A03 – تزریق): حملات تزریق به ورود اطلاعات غیرمجاز به برنامه‌ها منجر می‌شوند.
- Insecure Design (A04 – طراحی ناامن): طراحی نادرست برنامه‌ها ممکن است منجر به آسیب‌پذیری‌های امنیتی شود.
- Security Misconfiguration (A05 – پیکربندی امنیتی نادرست): تنظیمات امنیتی نادرست می‌توانند به حملات نفوذی منجر شوند.
- Vulnerable and Outdated Components (A06 – اجزاء آسیب‌پذیر و قدیمی): استفاده از اجزاء نرم‌افزاری با آسیب‌پذیری‌های شناخته شده ممکن است به حملات نفوذی منجر شود.
- Identification and Authentication Failures (A07 – شکست‌های احراز هویت و اعتبارسنجی): مشکلات در احراز هویت و دسترسی ممکن است به دسترسی غیرمجاز منجر شوند.
- Software and Data Integrity Failures (A08 – خطاهای صحت نرم‌افزار و داده): مشکلات در صحت نرم‌افزار و داده ممکن است به تغییرات غیرمجاز و اجرای کدهای مخرب منجر شود.
- Security Logging and Monitoring Failures (A09 – خطاهای ثبت و نظارت امنیتی): نقص در فرآیند ثبت و نظارت بر روی وقایع سیستم ممکن است تشخیص حملات را کاهش دهد.
- Server Side Request Forgery (SSRF) (A10 – فراموشی درخواست سمت سرور): درخواست‌های نادرست به سرور ممکن است به حملات نفوذی منجر شوند.
این لیست ارزشمند از خطرات امنیتی، توسعه‌دهندگان و مدیران امنیتی را در جلوگیری از حملات و بهبود امنیت برنامه‌های وب یاری می‌کند.
Broken Access Control
امنیت برنامه‌های وب از جمله چالش‌های اساسی در دنیای دیجیتال مدرن است. یکی از خطرات امنیتی برتر در سال 2021 از نظر OWASP ، خطر کنترل دسترسی شکسته شده (A01) بوده است. در ادامه، با بررسی جزئیات این خطر امنیتی، اقدامات پیشگیری و راهکارهای جلوگیری از آن آشنا خواهیم شد.
خطر کنترل دسترسی شکسته شده: موقعیت و آمار
در لیست 10 خطر امنیتی برتر 2021، خطر کنترل دسترسی شکسته شده (A01) از جایگاه پنجم به رتبه اول پیشرفته است. 94٪ از برنامه‌ها تست شده در این زمینه با میانگین نرخ حادثه 3.81٪ این خطر را تجربه کرده‌اند. با بیش از 318 هزار مورد، این خطر بیشترین تعداد وقوع را در مجموعه داده‌های مشارکت کننده دارد.
توضیحات خطر:
کنترل دسترسی، سیاست‌هایی را اجرا می‌کند تا کاربران نتوانند خارج از مجوزهای مقصودی خود عمل کنند. شکست در این کنترل‌ها معمولاً منجر به افشای اطلاعات غیرمجاز، تغییر یا از بین بردن همه داده‌ها یا انجام یک عملکرد تجاری خارج از محدودیت‌های کاربر می‌شود. آسیب‌پذیری‌های متداول کنترل دسترسی شامل موارد زیر هستند:
- نقض اصل حداقل امتیاز یا اصل عدم مجوز، جایی که دسترسی فقط باید برای قابلیت‌ها، نقش‌ها یا کاربران خاص اختصاص یابد، اما برای همه در دسترس است.
- نادیده گرفتن چک‌های کنترل دسترسی با تغییر URL (تقلب پارامتر یا مرور اجباری)، حالت داخلی برنامه یا صفحه HTML یا با استفاده از ابزار حمله بر روی درخواست‌های API.
- اجازه مشاهده یا ویرایش حساب شخص دیگر با فراهم کردن شناسه منحصر به فرد آن (مراجعه مستقیم اشیاء ناامن).
- دسترسی به API با کنترل‌های دسترسی گمشده برای POST، PUT و DELETE.
- افزایش امتیاز. عمل به عنوان یک کاربر بدون ورود یا عمل به عنوان یک مدیر هنگام ورود به عنوان یک کاربر.
- دستکاری متادیتا، مانند بازپخت یا دستکاری توکن کنترل دسترسی JSON Web Token (JWT) یا یک کوکی یا فیلد مخفی که برای افزایش امتیازها یا سوءاستفاده از ابطال JWT استفاده می‌شود.
- اشتباه تنظیم‌شده CORS اجازه دسترسی به API از منابع غیرمجاز یا ناامن را می‌دهد.
- ورود اجباری به صفحات احراز هویت شده به عنوان یک کاربر غیر احراز هویت شده یا به عنوان یک کاربر معمولی.
چگونگی پیشگیری:
- کنترل دسترسی تنها در کد سمت سرور یا API بدون سرور اعتبار دار است، جایی که حمله‌کننده نمی‌تواند کنترل دسترسی یا متادیتای آن را تغییر دهد.
- به جز برای منابع عمومی، اصل عدم مجوز را رعایت کنید.
- مکانیسم‌های کنترل دسترسی را یک بار پیاده‌سازی کنید و آنها را در سراسر برنامه استفاده کنید، از جمله کاهش استفاده از Cross-Origin Resource Sharing (CORS).
- مدل‌های کنترل دسترسی باید مالکیت را اعمال کنند به جای اینکه قبول کنند کاربر می‌تواند هر رکوردی را ایجاد، خواندن، به‌روزرسانی یا حذف کند.
- نیازمندی‌های منحصر به فرد کسب و کار برنامه باید توسط مدل‌های دامنه اجرا شوند.
- لیست‌های دایرکتوری وب سرور را غیرفعال کنید و اطمینان حاصل کنید که فایل‌های متادیتا (مانند .git) و فایل‌های پشتیبان در داخل ریشه وب وجود ندارند.
- خطاهای کنترل دسترسی را ثبت کنید و در مواقع مناسب (مثل خطاهای تکراری) به مدیران هشدار دهید.
- دسترسی به API و کنترل‌های کنترلر را محدود کنید تا آسیب از ابزار حمله‌گر خودکار کمینه شود.
- شناسه‌های نشست دارای حالت باید پس از خروج در سرور ابطال شوند. برای توکن‌های JSON Web Token بدون حالت، توصیه می‌شود تا کوتاه مدت باشند تا بازه فرصت حمله‌کننده کمینه شود. برای توکن‌های با مدت زندگی طولانی‌تر، بسیار پیشنهاد می‌شود که استانداردهای OAuth را برای لغو دسترسی دنبال کنید.
- توسعه‌دهندگان و تیم‌های QA باید آزمون‌های واحد و ادغام کنترل دسترسی را شامل کنند.
سناریوهای حمله نمونه:
سناریو ۱:
برنامه از داده‌های تأیید نشده در یک تماس SQL استفاده می‌کند که به اطلاعات حساب دسترسی دارد:
pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery();
حمله‌کننده به سادگی پارامتر ‘acct’ مرورگر را به هر شماره حسابی که می‌خواهد تغییر می‌دهد. اگر به درستی تأیید نشود، حمله‌کننده می‌تواند به هر حساب کاربری دلخواه دسترسی پیدا کند.
URL نمونه:
https://example.com/app/accountInfo?acct=notmyacct
سناریو ۲:
حمله‌کننده به سادگی URLهای هدف را مرور می‌کند. برای دسترسی به صفحه مدیر نیاز به دسترسی مدیریت است.
URLهای نمونه:
https://example.com/app/getappInfo https://example.com/app/admin_getappInfo
اگر یک کاربر غیر احراز هویت یا یک کاربر معمولی به هر کدام از صفحات دسترسی پیدا کند، این یک نقص است. اگر یک کاربر غیر ادمین به صفحه مدیر دسترسی پیدا کند، این یک نقص است.
Cryptographic Failures
یکی دیگر از خطرات امنیتی برتر در سال 2021 در OWASP، خطر رمزنگاری (A02) یا همان خطرات رمزنگاری ناکام در برنامه‌های وب است. در ادامه، با بررسی جزئیات این خطر امنیتی، راهکارهای جلوگیری و پیشگیری از آن به شما معرفی خواهیم کرد.
خطر رمزنگاری شکسته شده: تحلیل و آمار
با پیشرفت به رتبه دوم در لیست 10 خطر امنیتی برتر سال 2021، خطر رمزنگاری شکسته شده (A02) یا قبلاً شناخته شده به عنوان “افشای اطلاعات حساس”، موضوعی است که بیشتر به عنوان یک علامت کلی تلقی می‌شود تا علت اصلی. تمرکز در اینجا بر روی خطاهای مرتبط با رمزنگاری یا عدم وجود آن است که معمولاً منجر به افشای اطلاعات حساس می‌شود.
| CWE های نسبت داده‌شده | نرخ حوادث بیشینه | نرخ حوادث متوسط | میانگین تجربی تسخیر | میانگین تاثیر تسخیر | پوشش بیشینه | پوشش متوسط | تعداد کل وقایع | تعداد کل CVE ها |
|---|---|---|---|---|---|---|---|---|
| 29 | 46.44٪ | 4.49٪ | 7.29 | 6.81 | 79.33٪ | 34.85٪ | 233,788 | 3,075 |
تعیین نیازهای حفاظتی:
اولین گام برای پیشگیری از خطرات رمزنگاری شکسته شده، تعیین نیازهای حفاظتی برای داده‌ها در حال انتقال و در حال استراحت است. اطلاعات حساس مانند رمز عبور، شماره‌های کارت اعتباری، سوابق پزشکی، اطلاعات شخصی و رازهای تجاری نیاز به حفاظت اضافی دارند، به ویژه اگر این داده‌ها تحت قوانین حریم شخصی مانند GDPR یا آیین‌نامه‌ها مانند استاندارد امنیت داده‌های PCI (PCI DSS) قرار دارند.
رمزنگاری داده‌های حساس:
- آیا هر گونه اطلاعات به صورت متن ساده ارسال می‌شود؟ این امور پروتکل‌هایی نظیر HTTP، SMTP، FTP را نیز شامل می‌شود. ترافیک اینترنت خارجی خطرناک است. از تمام ترافیک داخلی، مثل بین توزیع‌کننده بار، سرورهای وب یا سیستم‌های پشتیبانی، اطمینان حاصل کنید.
- آیا الگوریتم‌ها یا پروتکل‌های رمزنگاری قدیمی یا ضعیف به صورت پیش‌فرض یا در کدهای قدیمی استفاده می‌شوند؟
- آیا کلیدهای رمزنگاری به صورت پیش‌فرض یا با کیفیت ضعیف تولید یا استفاده می‌شوند؟ آیا مدیریت یا چرخه کلید مناسب وجود دارد؟
- آیا رمزنگاری اجبار نشده است؟ آیا هدرهای امنیتی (امنیت مرورگر) یا هدرهای متداول HTTP از دست رفته‌اند؟
- آیا گواهی نامه سرور دریافتی و زنجیره اعتماد به درستی اعتبارسنجی شده‌اند؟
- آیا بردارهای مقدماتی نادیده گرفته شده، دوباره استفاده شده یا برای حالت عملیات رمزنگاری به اندازه کافی ایمن تولید نشده است؟
- آیا رمزنگاری هنگام استفاده از رمزنگاری تأیید شده مناسب به جای رمزنگاری معمولی استفاده می‌شود؟
- آیا گذرواژه‌ها به عنوان کلیدهای رمزنگاری در فقدان یک تابع مشتق‌سازی کلید بر پایه گذرواژه استفاده می‌شوند؟
- آیا تصادفی برای اهداف رمزنگاری استفاده می‌شود که برای تأمین نیازهای رمزنگاری طراحی نشده است؟
- آیا توابع هش قدیمی مانند MD5 یا SHA1 استفاده می‌شوند؟ آیا توابع هش غیررمزنگاری هنگامی که توابع هش رمزنگاری نیاز است، استفاده می‌شوند؟
- آیا اطلاعات جانبی یا اطلاعات کانال کناری رمزنگاری قابل بهره‌برداری هستند، به عنوان مثال در قالب حملات اوراکل پدینگ؟
چگونگی پیشگیری:
- دسته‌بندی داده‌هایی که توسط برنامه پردازش، ذخیره یا انتقال می‌شوند. شناسایی کنید کدام داده‌ها حساس هستند طبق قوانین حریم شخصی، الزامات نظارتی یا نیازهای تجاری.
- اطلاعات حساس را بدون دلیل لزومی ذخیره نکنید. آن‌را هر چه زودتر دور بریزید یا از توکن‌سازی یا حتی کاهش مطابق با استاندارد PCI DSS استفاده کنید. داده‌ای که نگهداری نمی‌شود، قابل دزدیده شدن نیست.
- اطمینان حاصل کنید که تمام داده‌های حساس در حال استراحت رمزنگاری شوند.
- از الگوریتم‌ها، پروتکل‌ها و کلیدهای استاندارد و قوی به‌روز باشید. مدیریت کلید صحیح را اجرا کنید.
- تمام داده‌ها را در حال انتقال با پروتکل‌های امن مانند TLS با رمزنگاری FS، اولویت دهی توسط سرور و پارامترهای امن انتقال دهید. رمزنگاری را با دستوراتی نظیر HTTP Strict Transport Security (HSTS) اجباری کنید.
- حافظه‌پنهانی را برای پاسخ‌های حاوی داده‌های حساس غیرفعال کنید.
- کنترل‌های امنیتی مورد نیاز را به موجودیت‌های داده واگذار کنید.
- از پروتکل‌های قدیمی مانند FTP و SMTP برای انتقال داده حساس استفاده نکنید.
- گذرواژه‌ها را با توابع هش adaptive و salted hashing با یک عامل کاری (عامل تأخیر) قوی نظیر Argon2، scrypt، bcrypt یا PBKDF2 ذخیره کنید.
-
بردارهای مقدماتی باید برای حالت عملیات مناسب انتخاب شوند. برای بسیاری از حالات، این بدان معناست که از یک مولد عدد تصادفی شبه‌رمزنگاری امن (CSPRNG) استفاده کنید. برای حالاتی که یک nonce نیاز است، بردار شروع (IV) به یک CSPRNG نیاز ندارد. در همه موارد، IV برای یک کلید ثابت هرگز باید برای یکبار استفاده مجدد استفاده شود.
Injection
با پیشرفت فناوری، حملات Injection به یکی از بزرگترین تهدیدهای امنیتی برنامه‌های وب تبدیل شده‌اند. در لیست خطرات امنیتی OWASP سال 2021، Injection با رتبه سوم به چشم می‌خورد. در ادامه این مقاله، به تجزیه و تحلیل این خطر، علل حملات، و راهکارهای پیشگیری از Injection در برنامه‌های وب می‌پردازیم.
Injection در رتبه سوم: بررسی وضعیت
حملات Injection با 94٪ برنامه‌ها که بررسی شده بودند، به شکلی یا شکلاتی از آنها در رتبه سوم قرار می‌گیرد. با نرخ حوادث بیشینه 19٪ و نرخ حوادث متوسط 3٪، این خطر امنیتی با بیش از 274 هزار اتفاق به وقوع پیوسته است. CWEهای مهم این حوادث شامل CWE-79: Cross-site Scripting، CWE-89: SQL Injection، و CWE-73: External Control of File Name or Path می‌شوند.
آسیب‌پذیری در برابر Injection:
برنامه‌ها آسیب‌پذیر به حملات Injection هستند زمانی که:
- داده‌های ارائه‌شده توسط کاربر توسط برنامه اعتبارسنجی، فیلتر یا تطهیر نمی‌شوند.
- در کوئری‌های دینامیک یا فراخوانی‌های بدون پارامتر بدون فراریابی محتوا مستقیماً در مفسر استفاده می‌شوند.
- داده خصومت‌آمیز در پارامترهای جستجوی ORM برای استخراج رکوردهای حساس استفاده می‌شود.
- داده خصومت‌آمیز به طور مستقیم یا ادغام می‌شود. SQL یا دستور حاوی ساختار و داده مخرب در کوئری‌ها، دستورات یا رویه‌های ذخیره‌شده دینامیک استفاده می‌شوند.
حملات شایع‌تر این نوع شامل حملات SQL، NoSQL، دستور سیستم عامل (OS command)، حملات Object Relational Mapping (ORM)، LDAP، و حملات Expression Language (EL) یا Object Graph Navigation Library (OGNL) می‌شوند. بررسی کد منبع بهترین روش برای شناسایی آیا برنامه‌ها در برابر حملات Injection آسیب‌پذیر هستند یا خیر است. تست خودکار تمام پارامترها، هدرها، URL، کوکی‌ها، JSON، SOAP و ورودی‌های داده XML به شدت توصیه می‌شود. سازمان‌ها می‌توانند ابزارهای تست امنیت برنامه (SAST)، تست امنیت داینامیک (DAST)، و تست امنیت تعاملی (IAST) را به لوله CI/CD خود اضافه کنند تا عیوب Injection معرفی‌شده را قبل از استقرار پیدا کنند.
چگونگی پیشگیری:
پیشگیری از Injection نیازمند جدا کردن داده از دستورات و کوئری‌هاست:
- گزینه ترجیحی استفاده از یک API ایمن است که از مفسر به‌طور کامل اجتناب می‌کند، یک رابط پارامتری‌شده فراهم می‌کند یا به ابزارهای Object Relational Mapping (ORMs) مهاجرت می‌کند. حتی زمانی که پارامتری شده‌اند، رویه‌های ذخیره‌شده هنوز ممکن است اگر PL/SQL یا T-SQL کوئری‌ها و داده را یا داده خصومت‌آمیز را با EXECUTE IMMEDIATE یا exec() ادغام کنند، حملات SQL Injection را معرفی کنند.
- از اعتبارسنجی مثبت در سمت سرور استفاده کنید. این یک دفاع کامل نیست زیرا بسیاری از برنامه‌ها به کاراکترهای ویژه نیاز دارند، مانند مناطق متنی یا APIها برای برنامه‌های موبایل.
- برای هر کوئری دینامیک باقی‌مانده، کاراکترهای ویژه را با استفاده از نحو خاص برای هر مفسر قرار دهید. توجه: ساختارهای SQL مانند اسامی جداول، اسامی ستون‌ها و غیره نمی‌توانند فرار کنند و از این رو اسامی ساختارهای ارائه‌شده توسط کاربر خطرناک هستند. این یک مسئله متداول در نرم‌افزارهای نویسنده گزارش است.
- از LIMIT و کنترل‌های دیگر SQL در داخل کوئری‌ها استفاده کنید تا اطلاعات جلوی نمایش جمعی رکوردها در صورت وقوع SQL Injection بگیرند.
حالت حمله:
حالت حمله 1:
یک برنامه از داده‌های ناامن در ساخت کوئری SQL آسیب‌پذیر است:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
حالت حمله 2:
به همین ترتیب، اعتماد کور برنامه به چارچوب‌ها ممکن است منجر به کوئری‌های هنوز آسیب‌پذیر شود (برای مثال Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
در هر دو حالت، حمله‌کننده مقدار پارامتر ‘id’ را در مرورگر خود تغییر داده و ارسال می‌کند: ‘ UNION SLEEP(10);–. به عنوان مثال:
http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--
این باعث تغییر معنی هر دو کوئری می‌شود تا تمام رکوردهای جدول accounts را بازگرداند. حملات خطرناک‌تر ممکن است داده‌ها را تغییر دهند یا حتی رویه‌های ذخیره‌شده را فراخوانی کنند.
Insecure Design
در لیست OWASP برای سال 2021، یک دسته‌بندی جدید با عنوان “Insecure Design” (طراحی ناامن) معرفی شده است که بر روی خطرات مرتبط با طراحی و خطاهای معماری تمرکز دارد.
طراحی ناامن در رتبه چهارم: بررسی وضعیت
طراحی ناامن به عنوان یک دسته گسترده، نمایانگر ضعف‌های مختلف است که به عنوان “طراحی کنترل ناکارآمد یا عدم وجود آن” بیان می‌شود. این دسته از طراحی ناامن منشاء تمام دسته‌های برتر خطرات OWASP نیست. تفاوتی بین طراحی ناامن و اجرای نادرست وجود دارد. ما بین عیوب طراحی و دیفکت‌های اجرایی تفاوت قائل هستیم زیرا آنها دلایل مختلف و راه‌حل‌های متفاوتی دارند. یک طراحی امن ممکن است هنوز دارای دیفکت‌های اجرایی باشد که به آسیب‌پذیری‌هایی منجر شود که ممکن است به آنها حمله شود. یک طراحی ناامن نمی‌تواند توسط یک اجرای کامل بهبود یابد زیرا به تعریف، کنترل‌های امنیتی مورد نیاز برای مقابله با حملات خاص هرگز ایجاد نشده‌اند. یکی از عواملی که به طراحی ناامن اسباب می‌شود، کمبود تجزیه و تحلیل ریسک تجاری در نرم‌افزار یا سیستم در حال توسعه است و در نتیجه عدم تعیین سطح امنیت مورد نیاز است.
مدیریت نیازمندی‌ها و منابع
- جمع‌آوری و مذاکره نیازمندی‌های تجاری برنامه با تجارت، از جمله نیازمندی‌های محافظت از محرمانگی، صداقت، دسترسی و اصالت تمام داده‌ها و منطق تجارت مورد انتظار. در نظر داشته باشید چقدر برنامه شما برای حمله‌پذیری باز است و آیا نیاز به اختصاص کاربران (به علاوه به کنترل دسترسی) دارید. نیازمندی‌های فنی را که شامل نیازمندی‌های امنیتی کارکردی و غیرکارکردی می‌شوند، جمع‌آوری و مذاکره کنید. برنامه و بودجه را برای تمام فعالیت‌های طراحی، ساخت، آزمایش و عملیات، شامل فعالیت‌های امنیتی، برنامه‌ریزی و مذاکره کنید.
طراحی امن
- طراحی امن یک فرهنگ و مهندسی است که به‌طور مداوم تهدیدات را ارزیابی می‌کند و اطمینان حاصل می‌شود که کد به طور قوی طراحی و آزمایش شده است تا از روش‌های حمله‌ای شناخته‌شده جلوگیری شود. تجزیه و تحلیل تهدید باید به جلسات بهینه‌سازی (یا فعالیت‌های مشابه) یا جلسات تطهیر ادغام شود؛ به دنبال تغییرات در جریان‌های داده و کنترل دسترسی یا کنترل‌های امنیتی دیگر بگردید. در توسعه داستان‌های کاربری جریان صحیح و وضعیت‌های خرابی را تعیین کنید، اطمینان حاصل کنید که توسط افراد مسئول و تأثیرگذار تعیین و مورد توافق قرار گرفته‌اند. فرضیات و شرایط جریان‌های متوقع و ناکارآمد را تجزیه و تحلیل کنید، اطمینان حاصل کنید که هنوز دقیق و مطلوب هستند. تعیین کنید چگونه می‌توان فرضیات را اعتبارسنجی کرد و شرایط مورد نیاز برای رفتارهای صحیح را اعمال کرد. اطمینان حاصل کنید که نتایج در داستان کاربری ثبت شده‌اند. از اشتباهات یاد بگیرید و انگیزه‌های مثبت برای ترویج بهبودها ارائه دهید. طراحی امن نه افزونه است و نه ابزاری است که می‌توانید به نرم‌افزار اضافه کنید.
چرخه توسعه امن
- نرم‌افزار امن نیازمند یک چرخه توسعه امن است، نوعی الگوی طراحی امن، راهبرد جاده‌آهنه، کتابخانه مؤلفه امن، ابزار، و مدل‌سازی تهدید. در ابتدای یک پروژه نرم‌افزار تا پایان پروژه و نگهداری نرم‌افزار خود، به تخصص‌های امنیتی خود مراجعه کنید. در نظر داشته باشید از مدل امنیتی OWASP Software Assurance Maturity Model (SAMM) برای ساختاردهی تلاش‌های توسعه امن نرم‌افزار خود استفاده کنید.
چگونگی جلوگیری
- یک چرخه توسعه امن با حضور حرفه‌ایان امنیتی برای کمک به ارزیابی و طراحی کنترل‌های مرتبط با امنیت و حریم شخصی راه‌اندازی کنید.
- یک کتابخانه از الگوهای طراحی امن یا مؤلفه‌های آماده به‌کاربرد راه بندازید.
- برای احراز هویت، کنترل دسترسی، منطق تجاری و جریان‌های کلیدی، از تجزیه و تحلیل تهدید استفاده کنید.
- زبان و کنترل‌های امنیتی را به داستان‌های کاربری اضافه کنید.
- چک‌های معقول را در هر لایه از برنامه‌تان (از بک تا فرانت) اضافه کنید.
- تست‌های یکانی و یکپارچه را برای اعتبارسنجی اینکه آیا تمام جریان‌های حیاتی مقاوم به مدل تهدید هستند یا خیر، بنویسید.
- برای هر لایه از سیستم و لایه‌های شبکه را به اصطلاح مورد نیاز جدا کنید.
- کلاینت را از طریق تمام لایه‌ها به‌طور قوی به‌طور طراحی جدا کنید.
- مصرف منابع را بر اساس کاربر یا سرویس محدود کنید.
حالات حمله
حالت حمله 1:
یک جریان بازیابی اعتبار ممکن است شامل “سوالات و پاسخ‌ها” باشد که توسط NIST 800-63b، OWASP ASVS و OWASP Top 10 ممنوع است. سوالات و جواب‌ها به عنوان شواهد هویت اعتمادی ندارند، زیرا بیش از یک نفر ممکن است جواب‌ها را بداند، به همین دلیل آن کد باید حذف شود و به یک طراحی امن‌تر ترکیب شود.
حالت حمله 2:
یک زنجیره سینمایی امکان تخفیف گروهی را فراهم کرده است و حداکثر تعداد نفرات را قبل از نیاز به سپرده تعیین کرده است. حمله‌کنندگان ممکن است این جریان را تجزیه و تحلیل کرده و امتحان کنند که آیا می‌توانند به سادگی 600 صندلی را در چند درخواست رزرو کرده و تمام سینماها را به‌یک‌باره اشغال کنند، که منجر به از دست رفته بزرگی اقتصادی می‌شود.
حالت حمله 3:
وب‌سایت یک شبکه خرده‌فروشی رتیل به بدون حفاظت برابر بازوهای ربات‌ها اجازه می‌دهد که تعداد زیادی کارت گرافیک ارزشمند را به صورت خودکار خریداری کنند و سپس آنها را در وب‌سایت‌های حراجی مجدداً بفروشند. این وضعیت منجر به افتخار نامطلوب برندها و شرکت‌های خرده‌فروشی می‌شود و باعث عدم رضایت افراد طرفدار محصول می‌گردد. طراحی دقیق و قوانین منطق دامنه، مانند خریدهای انجام شده در چند ثانیه از زمان در دسترس بودن ممکن است معاملات ناشناس را شناسایی و اینگونه تراکنش‌ها را رد کند.
با استفاده از این راهکارها و نکات پیشگیری مطرح شده، می‌توانید از حملات مرتبط با طراحی ناامن در برنامه‌های وب خود دفاع کرده و امنیت سیستم و اطلاعات حساس را تضمین نمایید. همچنین، ادامه دادن به تحقیقات و به‌روزرسانی‌های مربوط به امنیت و اطلاعاتی که در دنیای فناوری به وجود می‌آیند، امری ضروری برای حفظ امنیت در برابر تهدیدات متنوع و پیچیده است.
Security Misconfiguration
در این نسخه، رتبه این خطر به عنوان #6 بالاتر رفته است. 90% از برنامه‌ها بررسی شده‌اند تا حدی از اشتباهات پیکربندی امنیتی رنج ببرند، با میانگین درصد حادثه 4.5% و بیش از 208 هزار حادثه در این دسته. مهمترین Common Weakness Enumerations (CWEs) شامل CWE-16 Configuration و CWE-611 Improper Restriction of XML External Entity Reference می‌شوند.
برنامه ممکن است در معرض حملات باشد اگر:
- تنظیمات امنیتی مناسب در هر بخش از پشته برنامه انجام نشده باشد یا مجوزهای نادرستی در سرویس‌های ابر تنظیم شده باشد.
- ویژگی‌های غیرضروری فعال یا نصب شده باشند (به عنوان مثال، درگاه‌ها، سرویس‌ها، صفحات، حساب‌ها یا امتیازات غیرضروری).
- حساب‌ها و رمزهای عبور پیش‌فرض هنوز هم فعال و تغییر نکرده باشند.
- مدیریت خطا اطلاعات زیادی از خطوط استک یا پیام‌های خطاهای زیاد به کاربران نشان دهد.
- برای سیستم‌های ارتقاء یافته، ویژگی‌های امنیتی جدیدتر غیرفعال یا به‌طور امن تنظیم نشده باشد.
- تنظیمات امنیتی در سرورهای برنامه، چارچوب‌های برنامه (مانند Struts، Spring، ASP.NET)، کتابخانه‌ها، دیتابیس و غیره به مقادیر امنیتی تنظیم نشده باشد.
- سرور هدرها یا دستورات امنیتی را به کلاینت‌ها ارسال نکند یا اینکه به مقادیر امن تنظیم نشده باشند.
- نرم‌افزار به‌روز یا آسیب‌پذیر باشد.
چگونگی پیشگیری برای جلوگیری از این نوع حملات:
- فرآیند نصب امن باید اجرا شود، از جمله:
- فرآیند سخت‌افزاری تکرارپذیر که امکان استقرار سریع و آسان یک محیط دیگر با بستری مناسب را فراهم می‌کند.
- سیستم حداقل باید دارای ویژگی‌ها، اجزاء، مستندات و نمونه‌های غیرضروری باشد. ویژگی‌ها و چارچوب‌های غیراستفاده‌شده حذف یا نصب نشوند.
- بررسی و به‌روزرسانی پیکربندی‌ها مرتبط با همه یادداشت‌ها، به‌روزرسانی‌ها و پچ‌های امنیتی به عنوان یک بخش از فرآیند مدیریت پچ .
- مراجعه به دسترسی‌های ذخیره ابر (مانند S3 bucket permissions).
- معماری برنامه مجزا با افکتیو و جداکننده بین اجزاء یا مستأجران فراهم می‌کند. این به وسیله جداسازی، کانتینرسازی یا گروه‌های امنیتی ابر (ACL) امکان‌پذیر است.
- ارسال دستورات امنیتی به کلاینت‌ها (مثل هدرهای امنیتی).
- فرآیند خودکار برای اعتبارسنجی اثربخشی پیکربندی‌ها و تنظیمات در همه محیط‌ها.
سناریوهای حمله:
- سناریو #1:
- سرور برنامه با برنامه‌های نمونه ارائه شده در سرور تولیدی ارائه می‌شود. این برنامه‌های نمونه دارای نقاط ضعف امنیتی شناخته‌شده‌اند که حمله‌کنندگان از آنها برای مهاجمه به سرور استفاده می‌کنند. اگر یکی از این برنامه‌ها کنسول مدیریت باشد و حساب‌ها و رمزهای پیش‌فرض تغییر نکرده باشند، حمله‌کننده با رمزهای پیش‌فرض وارد شده و کنترل را به‌دست می‌آورد.
- سناریو #2:
- نمایش لیست‌ها در سرور غیرفعال نشده است. حمله‌کننده می‌فهمد که می‌تواند به سادگی لیست‌ها را مشاهده کند. او کدهای جاوا را که در آنها نیاز به کدگذاری شده به صورت دستی دانلود کند و متوجه شود که چطور می‌تواند به کد دسترسی پیدا کند. سپس او یک نقض کنترل دسترسی جدی در برنامه پیدا می‌کند.
- سناریو #3:
- پیکربندی سرور اجازه داده است که پیام‌های خطایی مانند اطلاعات کشف‌شده، مثل استک‌ها، به کاربران برگردانده شوند. این ممکن است اطلاعات حساس یا نقاط ضعف زیرین مانند نسخه‌های مؤلفه که به طور آشکار آسیب‌پذیر هستند، را نشان دهد.
- سناریو #4:
- یک سرویس ارائه‌دهنده ابر (CSP) دسترسی‌های به‌اشتراک‌گذاری پیش‌فرض را به اینترنت با سایر کاربران CSP باز می‌کند. این اجازه می‌دهد تا اطلاعات حساس ذخیره شده در ذخیره ابر، به دسترس عموم قرار گیرند.
با استفاده از این راهکارها و نکات پیشگیری ارائه شده، می‌توانید از حملات مرتبط با اشتباهات پیکربندی امنیتی در برنامه‌های وب خود دفاع نموده و امنیت سیستم و اطلاعات حساس را تضمین نمایید. ادامه دادن به تحقیقات و به‌روزرسانی‌های مربوط به امنیت و اطلاعاتی که در دنیای فناوری به وجود می‌آیند، امری ضروری برای حفظ امنیت در برابر تهدیدات متنوع و پیچیده است.
Vulnerable and Outdated Components
اجزای آسیب‌پذیر یک مشکل شناخته‌شده است که ما با آن سختی مواجه هستیم تا خطرات آن را ارزیابی و سنجیده کنیم و تنها دسته‌ای است که هیچ CVE ای به CWE های مرتبط ندارد، بنابراین از وزن پیش‌فرض موزد اجرایی/تأثیری معادل 5.0 استفاده شده‌است. CWEهای مشخص‌شده شامل CWE-1104: استفاده از اجزای جانشین‌نشده از شخص‌سوم و دو CWE از ده‌کی 2013 و 2017 هستند.
شما به احتمال زیاد آسیب‌پذیر هستید:
- اگر نسخه‌های تمام اجزاءی که استفاده می‌کنید (هم سمت مشتری و هم سمت سرور) را نمی‌دانید. این شامل اجزاءی است که به صورت مستقیم استفاده می‌کنید و همچنین وابستگی‌های درونی آنها.
- اگر نرم‌افزار آسیب‌پذیر، پشتیبانی نشده یا قدیمی است. این شامل سیستم‌عامل، سرور وب/برنامه، سیستم مدیریت پایگاه داده (DBMS)، برنامه‌ها، APIها و تمام اجزاء، محیط‌ها و کتابخانه‌ها می‌شود.
- اگر به طور منظم آسیب‌پذیری‌ها را اسکن نمی‌کنید و به بولتن‌های امنیتی مرتبط با اجزاءی که استفاده می‌کنید مشترک نمی‌شوید.
- اگر اقدام به تعمیر یا ارتقاء پلتفرم، چارچوب و وابستگی‌ها به‌صورت مبتنی بر خطر به موقع نمی‌کنید. این موارد معمولاً در محیط‌هایی اتفاق می‌افتد که پچ‌گذاری به صورت ماهیانه یا سه‌ماهه تحت کنترل تغییرات انجام می‌شود و این امکان را به سازمان‌ها می‌دهد که برای مدت‌ها یا ماه‌ها از آسیب‌پذیری‌های رفع شده باز بمانند.
- اگر توسعه‌دهندگان نرم‌افزار تطابق به‌روزرسانی‌ها، ارتقاء‌ها یا کتابخانه‌های پچ‌شده را تست نمی‌کنند.
- اگر تنظیمات اجزاء را امن نکنید.
چگونگی پیشگیری
برای جلوگیری باید یک فرآیند مدیریت پچ موجود باشد تا:
- وابستگی‌ها، ویژگی‌ها، اجزاء، فایل‌ها و مستندات غیراستفاده‌شده را حذف کنید.
- به‌صورت مداوم نسخه‌های اجزاء هم سمت مشتری و هم سمت سرور (مانند چارچوب‌ها، کتابخانه‌ها) و وابستگی‌های آنها را با استفاده از ابزارهایی مانند versions، OWASP Dependency Check، retire.js و غیره مرتب کنید. به‌صورت مداوم منابعی مانند Common Vulnerability and Exposures (CVE) و National Vulnerability Database (NVD) را برای یافتن آسیب‌پذیری‌های اجزاء نظارت کنید. از ابزارهای تجزیه و تحلیل ترکیب نرم‌افزار برای اتوماسیون این فرآیند استفاده کنید. برای آگاهی به مسائل امنیتی مرتبط با اجزاءی که استفاده می‌کنید، به خبرنامه ایمیل مشترک شوید.
- تنها از منابع رسمی از طریق پیوندهای امن اجزاء را دریافت کنید. برای کاهش احتمال درج یک اجزاء تغییر یافته و خبیث، از بسته‌های امضاشده استفاده کنید.
- برای کتابخانه‌ها و اجزاءی که نگهداری نمی‌شوند یا برای نسخه‌های قدیمی پچ امنیتی ارائه نمی‌دهند نظارت کنید. اگر پچ‌گذاری امکان‌پذیر نیست، در نظر بگیرید یک پچ مجازی (virtual patch) را برای نظارت، شناسایی یا حفاظت در برابر مشکل کشف شده پیاده‌سازی کنید.
-
هر سازمان باید برنامه‌ای مداوم برای نظارت، ارزیابی و اعمال به‌روزرسانی‌ها یا تغییرات پیکربندی برای عمر کاربرد یا پرتفوی خود داشته باشد.
اجزاء معمولاً با همان اختیارات برنامه اجرا می‌شوند، بنابراین نقص‌ها در هر اجزاء می‌تواند به تأثیرات جدی منجر شود. این نقص‌ها ممکن است تصادفی (مثل خطا در برنامه نویسی) یا ارادی (مثل یک دروازه پشتیبان در یک اجزاء) باشند. برخی از نقاط ضعف قابل اجرا که کشف شده‌اند عبارتند از:
CVE-2017-5638، یک آسیب‌پذیری اجرای کد از راه دور در Struts 2 که قادر به اجرای کد دلخواه در سرور است، به دلیل آن به حوادث مهم مربوط شده است.
ابزارهای خودکار برای کمک به حمله‌کنندگان برای یافتن سیستم‌های پچ‌نشده یا برنامه‌ریزی شده به‌صورت نادرست وجود دارد. به عنوان مثال، موتور جستجوی IoT Shodan می‌تواند به شما کمک کند تا دستگاه‌هایی که هنوز از آسیب‌پذیری Heartbleed که در آوریل 2014 پچ شده است، پیدا کنید.
Identification and Authentication Failures
این دسته قبلاً به عنوان اعتبارسنجی ناکامل شناخته می‌شد، اما اکنون این دسته از جایگاه دوم خود خارج شده و حالا شامل Common Weakness Enumerations (CWEها) مربوط به شکست‌های اعتبارسنجی است.
شرح تأیید هویت کاربر، احراز هویت و مدیریت نشست بسیار حیاتی است تا در برابر حملات مرتبط با احراز هویت محافظت شود. اگر برنامه:
- اجازه حملات خودکار مانند پر کردن اعتبارها را می‌دهد که حمله‌کننده لیستی از نام کاربری و رمزعبورهای معتبر دارد.
- اجازه حملات خودکار یا اجازه حملات دیگر را می‌دهد.
- اجازه استفاده از رمزهای عبور پیش‌فرض، ضعیف یا معروف مانند “Password1” یا “admin/admin” را می‌دهد.
- از روش‌های بازیابی اعتبار یا فراموشی رمزعبور ضعیف یا ناکارآمد مانند “پاسخ‌های مبتنی بر دانش” استفاده می‌کند که نمی‌تواند ایمن شود.
- از ذخیره‌سازی داده‌های رمزعبور به صورت متن ساده، رمزنگاری شده یا به صورت ضعیف هش‌شده استفاده می‌کند.
- شناسه تأیید چندگانه را نادرست یا ناکارآمد پیاده‌سازی کرده یا ندارد.
- شناسه نشست را در URL آشکار می‌کند.
- پس از ورود موفق، شناسه نشست را مجدداً استفاده می‌کند.
- شناسه‌های نشست یا توکن‌های احراز هویت کاربر ،عمدتاً توکن‌های ورود یک بار (SSO) را هنگام خروج یا در طول یک دوره عدم فعالیت به درستی ابطال نمی‌کند.
چگونه جلوگیری کنیم: در صورت امکان، اقدام به اجرای احراز هویت چندگانه کنید تا از حملات خودکار پر کردن اعتبار، حملات خودکار و استفاده مجدد از اعتبار دزدیده‌شده جلوگیری شود.
با هیچ اعتبار پیش‌فرضی، به ویژه برای کاربران مدیر استفاده نکنید.
بررسی‌های رمزعبور ضعیفی پیاده‌سازی کنید، مانند آزمایش رمزهای جدید یا تغییر یافته در مقابل لیست 10,000 رمز عبور بدترین.
اطمینان حاصل کنید که ثبت‌نام، بازیابی اعتبار و مسیرهای API در برابر حملات نشانی حساب تقویت شده با استفاده از پیام‌های یکسان برای تمام نتایج محکم شده‌اند.
تلاش‌های ناکام ورود به سیستم را محدود یا درصد موفقیت‌آمیز آنها را به طور گسترده‌تر کاهش دهید، اما مراقب باشید که سناریوی سرویس راه‌اندازی نکنید. همه شکست‌ها را ثبت کرده و هنگام تشخیص پر کردن اعتبار، حملات خودکار و یا حملات دیگر، به مدیران هشدار دهید.
سناریوهای حمله نمونه سناریو #1: پر کردن اعتبار، استفاده از لیست‌های رمزهای عبور شناخته‌شده، یک حمله متداول است. فرض کنید یک برنامه تحت هیچ حفاظت خودکار از تهدید یا محافظت در برابر پر کردن اعتبار پیاده‌سازی نکند، در این صورت می‌توان از برنامه به عنوان یک اوراکل رمزعبور استفاده کرد تا اعتبارها اگر معتبر باشند، تشخیص داده شود.
سناریو #2: بیشتر حملات احراز هویت به دلیل ادامه استفاده از رمزهای عبور به عنوان یک عامل واحد اتفاق می‌افتد. در گذشته به عنوان عملکردهای بهترین موارد مصرفی محسوب می‌شد، الزام به چرخش و الزام به پیچیدگی رمزها کاربران را ترغیب به استفاده و استفاده مجدد از رمزهای عبور ضعیف می‌کرد. سازمان‌ها توصیه می‌شوند که از این روش‌ها براساس NIST 800-63 منصرف شوند و از احراز هویت چندگانه استفاده کنند.
سناریو #3: زمان‌های بی‌فعالیت نشست برنامه به درستی تنظیم نشده‌اند. یک کاربر از یک کامپیوتر عمومی برای دسترسی به یک برنامه استفاده می‌کند. به جای انتخاب “خروج”، کاربر به سادگی تب مرورگر را ببندد و دور برود. یک حمله‌کننده یک ساعت بعد از همان مرورگر استفاده می‌کند و کاربر هنوز احراز هویت شده است.
Software and Data Integrity Failures
در رده‌بندی OWASP، یکی از مسائل کلان امنیتی که برخورداری می‌کند، “عیب در نرم‌افزار و تخلف از امانت داده” یا به انگلیسی “Software and Data Integrity Failures” نامیده می‌شود. این مسئله در رتبه هشتم از لیست OWASP قرار گرفته و اهمیت زیادی در حفظ امانت و سلامت داده‌ها و نرم‌افزارها دارد. در این مقاله، به بررسی علت اهمیت، راهکارها و یک مثال عملی از این نوع مشکلات می‌پردازیم.
اهمیت مسئله
نقض امانت داده و عیب در نرم‌افزار می‌تواند تبدیل به یک گام مهم در جهت حملات سایبری و تخلفات امنیتی شود. هنگامی که یک حمله‌کننده موفق به تغییر داده‌های حساس یا ساختار نرم‌افزار می‌شود، اطلاعات کاربران، اعتبارات، یا حتی عملکرد نرم‌افزار ممکن است به خطر بیافتد. این نوع حملات به شیوه‌های مختلفی ممکن است انجام شود، از جمله افزودن، تغییر یا حذف داده‌ها، تزریق کدهای مخرب، یا مخفی کردن فعالیت‌های مخرب در سیستم.
راهکارها برای جلوگیری
برای جلوگیری از عیب در نرم‌افزار و تخلف از امانت داده، می‌توان از راهکارهای زیر استفاده کرد:
1. استفاده از مدیریت مناسب اجازه دسترسی
تعیین دقیق و مدیریت صحیح دسترسی‌ها به داده‌ها و منابع نرم‌افزار از جمله راهکارهای اصلی است. اطمینان حاصل کنید که هر کاربر یا سیستمی تنها به حداقل دسترسی مورد نیاز برای انجام وظایف خود دسترسی داشته باشد.
2. معماری امن نرم‌افزار
استفاده از الگوها و معماری‌های امن در توسعه نرم‌افزار امکان پیشگیری از بسیاری از حملات را فراهم می‌کند. به‌طور مثال، استفاده از اصول امان در طراحی نرم‌افزار، اجتناب از استفاده از کتابخانه‌ها و قطعات قدیمی و آسیب‌پذیر، و ایجاد چارچوب‌های امن می‌تواند تاثیرات حملات را کاهش دهد.
3. اعتبارسنجی و کنترل داده‌ها
استفاده از مکانیزم‌های قوی اعتبارسنجی داده‌ها و کنترل دسترسی به آنها از تغییرات غیرمجاز جلوگیری می‌کند. این شامل بررسی دقیق داده‌ها قبل از استفاده، اجتناب از استفاده از داده‌های ناامن، و محدود کردن دسترسی به داده‌های حساس می‌شود.
مثال عملی
حالا که با اهمیت و راهکارهای جلوگیری از عیب در نرم‌افزار و تخلف از امانت داده آشنا شدیم، یک مثال عملی را در نظر بگیریم.
سناریو: حمله به داده‌های مالی در یک سیستم بانکی
فرض کنید یک حمله‌کننده با موفقیت به یک سیستم بانکی نفوذ پیدا کرده و توانسته است داده‌های مالی مشتریان را تغییر دهد. این حمله با تغییر مقادیر داده‌ها می‌تواند موجب انتقال پول از حساب‌ها به حساب‌های متناهی شود یا حتی اطلاعات حساب‌های مشتریان را تغییر داده و برای اهداف خود سوءاستفاده کند.
با اجرای راهکارهای امنیتی مانند مدیریت دقیق دسترسی، استفاده از معماری امن و اعتبارسنجی دقیق داده‌ها، احتمال وقوع چنین حملاتی کاهش می‌یابد.
در نتیجه، توجه به امنیت نرم‌افزار و امانت داده‌ها از اهمیت بسزایی برخوردار است و توسعه‌دهندگان و مدیران سیستم‌های اطلاعاتی باید مسئولیت پیشگیری از این گونه مشکلات را به‌عهده بگیرند.
Security Logging and Monitoring Failures
در فهرست OWASP، یکی از مسائل حیاتی امنیتی به نام “تعیین هویت و نقض امانت اطلاعات” یا به انگلیسی “Security Logging and Monitoring Failures” به رده نهم اختصاص یافته است. این مسئله نشان‌دهنده اهمیت لاگ‌گذاری و نظارت در سیستم‌های اطلاعاتی است. در این بخش، به بررسی چرایی اهمیت این موضوع، راهکارهای پیشگیری، و یک مثال عملی از مشکلات مرتبط با لاگ‌گذاری و نظارت می‌پردازیم.
اهمیت لاگ‌گذاری و نظارت امنیتی
لاگ‌گذاری و نظارت در سیستم‌های اطلاعاتی نقش بسزایی در شناسایی و پیشگیری از حملات سایبری و حوادث امنیتی دارد. این فرآیندها اطلاعات دقیقی از فعالیت‌ها و وقایع در سیستم فراهم می‌کنند و امکان تحلیل، تشخیص، و واکنش به وقایع امنیتی را فراهم می‌سازند. در صورتی که لاگ‌گذاری و نظارت به درستی انجام نشود، اطلاعات اساسی برای تشخیص زودهنگام حملات از دست می‌رود و امکان بروز اتفاقات ناخواسته و نقض امانت اطلاعات افزایش می‌یابد.
چرا لاگ‌گذاری و نظارت امنیتی اهمیت دارد؟
- شناسایی حملات: لاگ‌گذاری قادر به ثبت تمام وقایع و فعالیت‌های سیستم است، که در صورت حمله، اطلاعات لازم برای شناسایی الگوها و رفتارهای مشکوک فراهم می‌کند.
- تحلیل و پیشگیری: لاگ‌ها اطلاعات زمان وقوع حوادث را فراهم می‌کنند و این امکان را می‌دهند تا تحلیل‌های دقیقی از رخدادها انجام شود و برنامه‌های پیشگیری اجرا گردد.
- پیگیری قانونی: در صورت وقوع حوادثی که نیاز به پیگیری قانونی دارند، لاگ‌ها می‌توانند به عنوان شواهد حیاتی در دادگاه مورد استفاده قرار گیرند.
راهکارهای پیشگیری
برای جلوگیری از مشکلات لاگ‌گذاری و نظارت امنیتی، می‌توان از راهکارهای زیر استفاده کرد:
- پیکربندی صحیح لاگ‌ها: اطمینان از ثبت همه وقایع مهم، از جمله ورود و خروج کاربران، دسترسی‌های ناشناخته، و تغییرات در سطوح دسترسی.
- استفاده از ابزارهای نظارت: انتخاب و پیکربندی ابزارهای نظارت و تحلیل لاگ مانند SIEM (Security Information and Event Management) جهت تشخیص رخدادهای مشکوک.
- آموزش و آگاهی کارکنان: اطمینان از آگاهی کارکنان از اهمیت گزارش دادن به موقع وقایع مشکوک و درک نحوه استفاده از ابزارهای لاگ‌گذاری.
- تعیین‌مسیرهای واکنش: تعیین مسیرهای واکنش به رویدادهای امنیتی و آمادگی برای مدیریت حوادث احتمالی.
سناریو: حمله DDoS به یک سرویس آنلاین
فرض کنید یک سرویس آنلاین با حجم بالایی از ترافیک مواجه شود که باعث افت کارایی سرویس و از دست رفتن دسترسی کاربران می‌شود. اگر لاگ‌ها به درستی پیکربندی نشده باشند و ابزارهای نظارت کافی وجود نداشته باشد، شناسایی و پیشگیری از این حمله DDoS ممکن نخواهد بود. با استفاده از لاگ‌های مناسب و ابزارهای نظارت، تیم امنیتی می‌تواند الگوها و تغییرات غیرعادی در ترافیک را تشخیص داده و بلافاصله به واکنش مناسب نائل آید.
در نتیجه، به منظور افزایش امنیت سیستم‌های اطلاعاتی، اهمیت لاگ‌گذاری و نظارت امنیتی بسیار بالاست و سازمان‌ها باید به این بخش از امنیت با دقت ویژه‌ای توجه کنند.
Server Side Request Forgery (SSRF)
در فهرست OWASP، یکی از مسائل حیاتی امنیتی به نام “تقلب درخواست از سمت سرور” یا به انگلیسی “Server-Side Request Forgery (SSRF)” به رده دهم اختصاص یافته است. این تهدید به سرقت اطلاعات حیاتی و حملات به سیستم‌ها تبدیل شده و اهمیت زیادی در امنیت اطلاعاتی سازمان‌ها پیدا کرده است. در این بخش، به بررسی این تهدید، راهکارهای پیشگیری، و یک مثال عملی از حمله SSRF می‌پردازیم.
توضیحات حمله SSRF
حمله SSRF یا تقلب درخواست از سمت سرور به وقوع می‌پیوندد زمانی که یک حمله‌کننده توانایی تغییر یا ارسال درخواست‌ها به سمت سرور را دارد. این نوع حمله می‌تواند به دزدیده شدن اطلاعات داخلی سیستم یا دستیابی به سرویس‌های در داخل شبکه برای حملات دیگر منجر شود.
چرا SSRF اهمیت دارد؟
- دسترسی به منابع داخلی: حمله‌کننده با استفاده از SSRF می‌تواند به منابع داخلی شبکه مانند پایگاه‌های داده، فایل‌های سرور، یا سرویس‌های حیاتی دسترسی یابد.
- حمله به سرویس‌های داخلی: این نوع حمله ممکن است برای ارسال درخواست‌ها به سرویس‌های در داخل شبکه با هدف مخربی مثل حذف داده‌ها یا اجرای دستورات مخرب استفاده شود.
- سوءاستفاده از سرویس‌های خارجی: SSRF ممکن است برای حمله به سرویس‌های خارجی و ایجاد اتصالات غیرمجاز به آنها نیز استفاده شود.
راهکارهای پیشگیری
برای جلوگیری از حمله SSRF، می‌توان از راهکارهای زیر استفاده کرد:
- محدود کردن دسترسی‌ها: محدود کردن سرویس‌ها و منابعی که قابل دسترسی از سمت سرور هستند و ممنوع کردن دسترسی به منابع حساس.
- فیلترینگ درخواست‌ها: اعمال فیلترهای دقیق بر روی درخواست‌های ارسالی به سمت سرور تا جلوی ارسال درخواست‌های مخرب گرفته شود.
- استفاده از Whitelist: مشخص کردن یک لیست از آدرس‌ها و منابع معتبر که می‌توانند از سمت سرور قابل دسترسی باشند.
- استفاده از شناسه‌های تصویب‌شده: بررسی دقیق و استفاده از شناسه‌های تصویب‌شده برای اطمینان از معتبر بودن درخواست‌ها.
سناریو: دزدیدن اطلاعات حساس از داخل شبکه
حمله‌کننده با استفاده از یک SSRF موفق به ارسال درخواست به یک پایگاه داده داخلی می‌شود و اطلاعات حساسی از آن می بر میدارد. این اطلاعات ممکن است شامل اطلاعات کاربران، اطلاعات مالی، یا داده‌های حیاتی سازمان باشد که موجب خسارت‌های جدی برای سازمان می‌شود.
با توجه به پیچیدگی روزافزون تهدیدات سایبری، اهمیت پیشگیری از حملات SSRF و تقویت امنیت سیستم‌ها بسیار ضروری است. استفاده از راهکارهای مذکور و به‌روزرسانی مداوم سیستم‌ها می‌تواند به سازمان‌ها کمک کند تا از ورود حملات SSRF جلوگیری کنند و اطلاعات حساس خود را محافظت نمایند.
[…] از جمله حملات SQL Injection، حملات Cross-Site Scripting، […]