TON (The Open Network) to zdecentralizowana platforma blockchain, pierwotnie zaprojektowana i opracowana przez zespół Telegramu, która zwróciła na siebie uwagę zaraz po uruchomieniu. Celem TON jest zapewnienie wysokowydajnej i skalowalnej platformy blockchain do obsługi zdecentralizowanych aplikacji na dużą skalę (DApps) i inteligentnych kontraktów. Podstawową wiedzę na temat TON można znaleźć w książce Poznajemy TON: Konta, Tokeny, Transakcje i Bezpieczeństwo aktywów.

Warto zauważyć, że TON ma zupełnie inną architekturę niż inne blockchainy Oprócz wykorzystania głównie języka FunC do programowania, inteligentne kontrakty TON wykorzystują także wyższy poziom Tact lub niższy poziom Fift. Są to bardzo oryginalne języki, dlatego zapewnienie bezpieczeństwa inteligentnych kontraktów ma kluczowe znaczenie.

Zespół ds. bezpieczeństwa SlowMist zintegrował i wchłonął praktyki rozwoju bezpieczeństwa wspólne dla społeczności TON, w połączeniu z własnym doświadczeniem w zakresie audytu bezpieczeństwa zgromadzonym przez wiele lat, aby opublikować „Najlepsze praktyki w zakresie bezpieczeństwa kontraktów Toncoin Smart”, których celem jest pomoc programistom w lepszym zrozumieniu bezpieczeństwa Toncoin inteligentne kontrakty i zapewniają praktyczne rozwiązania łagodzące potencjalne zagrożenia bezpieczeństwa.

Ze względu na ograniczoną ilość miejsca w tym artykule wymieniono tylko część „Najlepszych praktyk w zakresie bezpieczeństwa kontraktów Toncoin Smart”. Zapraszamy do oglądania, udostępniania i oznaczania gwiazdek w serwisie GitHub: https://github.com/slowmist/Toncoin-Smart-Contract-Security. -Najlepsze -Praktyki.

Typowe pułapki inteligentnych kontraktów Toncoin

1. Brakujący nieczysty modyfikator

  • Dotkliwość: wysoka

  • Opis: osoba atakująca może odkryć, że funkcja „autoryzuj” nie jest oznaczona jako „nieczysta”. Brak tego modyfikatora pozwoli kompilatorowi pominąć wywoływanie funkcji, jeśli nie ma ona wartości zwracanej lub jeśli wartość zwracana jest nieużywana.

  • Scenariusz ataku:

  • Zalecenie: Upewnij się, że funkcja używa modyfikatora „nieczysty”.

2. Niewłaściwe użycie metod modyfikacji/niemodyfikowania

  • Dotkliwość: wysoka

  • Opis: „udict_delete_get?” zostało niepoprawnie wywołane z „.” zamiast „~”, więc rzeczywisty słownik nie został zmodyfikowany.

  • Scenariusz ataku:

  • Zalecenie: Zawsze sprawdzaj, czy metoda jest metodą modyfikującą/niemodyfikującą.

3. Nieprawidłowe użycie liczb całkowitych ze znakiem/bez znaku

  • Dotkliwość: Wysoka

  • Opis: Prawa głosu zapisywane są w wiadomości jako liczby całkowite. Zatem osoba atakująca może wysyłać wartości ujemne podczas przekazywania mocy i zyskać nieograniczone prawa głosu.

  • Scenariusz ataku:

  • Zalecenie: W niektórych scenariuszach liczby całkowite bez znaku są bezpieczniejsze, ponieważ w przypadku przepełnienia mogą zgłosić błąd. Używaj liczb całkowitych ze znakiem tylko wtedy, gdy naprawdę tego potrzebujesz.

4. Niebezpieczne liczby losowe

  • Dotkliwość: wysoka

  • Opis: Ziarno pochodzi z logicznego czasu transakcji, a atakujący może wygrać poprzez brutalne złamanie czasu logicznego w bieżącym bloku (ponieważ czas logiczny jest ciągły w granicach bloku).

  • Scenariusz ataku:

  • Zalecenie: Zawsze losuj materiał siewny przed wykonaniem „rand()”, a najlepiej nigdy nie używaj liczb losowych w łańcuchu, ponieważ walidator może kontrolować materiał siewny lub na niego wpływać.

5. Wysyłaj prywatne dane w sieci

  • Dotkliwość: wysoka

  • Opis: Pamiętaj, że wszystkie dane będą przechowywane na blockchainie.

  • Scenariusz ataku: Portfel jest chroniony hasłem, a jego wartość skrótu jest przechowywana w danych kontraktu. Jednak blockchain rejestruje wszystko – hasło pojawia się w historii transakcji.

  • Zalecenie: nie wysyłaj prywatnych danych w sieci.

6. Brak kontroli odesłanych wiadomości

  • Dotkliwość: Wysoka

  • Opis: Vault nie zwrócił do bazy danych komunikatu obsługi ani komunikatu proxy, gdy użytkownik wysłał żądanie „sprawdzenia”. Możemy ustawić „msg_addr_none” jako adres nagrody w bazie danych, ponieważ pozwala na to „load_msg_address”. Poprosiliśmy o sprawdzenie Vault i baza danych próbowała przeanalizować „msg_addr_none” przy użyciu „parse_std_addr”, ale analiza nie powiodła się. Komunikat został zwrócony z bazy danych do skarbca, a operacja nie była „op_not_winner”.

  • Scenariusz ataku: Vault zawiera następujący kod w procedurze obsługi komunikatów bazy danych:

  • Zalecenie: zawsze sprawdzaj zwracane wiadomości, nie zapomnij o błędach spowodowanych przez standardowe funkcje, stawiaj warunki tak rygorystyczne, jak to możliwe.

7. Ryzyko zniszczenia konta w warunkach konkurencji

8. Unikaj wykonywania kodu strony trzeciej

  • Dotkliwość: wysoka

  • Opis: programiści nie mają możliwości bezpiecznego wykonania kodu strony trzeciej w kontraktach, ponieważ CATCH nie jest w stanie obsłużyć niewystarczającej ilości gazu, a osoba atakująca musi jedynie przesłać dowolny stan kontraktu i spowodować niewystarczającą ilość gazu, aby przeprowadzić atak.

  • Scenariusz ataku:

  • Zalecenie: Unikaj wykonywania kodu stron trzecich w swoich umowach.

9. Konflikt nazw

  • Dotkliwość: średnia

  • Opis: Zmienne i funkcje funkcyjne mogą zawierać niemal dowolny znak dozwolony.

  • Scenariusz ataku: „var++”, „~bits”, „foo-bar+baz” i przecinek „,” to prawidłowe nazwy zmiennych i funkcji.

  • Zalecenie: Pisząc i sprawdzając kod Func, powinieneś używać narzędzi linterowych.

10. Sprawdź wartość rzutu

  • Dotkliwość: średnia

  • Opis: Za każdym razem, gdy wykonywanie TVM zatrzymuje się normalnie, zatrzymuje się z kodem zakończenia „0” lub „1”. Chociaż odbywa się to automatycznie, wykonywanie TVM może zostać przerwane w nieoczekiwany sposób, jeśli polecenia „throw(0)” lub „throw(1)” bezpośrednio rzucą kody wyjścia „0” i „1”.

  • Scenariusz ataku:

  • Sugestia: nie używaj „0” ani „1” jako wartości rzutu.

11. Odczyt/zapis prawidłowego typu danych

  • Dotkliwość: średnia

  • Opis: Odczytanie wartości nieoczekiwanej zmiennej i wywołanie metody na typie danych, który nie powinien mieć takiej metody (lub którego wartość zwracana nie jest poprawnie przechowywana) jest błędem i nie zostanie pominięty jako „ostrzeżenie” lub „powiadomienie” ", Zamiast tego nie można odzyskać kodu.

  • Scenariusz ataku: Należy pamiętać, że przechowywanie nieoczekiwanej wartości może być w porządku, ale jej odczytanie może powodować problemy. Na przykład w przypadku zmiennych całkowitych może zostać zgłoszony kod błędu 5 (liczba całkowita poza oczekiwanym zakresem).

  • Zalecenie: Śledź dokładnie działanie swojego kodu i możliwe wartości zwracane przez niego. Pamiętaj, że kompilator dba tylko o kod i jego stan początkowy.

12. Kod umowy można aktualizować

  • Dotkliwość: średnia

  • Opis: TON w pełni wdraża model Actor, co oznacza możliwość zmiany kodu umowy. Kod można zmienić na stałe za pomocą instrukcji TVM „SETCODE” lub poprzez ustawienie rejestru kodu TVM na nową wartość jednostki w czasie wykonywania, aż do zakończenia wykonywania.

  • Scenariusz ataku: pozbawiony skrupułów programista może złośliwie zaktualizować kod w celu kradzieży środków.

  • Zalecenie: Należy pamiętać, że kodeks umowy może być aktualizowany, upewnij się, że wszelkie aktualizacje są zgodne z bezpiecznymi praktykami i korzystaj z mechanizmów, takich jak model zarządzania lub zatwierdzenie wielu podpisów, aby wprowadzić zmiany.

13. Transakcje i etapy

  • Dotkliwość: średnia

  • Opis: W fazie obliczeń wykonywany jest kod inteligentnego kontraktu, a następnie wykonywane są operacje (takie jak wysyłanie wiadomości, modyfikowanie kodu, zmiana bibliotek itp.). W przeciwieństwie do blockchainów opartych na Ethereum, jeśli spodziewasz się, że wysłanie wiadomości nie powiedzie się, nie zobaczysz kodu wyjścia fazy obliczeń, ponieważ wiadomość nie jest wykonywana w fazie obliczeń, ale w późniejszej fazie operacji.

  • Scenariusz ataku: Nieoczekiwane zachowanie w przypadku niepowodzenia komunikatu w fazie operacji, prowadzące do błędnych założeń dotyczących statusu transakcji.

  • Zalecenie: Należy pamiętać, że każda transakcja składa się z maksymalnie pięciu faz: fazy przechowywania, fazy kredytu, fazy obliczeń, fazy eksploatacji i fazy odbicia.

14. Nie można pobierać danych z innych umów

  • Dotkliwość: średnia

  • Opis: Kontrakty w łańcuchu bloków mogą znajdować się na różnych fragmentach i być przetwarzane przez różnych walidatorów. Dlatego programiści nie mogą na żądanie pobierać danych z innych umów. Komunikacja jest asynchroniczna i odbywa się poprzez wysyłanie komunikatów.

  • Scenariusz ataku:

  • Zalecenie: Zaprojektuj logikę kontraktu wokół komunikatów asynchronicznych i unikaj założeń dotyczących dostępności danych synchronicznych.

15. Dwa predefiniowane identyfikatory metod

  • Dotkliwość: średnia

  • Opis: Istnieją dwa predefiniowane identyfikatory metod: jeden do odbierania komunikatów w obrębie łańcucha bloków „(0)”, zwykle nazywany „recv_internal”, a drugi do odbierania komunikatów z zewnątrz „(-1)” o nazwie „recv_external”.

  • Scenariusz ataku:

  • Zalecenie: Użyj metod takich jak „force_chain(to_address)”, aby sprawdzić, czy adres znajduje się w prawidłowym łańcuchu.

16. Używaj wiadomości, które można odesłać

  • Dotkliwość: wysoka

  • Opis: Blockchain TON jest asynchroniczny i wiadomości nie muszą docierać w określonej kolejności. Komunikaty o błędach powinny być obsługiwane prawidłowo.

  • Scenariusz ataku:

  • Zalecenie: Zawsze używaj komunikatów możliwych do odesłania („0x18”), aby prawidłowo obsługiwać błędy komunikatów.

17. Ochrona przed powtórkami

  • Dotkliwość: wysoka

  • Opis: Zaimplementuj ochronę przed powtarzaniem portfeli (umów przechowujących środki użytkownika) albo przy użyciu numerów sekwencyjnych („seqno”), aby mieć pewność, że wiadomości nie będą przetwarzane dwukrotnie, albo przy użyciu unikalnych identyfikatorów transakcji z datą ważności.

  • Scenariusz ataku:

  • Zalecenie: użyj metody ochrony przed powtórzeniem, takiej jak numery sekwencyjne lub unikalne identyfikatory wiadomości, aby zapobiec atakom poprzez powtórzenie.

18. Warunki wyścigu dla wiadomości

  • Dotkliwość: Wysoka

  • Opis: kaskady wiadomości mogą być przetwarzane w wielu blokach, a osoba atakująca może uruchomić strumień równoległy, powodując sytuację wyścigu.

  • Scenariusz ataku: osoba atakująca może wykorzystać różnice czasowe do manipulowania zachowaniem kontraktu.

  • Zalecenie: Zapobiegaj warunkom wyścigu, sprawdzając stan na każdym kroku i nie zakładając spójności stanu w przepływie komunikatów.

19. Użyj trybu wartości przenoszonej

  • Dotkliwość: wysoka

  • Opis: W przypadku transferów tokenowych (np. TON Jetton) salda powinny być przekazywane w trybie wartości przeniesienia. Nadawca odejmuje saldo, a odbiorca dodaje je z powrotem lub odrzuca.

  • Scenariusz ataku: Jeśli nie zostanie odpowiednio potraktowany, saldo Jettona może zostać zmanipulowane.

  • Zalecenie: Użyj trybu wartości przeniesionej, aby zapewnić prawidłowy transfer wartości.

20. Zachowaj ostrożność w przypadku zwrotu nadwyżki kosztów paliwa

  • Dotkliwość: wysoka

  • Opis: Jeżeli nadwyżka opłat za gaz nie zostanie zwrócona nadawcy, środki mogą z czasem gromadzić się w umowie. W zasadzie nie jest to nic strasznego, ale jest to podejście nieoptymalne. Można dodać funkcję usuwania nadmiernych opłat, ale popularne kontrakty, takie jak TON Jetton, nadal będą zwracać do nadawcy komunikaty o nadmiernych opłatach „op::excesses”.

21. Sprawdź wartość zwracaną przez funkcję

  • Dotkliwość: wysoka

  • Opis: Funkcje zawsze zwracają wartość lub błąd. Jeśli zignorujesz sprawdzenie zwracanej wartości, może to prowadzić do krytycznego błędu logicznego.

  • Scenariusz ataku:

  • Zalecenie: Zawsze sprawdzaj wartość zwracaną przez funkcję.

22. Sprawdź, czy nie ma fałszywych tokenów Jetton

  • Dotkliwość: wysoka

  • Opis: Token Jetton składa się z dwóch części: „jetton-minter” i „jetton-wallet”. Jeśli umowa skarbca nie zostanie odpowiednio sprawdzona, osoba atakująca może wyczerpać środki ze skarbca, deponując fałszywe tokeny i wycofując cenne tokeny.

  • Scenariusz ataku:

  • Zalecenie: Sprawdź, czy nadawca wysyła fałszywe tokeny Jetton, obliczając adres portfela Jetton użytkownika.

napisz na końcu

Dla programistów przestrzeganie tych najlepszych praktyk może skutecznie poprawić bezpieczeństwo inteligentnych kontraktów i zmniejszyć potencjalne zagrożenia bezpieczeństwa. Dziś, wraz z szybkim rozwojem technologii blockchain, bezpieczeństwo jest zawsze najwyższym priorytetem. Mamy nadzieję, że ta najlepsza praktyka pomoże większej liczbie programistów tworzyć bezpieczne i niezawodne inteligentne kontrakty oraz promować zdrowy rozwój technologii blockchain.

Linki referencyjne:

[1] https://dev.to/dvlkv/drawing-conclusions-from-ton-hack-challenge-1aep

[2] https://docs.ton.org/develop/smart-contracts/security/ton-hack-challenge-1

[3] https://docs.ton.org/learn/tvm-instructions/tvm-overview

[4] https://docs.ton.org/develop/smart-contracts/messages

[5] https://docs.ton.org/develop/smart-contracts/security/secure-programming

[6] https://docs.ton.org/develop/smart-contracts/security/things-to-focus

Autor |

Redaktor |

Skład |