OWASP و 10 خطر امنیتی برتر در برنامههای وب

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);--
یک دیدگاه