DApps - Decentralized Applications
Reading time: 5 minutes
{{#include ../../banners/hacktricks-training.md}}
What is a DApp?
DApp ni programu isiyo na kati inayofanya kazi kwenye mtandao wa mtu kwa mtu, badala ya kuwa kwenye seva ya kati. DApps kwa kawaida zimejengwa kwenye teknolojia ya blockchain, ambayo inapaswa kuruhusu uwazi, usalama, na kutoweza kubadilishwa kwa data.
Web3 DApp Architecture
Kulingana na hiki kifungu kuna aina 3 tofauti za usanifu wa Web3 DApps:
"API-less" DApps
DApps hizi zimejengwa juu ya blockchain na hazitegemei APIs au backend za kati. Unaweza kufikiria kwamba blockchain ndiyo backend halisi ya programu. Ziko kabisa zisizo na kati na zinaweza kufikiwa moja kwa moja kupitia blockchain.
Ili kuingiliana na blockchain, mteja kwa kawaida atatumia wallet. Wallet itatia saini muamala na kuwatuma kwa blockchain. Mteja pia anaweza kutumia node kusoma data kutoka kwa blockchain.
"API-Enabled" DApps
DApps hizi zimejengwa juu ya blockchain lakini pia zinategemea APIs za kati kwa kawaida ili kukusanya taarifa. Ziko zaidi ya zisizo na kati kwa sababu hata kama zinategemea API ya kati, kazi kuu ya DApp bado iko kwenye blockchain. Mawasiliano ya mteja na blockchain kwa kawaida hufanywa kupitia wallet.
Mfano mzuri wa aina hii ya DApp ni NFT minting application. Seva inaruhusu kupakia picha lakini minting inafanywa na mteja kupitia wallet.
"Full-Scale" DApps
DApps hizi zimejengwa juu ya blockchain lakini pia zinategemea APIs za kati na seva za backend. Zinaweza kuwa zisizo na kati kwa sehemu kwani mteja anaweza kufanya operesheni kwenye blockchain kwa kutumia wallet. Hata hivyo, kwa kawaida backend pia itakuwa na uwezo wa kufanya operesheni kwenye blockchain.
Mfano mzuri wa aina hii ya DApp ni daraja la cross-chain ambapo sehemu ya offchain inahitajika ili kuwasiliana na mikataba smart katika blockchains tofauti ili kufanya uhamisho wa mali.
Web2 vulnerabilities
Vulnerabilities za Web2 bado zinaathiri aina hizi za programu ingawa athari zao zinaweza kutofautiana:
- Vulnerabilities za upande wa mteja zina athari kubwa zaidi kwani katika DApps za Web3, mteja kwa kawaida ndiye anayefanya operesheni kwenye blockchain kupitia wallet. Hii inamaanisha kwamba mashambulizi kama XSS yanayoweza kutekeleza msimbo wa JS upande wa mteja au kubadilisha maudhui ya ukurasa yanaweza kuwa na athari kubwa zaidi kwani yanaweza kuingiliana na wallet na kumshawishi mtumiaji kufanya operesheni zisizotakiwa kwenye blockchain.
- Kumbuka kwamba kwa kawaida hata katika aina hizi za programu, mteja bado anaweza kupitia operesheni kabla ya kuziweka saini na wallet. Hata hivyo, ikiwa mshambuliaji anaweza kubadilisha maudhui ya ukurasa, anaweza kumshawishi mtumiaji kuweka saini muamala ambao utafanya operesheni isiyotakiwa kwenye blockchain.
- Vulnerabilities za upande wa seva bado zipo katika DApps zinazotegemea seva ya backend. Athari za vulnerabilities hizi zitategemea usanifu wa DApp. Hata hivyo, zinaweza kuwa na matatizo makubwa kwani mshambuliaji anaweza kupata funguo za kampuni kwenye backend ili kufikia fedha za mikataba smart, au anaweza kufanya kuchukua akaunti ambayo inaweza kuwapa uwezo wa kuiba fedha au NFTs kutoka kwa watumiaji.
Kwa hakika, ikiwa DApp haitumii backend au backend inayotumika inatoa tu data za umma au kurasa za static, uso wa shambulio wa DApp unakuwa mdogo.
Web3 attack surface
Hata kama kwa ujumla DApp ina uso wa shambulio mdogo kwani ukaguzi kadhaa wa usalama daima hufanywa kwenye blockchain, bado kuna baadhi ya njia za shambulio ambazo zinaweza kutumiwa na mshambuliaji.
Inaweza kuwa inawezekana kuunganisha vulnerabilities za web3 DApps katika makundi yafuatayo:
-
Mishandled On-Chain Transactions: APIs za muamala zisizo sahihi au zisizo na mipaka, ukosefu wa mantiki ya kusubiri majibu na uthibitisho wa block, kufichuliwa kwa data nyeti, na usimamizi usiofaa wa muamala uliofeli, ulioondolewa, au wa ndani ambao unaruhusu sindano za data mbaya.
-
Smart-Contract-Driven Backend Attacks: kuhifadhi au kusawazisha data nyeti kati ya mikataba na hifadhidata bila uthibitisho, kutolewa kwa matukio yasiyoangaliwa au anwani za mikataba, na vulnerabilities za mikataba zinazoweza kutumiwa ambazo zinaweza kuharibu mantiki ya backend.
-
Flawed Crypto-Asset Operations: kushughulikia vibaya aina tofauti za token (asili vs. ERC-20), kupuuza usahihi wa desimali, muamala uliofeli au muamala wa ndani, na kukubali token bandia, za kupungua, rebase, au zinazoweza kuathiriwa bila uthibitisho, na kuruhusu sindano za payload kupitia metadata ya token.
Baadhi ya mifano kutoka hiki kifungu:
Wasting Funds: Forcing backend to perform transactions
Katika hali Wasted Crypto in Gas via Unrestricted API
, mshambuliaji anaweza kulazimisha backend kuita kazi za mikataba smart ambazo zitakula gesi. Mshambuliaji, akituma nambari ya akaunti ya ETH na bila mipaka, atalazimisha backend kuita mikataba smart kuisajili, ambayo itakula gesi.
DoS: Poor transaction handling time
Katika hali Poor Transaction Time Handling Leads to DoS
, inaelezwa kwamba kwa sababu backend itakuwa na ombi la HTTP wazi hadi muamala ufanyike, mtumiaji anaweza kwa urahisi kutuma maombi kadhaa ya HTTP kwa backend, ambayo itakula rasilimali zote za backend na kusababisha DoS.
Backend<-->Blockchain desync - Race condition
Katika hali Poor Transaction Time Handling Leads to Race Condition
, inaelezwa kwamba katika mchezo ilikuwa inawezekana kwa mtumiaji kutuma ombi la kutoa kwa backend ambayo itatuma kwa mtumiaji sarafu zake lakini wakati muamala bado unashughulikiwa, mtumiaji alikuwa na uwezo wa kutumia sarafu hizo kununua vitu katika mchezo, akivipata bure.
Mfano mwingine unaweza kuwa kuwa na uwezo wa kutumia sarafu hizo hizo kununua vitu tofauti kwani backend mara moja inampa mtumiaji kitu bila kusubiri muamala uthibitishwe na hivyo kusubiri salio la mtumiaji kwenye blockchain kupunguzwa.
Smart contract address validation
Katika hali Bridge Backend Lacks Smart Contract Address Validation
inaelezwa jinsi backend ilikuwa ikikagua anwani ya mikataba smart, hivyo ilikuwa inawezekana kwa mshambuliaji kupeleka mikataba smart bandia, kuweka fedha kwenye hiyo, kutuma muamala kwa backend na backend itafikiri kwamba mtumiaji alituma fedha kwa mikataba smart halisi na itampa mtumiaji token.
Mishandling of Asset Classes
Katika hali Mishandling of Asset Classes
, inaelezwa kwamba backend ilichanganya NFT ya udanganyifu katika anwani na 1 MATIC, hivyo kumruhusu mshambuliaji kutuma mamia ya NFT za udanganyifu kwenye anwani hiyo na kupata 1 MATIC kutoka kwa jukwaa kwa kila moja yao.
References
{{#include ../../banners/hacktricks-training.md}}