Akıllı sözleşme hatalarını bulmak için Slither nasıl kullanılır

Solidity

akıllı sözleşmeler

güvenlik

test etme

İleri

Trailofbits

Building secure contracts

9 Haziran 2020

6 dakikalık okuma

Sayfayı düzenle

Slither nasıl kullanılır

Bu eğitimin amacı, akıllı sözleşmelerdeki hataları otomatik olarak bulmak için Slither'ın nasıl kullanılacağını göstermektir.

Kurulum
Komut satırı kullanımı
Statik analize giriş: Statik analize kısa bir giriş
API: Python API açıklaması

Kurulum

Slither, Python >= 3.6 gerektirir. pip aracılığıyla veya Docker kullanılarak kurulabilir.

pip aracılığıyla Slither:

pip3 install --user slither-analyzer

Docker aracılığıyla Slither:

docker pull trailofbits/eth-security-toolbox
docker run -it -v "$PWD":/home/trufflecon trailofbits/eth-security-toolbox

Son komut, eth-security-toolbox'ı mevcut dizininize erişimi olan bir Docker içinde çalıştırır. Dosyaları ana makinenizden değiştirebilir ve araçları Docker'daki dosyalar üzerinde çalıştırabilirsiniz

Docker içinde şunu çalıştırın:

solc-select 0.5.11
cd /home/trufflecon/

Bir betik çalıştırma

Python 3 ile bir Python betiği çalıştırmak için:

python3 script.py

Komut satırı

Komut satırı ve kullanıcı tanımlı betikler. Slither, birçok yaygın hatayı bulan önceden tanımlanmış bir dizi dedektörle birlikte gelir. Slither'ı komut satırından çağırmak tüm dedektörleri çalıştıracaktır, statik analiz hakkında detaylı bilgiye gerek yoktur:

slither project_paths

Dedektörlere ek olarak Slither, yazıcıları (printers) (opens in a new tab) ve araçları (opens in a new tab) aracılığıyla kod inceleme yeteneklerine sahiptir.

Özel dedektörlere ve GitHub entegrasyonuna erişim sağlamak için crytic.io (opens in a new tab) kullanın.

Statik analiz

Slither statik analiz çerçevesinin yetenekleri ve tasarımı blog yazılarında (1 (opens in a new tab), 2 (opens in a new tab)) ve bir akademik makalede (opens in a new tab) açıklanmıştır.

Statik analizin farklı türleri vardır. Büyük ihtimalle clang (opens in a new tab) ve gcc (opens in a new tab) gibi derleyicilerin bu araştırma tekniklerine dayandığını fark etmişsinizdir, ancak aynı zamanda (Infer (opens in a new tab), CodeClimate (opens in a new tab), FindBugs (opens in a new tab) ve Frama-C (opens in a new tab) ile Polyspace (opens in a new tab) gibi biçimsel yöntemlere dayalı araçların da temelini oluşturur.

Burada statik analiz tekniklerini ve araştırmalarını kapsamlı bir şekilde incelemeyeceğiz. Bunun yerine, hataları bulmak ve kodu anlamak için Slither'ı daha etkili bir şekilde kullanabilmeniz adına onun nasıl çalıştığını anlamak için gerekenlere odaklanacağız.

Kod gösterimi
Kod analizi
Ara gösterim

Kod gösterimi

Tek bir yürütme yolu hakkında akıl yürüten dinamik analizin aksine, statik analiz tüm yollar hakkında aynı anda akıl yürütür. Bunu yapmak için farklı bir kod gösterimine dayanır. En yaygın iki tanesi soyut sözdizimi ağacı (AST) ve kontrol akış grafiğidir (CFG).

Soyut Sözdizimi Ağaçları (AST)

AST, derleyici kodu her ayrıştırdığında kullanılır. Muhtemelen üzerinde statik analizin gerçekleştirilebileceği en temel yapıdır.

Kısacası AST, genellikle her yaprağın bir değişken veya sabit içerdiği ve iç düğümlerin işlenenler veya kontrol akışı işlemleri olduğu yapılandırılmış bir ağaçtır. Aşağıdaki kodu göz önünde bulundurun:

function safeAdd(uint a, uint b) pure internal returns(uint){
    if(a + b <= a){
        revert();
    }
    return a + b;
}

İlgili AST şurada gösterilmektedir:

Slither, solc tarafından dışa aktarılan AST'yi kullanır.

Oluşturulması basit olsa da AST iç içe geçmiş bir yapıdır. Bazen analiz edilmesi en kolay şey değildir. Örneğin, a + b <= a ifadesi tarafından kullanılan işlemleri tanımlamak için önce <= ve ardından + analiz edilmelidir. Yaygın bir yaklaşım, ağaçta özyinelemeli olarak gezinen ziyaretçi (visitor) desenini kullanmaktır. Slither, ExpressionVisitor (opens in a new tab) içinde genel bir ziyaretçi içerir.

Aşağıdaki kod, ifadenin bir toplama işlemi içerip içermediğini tespit etmek için ExpressionVisitor kullanır:

from slither.visitors.expression.expression import ExpressionVisitor
from slither.core.expressions.binary_operation import BinaryOperationType

class HasAddition(ExpressionVisitor):

    def result(self):
        return self._result

    def _post_binary_operation(self, expression):
        if expression.type == BinaryOperationType.ADDITION:
            self._result = True

visitor = HasAddition(expression) # ifade, test edilecek ifadedir
print(f'The expression {expression} has a addition: {visitor.result()}')

Kontrol Akış Grafiği (CFG)

İkinci en yaygın kod gösterimi kontrol akış grafiğidir (CFG). Adından da anlaşılacağı gibi, tüm yürütme yollarını ortaya çıkaran grafik tabanlı bir gösterimdir. Her düğüm bir veya birden fazla talimat içerir. Grafikteki kenarlar kontrol akışı işlemlerini (if/then/else, döngü vb.) temsil eder. Önceki örneğimizin CFG'si şöyledir:

CFG, analizlerin çoğunun üzerine inşa edildiği gösterimdir.

Başka birçok kod gösterimi mevcuttur. Gerçekleştirmek istediğiniz analize göre her gösterimin avantajları ve dezavantajları vardır.

Analiz

Slither ile gerçekleştirebileceğiniz en basit analiz türü sözdizimsel analizlerdir.

Sözdizimi analizi

Slither, desen eşleştirmeye benzer bir yaklaşım kullanarak tutarsızlıkları ve kusurları bulmak için kodun farklı bileşenleri ve bunların gösterimleri arasında gezinebilir.

Örneğin aşağıdaki dedektörler sözdizimi ile ilgili sorunları arar:

Durum değişkeni gölgeleme (State variable shadowing) (opens in a new tab): tüm durum değişkenleri üzerinde yinelenir ve herhangi birinin miras alınan bir sözleşmedeki bir değişkeni gölgeleyip gölgelemediğini kontrol eder (state.py#L51-L62 (opens in a new tab))
Yanlış ERC-20 arayüzü (opens in a new tab): yanlış ERC-20 işlev imzalarını arar (incorrect_erc20_interface.py#L34-L55 (opens in a new tab))

Anlamsal analiz

Sözdizimi analizinin aksine, anlamsal bir analiz daha derine iner ve kodun "anlamını" analiz eder. Bu aile bazı geniş analiz türlerini içerir. Daha güçlü ve faydalı sonuçlara yol açarlar, ancak yazılmaları da daha karmaşıktır.

Anlamsal analizler en gelişmiş güvenlik açığı tespitleri için kullanılır.

Veri bağımlılığı analizi

Eğer variable_a değerinin variable_b tarafından etkilendiği bir yol varsa, variable_a değişkeninin variable_b değişkenine veri bağımlı olduğu söylenir.

Aşağıdaki kodda variable_a, variable_b değişkenine bağımlıdır:

// ...
variable_a = variable_b + 1;

Slither, ara gösterimi (sonraki bir bölümde tartışılacaktır) sayesinde yerleşik veri bağımlılığı (opens in a new tab) yetenekleriyle birlikte gelir.

Veri bağımlılığı kullanımına bir örnek tehlikeli kesin eşitlik dedektöründe (opens in a new tab) bulunabilir. Burada Slither, tehlikeli bir değere karşı kesin eşitlik karşılaştırması arayacak (incorrect_strict_equality.py#L86-L87 (opens in a new tab)) ve bir saldırganın sözleşmeyi tuzağa düşürmesini önlemek için kullanıcıya == yerine >= veya <= kullanması gerektiğini bildirecektir. Diğerlerinin yanı sıra dedektör, balanceOf(address) çağrısının dönüş değerini tehlikeli olarak değerlendirecek (incorrect_strict_equality.py#L63-L64 (opens in a new tab)) ve kullanımını izlemek için veri bağımlılığı motorunu kullanacaktır.

Sabit nokta hesaplaması

Analiziniz CFG'de geziniyor ve kenarları takip ediyorsa, daha önce ziyaret edilmiş düğümleri görmeniz muhtemeldir. Örneğin, aşağıda gösterildiği gibi bir döngü sunulursa:

for(uint i; i < range; ++){
    variable_a += 1
}

Analizinizin ne zaman duracağını bilmesi gerekecektir. Burada iki ana strateji vardır: (1) her düğüm üzerinde sonlu sayıda yineleme yapmak, (2) sabit nokta (fixpoint) adı verilen bir değeri hesaplamak. Sabit nokta temel olarak bu düğümü analiz etmenin anlamlı bir bilgi sağlamadığı anlamına gelir.

Kullanılan sabit noktaya bir örnek yeniden giriş dedektörlerinde bulunabilir: Slither düğümleri keşfeder ve harici çağrıları, depolamaya yazma ve okuma işlemlerini arar. Bir sabit noktaya ulaştığında (reentrancy.py#L125-L131 (opens in a new tab)), keşfi durdurur ve farklı yeniden giriş desenleri (reentrancy_benign.py (opens in a new tab), reentrancy_read_before_write.py (opens in a new tab), reentrancy_eth.py (opens in a new tab)) aracılığıyla bir yeniden giriş olup olmadığını görmek için sonuçları analiz eder.

Verimli sabit nokta hesaplaması kullanarak analizler yazmak, analizin bilgilerini nasıl yaydığının iyi anlaşılmasını gerektirir.

Ara gösterim

Ara gösterim (IR), orijinaline göre statik analize daha uygun olması amaçlanan bir dildir. Slither, Solidity'yi kendi IR'sine çevirir: SlithIR (opens in a new tab).

Sadece temel kontroller yazmak istiyorsanız SlithIR'yi anlamak gerekli değildir. Ancak, gelişmiş anlamsal analizler yazmayı planlıyorsanız işinize yarayacaktır. SlithIR (opens in a new tab) ve SSA (opens in a new tab) yazıcıları, kodun nasıl çevrildiğini anlamanıza yardımcı olacaktır.

API Temelleri

Slither, sözleşmenin ve işlevlerinin temel niteliklerini keşfetmenizi sağlayan bir API'ye sahiptir.

Bir kod tabanını yüklemek için:

from slither import Slither
slither = Slither('/path/to/project')

Sözleşmeleri ve işlevleri keşfetme

Bir Slither nesnesi şunlara sahiptir:

contracts (list(Contract): sözleşmelerin listesi
contracts_derived (list(Contract): başka bir sözleşme tarafından miras alınmayan sözleşmelerin listesi (sözleşmelerin alt kümesi)
get_contract_from_name (str): Adından bir sözleşme döndürür

Bir Contract nesnesi şunlara sahiptir:

name (str): Sözleşmenin adı
functions (list(Function)): İşlevlerin listesi
modifiers (list(Modifier)): İşlevlerin listesi
all_functions_called (list(Function/Modifier)): Sözleşme tarafından ulaşılabilen tüm dahili işlevlerin listesi
inheritance (list(Contract)): Miras alınan sözleşmelerin listesi
get_function_from_signature (str): İmzasından bir İşlev (Function) döndürür
get_modifier_from_signature (str): İmzasından bir Değiştirici (Modifier) döndürür
get_state_variable_from_name (str): Adından bir Durum Değişkeni (StateVariable) döndürür

Bir Function veya Modifier nesnesi şunlara sahiptir:

name (str): İşlevin adı
contract (contract): işlevin bildirildiği sözleşme
nodes (list(Node)): İşlevin/değiştiricinin CFG'sini oluşturan düğümlerin listesi
entry_point (Node): CFG'nin giriş noktası
variables_read (list(Variable)): Okunan değişkenlerin listesi
variables_written (list(Variable)): Yazılan değişkenlerin listesi
state_variables_read (list(StateVariable)): Okunan durum değişkenlerinin listesi (okunan değişkenlerin alt kümesi)
state_variables_written (list(StateVariable)): Yazılan durum değişkenlerinin listesi (yazılan değişkenlerin alt kümesi)

Sayfanın son güncellenme tarihi: 15 Nisan 2026