قوانین تشخیصی هیجان انگیز جدید در PVS-Studio 7.35

با انتشار PVS-Studio 7.35 ، آنالایزر یک تن از قوانین تشخیصی جدید به دست آورد. شما می توانید تعداد زیادی MISRA را برای C ، قوانین تشخیصی وحدت جدید برای C#، OWASP 10 پوشش برتر برای جاوا و غیره پیدا کنید. در این یادداشت می توانید اطلاعات بیشتری کسب کنید.
قوانین تشخیصی جدید C و C ++
همانطور که در بیانیه مطبوعاتی نوشتیم ، تیم آنالایزر C و C ++ بر روی استاندارد MISRA متمرکز شده است (ممکن است با توجه به تعداد قوانین تشخیصی ، این موضوع را متوجه شوید).
با این حال ، به جای جدا کردن هر قانون ، بیایید جالب ترین موارد را طی کنیم. برای آسانتر کردن “انتخاب” ، می خواهم به شما یادآوری کنم که کتاب جدید ما خارج است! این “راهنمای برنامه نویس C ++ برای رفتار نامشخص” است ، نوعی راهنمای برای رفتار نامشخص و مخفی ترین و عجیب ترین گوشه های آن. این کتاب توسط دیمیتری سویریدکین نوشته شده و توسط آندری کارپوف ویرایش شده است.
همانطور که ممکن است از این پیشگفتار حدس بزنید ، ما در برخی از قوانین تشخیصی مربوط به رفتار نامشخص به شما پیشنهاد می کنیم.
v2627بشر MISRA نوع عملکرد نباید از نوع واجد شرایط باشد. [For the C language]
این قانون تشخیص به عنوان MISRA-C-17.13 طبقه بندی می شود.
بیایید با اولین قاعده تشخیصی که امکان رفتار نامشخص را تشخیص می دهد ، شروع کنیم.
آنالایزر تشخیص داده است که یک نوع عملکرد در کد با استفاده از کد اعلام شده است const
با volatile
با restrict
، یا _Atomic
مقدماتی هنگامی که از چنین نوع استفاده می شود ، رفتار برنامه تعریف نشده است.
مثال کد که در آن آنالایزر هشدار دهنده را صادر می کند:
typedef int fun_t(void);
typedef const fun_t qual_fun_t; // <=
typedef const fun_t * ptr_to_qual_fun_t; // <=
void foo()
{
const fun_t c_fun_t; // <=
const fun_t * ptr_c_fun_t; // <=
}
برای اطمینان از عملکرد مناسب ، const
در هنگام اعلام نوع عملکرد ، صلاحیت باید حذف شود.
v2631بشر MISRA نشانگرهایی که به انواع آرایه های اصلاح شده متغیر استفاده می شوند نباید استفاده شود. [For the C language]
این قانون تشخیصی به عنوان MISRA-C-17.13 طبقه بندی می شود.
ما به سفر تعریف نشده خود ادامه می دهیم …
در این قاعده تشخیصی ، مسئله مربوط به استفاده از یک نشانگر آرایه با طول متغیر (VLA) در اعلامیه های شی یا اعلامیه های پارامتر عملکرد است. این می تواند منجر به خطاهای احتمالی شود ، بنابراین استفاده از نشانگر توصیه نمی شود.
رفتار نامشخص زمانی اتفاق می افتد که دو نشانگر به آرایه هایی با اندازه های مشخص در هر زمینه ای استفاده شود که نیاز به سازگاری آنها داشته باشد ، اما اندازه آنها متفاوت است.
مثال کد که در آن آنالایزر هشدار دهنده را صادر می کند:
void foo(int n, int (*a)[n])
{
int (*b)[20] = a; // undefined behavior if n != 20
// types are assumed to be compatible
}
void bar(int n)
{
int a[n];
foo(n, &a);
}
void foobar()
{
bar(10);
}
در این کد ، foo
تابع قبول می کند a
اشاره گر به VLA که اندازه آن توسط n
پارامتر در داخل عملکرد ، نشانگر به دیگری اختصاص می یابد b
نشانگر ، که انتظار یک اشاره گر به مجموعه ای از دقیقاً 20 عنصر است.
چنین عملیاتی تا زمانی که منجر به رفتار نامشخص می شود n != 20
بشر
سایر قوانین تشخیصی
همانطور که گفتیم ، تعداد قوانین تشخیصی جدید Misra همچنان در حال رشد است ، در اینجا بقیه:
v2626. Misra C 2023 12.5. اپراتور SizeOf نباید دارای یک عملگر باشد که یک پارامتر عملکردی است که به عنوان “آرایه ای از نوع” اعلام شده است.
v2628. Misra C 2023 21.15. استدلال های اشاره گر به عملکرد استاندارد کتابخانه “foo” باید نشانگر نسخه های واجد شرایط یا غیر صلاحیت از انواع سازگار باشد.
v2629. Misra C 2023 21.16. آرگومان های اشاره گر به عملکرد استاندارد کتابخانه MEMCMP باید به یک نوع اشاره گر ، یک نوع اساساً امضا شده ، یک نوع اساساً بدون امضا ، یک نوع اساساً بولی یا یک نوع اساساً enum اشاره کند.
v2630. Misra C 2023 6.3. میدان بیت نباید به عنوان عضو اتحادیه اعلام شود.
v2632. Misra C 2023 18.9. شیء با طول عمر موقت نباید تحت تبدیل آرایه به نشانگر قرار بگیرد.
v2633. Misra C 2023 5.5. شناسه ها باید از نام های کلان متمایز باشند.
به هر حال ، در طول توسعه PVS-Studio 7.35 ، ما چندین مقاله جالب در مورد C ++ منتشر کرده ایم ، و در اینجا برخی از آنها وجود دارد: “خطاهای برتر C و C ++ در سال 2024” ، فصل آخر راهنمای UB ، “چگونه کتابخانه های شخص ثالث قوانین تجزیه و تحلیل کد را تغییر می دهند.”
قوانین جدید C#
در نسخه قبلی PVS-Studio 7.34 ، تیم C# Analyzer قول داد در نسخه آینده آنالایزر بر ایجاد قوانین تشخیصی خاص وحدت تمرکز کند.
خوب ، بچه ها دروغ نمی گفتند! بیایید برخی از این قوانین را طی کنیم.
همه ما به یاد می آوریم که تجزیه و تحلیل استاتیک برای Gamedev مفید است ، درست است؟ در مورد ما ، برای وحدت و موتور غیر واقعی.
v3214بشر موتور وحدت. استفاده از API وحدت در موضوع پس زمینه ممکن است منجر به خطا شود.
بیایید با یک قانون تشخیصی شروع کنیم که نه تنها برای ابزار ما بلکه برای وحدت جدید است ، زیرا مربوط به جدید است Awaitable
کلاس.
اگر در مورد سایر ویژگی های جدید در Unity کنجکاو هستید ، می توانید مقاله مرور ما را بخوانید – “چه چیزی در Unity 6 چیست؟ نمای کلی به روزرسانی های انتشار و مشکلات کد منبع.”
آنالایزر تشخیص داده است که از یک ویژگی ، روش یا سازنده پس از فراخوانی استفاده می شود Awaitable.BackgroundThreadAsync
بشر این ممکن است باعث ایجاد مشکلاتی مانند آویزان برنامه یا پرتاب استثنا در هنگام اجرای موضوع پس زمینه شود.
مستندات وحدت بیان می کند که تمام API هایی که با موتور تعامل دارند باید منحصراً در موضوع اصلی استفاده شوند.
مثال کد که در آن آنالایزر هشدار دهنده را صادر می کند:
private async Awaitable LoadSceneAndDoHeavyComputation()
{
await Awaitable.BackgroundThreadAsync();
await SceneManager.LoadSceneAsync("MainScene");
....
}
public async Awaitable Update()
{
if (....)
await LoadSceneAndDoHeavyComputation();
....
}
وقتی LoadSceneAndDoHeavyComputation
روش اجرا می شود ، تماس با Awaitable.BackgroundThreadAsync
روش اجرای کد بعدی را در همان روش به موضوع پس زمینه تغییر می دهد.
این ممکن است باعث ایجاد مشکلات شود که SceneManager.LoadSceneAsync
روش بعداً نامیده می شود.
v3216بشر موتور وحدت. بررسی یک فیلد با نوع موتور وحدت خاص برای NULL ممکن است به دلیل اولیه سازی ضمنی میدان توسط موتور به درستی کار نکند.
در اینجا یک قانون تشخیصی دیگر وجود دارد اما این بار با تمرکز بر ویژگی های غیر جالب موتور وحدت.
آنالایزر غیرقابل اعتماد را تشخیص داده است null
فیلدی را که می تواند در آن آغاز شود ، بررسی کنید Unity
بازرس
مثال کد که در آن آنالایزر هشدار دهنده را صادر می کند:
public class ActivateTrigger: MonoBehaviour
{
[SerializeField]
GameObject _target;
private void DoActivateTrigger()
{
var target = _target ?? gameObject;
....
}
}
در این حالت ، اگر _target
مقدار هنوز در زمان اجرا تغییر نکرده است ، ??
فرض کنید _target
نابرابر است null
، صرف نظر از اینکه آیا مقدار فیلد در بازرس وحدت اختصاص یافته است.
برای اطلاعات بیشتر در مورد این که چرا این مورد است ، به مستندات مراجعه کنید.
v3217بشر سرریز احتمالی در نتیجه یک عملیات حسابی.
قوانین تشخیصی خاص چیز خوبی است ، اما ما نمی توانیم موارد کلی را نیز فراموش کنیم!
این بار آنالایزر یک عملیات حسابی را تشخیص داده است که ممکن است منجر به سرریز شود.
مثال کد که در آن آنالایزر هشدار دهنده را صادر می کند:
private const int _halfMaximumValue = int.MaxValue / 2;
public void Calculate(int summand)
{
int sum;
if (summand > _halfMaximumValue + 1)
{
sum = _halfMaximumValue + summand;
}
....
}
در Calculate
روش ، مجموع پارامتر گذشت و ثابت محاسبه می شود. ثابت نیمی از حداکثر مقدار است System.Int32
بشر مقدار پارامتر قبل از عمل اضافی بررسی می شود تا از سرریز حسابی جلوگیری شود.
با این حال ، این شرط حاوی خطایی است: در مورد ما ، بررسی می کند که آیا summand
بزرگتر از است _halfMaximumValue + 1
بشر اگر شرط صحیح باشد ، سرریز حسابی در طی عملیات اضافی تضمین می شود.
سایر قوانین تشخیصی
فکر می کنید ما در مورد وحدت صحبت کرده ایم؟ خیلی سریع نیست!
در اینجا چند قانون تشخیصی خاص وحدت در این نسخه آورده شده است:
v3211. موتور وحدت. اپراتورها؟ و '؟؟ =' به درستی اشیاء نابود شده از “unityengine.object” را به درستی اداره نمی کنید.
V3212. موتور وحدت. تطبیق الگوی به درستی اشیاء نابود شده از “unityengine.object” را به درستی اداره نمی کند.
V3213. موتور وحدت. روش “getComponent” باید با نوعی که از “unityengine.component” به ارث می برد ، فوری شود.
V3214. موتور وحدت. استفاده از API وحدت در موضوع پس زمینه ممکن است منجر به خطا شود.
V3215. موتور وحدت. عبور از یک روش به عنوان یک رشته رشته به “startCoroutine” غیرقابل اعتماد است.
V3216. موتور وحدت. بررسی یک فیلد با نوع موتور وحدت خاص برای NULL ممکن است به دلیل اولیه سازی ضمنی میدان توسط موتور به درستی کار نکند.
V3217. سرریز احتمالی در نتیجه یک عملیات حسابی.
v4008. موتور وحدت. از استفاده از API های فیزیک تخصیص حافظه در زمینه حساس به عملکرد خودداری کنید.
به هر حال ، در حین توسعه PVS-Studio 7.35 ، ما چندین مقاله جالب در C#منتشر کرده ایم و در اینجا برخی از آنها وجود دارد: “خطاهای برتر 10 C#در سال 2024” ، “.NET Digest#5” ، و “چگونه می توان کتابخانه را به روز کرد و با این کار باتلاق شد”
قوانین تشخیصی جاوا جدید
در صفحه تاریخچه نسخه برای انتشار PVS-Studio 7.35 ، ممکن است پاراگراف را مشاهده کنید که در مورد آنالایزر جاوا صحبت می کند ، “ما در حال پوشش دادن استاندارد OWASP 10 2021 برای آنالایزر جاوا هستیم. با این نسخه ، PVS-Studio برای جاوا خطاهای 7 را از 10 دسته از آنها تشخیص می دهد”.
در حال حاضر ، PVS-Studio برای جاوا آسیب پذیری ها را در دسته های زیر تشخیص می دهد:
می توانید ببینید که چگونه PVS-Studio OWASP TOP TEN 2021 را برای C ++ ، C#و جاوا در اینجا پوشش می دهد.
من به شما پیشنهاد می کنم این جمله را آزمایش کنید! بیایید به قوانین تشخیصی مربوط به این موضوع نگاه کنیم:
v5310بشر OWASP تزریق فرماندهی احتمالی. از داده های بالقوه لکه دار برای ایجاد دستور سیستم عامل استفاده می شود.
این آسیب پذیری را می توان در طبقه بندی OWASP 10 2021 به عنوان A3: 2021-تزریق طبقه بندی کرد.
آنالایزر تشخیص داده است که یک دستور سطح سیستم عامل از داده های خارجی تأیید نشده ایجاد می شود. این می تواند منجر به آسیب پذیری تزریق فرمان شود.
مثال کد که در آن آنالایزر هشدار دهنده را صادر می کند:
public void doUsersCommand() throws IOException {
Scanner sc = new Scanner(System.in);
String command = sc.nextLine();
Runtime.getRuntime().exec(command);
}
در command
رشته خارجی است و به exec
روش به عنوان یک دستور سطح سیستم عامل. از آنجا که این دستور قبل از اجرای تأیید نشده است ، می تواند شامل هرگونه دستورالعمل ، از جمله موارد مخرب باشد.
به هر حال ، این قانون تشخیصی دارای یک خواهر و برادر ، V5311 است. OWASP تزریق استدلال احتمالی.
v5318بشر OWASP تنظیم مجوزهای پرونده POSIX در گروه های “همه” یا “دیگران” می تواند منجر به دسترسی ناخواسته به پرونده ها یا دایرکتوری ها شود.
این آسیب پذیری را می توان در زیر OWASP Top 10 2021 به عنوان A1: کنترل دسترسی شکسته و A4: طراحی ناامن طبقه بندی کرد.
آنالایزر پرونده هایی را با مجوزهای دسترسی نامحدود در برنامه شناسایی کرده است. به طور خاص ، گروه “دیگران” دسترسی پیدا می کنند. گروه “دیگران” به جز صاحب منابع به همه کاربران و گروه ها اشاره دارد. اعطای حقوق به این گروه ممکن است منجر به دسترسی غیرمجاز شود.
مثال کد که در آن آنالایزر هشدار دهنده را صادر می کند:
public void example() throws IOException {
Path path = Path.of("/path/to/resource");
Files.setPosixFilePermissions(
path,
PosixFilePermissions.fromString("rwxrwxrwx")
);
}
در این مثال ، هم مالک و هم سایر کاربران به منبع (خواندن ، نوشتن و اجرای) توسط آنها دسترسی پیدا می کنند path
بشر این اصل حداقل امتیاز را نقض می کند.
اجرای حداکثر محدودیت دسترسی در پرونده ها و دایرکتوری ها ضروری است ، به ویژه اگر منابع حاوی داده های محرمانه باشند.
سایر قوانین تشخیصی
تشخیص OWASP به آنجا ختم نمی شود ، در اینجا موارد دیگری وجود دارد:
v5312. OWASP تزریق XPath ممکن است. از داده های بالقوه لکه دار برای ایجاد بیان XPath استفاده می شود.
v5313. OWASP از نسخه های قدیمی پروتکل های SSL/TLS استفاده نکنید زیرا ممکن است باعث ایجاد مشکلات امنیتی شود.
V5314. OWASP استفاده از الگوریتم هش منسوخ توصیه نمی شود.
V5315. OWASP استفاده از یک الگوریتم رمزنگاری منسوخ توصیه نمی شود.
V5316. OWASP از روش “httpservletrequest.getRewestEsessionId” استفاده نکنید زیرا از شناسه جلسه ارائه شده توسط مشتری استفاده می کند.
V5317. OWASP اجرای یک الگوریتم رمزنگاری توصیه نمی شود زیرا ممکن است یک مهاجم آن را بشکند.
V5319. OWASP تزریق احتمالی ورود به سیستم. داده های بالقوه لکه دار در سیاههها نوشته شده است.
به هر حال ، در حین توسعه PVS-Studio 7.35 ، ما چندین مقاله جالب در مورد جاوا منتشر کرده ایم ، و در اینجا برخی از آنها وجود دارد: “10 خطای برتر جاوا در سال 2024” ، “جاوا ، رنگ و ساست؟” و “چگونه می توان با وزارت خود ماینکرافت را خراب کرد.”
“نکات وحشتناک برای یک توسعه دهنده C ++” در PDF
اکنون کتاب “نکات وحشتناک برای یک توسعه دهنده C ++” آندری کارپوف در PDF موجود است. این کتاب با فرمت طنز نوشته شده است. این به موقعیت های واقعی در برنامه نویسی C ++ می پردازد که باید از آن جلوگیری کند.
شرایط دریافت کتاب الکترونیکی بسیار ساده است: در مقاله ما Digest یا Telegram Bot مشترک شوید. تمام جزئیات در لینک است.
آیا می خواهید یک پروژه را با استفاده از PVS-Studio بررسی کنید؟ سپس از این صفحه شروع کنید.
اگر می خواهید در مورد آخرین نسخه ها اخبار دریافت کنید ، در خبرنامه PVS-Studio در اینجا مشترک شوید.
از خواندن شما متشکرم!
اگر سؤال یا درخواست مقاله دارید ، از ارسال آنها از طریق فرم بازخورد دریغ نکنید. آخرین و مهمترین چیز ، ما دوست داریم افکار شما را در نظرات بشنویم 🙂