Smart contracts with functions BlackList

Folytatjuk a cikksorozatot, amely a csalásos sémáknak az okostárcákban való leírására összpontosít. Ma a Black List funkciókat (BlackList) tartalmazó okostárcák elemzésével foglalkozunk.

A Black List funkciókkal (BlackList) rendelkező okostárcák veszélyei:

Azok az okostárcák, amelyek Blacklist funkciókat tartalmaznak, bizonyos kockázatokkal és problémákkal járnak mind a projekt, mind annak felhasználói számára. Íme néhány veszély, amely a blacklist funkciókkal kapcsolatos:

1. Centralizált irányítás: A Blacklist funkciók gyakran centralizált irányítást biztosítanak a szerződés tulajdonosának vagy adminisztrátorainak.


2. Blacklist visszaélés tisztességtelen gyakorlatokhoz: Visszaélők (beleértve a szerződés tulajdonosát) felhasználhatják a blacklistet konkrét címek megbüntetésére. Ez magában foglalhatja a fiókok befagyasztását vagy funkcióik korlátozását indok nélkül.


3. Átláthatóság hiánya: A blacklist funkciók létezése, különösen ha nem dokumentáltak, átláthatatlanságot eredményezhet. A felhasználók nem feltétlenül ismerik a blacklist kritériumait vagy a blacklistelés eljárását.


4. Biztonsági kockázatok: Ha a BlackList nem biztonságosan van implementálva, fennáll annak a veszélye, hogy sebezhetőségek alakulnak ki, amelyek lehetővé teszik illetéktelen felek számára a blacklist manipulálását, ami jogtalan befagyasztáshoz vagy alapok átutalásához vezethet.


5. Felhasználói bizalmatlanság: A blacklist funkciók léte alááshatja a felhasználói bizalmat, mivel eszközeiket blacklistelhetik anélkül, hogy világos szabályok lennének.


6. Token elkobzása: Támadók a blacklist segítségével lefoglalhatják a tokeneket vagy eszközöket bizonyos címekről való megfelelő indok nélkül. Ez jelentős pénzügyi veszteségeket okozhat.

Hogyan tudja függetlenül meghatározni, hogy az ilyen fenyegetések jelen vannak-e az okostárcákban?

Amikor egy okostárcát validál, bizonyos lépéseket tehet annak érdekében, hogy megállapítsa, fenyegetést jelentenek-e a blacklist funkciók:

• Mielőtt elkezdené a munkát egy okostárcával, alaposan olvassa el és tanulmányozza meg annak kódját, beleértve az összes blacklisteléssel kapcsolatos funkciót. Keresse azokat a funkciókat, amelyek a blacklisteléssel, befagyasztással vagy fiók funkcióinak korlátozásával kapcsolatosak. Ellenőrizze, hogy vannak-e olyan funkciók, amelyek lehetővé teszik a címek hozzáadását vagy eltávolítását a blacklistről.


• Vizsgálja meg, hogy ki rendelkezik tulajdonjoggal vagy adminisztratív ellenőrzéssel a szerződés felett. Értékelje, hogy mennyi irányítás és jog kapcsolódik a tulajdonoshoz vagy az adminisztrátorokhoz.


• Vizsgálja meg a szerződés dokumentációját annak érdekében, hogy megértse, hogyan tervezték a blacklist funkciók használatát. Keresse azokat az információkat, amelyek a blacklist használatát szabályozó irányítási mechanizmusokról szólnak.


• Értékelje az átláthatóságot: Biztosítja-e a szerződés, hogy a blacklist kritériumok átláthatóak legyenek? Ellenőrizze, hogy vannak-e világos eljárások a hamis pozitívumok megszüntetésére vagy a címek eltávolítására a blacklistről.


• Biztonsági auditok: Ellenőrizze, hogy a smart contract átesett-e biztonsági auditokon elismert harmadik felek által.


• Ismerkedjen meg a közösség visszajelzéseivel vagy az online fórumokkal kapcsolatos fekete listák használatáról a projektekben. Figyelmeztessen a közösség által felvetett piros zászlókra, amelyek tisztességtelen gyakorlatokra vagy átláthatatlanságra utalhatnak.


• Alapos elemzés végzésével és a fenti tényezők figyelembevételével jobban képes lesz értékelni a fekete lista funkciók okozta kockázatokat az okostárcákban. Maradjon naprakész a közösségünk legújabb fejleményeivel kapcsolatban (Telegram csatorna) és a csalások észlelése legjobb gyakorlataival (Blogunk és YouTube csatornánk).

 

Jó hír: Biztonsági szkennelőnk 99,9%-ban azonosítja az összes gyakori (beleértve a rejtett) Blacklist funkciót (BlackList). Használja prémium előfizetésünket, és védelmezze alapjait a fenyegetésektől.

 

Következő lépésben néhány gyakori példát vizsgálunk meg BlackList funkciókra, amelyeket platformunk sikeresen azonosít.

Vegye figyelembe, hogy ezek egyszerűsített példák, és az aktuális végrehajtás eltérhet. Az okostárcák elemzése során mindig végezzen alapos kódértékelést és vegye figyelembe a kontextusfüggő tényezőket.

Példa 1: A Black List alapvető funkciója

    contract TokenWithBlackListAndFee {
      address public owner;
      mapping(address => bool) public BlackList;
      uint256 public BlackListFee;
  
      constructor(uint256 _fee) {
          owner = msg.sender;
          BlackListFee = _fee;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackListWithFee(address _account) public payable onlyOwner {
          require(msg.value >= BlackListFee, "Insufficient fee");
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  }

Azonosítási tippek: Keresse azokat a funkciókat (például addToBlackList és removeFromBlackList), amelyek hozzáférési módosítókkal rendelkeznek (csak tulajdonos). Az ilyen módosítók jelenléte azt jelenti, hogy csak a tulajdonos módosíthatja a blacklistet.

Példa 2: Blacklist díjmechanizmussal (BlackList díjmechanizmus)

    contract TokenWithBlackListAndFee {
      address public owner;
      mapping(address => bool) public BlackList;
      uint256 public BlackListFee;
  
      constructor(uint256 _fee) {
          owner = msg.sender;
          BlackListFee = _fee;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackListWithFee(address _account) public payable onlyOwner {
          require(msg.value >= BlackListFee, "Insufficient fee");
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  }

Azonosítási tippek:Függvények definiálása (például addToBlackListWithFee), amelyek feketelistára helyezéshez díjat (msg.value) igényelnek. Ez nagyon veszélyes jelzés.

Példa 3: Feketelista időfüggő feltételekkel

    contract TokenWithTimeLock {
      address public owner;
      mapping(address => bool) public BlackList;
      uint256 public BlackListTimeLock;
  
      constructor(uint256 _timeLock) {
          owner = msg.sender;
          BlackListTimeLock = _timeLock;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackListTimed(address _account) public onlyOwner {
          require(block.timestamp >= BlackListTimeLock, "Time lock not yet expired");
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  }

Azonosítási tippek:Függvények definiálása (például addToBlackListTimed), amelyek időzár függő feltételeket szabnak a feketelistára. Ez általában késleltetett vagy ütemezett feketelistákhoz használatos.

Példa 4: Feketelista események naplózásával

    contract TokenWithBlackListAndEvents {
      address public owner;
      mapping(address => bool) public BlackList;
  
      event AddressAddedToBlackList(address indexed account);
      event AddressRemovedFromBlackList(address indexed account);
  
      constructor() {
          owner = msg.sender;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackList(address _account) public onlyOwner {
          BlackList[_account] = true;
          emit AddressAddedToBlackList(_account);
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
          emit AddressRemovedFromBlackList(_account);
      }
  }

Azonosítási tippek:Esemény naplózás: Keresse azokat az eseményeket, amelyek rögzítik a feketelistára vonatkozó intézkedéseket. Az események átláthatóságot biztosítanak, és nagyon fontosak a szerződési intézkedések nyomon követésében. Azt mondhatjuk, hogy ez a legbiztonságosabb fajta BlackList, mivel a fejlesztők nem rejtik el ezt a funkciót, hanem nyíltan naplózzák minden hívását az eseménynaplókban.

Példa 5: Feketelista fehérlistafunkciókkal (WhiteList)

    contract TokenWithBlackListAndWhitelist {
      address public owner;
      mapping(address => bool) public BlackList;
      mapping(address => bool) public whitelist;
  
      constructor() {
          owner = msg.sender;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the lists");
          _;
      }
  
      function addToBlackList(address _account) public onlyOwner {
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  
      function addToWhitelist(address _account) public onlyOwner {
          whitelist[_account] = true;
      }
  
      function removeFromWhitelist(address _account) public onlyOwner {
          whitelist[_account] = false;
      }
  }

Azonosítási tippek:Fehérlistafunkció: Figyeljen olyan szerződésekre, amelyek egyszerre rendelkeznek feketelistázási és fehérlistázási funkciókkal. Az ilyen kettős funkcionalitás hatással lehet a tokenátutalásokra a tulajdonos tudta nélkül vagy egyéb csalásos tevékenységekre.

Példa 6: Feketelista kormányzati irányítással (Governance Control)

    interface Governance {
      function canBlackList(address _caller) external view returns (bool);
  }
  
  contract TokenWithGovernanceControl {
      address public owner;
      address public governanceContract;
      mapping(address => bool) public BlackList;
  
      constructor(address _governanceContract) {
          owner = msg.sender;
          governanceContract = _governanceContract;
      }
  
      modifier onlyOwnerOrGovernance() {
          require(msg.sender == owner || Governance(governanceContract).canBlackList(msg.sender), "Not authorized");
          _;
      }
  
      function addToBlackListGoverned(address _account) public onlyOwnerOrGovernance {
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwnerOrGovernance {
          BlackList[_account] = false;
      }
  }

Azonosítási tippek:Azon szerződések azonosítása, ahol a feketelistázási tevékenységek külső szerződéskezelők irányítása alatt állnak. Amikor egy okostárcát megvizsgál, alaposan elemezze a kódot, figyelve az hozzáférési szabályokra, fizetési mechanizmusokra, időfüggő feltételekre és feltételekre, esemény naplózásra, megkerülés elleni védelmi mechanizmusokra és más fontos tényezőkre. Ezen felül vegye figyelembe a projekt sajátosságait és céljait, amikor a feketelista funkciók használatának következményeit értékeli.

Példa 7: Feketelista vészhelyzet leállítással

    contract TokenWithEmergencyStop {
      address public owner;
      bool public emergencyStop;
      mapping(address => bool) public BlackList;
  
      constructor() {
          owner = msg.sender;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      modifier whenNotPaused() {
          require(!emergencyStop, "Contract is paused");
          _;
      }
  
      function addToBlackList(address _account) public onlyOwner whenNotPaused {
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner whenNotPaused {
          BlackList[_account] = false;
      }
  
      function toggleEmergencyStop() public onlyOwner {
          emergencyStop = !emergencyStop;
      }
  }

Azonosítási tippek:A leállítási mechanizmus néhány funkciót is leállíthat, beleértve a feketelistára vonatkozó változtatásokat.

Példa 8: Feketelista dinamikus feltételekkel

    contract TokenWithDynamicBlackList {
      address public owner;
      mapping(address => bool) public BlackList;
  
      constructor() {
          owner = msg.sender;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function conditionallyBlackList(address _account, uint256 _threshold) public onlyOwner {
          require(getBalance(_account) < _threshold, "Account balance exceeds threshold");
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  }

Azonosítási tippek:A feketelistázás gyakran bizonyos feltételekhez vagy eseményekhez kapcsolódhat. Alaposan tanulmányozza azokat a funkciókat, amelyeket ellenőriznek a feketelistázás aktiválása előtt. Ezek a funkciók tartalmazzák a tulajdonos feketelistázására vonatkozó logikát, ebben a példában a feltétel az, hogy az egyenleg a megadott küszöbértéket meghaladja.

Példa 9: Időzített eltávolítású feketelista (Időzített eltávolítású feketelista)

    contract TokenWithTimeLockedRemoval {
      address public owner;
      mapping(address => bool) public BlackList;
      mapping(address => uint256) public removalTimeLock;
  
      constructor() {
          owner = msg.sender;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackList(address _account) public onlyOwner {
          BlackList[_account] = true;
          removalTimeLock[_account] = block.timestamp + 7 days;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          require(block.timestamp >= removalTimeLock[_account], "Time lock not expired");
          BlackList[_account] = false;
          removalTimeLock[_account] = 0;
      }
  }

Azonosítási tippek:Azon szerződések azonosítása, ahol a feketelistázás eltávolítása időkorlátozott. Ilyen esetekben gyakran blokk.timestamp alapján számítják ki az időt.

Példa 10: Feketelista gázkorlátozással (Gas Limit Protection)

    contract TokenWithGasLimitProtection {
      address public owner;
      mapping(address => bool) public BlackList;
  
      constructor() {
          owner = msg.sender;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      modifier limitGas() {
          require(gasleft() >= 100000, "Insufficient gas");
          _;
      }
  
      function addToBlackListGasLimited(address _account) public onlyOwner limitGas {
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  }

Azonosítási tippek:Azon szerződések azonosítása, ahol bizonyos funkciók, például a feketelistázás, gázkorlátozások alatt állnak.

Példa 11: Feketelista külső integrációval Oracle-dal (Oracle)

    interface Oracle {
      function isBlackListed(address _account) external view returns (bool);
  }
  
  contract TokenWithOracleIntegration {
      address public owner;
      Oracle public oracle;
  
      constructor(address _oracleAddress) {
          owner = msg.sender;
          oracle = Oracle(_oracleAddress);
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackListByOracle(address _account) public onlyOwner {
          require(oracle.isBlackListed(_account), "Oracle did not confirm BlackListing");
      }
  }

Azonosítási tippek:Vigyázzon azokra a szerződésekre, amelyek külső Oracle-okra támaszkodnak a feketelistázási döntések meghozatalához. Mindig ellenőrizze az Oracle-ok megbízhatóságát és átláthatóságát, amelyeket az okostárcák használnak.

Példa 12: Feketelista külső szerződéssel történő interakcióval

    interface ExternalContract {
      function addToBlackList(address _account) external;
      function removeFromBlackList(address _account) external;
  }
  
  contract TokenWithExternalInteraction {
      address public owner;
      ExternalContract public externalContract;
  
      constructor(address _externalContract) {
          owner = msg.sender;
          externalContract = ExternalContract(_externalContract);
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackListExternal(address _account) public onlyOwner {
          externalContract.addToBlackList(_account);
      }
  
      function removeFromBlackListExternal(address _account) public onlyOwner {
          externalContract.removeFromBlackList(_account);
      }
  }    

Azonosítási tippek:A feketelistázási döntések meghozatalakor vigyázzon azokra a szerződésekre, amelyek külső szerződésekkel lépnek interakcióba, különösen akkor, ha az külső szerződés forráskódja nem ellenőrzött.

Példa 13: Feketelista dinamikus küszöbbel (Dynamic Threshold)

    contract TokenWithDynamicThreshold {
      address public owner;
      mapping(address => bool) public BlackList;
      uint256 public dynamicThreshold;
  
      constructor(uint256 _initialThreshold) {
          owner = msg.sender;
          dynamicThreshold = _initialThreshold;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackListDynamicThreshold(address _account) public onlyOwner {
          require(getBalance(_account) > dynamicThreshold, "Account balance is below threshold");
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  
      function updateDynamicThreshold(uint256 _newThreshold) public onlyOwner {
          dynamicThreshold = _newThreshold;
      }
  }

Azonosítási tippek:Azon szerződések azonosítása, ahol a feketelistázási küszöb dinamikus és az tulajdonos idővel beállítható (bizonyos szerződési módszerek meghívásával).

Általános tippek a Black List funkciók azonosításához (BlackList)

1. Keresse a címek listáját módosító funkciókat (mapping):
   Vizsgálja meg az okos szerződés kódját annak érdekében, hogy azonosítsa azokat a funkciókat, amelyek módosítják a címek listáját, például címek hozzáadását vagy eltávolítását.


2. Ellenőrizze a kizárólag tulajdonos hozzáférést:
   A feketelistázási funkciók gyakran hozzáférési korlátozásokkal rendelkeznek, amelyek csak a szerződés tulajdonosának vagy adminisztrátorainak engedélyezik a végrehajtásukat. Keresse a csak tulajdonos modifier használatát vagy hasonló hozzáférési ellenőrzési mechanizmusokat.


3. Vizsgálja meg a constructor() konstruktor függvényt:
   A constructor függvény meghatározza a szerződés kezdeti állapotát. Ellenőrizze, hogy van-e bármilyen cím kötés vagy lista inicializálva a constructorban, ami a feketelistát jelzi.


4. Fedezze fel a modifier logika:
   Vizsgálja meg az onlyOwner típusú modifier logikáját, hogy megértse, milyen feltételek mellett végezhetők el a feketelistázással kapcsolatos funkciók.


5. Keresse a kulcsszavakat:
   Keresse a "BlackList", "addBlackList", "removeBlackList" vagy hasonló kulcsszavakat a smart szerződés kódjában (egyszerű esetekben ezek a funkciók hasonló nevekkel rendelkeznek, összetettebb változatokban a nevek nem feltétlenül tükrözik a funkció lényegét, hogy elrejtsék azt).


6. Ellenőrizze a dokumentációt és a kommenteket:
   Nézze át a dokumentációt és a szerződés kommentjeit a feketelistázási funkciókra vonatkozóan. A fejlesztők gyakran adnak információt arról, hogyan kell használni bizonyos funkciókat, beleértve a feketelistázást is.


7. Ellenőrizze a külső hívásokat (call) vagy eseményeket (event):
   Keresse azokat a külső hívásokat vagy eseményeket, amelyeket akkor lehet kiváltani, amikor egy címet hozzáadnak vagy eltávolítanak a feketelistáról. Ez betekintést nyújthat abba, hogy hogyan lép kapcsolatba a szerződés külső komponensekkel a feketelistával kapcsolatos tevékenységek alapján.


8. Értékelje a szerződéskód frissítési és kezelési képességeit:
   Értékelje a smart szerződést az frissítési mechanizmusok vagy kormányzási struktúrák szempontjából, amelyek lehetővé teszik a feketelistázási logika változtatását. A frissítések kezelésének megértése kulcsfontosságú annak előrejelzésében, hogy milyen potenciális változások várhatók a feketelistafunkcionalitásban.


9. Ellenőrizze a feketelistával kapcsolatos logikát más funkciókban:
   Vizsgálja meg a szerződés más funkcióit annak megállapítására, hogy vannak-e ellenőrzések, amelyek meghatározzák, hogy egy cím feketelistán van-e, mielőtt bizonyos műveleteket végeznének.


10. Fedezze fel az alkalmazási eseteket és a tokenomikát:
    Ismerje meg a projekt felhasználási forgatókönyveit és tokenomikáját. Ha a projekt a felhasználói címkezeléssel kapcsolatos, vagy funkciói vannak a felhasználói jogokkal kapcsolatban, lehet, hogy van ok a feketelistázásra.


11. Esemény naplózás:
    Jegyezze fel a feketelistázási cselekvésekkel kapcsolatos eseménynaplót. Az események gyakran használatosak a jelentős állapotváltozások naplózására, átláthatóságot biztosítva a szerződés viselkedésére vonatkozóan.


12. Gázkorlátozó védelem:
    Ügyeljen azokra a funkciókra, amelyek gázkorlátozó védelmet biztosítanak. Bár ez biztonsági jellemző végrehajtása lehet, ugyanakkor felhasználható kritikus szerződési funkciók teljesítményének kontrollálására vagy korlátozására is.


13. Időfüggő feltételek:
    Ellenőrizze az időfüggő feltételeket a feketelistázással kapcsolatosan. Például a szerződések időzített zárolásokat alkalmazhatnak törlés vagy más időérzékeny mechanizmusokra.


14. Független átvilágítások:
    Keresse azokat a smart szerződéseket, amelyeket független átvilágítási cégek által vizsgáltak. Az átvilágítási jelentések betekintést nyújtanak a szerződés biztonságába és funkcionalitásába.


15. Vizsgálja meg a közösségi visszajelzéseket:
    Keresse meg a közösségi fórumokat, közösségi médiát vagy hivatalos kommunikációs csatornákat a feketelistázási funkciók jelenlétével és használatával kapcsolatos vitákhoz. A felhasználók értékes betekintéseket és aggodalmakat nyújthatnak.








 
16.  
17.  
18.  
19.  
20.  
21.  

Amikor egy smart szerződést elemzünk, kritikus fontosságú teljes körű megértést szerezni annak jellemzőiről és funkcionalitásáról. Ezek a tippek segítenek azonosítani és értékelni a feketelistafunkciók jelenlétét, lehetővé téve Önnek, hogy tájékozott döntéseket hozzon a szerződésekkel való interakció során.

Ahol lehetséges, válasszon olyan szerződéseket, amelyek megfelelnek az elismert szabványoknak (pl. ERC-20). Ezek a szabványok gyakran szigorú ellenőrzés alatt állnak és hírnevük van a megbízhatóság terén.

 

Reméljük, hogy ezek a példák segítettek jobban megérteni a Black List sémákat (BlackList) smart szerződésekben.

 

Mivel az összes információ a blokkláncon nyitott (feltéve, persze, hogy a szerződés forráskódja ellenőrzött), felfegyverkezve ezzel a tudással önállóan tanulmányozhatja a smart szerződéseket és azonosíthat különféle csalásos sémákat.

Azonban mindezt már mi is elvégeztük Önnek! Iratkozzon fel prémium előfizetésre, és hozzáférést kap a smart szerződés funkciók exkluzív szűrőihez és friss analitikáihoz. Növelje az esélyeit a nyereséges tokenekbe történő sikeres befektetésre.

Tisztelettel, Lotus Market csapata.

All posts