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

Еј Хабр!

Во нашата работа, нашата компанија многу често се занимава со различни алатки за анализа на статички кодови (SAST). Надвор од кутијата сите тие работат просечно. Се разбира, се зависи од проектот и технологиите што се користат во него, како и од тоа колку добро овие технологии се опфатени со правилата за анализа. Според мое мислење, еден од најважните критериуми при изборот на алатката SAST е способноста да се прилагоди на спецификите на вашите апликации, имено, да се пишуваат и менуваат правилата за анализа или, како што почесто се нарекуваат, Custom Queries.

Најчесто користиме Checkmarx - многу интересен и моќен анализатор на кодови. Во оваа статија ќе зборувам за моето искуство за пишување правила за анализа за тоа.

Содржина

• Влегување

• Општи информации за правилата

• „Речник“ за почетници

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

  • Сите пронајдени предмети

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

  • Добивање име/пат на датотека

  • Резултат од извршувањето

  • Користење на резултатите од други правила

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

  • Сеча

  • Проблем со најавување

• Правила за пишување

• Заклучок

Влегување

За почеток, би сакал да препорачам една од ретките написи на руски јазик за карактеристиките на пишување прашања за Checkmarx. Објавено е на Хабре на крајот на 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 има основни правила, чии резултати се користат од многу други прашања. Со дополнување на некои од овие правила со податоци специфични за вашата апликација, можете веднаш да ги подобрите резултатите од скенирањето. Подолу е пример правило за да започнете:

Список за општа_приватност_повреда

Ајде да додадеме неколку променливи што се користат во нашата апликација за складирање на чувствителни информации:

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

Пример за тестирање на код што ја користи библиотеката 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 како излезна точка за податоци од апликацијата:

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. Ајде да напишеме правило кое ќе ги бара податоците што ни се потребни и ќе ни каже дали некаде се споменати лозинки или токени.

Пример за таква датотека, која содржи токен за комуникација со заднинската услуга:

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

Задача: Ограничете ги резултатите по име/пат на датотеката

решение: Во еден од големите проекти поврзани со развој на мобилна апликација за Андроид, наидовме на лажни позитиви на правилото што ја одредува поставката за замаглување. Факт е дека правилото надвор од кутијата бара во датотеката 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 барање. Тоа е, всушност, тоа е директен аналог на Подготвената изјава во Јава. Но, ако треба динамички да конструирате 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