پاگل ہوئے بغیر چیک مارکس کے قواعد کیسے لکھیں۔

ارے حبر!

ہمارے کام میں، ہماری کمپنی اکثر مختلف سٹیٹک کوڈ تجزیہ ٹولز (SAST) سے نمٹتی ہے۔ باکس سے باہر وہ سب اوسط کام کرتے ہیں۔ بلاشبہ، یہ سب اس پراجیکٹ اور اس میں استعمال ہونے والی ٹیکنالوجیز پر منحصر ہے، نیز یہ کہ یہ ٹیکنالوجیز تجزیہ کے اصولوں میں کتنی اچھی طرح سے شامل ہیں۔ میری رائے میں، SAST ٹول کا انتخاب کرتے وقت سب سے اہم معیار میں سے ایک یہ ہے کہ اسے اپنی ایپلی کیشنز کی تفصیلات کے مطابق اپنی مرضی کے مطابق کرنے کی صلاحیت ہے، یعنی تجزیہ کے قواعد لکھیں اور تبدیل کریں یا جیسا کہ انہیں زیادہ کثرت سے حسب ضرورت سوالات کہا جاتا ہے۔

پاگل ہوئے بغیر چیک مارکس کے قواعد کیسے لکھیں۔

ہم اکثر چیک مارکس استعمال کرتے ہیں - ایک بہت ہی دلچسپ اور طاقتور کوڈ تجزیہ کار۔ اس مضمون میں میں اس کے لیے تجزیہ کے قواعد لکھنے کے اپنے تجربے کے بارے میں بات کروں گا۔

مواد کی میز

داخلہ

شروع کرنے کے لیے، میں چیک مارکس کے لیے سوالات لکھنے کی خصوصیات کے بارے میں روسی زبان میں چند مضامین میں سے ایک تجویز کرنا چاہوں گا۔ یہ 2019 کے آخر میں Habré پر اس عنوان سے شائع ہوا تھا: "ہیلو، چیک مارکس!" چیک مارکس SAST استفسار کیسے لکھیں اور ٹھنڈی کمزوریوں کو تلاش کریں۔.

یہ تفصیل سے جانچتا ہے کہ پہلے سوالات کو کس طرح CxQL (Checkmarx Query Language) میں کچھ ٹیسٹ ایپلیکیشن کے لیے لکھنا ہے اور اس کے بنیادی اصول دکھاتا ہے کہ تجزیہ کے اصول کیسے کام کرتے ہیں۔

جو کچھ اس میں بیان کیا گیا ہے میں اسے نہیں دہراوں گا، البتہ کچھ مقطعات اب بھی موجود ہوں گے۔ اپنے مضمون میں میں ایک قسم کی "ترکیبوں کا مجموعہ" مرتب کرنے کی کوشش کروں گا، مخصوص مسائل کے حل کی فہرست جو مجھے چیک مارکس کے ساتھ کام کے دوران درپیش تھیں۔ مجھے ان میں سے بہت سے مسائل پر اپنے دماغ کو ریک کرنا پڑا۔ بعض اوقات دستاویزات میں کافی معلومات نہیں ہوتی تھیں، اور بعض اوقات یہ سمجھنا بھی مشکل ہو جاتا تھا کہ کیا کرنا ہے۔ مجھے امید ہے کہ میرا تجربہ اور بے خواب راتیں رائیگاں نہیں جائیں گی، اور یہ "کسٹم سوالات کی ترکیبوں کا مجموعہ" آپ کے چند گھنٹے یا چند اعصابی خلیوں کی بچت کرے گا۔ تو، چلو شروع کرتے ہیں!

قواعد کے بارے میں عمومی معلومات

سب سے پہلے، آئیے کچھ بنیادی تصورات اور قواعد کے ساتھ کام کرنے کے عمل کو دیکھتے ہیں، اس بات کی بہتر تفہیم کے لیے کہ آگے کیا ہوگا۔ اور یہ بھی کہ دستاویزات اس بارے میں کچھ نہیں کہتی ہیں یا ڈھانچے میں بہت پھیلی ہوئی ہیں، جو کہ زیادہ آسان نہیں ہے۔

  1. قواعد اسکیننگ کے دوران لاگو کیے جاتے ہیں اس پر منحصر ہے کہ شروع میں منتخب کیا گیا ہے (فعال قواعد کا ایک مجموعہ)۔ آپ لامحدود تعداد میں پیش سیٹیں تشکیل دے سکتے ہیں، اور بالکل ان کی ساخت کا انحصار آپ کے عمل کی تفصیلات پر ہے۔ آپ انہیں زبان کے لحاظ سے گروپ کر سکتے ہیں یا ہر پروجیکٹ کے لیے پیش سیٹ منتخب کر سکتے ہیں۔ فعال قواعد کی تعداد اسکیننگ کی رفتار اور درستگی کو متاثر کرتی ہے۔

    پاگل ہوئے بغیر چیک مارکس کے قواعد کیسے لکھیں۔چیک مارکس انٹرفیس میں پیش سیٹ اپ کرنا

  2. قوانین CxAuditor نامی ایک خصوصی ٹول میں ترمیم کیے جاتے ہیں۔ یہ ایک ڈیسک ٹاپ ایپلی کیشن ہے جو چیک مارکس چلانے والے سرور سے جڑتی ہے۔ اس ٹول میں آپریشن کے دو طریقے ہیں: قوانین میں ترمیم کرنا اور پہلے سے انجام دیے گئے اسکین کے نتائج کا تجزیہ کرنا۔

    پاگل ہوئے بغیر چیک مارکس کے قواعد کیسے لکھیں۔CxAudit انٹرفیس

  3. چیک مارکس میں قواعد کو زبان کے لحاظ سے تقسیم کیا گیا ہے، یعنی ہر زبان کے اپنے سوالات کا سیٹ ہے۔ کچھ عمومی اصول بھی ہیں جو زبان سے قطع نظر لاگو ہوتے ہیں، یہ نام نہاد بنیادی سوالات ہیں۔ زیادہ تر حصے کے لیے، بنیادی سوالات میں ایسی معلومات کی تلاش شامل ہوتی ہے جو دوسرے قواعد استعمال کرتے ہیں۔

    پاگل ہوئے بغیر چیک مارکس کے قواعد کیسے لکھیں۔زبان کے لحاظ سے قواعد کی تقسیم

  4. قواعد "قابل عمل" اور "نان ایگزیکیوٹیبل" (پھانسی شدہ اور عمل نہیں کیے گئے) ہیں۔ میری رائے میں بالکل صحیح نام نہیں ہے، لیکن یہ وہی ہے۔ سب سے اہم بات یہ ہے کہ "قابل عمل" قواعد پر عمل کرنے کا نتیجہ UI میں اسکیننگ کے نتائج میں ظاہر کیا جائے گا، اور "غیر قابل عمل" قواعد صرف ان کے نتائج کو دوسری درخواستوں میں استعمال کرنے کے لیے درکار ہیں (حقیقت میں، وہ صرف ایک فنکشن ہیں۔ )۔

    پاگل ہوئے بغیر چیک مارکس کے قواعد کیسے لکھیں۔بناتے وقت اصول کی قسم کا تعین کرنا

  5. آپ نئے قواعد تشکیل دے سکتے ہیں یا موجودہ قوانین کی تکمیل/دوبارہ لکھ سکتے ہیں۔ کسی اصول کو دوبارہ لکھنے کے لیے، آپ کو اسے درخت میں تلاش کرنا ہوگا، دائیں کلک کریں اور ڈراپ ڈاؤن مینو سے "اوور رائڈ" کو منتخب کریں۔ یہاں یہ یاد رکھنا ضروری ہے کہ نئے قواعد ابتدائی طور پر پیش سیٹوں میں شامل نہیں ہیں اور فعال نہیں ہیں۔ ان کا استعمال شروع کرنے کے لیے آپ کو ان کو انسٹرومنٹ میں "پریسیٹ مینیجر" مینو میں فعال کرنا ہوگا۔ دوبارہ لکھے گئے قواعد اپنی ترتیبات کو برقرار رکھتے ہیں، یعنی، اگر اصول فعال تھا، تو یہ ایسا ہی رہے گا اور فوری طور پر لاگو کیا جائے گا۔

    پاگل ہوئے بغیر چیک مارکس کے قواعد کیسے لکھیں۔پیش سیٹ مینیجر انٹرفیس میں ایک نئے اصول کی مثال

  6. عملدرآمد کے دوران، درخواستوں کا ایک "درخت" بنایا گیا ہے، جو کس چیز پر منحصر ہے۔ جو قوانین معلومات جمع کرتے ہیں ان پر پہلے عمل کیا جاتا ہے اور جو لوگ اسے استعمال کرتے ہیں وہ دوسرے۔ عملدرآمد کا نتیجہ کیش شدہ ہے، لہذا اگر موجودہ اصول کے نتائج کو استعمال کرنا ممکن ہے، تو ایسا کرنا بہتر ہے، اس سے اسکیننگ کا وقت کم ہو جائے گا۔

  7. قوانین کو مختلف سطحوں پر لاگو کیا جا سکتا ہے:

  • پورے سسٹم کے لیے - کسی بھی پروجیکٹ کی اسکیننگ کے لیے استعمال کیا جائے گا۔

  • ٹیم کی سطح پر (ٹیم) - صرف منتخب ٹیم میں پروجیکٹس کو اسکین کرنے کے لیے استعمال کیا جائے گا۔

  • پروجیکٹ کی سطح پر - ایک مخصوص پروجیکٹ میں لاگو کیا جائے گا۔

    پاگل ہوئے بغیر چیک مارکس کے قواعد کیسے لکھیں۔اس سطح کا تعین کرنا جس پر اصول لاگو کیا جائے گا۔

ابتدائیوں کے لیے "لغت"

اور میں کچھ ایسی چیزوں سے شروع کروں گا جو میرے لیے سوالات کا باعث بنی ہیں، اور میں بہت سی ایسی تکنیکیں بھی دکھاؤں گا جو زندگی کو نمایاں طور پر آسان بنائیں گی۔

فہرستوں کے ساتھ آپریشنز

- вычитание одного из другого (list2 - list1)
* пересечение списков (list1 * list2)
+ сложение списков (list1 + list2)

& (логическое И) - объединяет списки по совпадению (list1 & list2), аналогично пересечению (list1 * list2)
| (логическое ИЛИ) - объединяет списки по широкому поиску (list1 | list2)

Со списками не работает:  ^  &&  ||  %  / 

تمام چیزیں مل گئیں۔

اسکین شدہ زبان کے اندر، آپ بالکل ان تمام عناصر کی فہرست حاصل کر سکتے ہیں جن کی چیک مارکس نے شناخت کی ہے (سٹرنگز، فنکشنز، کلاسز، طریقے وغیرہ)۔ یہ اشیاء کی کچھ جگہ ہے جس تک رسائی حاصل کی جا سکتی ہے۔ All. یعنی کسی شے کو مخصوص نام کے ساتھ تلاش کرنا searchMe، آپ تلاش کر سکتے ہیں، مثال کے طور پر، تمام پائی جانے والی اشیاء میں نام سے:

// Такой запрос выдаст все элементы
result = All;

// Такой запрос выдаст все элементы, в имени которых присутствует “searchMe“
result = All.FindByName("searchMe");

لیکن، اگر آپ کو کسی دوسری زبان میں تلاش کرنے کی ضرورت ہے جسے کسی وجہ سے اسکین میں شامل نہیں کیا گیا تھا (مثال کے طور پر، اینڈرائیڈ پروجیکٹ میں گرووی)، تو آپ متغیر کے ذریعے ہمارے آبجیکٹ کی جگہ کو بڑھا سکتے ہیں:

result = AllMembers.All.FindByName("searchMe");

بہاؤ کے تجزیہ کے لیے افعال

یہ فنکشن بہت سے اصولوں میں استعمال ہوتے ہیں اور یہاں ان کے معنی کی ایک چھوٹی سی چیٹ شیٹ ہے:

// Какие данные second влияют на first.
// Другими словами - ТО (second) что влияет на  МЕНЯ (first).
result = first.DataInfluencedBy(second);

// Какие данные first влияют на second.
// Другими словами - Я (first) влияю на ТО (second).
result = first.DataInfluencingOn(second);

فائل کا نام / راستہ حاصل کرنا

ایسی کئی صفات ہیں جو استفسار کے نتائج سے حاصل کی جا سکتی ہیں (اس فائل کا نام جس میں اندراج پایا گیا تھا، سٹرنگ وغیرہ)، لیکن دستاویزات میں یہ نہیں بتایا گیا کہ انہیں کیسے حاصل کیا جائے اور استعمال کیا جائے۔ لہذا، ایسا کرنے کے لیے، آپ کو LinePragma پراپرٹی تک رسائی حاصل کرنے کی ضرورت ہے اور ہمیں جن اشیاء کی ضرورت ہے وہ اس کے اندر موجود ہوں گی۔

// Для примера найдем все методы
CxList methods = Find_Methods();

// В методах найдем по имени метод scope
CxList scope = methods.FindByName("scope");

// Таким образом можо получить путь к файлу
string current_filename = scope.GetFirstGraph().LinePragma.FileName;

// А вот таким - строку, где нашлось срабатывание
int current_line = scope.GetFirstGraph().LinePragma.Line;

// Эти параметры можно использовать по разному
// Например получить все объекты в файле
CxList inFile = All.FindByFileName(current_filename);

// Или найти что происходит в конкретной строке
CxList inLine = inFile.FindByPosition(current_line);

یہ بات ذہن میں رکھنے کے قابل ہے۔ FileName اصل میں فائل کا راستہ ہے، کیونکہ ہم نے طریقہ استعمال کیا ہے۔ GetFirstGraph.

پھانسی کا نتیجہ

CxQL کے اندر ایک خاص متغیر ہے۔ result، جو آپ کے تحریری اصول پر عمل درآمد کا نتیجہ لوٹاتا ہے۔ اسے فوری طور پر شروع کیا جاتا ہے اور آپ اس میں انٹرمیڈیٹ نتائج لکھ سکتے ہیں، اپنے کام کے دوران انہیں تبدیل اور بہتر کر سکتے ہیں۔ لیکن، اگر اصول کے اندر اس متغیر یا فنکشن کی کوئی تفویض نہیں ہے۔ return- پھانسی کا نتیجہ ہمیشہ صفر ہوگا۔

درج ذیل استفسار پر عمل درآمد کے نتیجے میں ہمیں کچھ واپس نہیں آئے گا اور ہمیشہ خالی رہے گا۔

// Находим элементы foo
CxList libraries = All.FindByName("foo");

لیکن، جادوئی متغیر کے نتیجے میں عمل درآمد کے نتیجے کو تفویض کرنے کے بعد، ہم دیکھیں گے کہ یہ کال ہمیں کیا لوٹاتی ہے:

// Находим элементы foo
CxList libraries = All.FindByName("foo");

// Выводим, как результат выполнения правила
result = libraries

// Или еще короче
result = All.FindByName("foo");

دوسرے قوانین کے نتائج کا استعمال کرتے ہوئے

چیک مارکس میں قواعد کو باقاعدہ پروگرامنگ زبان میں افعال کے مطابق کہا جا سکتا ہے۔ ایک اصول لکھتے وقت، آپ دوسرے سوالات کے نتائج کو اچھی طرح استعمال کر سکتے ہیں۔ مثال کے طور پر، ہر بار کوڈ میں تمام میتھڈ کالز تلاش کرنے کی ضرورت نہیں ہے، بس مطلوبہ اصول پر کال کریں:

// Получаем результат выполнения другого правила
CxList methods = Find_Methods();

// Ищем внутри метод foo. 
// Второй параметр false означает, что ищем без чувствительности к регистру
result = methods.FindByShortName("foo", false);

یہ نقطہ نظر آپ کو کوڈ کو مختصر کرنے اور اصول پر عمل درآمد کے وقت کو نمایاں طور پر کم کرنے کی اجازت دیتا ہے۔

مسئلہ حل کرنا

لاگنگ

ٹول کے ساتھ کام کرتے وقت، بعض اوقات مطلوبہ استفسار کو فوری طور پر لکھنا ممکن نہیں ہوتا اور آپ کو مختلف آپشنز آزماتے ہوئے تجربہ کرنا پڑتا ہے۔ ایسی صورت میں، ٹول لاگنگ فراہم کرتا ہے، جسے درج ذیل کہا جاتا ہے:

// Находим что-то
CxList toLog = All.FindByShortName("log");

// Формируем строку и отправляем в лог
cxLog.WriteDebugMessage (“number of DOM elements =” + All.Count);

لیکن یہ یاد رکھنے کے قابل ہے کہ یہ طریقہ صرف ان پٹ کے طور پر قبول کرتا ہے۔ تار، لہذا پہلی کارروائی کے نتیجے میں پائے جانے والے عناصر کی مکمل فہرست ظاہر کرنا ممکن نہیں ہوگا۔ دوسرا آپشن، جو ڈیبگنگ کے لیے استعمال ہوتا ہے، وقتاً فوقتاً جادوئی متغیر کو تفویض کرنا ہے۔ result سوال کا نتیجہ اور دیکھیں کہ کیا ہوتا ہے۔ یہ نقطہ نظر بہت آسان نہیں ہے؛ آپ کو اس بات کا یقین کرنے کی ضرورت ہے کہ اس کے بعد کوڈ میں اس کے ساتھ کوئی اوور رائیڈ یا آپریشن نہیں ہے۔ result یا صرف ذیل میں کوڈ پر تبصرہ کریں۔ یا آپ، میری طرح، ایک ریڈی میڈ اصول سے ایسی کئی کالز کو ہٹانا بھول سکتے ہیں اور حیران ہیں کہ کیوں کچھ کام نہیں ہوتا ہے۔

طریقہ کو کال کرنا زیادہ آسان طریقہ ہے۔ return مطلوبہ پیرامیٹر کے ساتھ۔ اس صورت میں، قاعدہ کا نفاذ ختم ہو جائے گا اور ہم یہ دیکھ سکیں گے کہ جو کچھ ہم نے لکھا ہے اس کے نتیجے میں کیا ہوا:

// Находим что-то
CxList toLog = All.FindByShortName("log");

// Выводим результат выполнения
return toLog

//Все, что написано дальше не будет выполнено
result = All.DataInfluencedBy(toLog)

لاگ ان کا مسئلہ

ایسے حالات ہوتے ہیں جب آپ CxAudit ٹول تک رسائی حاصل نہیں کر سکتے (جو قواعد لکھنے کے لیے استعمال ہوتا ہے)۔ اس کی بہت سی وجوہات ہو سکتی ہیں، بشمول کریش، اچانک ونڈوز اپ ڈیٹس، BSOD اور دیگر غیر متوقع حالات جو ہمارے قابو سے باہر ہیں۔ اس صورت میں، کبھی کبھی ڈیٹا بیس میں ایک نامکمل سیشن ہوتا ہے، جو آپ کو دوبارہ لاگ ان کرنے سے روکتا ہے۔ اسے ٹھیک کرنے کے لیے، آپ کو کئی سوالات چلانے کی ضرورت ہے:

8.6 سے پہلے چیک مارکس کے لیے:

// Проверяем, что есть залогиненые пользователи, выполнив запрос в БД
SELECT COUNT(*) FROM [CxDB].[dbo].LoggedinUser WHERE [ClientType] = 6;
 
// Если что-то есть, а на самом деле даже если и нет, попробовать выполнить запрос
DELETE FROM [CxDB].[dbo].LoggedinUser WHERE [ClientType] = 6;

8.6 کے بعد چیک مارکس کے لیے:

// Проверяем, что есть залогиненые пользователи, выполнив запрос в БД
SELECT COUNT(*) FROM LoggedinUser WHERE (ClientType = 'Audit');
 
// Если что-то есть, а на самом деле даже если и нет, попробовать выполнить запрос
DELETE FROM [CxDB].[dbo].LoggedinUser WHERE (ClientType = 'Audit');

تحریری قواعد

اب ہم سب سے دلچسپ حصے کی طرف آتے ہیں۔ جب آپ CxQL میں قواعد لکھنا شروع کرتے ہیں، تو آپ کے پاس اکثر دستاویزات کی اتنی زیادہ کمی نہیں ہوتی ہے جتنی کہ بعض مسائل کو حل کرنے اور سوالات کے عمومی طور پر کام کرنے کے طریقہ کار کو بیان کرنے کی کچھ زندہ مثالیں۔

میں ان لوگوں کے لیے زندگی کو قدرے آسان بنانے کی کوشش کروں گا جو استفسار کی زبان میں غوطہ لگانا شروع کر رہے ہیں اور بعض مسائل کو حل کرنے کے لیے اپنی مرضی کے سوالات کے استعمال کی کئی مثالیں پیش کروں گا۔ ان میں سے کچھ بالکل عام ہیں اور آپ کی کمپنی میں عملی طور پر بغیر کسی تبدیلی کے استعمال کی جا سکتی ہیں، دیگر زیادہ مخصوص ہیں، لیکن آپ کی ایپلی کیشنز کی تفصیلات کے مطابق کوڈ کو تبدیل کر کے بھی ان کا استعمال کیا جا سکتا ہے۔

لہذا، یہاں وہ مسائل ہیں جن کا ہمیں اکثر سامنا کرنا پڑتا ہے:

ٹاسک: قاعدہ پر عمل کرنے کے نتائج میں کئی بہاؤ ہیں اور ان میں سے ایک دوسرے کا گھونسلا ہے، آپ کو ان میں سے ایک کو چھوڑنا چاہیے۔

حل: درحقیقت، بعض اوقات چیک مارکس کئی ڈیٹا فلو دکھاتا ہے جو اوورلیپ ہو سکتے ہیں اور دوسروں کا مختصر ورژن ہو سکتے ہیں۔ ایسے معاملات کے لیے ایک خاص طریقہ ہے۔ بہاؤ کو کم کریں۔ پیرامیٹر پر منحصر ہے، یہ مختصر ترین یا طویل ترین بہاؤ کا انتخاب کرے گا:

// Оставить только длинные Flow
result = result.ReduceFlow(CxList.ReduceFlowType.ReduceSmallFlow);

// Оставить только короткие Flow
result = result.ReduceFlow(CxList.ReduceFlowType.ReduceBigFlow);

ٹاسک: حساس ڈیٹا کی فہرست کو پھیلائیں جس پر ٹول رد عمل ظاہر کرتا ہے۔

حل: چیک مارکس کے بنیادی اصول ہیں، جن کے نتائج بہت سے دوسرے سوالات میں استعمال ہوتے ہیں۔ اپنی درخواست کے مخصوص ڈیٹا کے ساتھ ان میں سے کچھ اصولوں کی تکمیل کرکے، آپ اپنے اسکین کے نتائج کو فوری طور پر بہتر بنا سکتے ہیں۔ آپ کو شروع کرنے کے لیے ذیل میں ایک مثالی اصول ہے:

عمومی_پرائیویسی_خلاف ورزی_لسٹ

آئیے کئی متغیرات شامل کریں جو ہماری ایپلیکیشن میں حساس معلومات کو ذخیرہ کرنے کے لیے استعمال ہوتے ہیں:

// Получаем результат выполнения базового правила
result = base.General_privacy_violation_list();

// Ищем элементы, которые попадают под простые регулярные выражения. Можно дополнить характерными для вас паттернами.
CxList personalList = All.FindByShortNames(new List<string> {
	"*securityToken*", "*sessionId*"}, false);

// Добавляем к конечному результату
result.Add(personalList);

ٹاسک: پاس ورڈ کے ساتھ متغیرات کی فہرست کو وسعت دیں۔

حل: میں تجویز کروں گا کہ کوڈ میں پاس ورڈ کی وضاحت کرنے کے بنیادی اصول پر فوری توجہ دیں اور اس میں متغیر ناموں کی فہرست شامل کریں جو آپ کی کمپنی میں عام طور پر استعمال ہوتے ہیں۔

پاس ورڈ_پرائیویسی_خلاف ورزی_لسٹ

CxList allStrings = All.FindByType("String"); 
allStrings.Add(All.FindByType(typeof(StringLiteral))); 
allStrings.Add(Find_UnknownReference());
allStrings.Add(All.FindByType(typeof (Declarator)));
allStrings.Add(All.FindByType(typeof (MemberAccess)));
allStrings.Add(All.FindByType(typeof(EnumMemberDecl))); 
allStrings.Add(Find_Methods().FindByShortName("get*"));

// Дополняем дефолтный список переменных
List < string > pswdIncludeList = new List<string>{"*password*", "*psw", "psw*", "pwd*", "*pwd", "*authKey*", "pass*", "cipher*", "*cipher", "pass", "adgangskode", "benutzerkennwort", "chiffre", "clave", "codewort", "contrasena", "contrasenya", "geheimcode", "geslo", "heslo", "jelszo", "kennwort", "losenord", "losung", "losungswort", "lozinka", "modpas", "motdepasse", "parol", "parola", "parole", "pasahitza", "pasfhocal", "passe", "passord", "passwort", "pasvorto", "paswoord", "salasana", "schluessel", "schluesselwort", "senha", "sifre", "wachtwoord", "wagwoord", "watchword", "zugangswort", "PAROLACHIAVE", "PAROLA CHIAVE", "PAROLECHIAVI", "PAROLE CHIAVI", "paroladordine", "verschluesselt", "sisma",
                "pincode",
								"pin"};
								
List < string > pswdExcludeList = new List<string>{"*pass", "*passable*", "*passage*", "*passenger*", "*passer*", "*passing*", "*passion*", "*passive*", "*passover*", "*passport*", "*passed*", "*compass*", "*bypass*", "pass-through", "passthru", "passthrough", "passbytes", "passcount", "passratio"};

CxList tempResult = allStrings.FindByShortNames(pswdIncludeList, false);
CxList toRemove = tempResult.FindByShortNames(pswdExcludeList, false);
tempResult -= toRemove;
tempResult.Add(allStrings.FindByShortName("pass", false));

foreach (CxList r in tempResult)
{
	CSharpGraph g = r.data.GetByIndex(0) as CSharpGraph;
	if(g != null && g.ShortName != null && g.ShortName.Length < 50)
	{
		result.Add(r);
	}
}

ٹاسک: استعمال شدہ فریم ورک شامل کریں جو چیک مارکس کے ذریعے تعاون یافتہ نہیں ہیں۔

حل: چیک مارکس میں تمام سوالات کو زبان کے لحاظ سے تقسیم کیا گیا ہے، لہذا آپ کو ہر زبان کے لیے قواعد شامل کرنے کی ضرورت ہے۔ ذیل میں ایسے قوانین کی کچھ مثالیں ہیں۔

اگر لائبریریوں کا استعمال کیا جاتا ہے جو معیاری فعالیت کی تکمیل کرتی ہے یا اس کی جگہ لیتی ہے، تو انہیں آسانی سے بنیادی اصول میں شامل کیا جا سکتا ہے۔ پھر ہر کوئی جو اسے استعمال کرتا ہے وہ فوری طور پر نئے تعارف کے بارے میں جان لے گا۔ مثال کے طور پر، اینڈرائیڈ میں لاگ ان کرنے کے لیے لائبریریاں ٹمبر اور لوگی ہیں۔ بنیادی پیکج میں، نان سسٹم کالز کی شناخت کے لیے کوئی اصول نہیں ہیں، اس لیے اگر کوئی پاس ورڈ یا سیشن شناخت کنندہ لاگ میں آتا ہے، تو ہمیں اس کے بارے میں معلوم نہیں ہوگا۔ آئیے چیک مارکس کے قواعد میں ایسے طریقوں کی تعریفیں شامل کرنے کی کوشش کرتے ہیں۔

ٹیسٹ کوڈ کی مثال جو لاگنگ کے لیے ٹمبر لائبریری کا استعمال کرتی ہے:

package com.death.timberdemo;

import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;

import timber.log.Timber;

public class MainActivity extends AppCompatActivity {
    private static final String TAG = MainActivity.class.getSimpleName();

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        Timber.e("Error Message");
        Timber.d("Debug Message");

        Timber.tag("Some Different tag").e("And error message");
    }
}

اور یہاں چیک مارکس کی درخواست کی ایک مثال ہے، جو آپ کو درخواست سے ڈیٹا کے لیے ایک ایگزٹ پوائنٹ کے طور پر ٹمبر کے طریقوں کو کال کرنے کی تعریف شامل کرنے کی اجازت دے گی۔

اینڈرائیڈ آؤٹ پٹ تلاش کریں۔

// Получаем результат выполнения базового правила
result = base.Find_Android_Outputs();

// Дополняем вызовами, которые приходят из библиотеки Timber
CxList timber = All.FindByExactMemberAccess("Timber.*") +
    All.FindByShortName("Timber").GetMembersOfTarget();

// Добавляем к конечному результату
result.Add(timber);

اور آپ پڑوسی اصول میں بھی شامل کر سکتے ہیں، لیکن اس کا تعلق براہ راست اینڈرائیڈ میں لاگ ان کرنے سے ہے:

FindAndroidLog_Outputs

// Получаем результат выполнения базового правила
result = base.Find_Android_Log_Outputs();

// Дополняем вызовами, которые приходят из библиотеки Timber
result.Add(
  All.FindByExactMemberAccess("Timber.*") +
  All.FindByShortName("Timber").GetMembersOfTarget()
);

اس کے علاوہ، اگر اینڈرائیڈ ایپلی کیشنز استعمال کریں۔ ورک مینیجر غیر مطابقت پذیر کام کے لیے، یہ ایک اچھا خیال ہے کہ اس کے بارے میں چیک مارکس کو اضافی طور پر مطلع کریں تاکہ کام سے ڈیٹا حاصل کرنے کا طریقہ شامل کیا جائے۔ getInputData:

FindAndroidRead

// Получаем результат выполнения базового правила
result = base.Find_Android_Read();

// Дополняем вызовом функции getInputData, которая используется в WorkManager
CxList getInputData = All.FindByShortName("getInputData");

// Добавляем к конечному результату
result.Add(getInputData.GetMembersOfTarget());

ٹاسک: iOS پروجیکٹس کے لیے plist میں حساس ڈیٹا کی تلاش

حل: iOS اکثر مختلف متغیرات اور اقدار کو ذخیرہ کرنے کے لیے .plist ایکسٹینشن کے ساتھ خصوصی فائلوں کا استعمال کرتا ہے۔ ان فائلوں میں پاس ورڈز، ٹوکنز، کیز اور دیگر حساس ڈیٹا کو ذخیرہ کرنے کی سفارش نہیں کی جاتی ہے، کیونکہ انہیں بغیر کسی پریشانی کے ڈیوائس سے نکالا جا سکتا ہے۔

پلسٹ فائلوں میں ایسی خصوصیات ہوتی ہیں جو کھلی آنکھوں سے ظاہر نہیں ہوتیں، لیکن چیک مارکس کے لیے اہم ہیں۔ آئیے ایک اصول لکھتے ہیں جو ہمیں مطلوبہ ڈیٹا کو تلاش کرے گا اور ہمیں بتائے گا کہ پاس ورڈ یا ٹوکن کا کہیں ذکر ہے۔

ایسی فائل کی ایک مثال، جس میں بیک اینڈ سروس کے ساتھ مواصلت کا ٹوکن ہوتا ہے:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>DeviceDictionary</key>
	<dict>
		<key>phone</key>
		<string>iPhone 6s</string>
	</dict>
	<key>privatekey</key>
	<string>MIICXAIBAAKBgQCqGKukO1De7zhZj6+</string>
</dict>
</plist>

اور چیک مارکس کے لیے ایک اصول، جس میں کئی باریکیاں ہیں جنہیں لکھتے وقت دھیان میں رکھنا چاہیے:

// Используем результат выполнения правила по поиску файлов plist, чтобы уменьшить время работы правила и 
CxList plist = Find_Plist_Elements();

// Инициализируем новую переменную
CxList dictionarySettings = All.NewCxList();

// Теперь добавим поиск всех интересующих нас значений. В дальнейшем можно расширять этот список.
// Для поиска значений, как ни странно, используется FindByMemberAccess - поиск обращений к методам. Второй параметр внутри функции, false, означает, что поиск нечувствителен к регистру
dictionarySettings.Add(plist.FindByMemberAccess("privatekey", false));
dictionarySettings.Add(plist.FindByMemberAccess("privatetoken", false));

// Для корректного поиска из-за особенностей структуры plist - нужно искать по типу "If statement"
CxList ifStatements = plist.FindByType(typeof(IfStmt));

// Добавляем в результат, перед этим получив родительский узел - для правильного отображения
result = dictionarySettings.FindByFathers(ifStatements);

ٹاسک: XML میں معلومات تلاش کرنا

حل: چیک مارکس میں XML کے ساتھ کام کرنے اور قدروں، ٹیگز، اوصاف وغیرہ کی تلاش کے لیے بہت آسان کام ہیں۔ لیکن، بدقسمتی سے، دستاویزات میں ایک خامی تھی جس کی وجہ سے ایک بھی مثال کام نہیں کرتی۔ اس حقیقت کے باوجود کہ دستاویزات کے تازہ ترین ورژن میں اس خرابی کو ختم کر دیا گیا ہے، اگر آپ دستاویزات کے پرانے ورژن استعمال کرتے ہیں تو محتاط رہیں۔

یہاں دستاویزات سے ایک غلط مثال ہے:

// Код работать не будет
result = All.FindXmlAttributesByNameAndValue("*.app", 8, “id”, "error- section", false, true);

پھانسی کی کوشش کے نتیجے میں، ہمیں ایک غلطی موصول ہوگی جو All ایسا کوئی طریقہ نہیں ہے... اور یہ سچ ہے، کیونکہ XML کے ساتھ کام کرنے کے لیے فنکشنز استعمال کرنے کے لیے ایک خاص، الگ آبجیکٹ کی جگہ ہے - cxXPath. اینڈرائیڈ میں ایسی ترتیب تلاش کرنے کے لیے درست استفسار ایسا لگتا ہے جو HTTP ٹریفک کے استعمال کی اجازت دیتا ہے:

// Правильный вариант с использованием cxXPath
result = cxXPath.FindXmlAttributesByNameAndValue("*.xml", 8, "cleartextTrafficPermitted", "true", false, true);

آئیے اس کو تھوڑی اور تفصیل سے دیکھتے ہیں، چونکہ تمام فنکشنز کا نحو ایک جیسا ہوتا ہے، اس کے بعد آپ ایک کو تلاش کر لیتے ہیں، پھر آپ کو صرف اپنی ضرورت کو منتخب کرنے کی ضرورت ہوتی ہے۔ تو، ترتیب وار پیرامیٹرز کے مطابق:

  • "*.xml"- تلاش کی جانی والی فائلوں کا ماسک

  • 8 - اس زبان کی شناخت جس کے لیے اصول لاگو کیا گیا ہے۔

  • "cleartextTrafficPermitted"xML میں انتساب کا نام

  • "true" - اس وصف کی قدر

  • false - تلاش کرتے وقت باقاعدہ اظہار کا استعمال

  • true - کا مطلب ہے کہ تلاش کیس کو نظر انداز کرتے ہوئے کی جائے گی، یعنی کیس غیر حساس

مثال کے طور پر، ہم نے ایک قاعدہ استعمال کیا جو غلط کی شناخت کرتا ہے، حفاظتی نقطہ نظر سے، Android میں نیٹ ورک کنکشن کی ترتیبات جو HTTP پروٹوکول کے ذریعے سرور کے ساتھ مواصلت کی اجازت دیتی ہیں۔ ایک خصوصیت پر مشتمل ترتیب کی مثال cleartextTrafficPermitted معنی کے ساتھ true:

<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <trust-anchors>
            <certificates src="@raw/my_ca"/>
        </trust-anchors>
        <domain-config cleartextTrafficPermitted="true">
            <domain includeSubdomains="true">secure.example.com</domain>
        </domain-config>
    </domain-config>
</network-security-config>

ٹاسک: فائل کے نام/پاتھ سے نتائج کو محدود کریں۔

حل: اینڈرائیڈ کے لیے موبائل ایپلیکیشن کی ترقی سے متعلق بڑے پروجیکٹس میں سے ایک میں، ہمیں اس اصول کے غلط مثبتات کا سامنا کرنا پڑا جو مبہم ترتیب کا تعین کرتا ہے۔ حقیقت یہ ہے کہ رول آؤٹ آف دی باکس فائل میں تلاش کرتا ہے۔ build.gradle ایپلیکیشن کے ریلیز ورژن کے لیے مبہم قوانین کو لاگو کرنے کے لیے ذمہ دار ترتیب۔

لیکن بڑے منصوبوں میں بعض اوقات چائلڈ فائلیں ہوتی ہیں۔ build.gradle، جو پروجیکٹ میں شامل لائبریریوں کا حوالہ دیتے ہیں۔ خاص بات یہ ہے کہ یہاں تک کہ اگر یہ فائلیں مبہم ہونے کی ضرورت کی نشاندہی نہیں کرتی ہیں، تب بھی پیرنٹ اسمبلی فائل کی سیٹنگز کو تالیف کے دوران لاگو کیا جائے گا۔

اس طرح، کام بچوں کی فائلوں میں محرکات کو کاٹنا ہے جو لائبریریوں سے تعلق رکھتے ہیں۔ ان کی شناخت لائن کی موجودگی سے کی جا سکتی ہے۔ apply 'com.android.library'.

فائل سے کوڈ کی مثال build.gradle، جو مبہم ہونے کی ضرورت کا تعین کرتا ہے:

apply plugin: 'com.android.application'

android {
    compileSdkVersion 24
    buildToolsVersion "24.0.2"
    defaultConfig {
        ...
    }

    buildTypes {
        release {
            minifyEnabled true
            ...
        }
    }
}

dependencies {
  ...
}

فائل کی مثال build.gradle پروجیکٹ میں شامل لائبریری کے لیے جس میں یہ ترتیب نہیں ہے:

apply plugin: 'android-library'

dependencies {
  compile 'com.android.support:support-v4:18.0.+'
}

android {
  compileSdkVersion 14
  buildToolsVersion '17.0.0'
  ...
}

اور چیک مارکس کے لیے اصول:

ProGuardObfuscationNotInUse

// Поиск метода release среди всех методов в Gradle файлах
CxList releaseMethod = Find_Gradle_Method("release");

// Все объекты из файлов build.gradle
CxList gradleBuildObjects = Find_Gradle_Build_Objects();

// Поиск того, что находится внутри метода "release" среди всех объектов из файлов build.gradle
CxList methodInvokesUnderRelease = gradleBuildObjects.FindByType(typeof(MethodInvokeExpr)).GetByAncs(releaseMethod);

// Ищем внутри gradle-файлов строку "com.android.library" - это значит, что данный файл относится к библиотеке и его необходимо исключить из правила
CxList android_library = gradleBuildObjects.FindByName("com.android.library");

// Инициализация пустого массива
List<string> libraries_path = new List<string> {};

// Проходим через все найденные "дочерние" файлы
foreach(CxList library in android_library)
{
    // Получаем путь к каждому файлу
	string file_name_library = library.GetFirstGraph().LinePragma.FileName;
    
    // Добавляем его в наш массив
	libraries_path.Add(file_name_library);
}

// Ищем все вызовы включения обфускации в релизных настройках
CxList minifyEnabled = methodInvokesUnderRelease.FindByShortName("minifyEnabled");

// Получаем параметры этих вызовов
CxList minifyValue = gradleBuildObjects.GetParameters(minifyEnabled, 0);

// Ищем среди них включенные
CxList minifyValueTrue = minifyValue.FindByShortName("true");

// Немного магии, если не нашли стандартным способом :D
if (minifyValueTrue.Count == 0) {
	minifyValue = minifyValue.FindByAbstractValue(abstractValue => abstractValue is TrueAbstractValue);
} else {
    // А если всё-таки нашли, то предыдущий результат и оставляем
	minifyValue = minifyValueTrue;	
}

// Если не нашлось таких методов
if (minifyValue.Count == 0)
{
    // Для более корректного отображения места срабатывания в файле ищем или buildTypes или android
	CxList tempResult = All.NewCxList();
	CxList buildTypes = Find_Gradle_Method("buildTypes");
	if (buildTypes.Count > 0) {
		tempResult = buildTypes;
	} else {
		tempResult = Find_Gradle_Method("android");
	}
	
	// Для каждого из найденных мест срабатывания проходим и определяем, дочерний или основной файлы сборки
	foreach(CxList res in tempResult)
	{
        // Определяем, в каком файле был найден buildType или android методы
		string file_name_result = res.GetFirstGraph().LinePragma.FileName;
        
        // Если такого файла нет в нашем списке "дочерних" файлов - значит это основной файл и его можно добавить в результат
		if (libraries_path.Contains(file_name_result) == false){
			result.Add(res);
		}
	}
}

یہ نقطہ نظر نہ صرف اینڈرائیڈ ایپلی کیشنز کے لیے کافی آفاقی اور مفید ہو سکتا ہے، بلکہ دیگر معاملات کے لیے بھی جب آپ کو یہ تعین کرنے کی ضرورت ہو کہ آیا نتیجہ کسی مخصوص فائل سے تعلق رکھتا ہے۔

ٹاسک: اگر نحو مکمل طور پر تعاون یافتہ نہیں ہے تو فریق ثالث لائبریری کے لیے تعاون شامل کریں۔

حل: کوڈ لکھنے کے عمل میں استعمال ہونے والے مختلف فریم ورکس کی تعداد صرف چارٹ سے دور ہے۔ بلاشبہ، چیک مارکس ہمیشہ ان کے وجود کے بارے میں نہیں جانتا، اور ہمارا کام اسے یہ سمجھنا سکھانا ہے کہ کچھ طریقے خاص طور پر اس فریم ورک سے تعلق رکھتے ہیں۔ بعض اوقات یہ اس حقیقت سے پیچیدہ ہوتا ہے کہ فریم ورک فنکشن کے نام استعمال کرتے ہیں جو بہت عام ہیں اور کسی خاص لائبریری سے کسی خاص کال کے تعلق کا واضح طور پر تعین کرنا ناممکن ہے۔

مشکل یہ ہے کہ ایسی لائبریریوں کے نحو کو ہمیشہ درست طریقے سے نہیں پہچانا جاتا اور آپ کو غلط مثبتات کی ایک بڑی تعداد حاصل کرنے سے بچنے کے لیے تجربہ کرنا پڑتا ہے۔ اسکیننگ کی درستگی کو بہتر بنانے اور مسئلے کو حل کرنے کے لیے کئی اختیارات ہیں:

  • پہلا آپشن، ہم یقینی طور پر جانتے ہیں کہ لائبریری ایک مخصوص پروجیکٹ میں استعمال ہوتی ہے اور ٹیم کی سطح پر اس اصول کو لاگو کر سکتی ہے۔ لیکن اگر ٹیم ایک مختلف نقطہ نظر اختیار کرنے کا فیصلہ کرتی ہے یا متعدد لائبریریوں کا استعمال کرتی ہے جس میں فنکشن کے نام اوورلیپ ہوتے ہیں، تو ہم متعدد غلط مثبتات کی ایک بہت ہی خوشگوار تصویر حاصل کر سکتے ہیں۔

  • دوسرا آپشن ان فائلوں کو تلاش کرنا ہے جس میں لائبریری واضح طور پر درآمد کی گئی ہو۔ اس نقطہ نظر کے ساتھ، ہم اس بات کا یقین کر سکتے ہیں کہ ہمیں جس لائبریری کی ضرورت ہے اس فائل میں بالکل استعمال کی گئی ہے۔

  • اور تیسرا آپشن یہ ہے کہ مذکورہ بالا دونوں طریقوں کو ایک ساتھ استعمال کیا جائے۔

مثال کے طور پر، آئیے ایک لائبریری کو دیکھتے ہیں جو تنگ دائروں میں مشہور ہے۔ سست اسکیلا پروگرامنگ زبان کے لیے، یعنی فعالیت لغوی اقدار کو الگ کرنا. عام طور پر، کسی SQL استفسار پر پیرامیٹرز منتقل کرنے کے لیے، آپ کو آپریٹر کا استعمال کرنا چاہیے۔ $، جو ڈیٹا کو پہلے سے بنائے گئے SQL استفسار میں بدل دیتا ہے۔ یعنی درحقیقت یہ جاوا میں تیار شدہ بیان کا براہ راست اینالاگ ہے۔ لیکن، اگر آپ کو متحرک طور پر ایک SQL استفسار بنانے کی ضرورت ہے، مثال کے طور پر، اگر آپ کو ٹیبل کے نام پاس کرنے کی ضرورت ہے، تو آپ آپریٹر استعمال کر سکتے ہیں #$، جو ڈیٹا کو براہ راست استفسار میں بدل دے گا (تقریبا سٹرنگ کنکٹنیشن کی طرح)۔

نمونہ کوڈ:

// В общем случае - значения, контролируемые пользователем
val table = "coffees"
sql"select * from #$table where name = $name".as[Coffee].headOption

چیک مارکس ابھی تک یہ نہیں جانتا ہے کہ اسپلسنگ لٹریل ویلیوز اور اسکپس آپریٹرز کے استعمال کا کیسے پتہ لگایا جائے #$، تو آئیے اسے ممکنہ SQL انجیکشن کی شناخت کرنے اور کوڈ میں صحیح جگہوں کو نمایاں کرنے کے لیے سکھانے کی کوشش کریں:

// Находим все импорты
CxList imports = All.FindByType(typeof(Import));

// Ищем по имени, есть ли в импортах slick
CxList slick = imports.FindByShortName("slick");

// Некоторый флаг, определяющий, что импорт библиотеки в коде присутствует
// Для более точного определения - можно применить подход с именем файла
bool not_empty_list = false;
foreach (CxList r in slick)
{
    // Если встретили импорт, считаем, что slick используется
	not_empty_list = true;
}

if (not_empty_list) {
    // Ищем вызовы, в которые передается SQL-строка
	CxList sql = All.FindByShortName("sql");
	sql.Add(All.FindByShortName("sqlu"));
	
	// Определяем данные, которые попадают в эти вызовы
	CxList data_sql = All.DataInfluencingOn(sql);
	
	// Так как синтакис не поддерживается, можно применить подход с регулярными выражениями
	// RegExp стоит использовать крайне осторожно и не применять его на большом количестве данных, так как это может сильно повлиять на производительность
	CxList find_possible_inj = data_sql.FindByRegex(@"#$", true, true, true);

    // Избавляемся от лишних срабатываний, если они есть и выводим в результат
	result = find_possible_inj.FindByType(typeof(BinaryExpr));
}

ٹاسک: اوپن سورس لائبریریوں میں استعمال شدہ کمزور فنکشنز تلاش کریں۔

حل: بہت سی کمپنیاں ترقی یافتہ ایپلی کیشنز میں لائبریریوں کے کمزور ورژن کے استعمال کا پتہ لگانے کے لیے اوپن سورس مانیٹرنگ ٹولز (OSA پریکٹس) کا استعمال کرتی ہیں۔ بعض اوقات ایسی لائبریری کو محفوظ ورژن میں اپ ڈیٹ کرنا ممکن نہیں ہوتا۔ کچھ معاملات میں فعال حدود ہیں، دوسروں میں کوئی محفوظ ورژن نہیں ہے۔ اس صورت میں، SAST اور OSA طریقوں کا مجموعہ اس بات کا تعین کرنے میں مدد کرے گا کہ وہ افعال جو کمزوری کے استحصال کا باعث بنتے ہیں کوڈ میں استعمال نہیں کیے گئے ہیں۔

لیکن بعض اوقات، خاص طور پر جاوا اسکرپٹ پر غور کرتے وقت، یہ مکمل طور پر معمولی کام نہیں ہوسکتا ہے۔ ذیل میں ایک حل ہے، شاید مثالی نہیں، لیکن اس کے باوجود جزو میں کمزوریوں کی مثال استعمال کرتے ہوئے کام کر رہا ہے lodash طریقوں میں template и *set.

جے ایس فائل میں ممکنہ طور پر کمزور کوڈ کی جانچ کی مثالیں:

/**
 * Template example
 */

'use strict';
var _ = require("./node_modules/lodash.js");


// Use the "interpolate" delimiter to create a compiled template.
var compiled = _.template('hello <%= js %>!');
console.log(compiled({ 'js': 'lodash' }));
// => 'hello lodash!'

// Use the internal `print` function in "evaluate" delimiters.

var compiled = _.template('<% print("hello " + js); %>!');
console.log(compiled({ 'js': 'lodash' }));
// => 'hello lodash!'

اور جب براہ راست html میں جڑتے ہیں:

<!DOCTYPE html>
<html>
<head>
    <title>Lodash Tutorial</title>
    <script src="./node_modules/lodash.js"></script>
    <script type="text/javascript">
  // Lodash chunking array
        nums = [1, 2, 3, 4, 5, 6, 7, 8, 9];

        let c1 = _.template('<% print("hello " + js); %>!');
        console.log(c1);

        let c2 = _.template('<% print("hello " + js); %>!');
        console.log(c2);
    </script>
</head>
<body></body>
</html>

ہم اپنے تمام کمزور طریقوں کی تلاش کر رہے ہیں، جو خطرات میں درج ہیں:

// Ищем все строки: в которых встречается строка lodash (предполагаем, что это объявление импорта библиотеки
CxList lodash_strings = Find_String_Literal().FindByShortName("*lodash*");

// Ищем все данные: которые взаимодействуют с этими строками
CxList data_on_lodash = All.InfluencedBy(lodash_strings);


// Задаем список уязвимых методов
List<string> vulnerable_methods = new List<string> {"template", "*set"};

// Ищем все наши уязвимые методы, которые перечисленны в уязвимостях и отфильтровываем их только там, где они вызывались
CxList vulnerableMethods = All.FindByShortNames(vulnerable_methods).FindByType(typeof(MethodInvokeExpr));

//Находим все данные: которые взаимодействуют с данными методами
CxList vulnFlow = All.InfluencedBy(vulnerableMethods);

// Если есть пересечение по этим данным - кладем в результат
result = vulnFlow * data_on_lodash;

// Формируем список путей по которым мы уже прошли, чтобы фильтровать в дальнейшем дубли
List<string> lodash_result_path = new List<string> {};

foreach(CxList lodash_result in result)
{
    // Очередной раз получаем пути к файлам
	string file_name = lodash_result.GetFirstGraph().LinePragma.FileName;
	lodash_result_path.Add(file_name);
}

// Дальше идет часть относящаяся к html файлам, так как в них мы не можем проследить откуда именно идет вызов
// Формируем массив путей файлов, чтобы быть уверенными, что срабатывания уязвимых методов были именно в тех файлах, в которых объявлен lodash
List<string> lodash_path = new List<string> {};
foreach(CxList string_lodash in lodash_strings)
{
	string file_name = string_lodash.GetFirstGraph().LinePragma.FileName;
	lodash_path.Add(file_name);
}

// Перебираем все уязвимые методы и убеждаемся, что они вызваны в тех же файлах, что и объявление/включение lodash
foreach(CxList method in vulnerableMethods)
{
	string file_name_method = method.GetFirstGraph().LinePragma.FileName;
	if (lodash_path.Contains(file_name_method) == true && lodash_result_path.Contains(file_name_method) == false){
		result.Add(method);
	}
}

// Убираем все UknownReferences и оставляем самый "длинный" из путей, если такие встречаются
result = result.ReduceFlow(CxList.ReduceFlowType.ReduceSmallFlow) - result.FindByType(typeof(UnknownReference));

ٹاسک: درخواست میں سرایت شدہ سرٹیفکیٹس کی تلاش

حل: ایپلیکیشنز، خاص طور پر موبائل کے لیے، مختلف سرورز تک رسائی حاصل کرنے یا SSL-Pinning کی تصدیق کے لیے سرٹیفکیٹ یا کیز استعمال کرنا کوئی معمولی بات نہیں ہے۔ حفاظتی نقطہ نظر سے، ایسی چیزوں کو کوڈ میں محفوظ کرنا بہترین عمل نہیں ہے۔ آئیے ایک اصول لکھنے کی کوشش کرتے ہیں جو مخزن میں اسی طرح کی فائلوں کو تلاش کرے گا:

// Найдем все сертификаты по маске файла
CxList find_certs = All.FindByShortNames(new List<string> {"*.der", "*.cer", "*.pem", "*.key"}, false);

// Проверим, где в приложении они используются
CxList data_used_certs = All.DataInfluencedBy(find_certs);

// И для мобильных приложений - можем поискать методы, где вызывается чтение сертификатов
// Для других платформ и приложений могут быть различные методы
CxList methods = All.FindByMemberAccess("*.getAssets");

// Пересечение множеств даст нам результат по использованию локальных сертификатов в приложении
result = methods * data_used_certs;

ٹاسک: درخواست میں سمجھوتہ شدہ ٹوکن تلاش کرنا

حل: سمجھوتہ شدہ ٹوکنز یا کوڈ میں موجود دیگر اہم معلومات کو منسوخ کرنا اکثر ضروری ہوتا ہے۔ بلاشبہ، انہیں سورس کوڈ کے اندر ذخیرہ کرنا اچھا خیال نہیں ہے، لیکن حالات مختلف ہوتے ہیں۔ CxQL سوالات کا شکریہ، اس طرح کی چیزیں تلاش کرنا کافی آسان ہے:

// Получаем все строки, которые содержатся в коде
CxList strings = base.Find_Strings();

// Ищем среди всех строк нужное нам значение. В примере токен в виде строки "qwerty12345"
result = strings.FindByShortName("qwerty12345");

حاصل يہ ہوا

مجھے امید ہے کہ یہ مضمون ان لوگوں کے لیے کارآمد ثابت ہو گا جو چیک مارکس ٹول سے اپنی واقفیت شروع کر رہے ہیں۔ شاید وہ لوگ جو ایک طویل عرصے سے اپنے اصول لکھ رہے ہیں انہیں بھی اس گائیڈ میں کچھ مفید معلوم ہوگا۔

بدقسمتی سے، فی الحال ایسے وسائل کی کمی ہے جہاں چیک مارکس کے قوانین کی ترقی کے دوران نئے خیالات کو اکٹھا کیا جا سکے۔ اسی لیے ہم نے پیدا کیا۔ Github پر ذخیرہ، جہاں ہم اپنا کام پوسٹ کریں گے تاکہ ہر وہ شخص جو CxQL استعمال کرتا ہے اس میں کچھ مفید تلاش کر سکے، اور اسے کمیونٹی کے ساتھ اپنا کام شیئر کرنے کا موقع بھی ملے۔ ذخیرہ مواد کو بھرنے اور تشکیل دینے کے عمل میں ہے، لہذا تعاون کرنے والوں کا استقبال ہے!

آپ کا شکریہ!

ماخذ: www.habr.com

نیا تبصرہ شامل کریں