Как да напиша правила за Checkmarx, без да полудея

Хей Хабр!

В нашата работа нашата компания много често се занимава с различни инструменти за анализ на статичен код (SAST). Извън кутията всички работят средно. Разбира се, всичко зависи от проекта и технологиите, използвани в него, както и доколко тези технологии са обхванати от правилата за анализ. Според мен един от най-важните критерии при избора на SAST инструмент е възможността да го персонализирате според спецификата на вашите приложения, а именно да пишете и променяте правила за анализ или както по-често се наричат ​​Custom Queries.

Най-често използваме Checkmarx - много интересен и мощен код анализатор. В тази статия ще говоря за моя опит в писането на правила за анализ за него.

Таблица на съдържанието

• Влизане

• Обща информация за правилата

• "Речник" за начинаещи

  • Операции със списъци

  • Всички намерени артикули

  • Функции за анализ на потока

  • Получаване на име/път на файл

  • Резултат от изпълнението

  • Използване на резултатите от други правила

• Решаване на проблеми

  • Сеч

  • Проблем с влизането

• Правила за писане

• Заключение

Влизане

Като начало бих искал да препоръчам една от малкото статии на руски за характеристиките на писане на заявки за Checkmarx. Той беше публикуван на Habré в края на 2019 г. под заглавие: „Здравей, Чекмаркс!“ Как да напишете Checkmarx SAST заявка и да намерите страхотни уязвимости.

Той разглежда подробно как да напишете първите заявки в CxQL (Checkmarx Query Language) за някои тестови приложения и показва основните принципи на това как работят правилата за анализ.

Няма да повтарям описаното в него, но някои пресичания все пак ще има. В моята статия ще се опитам да съставя един вид „колекция от рецепти“, списък с решения на конкретни проблеми, които срещнах по време на работата си с Checkmarx. Трябваше да си набия главата над много от тези проблеми. Понякога в документацията нямаше достатъчно информация, а понякога дори беше трудно да се разбере как да се направи това, което се изисква. Надявам се моят опит и безсънни нощи да не са напразни и тази „колекция от рецепти за персонализирани заявки“ ще ви спести няколко часа или няколко нервни клетки. И така, да започваме!

Обща информация за правилата

Първо, нека разгледаме няколко основни концепции и процеса на работа с правилата, за да разберем по-добре какво ще се случи след това. А също и защото документацията не казва нищо за това или е много разпръсната в структурата, което не е много удобно.

1. Правилата се прилагат по време на сканиране в зависимост от избраната при стартиране предварително зададена настройка (набор от активни правила). Можете да създадете неограничен брой предварителни настройки, а как точно да ги структурирате зависи от спецификата на вашия процес. Можете да ги групирате по език или да изберете предварително зададени настройки за всеки проект. Броят на активните правила влияе върху скоростта и точността на сканиране.

   Настройка на Preset в интерфейса Checkmarx

2. Правилата се редактират в специален инструмент, наречен CxAuditor. Това е десктоп приложение, което се свързва със сървър, изпълняващ Checkmarx. Този инструмент има два режима на работа: редактиране на правила и анализ на резултатите от вече извършено сканиране.

   CxAudit интерфейс

3. Правилата в Checkmarx са разделени по език, т.е. всеки език има свой собствен набор от заявки. Има и някои общи правила, които се прилагат независимо от езика, това са така наречените основни заявки. В по-голямата си част основните заявки включват търсене на информация, която използват други правила.

   Разделяне на правилата по език

4. Правилата са „изпълними“ и „неизпълними“ (изпълнени и неизпълнени). Не съвсем правилното име, според мен, но това е. Изводът е, че резултатът от изпълнението на „изпълнимите“ правила ще бъде показан в резултатите от сканирането в потребителския интерфейс, а „неизпълнимите“ правила са необходими само за използване на техните резултати в други заявки (всъщност те са просто функция ).

   Определяне на типа правило при създаване

5. Можете да създавате нови правила или да допълвате/пренаписвате съществуващи. За да пренапишете правило, трябва да го намерите в дървото, да щракнете с десния бутон и да изберете „Override“ от падащото меню. Тук е важно да запомните, че новите правила първоначално не са включени в предварително зададените настройки и не са активни. За да започнете да ги използвате, трябва да ги активирате в менюто “Preset Manager” на инструмента. Пренаписаните правила запазват настройките си, тоест ако правилото е било активно, то ще остане такова и ще бъде приложено веднага.

   Пример за ново правило в интерфейса на Preset Manager

6. По време на изпълнение се изгражда „дърво“ от заявки, което зависи от какво. Правилата, които събират информация, се изпълняват първи, а тези, които я използват, втори. Резултатът от изпълнението се кешира, така че ако е възможно да използвате резултатите от съществуващо правило, тогава е по-добре да го направите, това ще намали времето за сканиране.

7. Правилата могат да се прилагат на различни нива:

• За цялата система - ще се използва за всяко сканиране на всеки проект

• На ниво екип (Екип) - ще се използва само за сканиране на проекти в избрания екип.

• На ниво проект – Ще се приложи в конкретен проект

  Определяне на нивото, на което ще се прилага правилото

"Речник" за начинаещи

И ще започна с няколко неща, които предизвикаха у мен въпроси, и също така ще покажа редица техники, които значително ще опростят живота.

Операции със списъци

- вычитание одного из другого (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, това, което често ви липсва, е не толкова документация, колкото някои живи примери за решаване на определени проблеми и описание на процеса на работа със заявки като цяло.

Ще се опитам да направя живота малко по-лесен за тези, които започват да се гмуркат в езика на заявките, и ще дам няколко примера за използване на персонализирани заявки за решаване на определени проблеми. Някои от тях са доста общи и могат да се използват във вашата компания практически без промени, други са по-специфични, но могат да се използват и чрез промяна на кода, за да отговаря на спецификата на вашите приложения.

И така, ето проблемите, които най-често срещаме:

Цел: Има няколко потока в резултатите от изпълнението на правилото и един от тях е вложен в друг, трябва да напуснете един от тях.

решение: Наистина, понякога Checkmarx показва няколко потока от данни, които може да се припокриват и да са съкратена версия на други. За такива случаи има специален метод ReduceFlow. В зависимост от параметъра, той ще избере най-късия или най-дългия поток:

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

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

Цел: Разширете списъка с чувствителни данни, на които инструментът реагира

решение: Checkmarx има основни правила, резултатите от които се използват от много други заявки. Чрез допълване на някои от тези правила с данни, специфични за вашето приложение, можете незабавно да подобрите резултатите от сканирането. По-долу е дадено примерно правило, за да започнете:

General_privacy_violation_list

Нека добавим няколко променливи, които се използват в нашето приложение за съхраняване на чувствителна информация:

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

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

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

Цел: Разширете списъка с променливи с пароли

решение: Бих препоръчал веднага да обърнете внимание на основното правило за дефиниране на пароли в код и да добавите към него списък с имена на променливи, които обикновено се използват във вашата компания.

Password_privacy_violation_list

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.

Пример за тестов код, който използва библиотеката Timber за регистриране:

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 като изходна точка за данни от приложението:

Намерете AndroidOutputs

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

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

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

И можете също да добавите към съседното правило, но това се отнася директно до влизането в Android:

Намерете AndroidLog_Outputs

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

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

Също така, ако приложенията за Android използват WorkManager за асинхронна работа е добра идея допълнително да информирате 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. Нека напишем правило, което ще търси нужните ни данни и ще ни казва дали някъде се споменават пароли или токени.

Пример за такъв файл, който съдържа токен за комуникация с бекенд услугата:

<?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 — идентификатор на езика, за който се прилага правилото

• "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 не винаги знае за тяхното съществуване и нашата задача е да го научим да разбере, че определени методи принадлежат конкретно към тази рамка. Понякога това се усложнява от факта, че рамките използват имена на функции, които са много често срещани и е невъзможно недвусмислено да се определи връзката на конкретно извикване с конкретна библиотека.

Трудността е, че синтаксисът на такива библиотеки не винаги се разпознава правилно и трябва да експериментирате, за да избегнете получаването на голям брой фалшиви положителни резултати. Има няколко опции за подобряване на точността на сканиране и решаване на проблема:

• Първият вариант, знаем със сигурност, че библиотеката се използва в конкретен проект и може да приложи правилото на ниво екип. Но ако екипът реши да предприеме различен подход или използва няколко библиотеки, в които имената на функциите се припокриват, можем да получим не много приятна картина на множество фалшиви положителни резултати

• Втората опция е да търсите файлове, в които библиотеката е ясно импортирана. С този подход можем да сме сигурни, че библиотеката, от която се нуждаем, се използва точно в този файл.

• И третият вариант е да използвате двата горни подхода заедно.

Като пример, нека да разгледаме библиотека, добре позната в тесни кръгове хлъзгав за езика за програмиране Scala, а именно функционалността Снаждане на буквални стойности. По принцип, за да предадете параметри на SQL заявка, трябва да използвате оператора $, който замества данни в предварително формирана SQL заявка. Това всъщност е пряк аналог на Prepared Statement в Java. Но ако трябва динамично да конструирате SQL заявка, например, ако трябва да подадете имена на таблици, можете да използвате оператора #$, което директно ще замести данните в заявката (почти като конкатенация на низ).

Примерен код:

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

Checkmarx все още не знае как да открие използването на сплайсинга на буквални стойности и пропуска операторите #$, така че нека се опитаме да го научим да идентифицира потенциални 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