Samodzielna kontrola inteligentnych kontraktów za pomocą ChatGPT

Podczas audytu inteligentnych kontraktów należy uwzględnić szeroki zakres zagadnień, aby zapewnić bezpieczeństwo kodu. Pytania te obejmują różne aspekty, w tym kontrolę dostępu, zarządzanie zasobami, zarządzanie danymi, założenia, zależności i listy kontrolne bezpieczeństwa. Poniżej przedstawiamy szczegółową listę kontrolną i instrukcje dotyczące zapytań ChatGPT, które poprowadzą Cię przez proces audytu inteligentnego kontraktu.

Jeśli chcesz samodzielnie zbadać inteligentny kontrakt pod kątem luk w zabezpieczeniach i ukrytych technik oszustwa, pierwszym krokiem jest poprawnie spreparowany monit ChatGPT.

Przydatnym zapytaniem dla ChatGPT byłoby następujące polecenie:

Podaj wyczerpującą listę wszystkich problemów i luk w poniższym inteligentnym kontrakcie. Szczegółowo opisz problemy i możliwe podatności. Podaj jeden scenariusz wykorzystania dla każdej luki. Dane wyjściowe jako prawidłowa tabela w formacie markdown z listą obiektów, każdy z kolumnami "opis", "akcja", "dotkliwość", "aktorzy", "scenariusz", "typ" i "wiersz". "typ", gdzie może być "użyteczność", "podatność", "optymalizacja" lub "sugestia". "actors" to lista zaangażowanych podmiotów. "dotkliwość" może być "niska", "średnia" lub "wysoka". "row" to numer wiersza problemu. Upewnij się, że wszystkie pola w tabeli są wypełnione.

Następnie użyj poniższych pytań, aby dokładniej zbadać inteligentny kontrakt.

Scenariusze użycia:

1. Kim są aktorzy w systemie?


2. Jakie działania ma system?


3. Jakie są ograniczenia systemu?


4. Jakie są potencjalne sposoby złamania systemu?


5. Jakie mechanizmy obronne są używane do odpierania ataków?


6. Opisz, w oparciu o ograniczenia, zmiany stanu każdej funkcji.


7. Podaj informacje o używanych szablonach Solidity i DeFi.


8. Opisz pozytywne i negatywne aksjomaty na podstawie informacji o systemie.


9. Wymień sposoby optymalizacji i modyfikacji kodu, aby uczynić go bardziej niezawodnym (z fragmentami kodu).


10. Wymień ukryte metody oszustwa używane w kodzie (z fragmentami kodu).

Wskazówka: Wizualna reprezentacja danych często zapewnia lepsze zrozumienie działania systemu. Podczas pracy z ChatGPT zalecane jest żądanie wizualizacji danych wyjściowych, takich jak modyfikacje stanu w postaci diagramów znaków ASCII. Chociaż nie wszystkie wizualizacje mogą mieć sens, niektóre mogą zapewnić bardzo cenny wgląd w działanie inteligentnego kontraktu.

W rzeczywistości, chociaż ChatGPT nie może zastąpić ludzkiego audytora, znacznie uzupełnia proces audytu, zapewniając lepsze zrozumienie przejść stanu protokołu, ograniczeń, niezmienników i zgodności. Narzędzie to jest szczególnie skuteczne w zrozumieniu przejść stanu protokołu i ograniczeń.

Wskazówka: Przed rozpoczęciem audytu, dostarczenie chatbotowi dokumentacji dotyczącej audytowanego protokołu może znacznie poprawić dokładność i trafność odpowiedzi. Wystarczy wspomnieć: "To jest dokumentacja, która zapewnia najlepszy kontekst dla 'nazwa_protokołu', który poddaję audytowi" i wstawić dokument.

Można powiedzieć, że ChatGPT jest potężnym asystentem dla audytorów, zapewniającym ustrukturyzowane i dogłębne podejście do audytu inteligentnych kontraktów. Należy jednak pamiętać, że ChatGTP (i podobne usługi) to tylko złożone interpretacje analizy maszynowej pracującej z prawdopodobieństwami, więc często powoduje błędy i nieścisłości. W związku z tym nie można w pełni polegać na wynikach ChatGPT - jest to tylko dobre narzędzie we właściwych rękach i "punkt wyjścia" w badaniach nad inteligentnymi kontraktami.

Dlatego, aby uchronić się przed możliwymi zagrożeniami, inteligentne kontrakty powinny być dokładniej badane pod kątem możliwych luk w zabezpieczeniach i nieuczciwych schematów.

Jak przeprowadzić dogłębny audyt inteligentnych kontraktów? Top 100 zapytań do ChatGPT

Powyżej rozważyliśmy ogólne zapytanie (monit) do ChatGPT, od którego można rozpocząć analizę inteligentnego kontraktu. Ale oczywiście szczegółowa analiza nie ogranicza się do wstępnego monitu.

Oszuści stale ulepszają swoje taktyki, więc musisz być poinformowany i ostrożny w wielu aspektach - są to podstawowe strategie ochrony inwestycji w tokeny.

Przyjrzyjrzyjmy się liście 100 najlepszych zapytań, które zapewnią profesjonalne podejście do audytu inteligentnego kontraktu:

1. Czy kod kompiluje się pomyślnie?
2. Jaka wersja Solidity jest używana w kodzie? Czy jest to aktualna stabilna wersja?
3. Czy obecne są jasne komentarze wyjaśniające przeznaczenie funkcji i zmiennych?
4. Czy kontrakt wykorzystuje schemat "Ownable"? Jeśli tak, to dla których funkcji?
5. Czy zmienne stanu są prawidłowo przydzielane przy użyciu modyfikatorów widoczności?
6. Czy zdarzenia są używane do prawidłowego rejestrowania?
7. Czy dostarczane są przyjazne dla użytkownika komunikaty o błędach?
8. Czy sprawdzana jest wartość zwracana wywołań niskiego poziomu?
9. Czy istnieją scenariusze, w których właściciel może autoryzować się, co może prowadzić do ciągnięcia dywanu?
10. Kto ma kontrolę nad kontami uprzywilejowanymi i jakie są mechanizmy kontroli?
11. Jakie mechanizmy zarządzania istnieją w umowie i czy zarządzanie jest w pełni otwarte czy ograniczone?
12. Czy inne umowy są używane w systemie i jakie role pełnią (np. umowa proxy)?
13. Czy istnieje mechanizm blokady czasowej i czy można go obejść?
14. Czy dostępna jest odpowiednia dokumentacja?
15. Czy w kodzie występują potencjalne luki w zabezpieczeniach przed atakami DoS lub reentrancy?
16. Czy wszystkie funkcje są wewnętrzne, z wyjątkiem tych, które są wyraźnie wymagane jako publiczne/zewnętrzne?
17. Brak przepełnień/niedopełnień arytmetycznych w operacjach matematycznych?
18. Czy używana jest bezpieczna biblioteka OpenZeppelin?
19. Czy eter lub tokeny nie mogą zostać przypadkowo wysłane na adres zerowy (0x0)?
20. Czy warunki są sprawdzane za pomocą require przed operacjami i zmianami stanu?
21. Czy stan jest ustawiany przed i w trakcie wykonywania akcji?
22. Czy stosowana jest ochrona przed atakami typu reentry (ponowne wejście) (A wywołuje B wywołuje A)?
23. Czy interfejs ERC20 jest prawidłowo zaimplementowany?
24. Czy modyfikator jest używany w wielu miejscach tylko wtedy, gdy jest to naprawdę konieczne?
25. Czy wszystkie typy są ustawione jawnie (np. uint256 jest używany zamiast uint)?
26. Czy wszystkie metody i cykle mieszczą się w maksymalnym dopuszczalnym limicie gazu?
27. Brak niepotrzebnych inicjalizacji w konstruktorze (pamiętaj, że ustawione są wartości domyślne)?
28. Całkowite pokrycie testami: przetestowano każdą metodę inteligentnego kontraktu i wszystkie możliwe typy danych wejściowych?
29. Czy przeprowadzono testy rozmyte przy użyciu losowych danych wejściowych?
30. Czy przetestowano wszystkie możliwe stany, w których może znajdować się kontrakt?
31. Czy domyślne ilości eteru i tokenów są określone w jednostkach wei?
32. Czy blok/czas zakończenia crowdsale następuje po bloku/czasie rozpoczęcia (rozpoczęcia/włączenia handlu)?
33. Czy kurs wymiany/konwersji tokenów crowdsale jest ustawiony prawidłowo?
34. Czy ustawiony jest miękki/twardy limit crowdsale?
35. Czy minimalny/maksymalny dopuszczalny wkład w crowdsale jest ustawiony i przetestowany?
36. Czy funkcjonalność białej listy crowdsale została przetestowana?
37. Czy logika zwrotu crowdsale została zweryfikowana?
38. Czy uczestnicy crowdsale otrzymują proporcjonalną liczbę tokenów lub mogą ubiegać się o swój wkład?
39. Czy czas trwania każdego etapu crowdsale (np, przedsprzedaż, sprzedaż publiczna) jest odpowiednio skonfigurowany?
40. Czy określa, które funkcje powinny być kontrolowane tylko przez właściciela (np, wstrzymanie crowdsale, przejście do innego etapu crowdsale, włączenie dystrybucji tokenów itp.)?
41. Czy logika nabywania uprawnień (vesting) crowdsale została sprawdzona?
42. Czy crowdsale ma tryb awaryjny, który po włączeniu przez właściciela ogranicza wywołania funkcji i zawiera funkcję zwrotu pieniędzy?
43. Crowdsale ma funkcję awaryjną, jeśli ma to sens.
44. Czy zaimportowane biblioteki zostały wstępnie sprawdzone i nie zawierają niepożądanych części, które mogą zostać zastąpione w przyszłych wersjach i mogą zostać wykorzystane do złośliwych celów?
45. Metody transferu tokenów (transfer) opakowane w require?
46. Czy require i assert są używane poprawnie? Metoda assert jest używana tylko do rzeczy, które nigdy nie powinny się zdarzyć, zwykle jest używana do sprawdzania stanu po wprowadzeniu zmian.
47. Czy istnieje obrona przed atakami rekurencyjnymi?
48. Czy długość dowolnych ciągów znaków na wejściu jest ograniczona?
49. Gdzie to możliwe, unikaj używania tablic i zamiast tego używaj mapowań?
50. Czy hashe blokowe nie są używane do obsługi losowych wartości (górnicy mogą mieć na to wpływ)?
51. Czy tx.origin nie jest nigdzie używany?
52. Czy elementy tablicy są przesuwane w dół, gdy element jest usuwany, aby nie pozostawiać luk?
53. Czy revert jest używany zamiast throw?
54. Czy funkcje kończą się natychmiast, jeśli warunki nie są spełnione?
55. Czy ostrzeżenia kompilatora zostały rozwiązane?
56. Czy biblioteka SafeMath jest używana w obliczeniach?
57. Czy jakiekolwiek gniazda pamięci (gniazda przechowywania) są odczytywane więcej niż jeden raz?
58. Czy używane są jakieś nieograniczone pętle / tablice, które mogą powodować DoS?
59. Czy block.timestamp jest używany tylko dla długich interwałów?
60. Nie używając block. number do obliczania czasu, który upłynął?
61. Czy unika się wywoływania delegatecall, zwłaszcza w przypadku zewnętrznych (nawet jeśli zaufanych) kontraktów?
62. Czy długość tablicy nie jest aktualizowana podczas iteracji po niej?
63. Czy podpisy są chronione przed odtworzeniem za pomocą nonce i block.chainid?
64. Upewnij się, że wszystkie podpisy używają EIP-712?
65. Wynik abi.encodePacked() nie powinien być hashowany, jeśli używane są więcej niż 2 typy dynamiczne. Ogólnie rzecz biorąc, lepiej jest używać abi.encode().
66. Dokładnie sprawdzaj wstawki kodu asemblera.
67. Unikaj niewystarczającego zużycia gazu (gas griefing).
68. Czy wszystkie prywatne dane są naprawdę prywatne?
69. Czy aktualizacja struktury / tablicy w pamięci (memory) nie zmieni jej w magazynie (stage)?
70. Czy zmienne stage są przesłonięte?
71. Czy obliczanie wartości zmiennej w locie jest tańsze niż jej przechowywanie?
72. Czy wszystkie zmienne stanu są odczytywane z właściwego kontraktu (master vs. clone)?
73. Czy operatory porównania (>, <, >=, <=) są używane poprawnie, zwłaszcza w celu zapobiegania błędom off-by-one?
74. Czy operatory logiczne (==, ! =, &&, ||, !) są używane poprawnie, zwłaszcza w celu zapobiegania błędom typu "off-by-one"?
75. Czy mnożenie jest zawsze wykonywane przed dzieleniem (chyba że mnożenie może spowodować przepełnienie)?
76. Czy liczby magiczne są zastępowane stałą o intuicyjnej nazwie?
77. Jeśli odbiorca ETH ma funkcję awaryjną (fallback ), którą można cofnąć, czy może to prowadzić do DoS?
78. Czy używany jest standard SafeERC20 i czy wartości zwracane są sprawdzane w bezpieczny sposób?
79. Czy zakłada się, że nadawca msg. nadawca jest zawsze odpowiednim użytkownikiem?
80. Czy tx.origin nie jest używany do autoryzacji?
81. Czy address.transfer() lub address.send() nie są używane zamiast .call.value()?
82. Przy korzystaniu z wywołań niskiego poziomu upewnij się, że przed wywołaniem istnieje umowa.
83. Czy kod asemblera jest używany do uzyskania dostępu do chainid lub kodu kontraktu / rozmiaru / skrótu zamiast składni Solidity?
84. Czy słowo kluczowe delete jest używane podczas ustawiania zmiennej na wartość null (0, false, "" itp.)?
85. Wyrażenia przekazywane do operatorów logicznych/porównań (&&/||/>=/==/itp) nie mogą mieć efektów ubocznych.
86. Kiedy masz do czynienia z wieloma adresami, zadaj sobie pytanie, co się stanie, jeśli są one takie same?
87. Jak dobrze udokumentowany jest kod? Czy komentarze i przykłady są dostarczane wszędzie tam, gdzie używany jest niestandardowy kod?
88. Jeśli używane jest wywołanie zewnętrzne, upewnij się, że zewnętrzne wywołanie umowy jest naprawdę konieczne?
89. Czy wynik wywołania zewnętrznego jest sprawdzany i czy obsługiwane są błędy?
90. Co się stanie, jeśli wywołanie zewnętrzne wykorzysta cały dostarczony gaz?
91. Jeśli wywołanie zewnętrzne wywołuje określoną funkcję, upewnij się, że funkcja faktycznie istnieje (funkcje fantomowe).
92. Upewnij się, że żadne zewnętrzne wywołania nie są używane w modyfikatorach
93. Czy zdarzenia są generowane dla każdej funkcji, która modyfikuje pamięć?
94. Sprawdź swoje założenia dotyczące tego, co zewnętrzne kontrakty używane w main robią i zwracają.
95. Uważaj na tokeny, które używają zbyt wielu lub zbyt mało miejsc po przecinku. Upewnij się, że maksymalne i minimalne obsługiwane wartości są udokumentowane.
96. Czy uprawnienia związane z rolami są udokumentowane?
97. Jakie są zagrożenia w przypadku naruszenia praw dostępu i jak może to wpłynąć na różne komponenty systemu?
98. Czy właściciel może manipulować tokenami i ETH w ramach umowy?
99. Jak jest ustawiony adres wyroczni (Oracle) i jaki proces za tym stoi? Czy istnieją zapasowe wyrocznie do tworzenia kopii zapasowych?
100. Jak podobne funkcje są wdrażane w innych projektach, czy uwzględniono najlepsze praktyki?

Ta lista kontrolna pomoże ci zapewnić przeprowadzenie dokładnego audytu bezpieczeństwa inteligentnych kontraktów Solidity. Obejmuje ona szeroki zakres krytycznych aspektów w celu zidentyfikowania i złagodzenia potencjalnych luk w zabezpieczeniach i zagrożeń w kodzie i powiązanych systemach.

 

Mamy nadzieję, że te przykłady pomogły Ci lepiej zrozumieć metodologię audytu inteligentnych kontraktów.

 

Ponieważ wszystkie informacje w łańcuchu bloków są otwarte (oczywiście pod warunkiem, że kod źródłowy kontraktu jest zweryfikowany), uzbrojony w tę wiedzę możesz niezależnie badać inteligentne kontrakty i identyfikować różne schematy oszustw.

Jednak już zrobiliśmy to wszystko za Ciebie! Zarejestruj się w subskrypcji premium i uzyskaj dostęp do ekskluzywnych filtrów funkcji inteligentnych kontraktów i świeżych analiz. Zwiększ swoje szanse na udane inwestycje w dochodowe tokeny.

Regards, Lotus Market team.

All posts