Семь бед — один Semgrep. Ищем уязвимый код с помощью кастомных правил

В пре­дыду­щей статье я показал, как находить уяз­вимос­ти в при­ложе­ниях с помощью динами­чес­кого ска­ниро­вания (DAST) на при­мере ска­нера Nuclei. Одна­ко DAST — это лишь один из под­ходов к пос­тро­ению безопас­ности. В этот раз рас­смот­рим ста­тичес­кий ана­лиз и прин­ципы, на которых он стро­ится.

Ты, воз­можно, стал­кивал­ся со ста­тичес­кими лин­терами в популяр­ных IDE вро­де VS Code. Они ана­лизи­руют исходный код и дают рекомен­дации по улуч­шению. При­мер­но так же работа­ет и SAST, толь­ко с укло­ном в безопас­ность.

Бла­года­ря SAST спе­циалис­ты, ответс­твен­ные за безопас­ность кода, backend-раз­работ­чики, инже­неры Application Security, сот­рудни­ки DevSecOps и DevOps могут нем­ного рас­сла­бить­ся, так как есть допол­нитель­ный уро­вень про­вер­ки и проб­лемный код не сра­зу попадет в про­дук­товое окру­жение.

Од­нако с нас­трой­ками по умол­чанию SAST не отли­чает­ся высокой эффектив­ностью. Что­бы выжать из него мак­симум, нуж­но добавить свои нас­трой­ки — в иде­але для кон­крет­ного при­ложе­ния. Я про­демонс­три­рую, как это делать.

В качес­тве инс­тру­мен­та я выб­рал Semgrep, как самый прос­той спо­соб поз­накомить­ся со ста­тичес­ким ана­лизом.

На­пишем три пра­вила для обна­руже­ния уяз­вимос­тей в API:

1. Broken Object Level Authorization.
2. Broken Function Level Authorization.
3. SQL Injection.

В качес­тве уяз­вимой кодовой базы сно­ва возь­мем спе­циаль­ное при­ложе­ние для тес­тирова­ния защищен­ности API — VAmPI.

За­пус­кать нам его в этот раз не нуж­но, дос­таточ­но прос­то ска­чать исходный код:

Для ска­ниро­вания при­ложе­ния локаль­но уста­новим Semgrep. Он дос­тупен на всех популяр­ных опе­раци­онных сис­темах, а инс­трук­ция по уста­нов­ке есть на офи­циаль­ном сай­те. Уни­вер­саль­ный спо­соб — ста­вить через пакет­ный менед­жер pip:

Что­бы запус­тить Semgrep со встро­енны­ми пра­вила­ми, нуж­но перей­ти в дирек­торию с исходным кодом тес­тиру­емо­го при­ложе­ния и выпол­нить сле­дующую коман­ду:

При таком запус­ке Semgrep обна­ружил толь­ко небезо­пас­ное исполь­зование сек­ретов в исходном коде. Это луч­ше, чем ничего, но в нашем уяз­вимом при­ложе­нии точ­но есть и более опас­ные баги.

Об­рати вни­мание, что это бес­плат­ная вер­сия, а раз­работ­чики явно говорят, что в плат­ной вер­сии заложе­но гораз­до боль­ше экспер­тизы. Воз­можно, в нашем при­мере ситу­ация тоже бы изме­нилась в луч­шую сто­рону.

Од­нако мы решим проб­лему ина­че: добавив собс­твен­ные пра­вила. Но сна­чала рас­смот­рим, как устро­ен SAST.

Статический анализ безопасности

Что­бы понять, как работа­ет SAST, рас­смот­рим четыре под­хода:

• Abstract syntax tree (AST), абс­трак­тное син­такси­чес­кое дерево. AST помога­ет инс­тру­мен­там SAST понять струк­туру кода и его семан­тику. AST — это струк­тура дан­ных, пред­став­ляющая син­такси­чес­кую иерар­хию исходно­го кода прог­раммы в виде дерева. Нап­ример, одним из узлов может быть вызов метода, а его аргу­мен­ты будут дочер­ними узла­ми.
• Control flow graph (CFG), граф потока управле­ния. На осно­ве CFG инс­тру­мен­ты SAST могут ана­лизи­ровать воз­можные пути выпол­нения прог­раммы. CFG пред­став­ляет собой граф, где узлы обоз­нача­ют базовые бло­ки кода (пос­ледова­тель­нос­ти инс­трук­ций без вет­вле­ний), а реб­ра — воз­можные пути выпол­нения меж­ду эти­ми бло­ками. Этот граф поз­воля­ет понять, как управле­ние переда­ется по прог­рамме.
• Data flow graph (DFG) — граф потока дан­ных. Ана­лиз потока дан­ных поз­воля­ет выявить уяз­вимос­ти, свя­зан­ные с неп­равиль­ной переда­чей или исполь­зовани­ем дан­ных. DFG — граф, в узлах которо­го рас­положе­ны опе­рации, а реб­ра показы­вают поток дан­ных меж­ду эти­ми опе­раци­ями.
• Taint analysis — ана­лиз заражен­ности. Это прод­винутая вер­сия DFG, она фокуси­рует­ся на отсле­жива­нии источни­ков потен­циаль­но опас­ных дан­ных (нап­ример, поль­зователь­ско­го вво­да) через прог­рамму и про­вер­ке того, как эти дан­ные исполь­зуют­ся. Если такие дан­ные при­меня­ются без над­лежащей филь­тра­ции или валида­ции, это может при­вес­ти к уяз­вимос­тям.

Как работает SAST?

Те­перь по шагам пос­мотрим, что, собс­твен­но, дела­ет SAST.

1. Ана­лизи­рует исходный код. SAST-инс­тру­мен­ты ана­лизи­руют исходный код, исполь­зуя AST, CFG, DFG и дру­гие модели, что­бы получить пол­ное пред­став­ление о струк­туре и логике прог­раммы.
2. Ищет пат­терны уяз­вимос­тей. При­меняя раз­личные пра­вила и пат­терны (нап­ример, исполь­зование небезо­пас­ных фун­кций, неп­равиль­ная обра­бот­ка оши­бок), инс­тру­мен­ты SAST обна­ружи­вают потен­циаль­ные уяз­вимос­ти.
3. Соз­дает отче­ты. SAST-инс­тру­мен­ты генери­руют отче­ты с опи­сани­ем най­ден­ных уяз­вимос­тей, ука­зывая на проб­лемные мес­та в коде.

Semgrep — это как grep?