როგორ დავწეროთ წესები Checkmarx-ისთვის გაგიჟების გარეშე

ჰეი ჰაბრ!

ჩვენს საქმიანობაში, ჩვენი კომპანია ძალიან ხშირად ეხება სხვადასხვა სტატიკური კოდის ანალიზის ხელსაწყოებს (SAST). ყუთიდან ისინი ყველა საშუალოდ მუშაობენ. რა თქმა უნდა, ეს ყველაფერი დამოკიდებულია პროექტზე და მასში გამოყენებულ ტექნოლოგიებზე, ასევე რამდენად კარგად არის დაფარული ეს ტექნოლოგიები ანალიზის წესებით. ჩემი აზრით, ერთ-ერთი ყველაზე მნიშვნელოვანი კრიტერიუმი SAST ინსტრუმენტის არჩევისას არის თქვენი აპლიკაციების სპეციფიკაზე მისი მორგების შესაძლებლობა, კერძოდ, ჩაწეროთ და შეცვალოთ ანალიზის წესები ან, როგორც მათ უფრო ხშირად უწოდებენ, Custom Queries.

ჩვენ ყველაზე ხშირად ვიყენებთ Checkmarx - ძალიან საინტერესო და მძლავრი კოდის ანალიზატორს. ამ სტატიაში მე ვისაუბრებ მასზე ანალიზის წესების დაწერის ჩემს გამოცდილებაზე.

სარჩევი

• Entry

• ზოგადი ინფორმაცია წესების შესახებ

• "ლექსიკონი" დამწყებთათვის

  • ოპერაციები სიებით

  • ყველა ნაპოვნი ნივთი

  • ფუნქციები ნაკადის ანალიზისთვის

  • ფაილის სახელის/გზის მიღება

  • შესრულების შედეგი

  • სხვა წესების შედეგების გამოყენება

• პრობლემების მოგვარება

  • ხე-ტყე

  • შესვლის პრობლემა

• წერის წესები

• დასკვნა

Entry

დასაწყისისთვის, მინდა გირჩიოთ რამდენიმე სტატიიდან ერთ-ერთი რუსულ ენაზე Checkmarx-ისთვის მოთხოვნების დაწერის მახასიათებლების შესახებ. იგი გამოქვეყნდა Habré-ზე 2019 წლის ბოლოს სათაურით: "გამარჯობა, Checkmarx!" როგორ დავწეროთ Checkmarx SAST მოთხოვნა და იპოვოთ მაგარი დაუცველობა.

იგი დეტალურად განიხილავს, თუ როგორ უნდა დაწეროთ პირველი მოთხოვნები CxQL-ში (Checkmarx Query Language) ზოგიერთი ტესტის აპლიკაციისთვის და აჩვენებს ანალიზის წესების მუშაობის ძირითად პრინციპებს.

არ გავიმეორებ, რაც მასშია აღწერილი, თუმცა ზოგიერთი კვეთა მაინც იქნება. ჩემს სტატიაში შევეცდები შევადგინო ერთგვარი „რეცეპტების კრებული“, იმ კონკრეტული პრობლემების გადაჭრის ჩამონათვალი, რომლებიც შემხვდა Checkmarx-თან მუშაობის დროს. მე მომიწია ჭკუის შეკავება ამ მრავალი პრობლემის გამო. ხანდახან დოკუმენტაციაში არ იყო საკმარისი ინფორმაცია და ზოგჯერ ძნელი იყო იმის გაგება, თუ როგორ უნდა გაეკეთებინა ის, რაც იყო საჭირო. ვიმედოვნებ, რომ ჩემი გამოცდილება და უძილო ღამეები არ იქნება უშედეგო და ეს "მომხმარებლური შეკითხვის რეცეპტების კოლექცია" დაზოგავს თქვენ რამდენიმე საათს ან რამდენიმე ნერვულ უჯრედს. მაშ ასე, დავიწყოთ!

ზოგადი ინფორმაცია წესების შესახებ

პირველ რიგში, მოდით გადავხედოთ რამდენიმე ძირითად კონცეფციას და წესებთან მუშაობის პროცესს, რათა უკეთ გავიგოთ რა მოხდება შემდეგ. და ასევე იმის გამო, რომ დოკუმენტაცია არაფერს ამბობს ამის შესახებ ან ძალიან გავრცელებულია სტრუქტურაში, რაც არც თუ ისე მოსახერხებელია.

1. წესები გამოიყენება სკანირების დროს, დაწყებისას არჩეული წინასწარ დაყენების მიხედვით (აქტიური წესების ნაკრები). თქვენ შეგიძლიათ შექმნათ წინასწარ დაყენების შეუზღუდავი რაოდენობა, და ზუსტად როგორ ააწყოთ ისინი, დამოკიდებულია თქვენი პროცესის სპეციფიკაზე. თქვენ შეგიძლიათ დააჯგუფოთ ისინი ენის მიხედვით ან აირჩიოთ წინასწარ დაყენებული თითოეული პროექტისთვის. აქტიური წესების რაოდენობა გავლენას ახდენს სკანირების სიჩქარეზე და სიზუსტეზე.

   Preset-ის დაყენება Checkmarx-ის ინტერფეისში

2. წესები რედაქტირებულია სპეციალურ ინსტრუმენტში, სახელწოდებით CxAuditor. ეს არის დესკტოპის პროგრამა, რომელიც უკავშირდება სერვერს, რომელიც მუშაობს Checkmarx-ზე. ამ ხელსაწყოს აქვს მუშაობის ორი რეჟიმი: წესების რედაქტირება და უკვე შესრულებული სკანირების შედეგების ანალიზი.

   CxAudit ინტერფეისი

3. Checkmarx-ის წესები დაყოფილია ენის მიხედვით, ანუ თითოეულ ენას აქვს მოთხოვნების საკუთარი ნაკრები. ასევე არსებობს ზოგადი წესები, რომლებიც გამოიყენება ენის მიუხედავად, ეს არის ეგრეთ წოდებული ძირითადი მოთხოვნები. უმეტესწილად, ძირითადი მოთხოვნები მოიცავს ინფორმაციის ძიებას, რომელსაც სხვა წესები იყენებს.

   წესების დაყოფა ენის მიხედვით

4. წესები არის „შესასრულებელი“ და „არაშესასრულებელი“ (შესრულებულია და არ არის შესრულებული). არც ისე სწორი სახელია, ჩემი აზრით, მაგრამ ეს ასეა. დასკვნა ის არის, რომ "შესასრულებელი" წესების შესრულების შედეგი გამოჩნდება სკანირების შედეგებში UI-ში, ხოლო "არაშემსრულებელი" წესები საჭიროა მხოლოდ მათი შედეგების სხვა მოთხოვნებში გამოსაყენებლად (არსებითად, მხოლოდ ფუნქცია).

   წესის ტიპის განსაზღვრა შექმნისას

5. თქვენ შეგიძლიათ შექმნათ ახალი წესები ან შეავსოთ/გადაწეროთ არსებული. წესის გადასაწერად, თქვენ უნდა იპოვოთ ის ხეში, დააწკაპუნეთ მაუსის მარჯვენა ღილაკით და ჩამოსაშლელი მენიუდან აირჩიეთ “Override”. აქ მნიშვნელოვანია გვახსოვდეს, რომ ახალი წესები თავიდანვე არ შედის წინასწარ დაყენებულ და არ არის აქტიური. მათი გამოყენების დასაწყებად, თქვენ უნდა გაააქტიუროთ ისინი ინსტრუმენტში "Preset Manager" მენიუში. ხელახლა დაწერილი წესები ინარჩუნებს თავის პარამეტრებს, ანუ თუ წესი აქტიური იყო, ის ასე დარჩება და დაუყოვნებლივ გამოიყენებს.

   ახალი წესის მაგალითი Preset Manager ინტერფეისში

6. შესრულების დროს შენდება მოთხოვნების „ხე“, რაც დამოკიდებულია იმაზე, თუ რა. წესები, რომლებიც აგროვებს ინფორმაციას, შესრულებულია ჯერ, ხოლო ვინც იყენებს მას. შესრულების შედეგი ქეშირებულია, ასე რომ, თუ შესაძლებელია არსებული წესის შედეგების გამოყენება, მაშინ უმჯობესია ამის გაკეთება, ეს შეამცირებს სკანირების დროს.

7. წესები შეიძლება გამოყენებულ იქნას სხვადასხვა დონეზე:

• მთელი სისტემისთვის - გამოყენებული იქნება ნებისმიერი პროექტის სკანირებისთვის

• გუნდის დონეზე (Team) - გამოყენებული იქნება მხოლოდ შერჩეულ გუნდში პროექტების სკანირებისთვის.

• პროექტის დონეზე - გამოყენებული იქნება კონკრეტულ პროექტში

  იმის განსაზღვრა, თუ რა დონეზე იქნება გამოყენებული წესი

"ლექსიკონი" დამწყებთათვის

და დავიწყებ რამდენიმე რამით, რამაც გამოიწვია კითხვები და ასევე გაჩვენებთ უამრავ ტექნიკას, რომელიც მნიშვნელოვნად გაამარტივებს ცხოვრებას.

ოპერაციები სიებით

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

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

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

ყველა ნაპოვნი ნივთი

დასკანირებულ ენაში შეგიძლიათ მიიღოთ აბსოლუტურად ყველა ელემენტის სია, რომლებიც Checkmarx-მა ამოიცნო (სტრიქონები, ფუნქციები, კლასები, მეთოდები და ა.შ.). ეს არის ობიექტების გარკვეული სივრცე, რომლის საშუალებითაც შესაძლებელია წვდომა All. ანუ კონკრეტული სახელის მქონე ობიექტის ძიება searchMe, შეგიძლიათ მოძებნოთ, მაგალითად, სახელით ყველა ნაპოვნი ობიექტში:

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

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

მაგრამ, თუ გჭირდებათ სხვა ენაზე ძიება, რომელიც რაიმე მიზეზით არ იყო ჩართული სკანირებაში (მაგალითად, groovy Android პროექტში), შეგიძლიათ გააფართოვოთ ჩვენი ობიექტის სივრცე ცვლადის საშუალებით:

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");

სხვა წესების შედეგების გამოყენება

Checkmarx-ის წესებს შეიძლება ეწოდოს ფუნქციების ანალოგი ჩვეულებრივ პროგრამირების ენაზე. წესების დაწერისას, შეგიძლიათ გამოიყენოთ სხვა მოთხოვნების შედეგები. მაგალითად, არ არის საჭირო ყოველ ჯერზე ყველა მეთოდის ზარის ძიება კოდში, უბრალოდ გამოიძახეთ სასურველი წესი:

// Получаем результат выполнения другого правила
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 ინსტრუმენტზე (რომელიც გამოიყენება წესების დასაწერად). ამის მრავალი მიზეზი შეიძლება იყოს, მათ შორის ავარია, უეცარი Windows განახლებები, BSOD და სხვა გაუთვალისწინებელი სიტუაციები, რომლებიც ჩვენს კონტროლს სცილდება. ამ შემთხვევაში, ზოგჯერ მონაცემთა ბაზაში არის დაუმთავრებელი სესია, რაც ხელს უშლის ხელახლა შესვლას. გამოსასწორებლად, თქვენ უნდა შეასრულოთ რამდენიმე შეკითხვა:

Checkmarx-ისთვის 8.6-მდე:

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

Checkmarx-ისთვის 8.6-ის შემდეგ:

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

წერის წესები

ახლა ჩვენ მივდივართ ყველაზე საინტერესო ნაწილზე. როდესაც იწყებთ წესების წერას CxQL-ში, ის, რაც ხშირად გაკლიათ, არის არა იმდენად დოკუმენტაცია, როგორც ზოგიერთი პრობლემის გადაჭრის ცოცხალი მაგალითი და ზოგადად შეკითხვის ოპერაციის პროცესის აღწერა.

ვეცდები ცოტათი გავუადვილო ცხოვრება მათთვის, ვინც იწყებს შეკითხვის ენაში ჩაძირვას და მოვიყვან რამდენიმე მაგალითი Custom Queries-ის გამოყენებისას გარკვეული პრობლემების გადასაჭრელად. ზოგიერთი მათგანი საკმაოდ ზოგადია და შეიძლება გამოყენებულ იქნას თქვენს კომპანიაში პრაქტიკულად ცვლილებების გარეშე, სხვები უფრო სპეციფიკურია, მაგრამ მათი გამოყენება ასევე შესაძლებელია თქვენი აპლიკაციის სპეციფიკის შესაბამისად კოდის შეცვლით.

ასე რომ, აქ არის ის პრობლემები, რომლებსაც ყველაზე ხშირად ვაწყდებით:

Დავალება: წესების შესრულების შედეგებში არის რამდენიმე ნაკადი და ერთი მათგანი მეორის ბუდეა, თქვენ უნდა დატოვოთ ერთი მათგანი.

გამოსავალი: მართლაც, ზოგჯერ Checkmarx აჩვენებს რამდენიმე მონაცემთა ნაკადს, რომლებიც შეიძლება გადახურდეს და იყოს სხვათა შემოკლებული ვერსია. ასეთი შემთხვევებისთვის არსებობს სპეციალური მეთოდი ReduceFlow. პარამეტრიდან გამომდინარე, ის შეარჩევს უმოკლეს ან გრძელ ნაკადს:

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

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

Დავალება: გააფართოვეთ მგრძნობიარე მონაცემების სია, რომლებზეც ინსტრუმენტი რეაგირებს

გამოსავალი: Checkmarx-ს აქვს ძირითადი წესები, რომელთა შედეგებს იყენებენ მრავალი სხვა მოთხოვნა. ამ წესებიდან ზოგიერთი თქვენი აპლიკაციისთვის დამახასიათებელი მონაცემების დამატებით, შეგიძლიათ დაუყოვნებლივ გააუმჯობესოთ თქვენი სკანირების შედეგები. ქვემოთ მოცემულია წესის მაგალითი დასაწყებად:

ზოგადი_კონფიდენციალურობის_დარღვევის_სიტი

მოდით დავამატოთ რამდენიმე ცვლადი, რომლებიც გამოიყენება ჩვენს აპლიკაციაში მგრძნობიარე ინფორმაციის შესანახად:

// Получаем результат выполнения базового правила
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);
	}
}

Დავალება: დაამატეთ გამოყენებული ჩარჩოები, რომლებიც არ არის მხარდაჭერილი Checkmarx-ის მიერ

გამოსავალი: Checkmarx-ში ყველა მოთხოვნა დაყოფილია ენის მიხედვით, ასე რომ თქვენ უნდა დაამატოთ წესები თითოეული ენისთვის. ქვემოთ მოცემულია ასეთი წესების რამდენიმე მაგალითი.

თუ გამოიყენება ბიბლიოთეკები, რომლებიც ავსებენ ან ცვლიან სტანდარტულ ფუნქციონირებას, ისინი ადვილად შეიძლება დაემატოს ძირითად წესს. შემდეგ ყველა, ვინც მას იყენებს, დაუყოვნებლივ გაიგებს ახალ შესავალს. მაგალითად, Android-ში შესვლის ბიბლიოთეკები არის Timber და Loggi. ძირითად პაკეტში არ არსებობს წესები არასისტემური ზარების იდენტიფიკაციისთვის, ასე რომ, თუ პაროლი ან სესიის იდენტიფიკატორი მოხვდება ჟურნალში, ჩვენ ამის შესახებ არ ვიცით. შევეცადოთ დავამატოთ ასეთი მეთოდების განმარტებები Checkmarx-ის წესებს.

სატესტო კოდის მაგალითი, რომელიც იყენებს ტიმბერ ბიბლიოთეკას შესვლისთვის:

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");
    }
}

და აქ არის Checkmarx-ის მოთხოვნის მაგალითი, რომელიც საშუალებას მოგცემთ დაამატოთ Timber მეთოდების გამოძახების განმარტება, როგორც აპლიკაციიდან მონაცემების გასასვლელი:

FindAndroidOutputs

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

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

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

თქვენ ასევე შეგიძლიათ დაამატოთ მეზობელი წესი, მაგრამ ეს პირდაპირ ეხება Android-ში შესვლას:

FindAndroidLog_Outputs

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

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

ასევე, თუ Android აპლიკაციები იყენებენ სამუშაო მენეჯერი ასინქრონული მუშაობისთვის კარგი იდეაა დამატებით აცნობოთ Checkmarx-ს დავალებიდან მონაცემების მიღების მეთოდის დამატებით getInputData:

FindAndroidRead

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

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

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

Დავალება: სენსიტიური მონაცემების ძიება plist-ში iOS პროექტებისთვის

გამოსავალი: iOS ხშირად იყენებს სპეციალურ ფაილებს .plist გაფართოებით სხვადასხვა ცვლადების და მნიშვნელობების შესანახად. ამ ფაილებში პაროლების, ჟეტონების, გასაღებების და სხვა მგრძნობიარე მონაცემების შენახვა არ არის რეკომენდებული, რადგან მათი ამოღება შესაძლებელია მოწყობილობიდან უპრობლემოდ.

Plist ფაილებს აქვთ ფუნქციები, რომლებიც შეუიარაღებელი თვალით არ ჩანს, მაგრამ მნიშვნელოვანია Checkmarx-ისთვის. დავწეროთ წესი, რომელიც მოიძიებს ჩვენთვის საჭირო მონაცემებს და გვეტყვის არის თუ არა სადმე ნახსენები პაროლები ან ჟეტონები.

ასეთი ფაილის მაგალითი, რომელიც შეიცავს backend სერვისთან კომუნიკაციის ნიშანს:

<?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>

და Checkmarx-ის წესი, რომელსაც აქვს რამდენიმე ნიუანსი, რომელიც უნდა იქნას გათვალისწინებული წერისას:

// Используем результат выполнения правила по поиску файлов 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-ში

გამოსავალი: Checkmarx-ს აქვს ძალიან მოსახერხებელი ფუნქციები XML-თან მუშაობისთვის და მნიშვნელობების, ტეგების, ატრიბუტებისა და სხვათა საძიებლად. მაგრამ, სამწუხაროდ, დოკუმენტაციაში იყო შეცდომა, რის გამოც არც ერთი მაგალითი არ მუშაობს. მიუხედავად იმისა, რომ ეს ხარვეზი აღმოფხვრილია დოკუმენტაციის უახლეს ვერსიაში, ფრთხილად იყავით, თუ იყენებთ დოკუმენტების უფრო ადრეულ ვერსიებს.

აქ არის დოკუმენტაციის არასწორი მაგალითი:

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

შესრულების მცდელობის შედეგად, ჩვენ მივიღებთ შეცდომას, რომელიც All ასეთი მეთოდი არ არსებობს... და ეს მართალია, რადგან არსებობს სპეციალური, ცალკე ობიექტის სივრცე XML-თან მუშაობისთვის ფუნქციების გამოსაყენებლად - cxXPath. ასე გამოიყურება სწორი მოთხოვნა Android-ში პარამეტრის მოსაძებნად, რომელიც HTTP ტრაფიკის გამოყენების საშუალებას იძლევა:

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

მოდით შევხედოთ მას ცოტა უფრო დეტალურად, რადგან ყველა ფუნქციის სინტაქსი მსგავსია, მას შემდეგ რაც ერთს გაარკვიეთ, თქვენ უბრალოდ უნდა აირჩიოთ ის, რაც გჭირდებათ. ასე რომ, თანმიმდევრობით პარამეტრების მიხედვით:

• "*.xml"— მოსაძიებელი ფაილების ნიღაბი

• 8 - ენის id, რომელზედაც გამოიყენება ეს წესი

• "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>

Დავალება: შედეგების შეზღუდვა ფაილის სახელის/გზის მიხედვით

გამოსავალი: ერთ-ერთ მსხვილ პროექტში, რომელიც დაკავშირებულია Android-ისთვის მობილური აპლიკაციის შემუშავებასთან, შეგვხვდა წესის ცრუ პოზიტივი, რომელიც განსაზღვრავს ბუნდოვან პარამეტრს. ფაქტია, რომ ფაილში ძებნის გამორიცხვის წესი 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'
  ...
}

და Checkmarx-ის წესი:

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);
		}
	}
}

ეს მიდგომა შეიძლება იყოს საკმაოდ უნივერსალური და გამოსადეგი არა მხოლოდ Android აპლიკაციებისთვის, არამედ სხვა შემთხვევებისთვისაც, როდესაც უნდა დაადგინოთ, ეკუთვნის თუ არა შედეგი კონკრეტულ ფაილს.

Დავალება: დაამატეთ მხარდაჭერა მესამე მხარის ბიბლიოთეკისთვის, თუ სინტაქსი სრულად არ არის მხარდაჭერილი

გამოსავალი: სხვადასხვა ჩარჩოების რაოდენობა, რომლებიც გამოიყენება კოდის დაწერის პროცესში, უბრალოდ არ არის ჩარტებში. რა თქმა უნდა, Checkmarx-მა ყოველთვის არ იცის მათი არსებობის შესახებ და ჩვენი ამოცანაა ვასწავლოთ მას იმის გაგება, რომ გარკვეული მეთოდები სწორედ ამ ჩარჩოს ეკუთვნის. ზოგჯერ ეს გართულებულია იმით, რომ ფრეიმორები იყენებენ ფუნქციების სახელებს, რომლებიც ძალიან გავრცელებულია და შეუძლებელია ცალსახად განსაზღვროს კონკრეტული ზარის კავშირი კონკრეტულ ბიბლიოთეკასთან.

სირთულე იმაში მდგომარეობს, რომ ასეთი ბიბლიოთეკების სინტაქსი ყოველთვის არ არის აღიარებული სწორად და თქვენ უნდა ჩაატაროთ ექსპერიმენტები, რათა თავიდან აიცილოთ ცრუ დადებითი შედეგების დიდი რაოდენობა. არსებობს რამდენიმე ვარიანტი სკანირების სიზუსტის გასაუმჯობესებლად და პრობლემის გადასაჭრელად:

• პირველი ვარიანტი, ჩვენ ზუსტად ვიცით, რომ ბიბლიოთეკა გამოიყენება კონკრეტულ პროექტში და შეუძლია გამოიყენოს წესი გუნდის დონეზე. მაგრამ თუ გუნდი გადაწყვეტს განსხვავებულ მიდგომას ან გამოიყენებს რამდენიმე ბიბლიოთეკას, რომლებშიც ფუნქციების სახელები ერთმანეთს ემთხვევა, ჩვენ შეგვიძლია მივიღოთ არც თუ ისე სასიამოვნო სურათი მრავალი ცრუ დადებითის შესახებ.

• მეორე ვარიანტი არის ფაილების ძიება, რომლებშიც ბიბლიოთეკა აშკარად არის იმპორტირებული. ამ მიდგომით ჩვენ შეგვიძლია დარწმუნებული ვიყოთ, რომ ჩვენთვის საჭირო ბიბლიოთეკა ზუსტად არის გამოყენებული ამ ფაილში.

• და მესამე ვარიანტი არის ზემოთ ჩამოთვლილი ორი მიდგომის ერთად გამოყენება.

მაგალითად, მოდით შევხედოთ ვიწრო წრეებში კარგად ცნობილ ბიბლიოთეკას slick Scala პროგრამირების ენისთვის, კერძოდ, ფუნქციონალისთვის ლიტერალური მნიშვნელობების შერწყმა. ზოგადად, SQL შეკითხვაზე პარამეტრების გადასაცემად, თქვენ უნდა გამოიყენოთ ოპერატორი $, რომელიც ანაცვლებს მონაცემებს წინასწარ ჩამოყალიბებულ SQL მოთხოვნაში. ეს არის, ფაქტობრივად, ეს არის მომზადებული განცხადების პირდაპირი ანალოგი Java-ში. მაგრამ, თუ თქვენ გჭირდებათ SQL მოთხოვნის დინამიურად აწყობა, მაგალითად, თუ გჭირდებათ ცხრილების სახელების გადაცემა, შეგიძლიათ გამოიყენოთ ოპერატორი #$, რომელიც პირდაპირ ჩაანაცვლებს მონაცემებს მოთხოვნაში (თითქმის სიმებიანი შეერთების მსგავსად).

კოდის ნიმუში:

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

Checkmarx-მა ჯერ არ იცის როგორ აღმოაჩინოს Splicing Literal Values-ის გამოყენება და გამოტოვოს ოპერატორები #$, ასე რომ, შევეცადოთ ვასწავლოთ პოტენციური 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 პრაქტიკის კომბინაცია დაგეხმარებათ იმის დადგენაში, რომ ფუნქციები, რომლებიც იწვევს დაუცველობის ექსპლუატაციას, არ არის გამოყენებული კოდში.

მაგრამ ზოგჯერ, განსაკუთრებით JavaScript-ის განხილვისას, ეს შეიძლება არ იყოს სრულიად ტრივიალური ამოცანა. ქვემოთ მოცემულია გამოსავალი, შესაძლოა არა იდეალური, მაგრამ მაინც მუშაობს კომპონენტის დაუცველობის მაგალითის გამოყენებით lodash მეთოდებში template и *set.

პოტენციურად დაუცველი კოდის ტესტის მაგალითები JS ფაილში:

/**
 * 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");

დასკვნა

იმედი მაქვს, რომ ეს სტატია სასარგებლო იქნება მათთვის, ვინც იწყებს გაცნობას Checkmarx-ის ინსტრუმენტთან. შესაძლოა მათ, ვინც დიდი ხანია წერენ საკუთარ წესებს, ამ სახელმძღვანელოშიც იპოვონ რაიმე სასარგებლო.

სამწუხაროდ, ამჟამად არ არის რესურსის ნაკლებობა, სადაც ახალი იდეების შეგროვება შესაძლებელი იქნებოდა Checkmarx-ის წესების შემუშავებისას. ამიტომ შევქმენით საცავი Github-ზე, სადაც ჩვენ გამოვაქვეყნებთ ჩვენს ნამუშევრებს, რათა ყველამ, ვინც იყენებს CxQL-ს, იპოვნოს მასში რაიმე სასარგებლო და ასევე ჰქონდეს შესაძლებლობა გაუზიაროს თავისი ნამუშევარი საზოგადოებას. საცავი მიმდინარეობს შინაარსის შევსებისა და სტრუქტურირების პროცესში, ამიტომ მისასალმებელია კონტრიბუტორები!

დიდი მადლობა!

წყარო: www.habr.com