Detsember 16, 2021
Sissejuhatus
. 1inch meeskond palus meil need üle vaadata ja auditeerida Limiittellimuse protokoll v2 nutikad lepingud. Vaatasime koodi ja avaldame nüüd oma tulemused.
Ulatus
Auditeerisime kohustust 4d94eea25e4dac6271bfd703096a5c4a4d899b4a
Euroopa 1inch/limit-order-protocol
hoidla. Reguleerimisalasse kuulusid järgmised lepingud:
- OrderMixin.sol
- OrderRFQMixin.sol
- PredicateHelper.sol
- RevertReasonParser.sol
- Permitable.sol
- ChainlinkCalculator.sol
- ArgumentsDecoder.sol
- AmountCalculator.sol
- NonceManager.sol
- LimitOrderProtocol.sol
- ImmutableOwner.sol
- InteractiveNotificationReceiver.sol
- AggregatorInterface.sol
- IDaiLikePermit.sol
Sellest auditist jäeti välja ka kõik muud projektifailid ja kataloogid (sealhulgas testid) ning välised sõltuvused ja projektid, mänguteooria ja stiimulite disain. Eeldati, et välised koodi- ja lepingusõltuvused töötavad dokumenteeritud kujul ning 1-tollise pakutavad taustateenused toimivad protokolli parimates huvides.
Üldine tervis
Üldiselt leidsime, et projekti koodibaas on loetav ja hästi organiseeritud, kuigi see võiks kasu saada ulatuslikumast dokumentatsioonist, eriti koostekoodi plokkide, protokolli servajuhtude, kasutatavate varade/predikaatide/väliste ressursside kohta, pakutava taustateenuse kohustused/piirangud ja osalejate vaheline suhtlus. Projekt näeb palju vaeva, et muuta meetmed gaasitõhusaks, mõnikord isegi riskides sellega, et koodi on raskem põhjendada; tõstatame allpool sellega seotud probleemid. Kogu auditi ajal oli 1-tolline meeskond väga kättesaadav, tundlik ja temaga oli väga lihtne töötada.
Süsteemi ülevaade
Limiittellimuse protokoll võimaldab tellida makers
allkirjastada ahelaväliseid korraldusi märgivahetuste jaoks. Seejärel hõlbustab protokoll varem allkirjastatud tellimuste täitmist tellimuse alusel takers
. Tellimused on väga laiendatavad ja võivad staatiliselt helistada välislepingutele mitmes punktis kogu tellimuse täitmise protsessi jooksul. See laiendatavus lisab protokollile kasulikkust, kuid lisab nii keerukust kui ka suuremat rünnakupinda tellimustele endile.
Oluline on märkida, et tellimuse üksikasjade ahelas ei ole salvestatud. Tellimuste täitmisolekut või tühistamise olekut jälgitakse ainult tellimuse räsi kaudu. See eeldab, et tellimusi jagatakse võrgupõhiselt või tsentraliseeritud osapoole kaudu. Sel juhul kavatseb 1-tolline meeskond tegutseda selle tsentraliseeritud osapoolena, koondades allkirjastatud korraldused ja kasutades neid korraldusi oma muude protokollide likviidsuse allikana. Tellimused avaldatakse nende enda API kaudu, et kasutajad saaksid nendega suhelda.
See tsentraliseerimine annab 1-tollisele meeskonnale äärmise kontrolli selle üle, millised korraldused avaldatakse ja lõpuks täidetakse. See annab neile ka võimaluse tellimusi tsenseerida, mis võib olla kasulik pahatahtlike või petlike korralduste korral, kuid seda võidakse ka kuritarvitada ja võimaldada neil soodsa tellimuse korral mis tahes muu kasutaja ees käia, jättes seda API kaudu näitamata.
Privilegeeritud rollid
Kuigi lepingud, mille puhul seda rolli kasutatakse, ei kuulunud kohaldamisalasse, tuvastati üks privilegeeritud roll. An immutableOwner
on seatud ehitamise ajal volikirja loojale ja seda kasutatakse juurdepääsu piiramiseks volikirjale external
funktsioone.
Välised sõltuvused ja usalduse eeldused
Selle protokolli ülesehitus nõuab ahelaväliseid ja ahelasiseseid komponente ning seda hübriidmudelit saab kasutada mõningate meie aruandes tuvastatud rünnakuvektorite leevendamiseks, kuid selle võimaluse maksumus on suurem sõltuvus 1-tollisest meeskonnast ja infrastruktuurist.
Lisaks pakub Limit Order Protocol funktsioone, mis on mõeldud hindade hankimiseks Chainlinki oraaklitest. Eeldasime, et need oraaklid on ausad, juurdepääsetavad ja korralikult töötavad.
Lisaks on tellimuse paindlikkuse tõttu mitmeid kokkupuutepunkte välislepingutega, mida ei kinnitata. See tähendab, et pahatahtlik kasutaja võib selliseid kõnesid kuritarvitada ja esineda pahatahtlike lepingutega predikaatide, varade või oraaklitega, et tellimuste täitmise ajal toiminguid teha. Kuigi projekt on mõnes piirkonnas taassisenemise eest kaitstud, võivad sellised vektorid põhjustada teenuse keelamise rünnakuid või avastamata rämpsposti tellimusi. 1-tolline meeskond on teadlik, et teatud probleemid võivad ilmneda, kui protokolli jaoks kasutatakse võõraid lepinguid, ja on teatanud oma kavatsusest, et projekt toetab täielikult ainult suuremaid "blue chip" varasid. Siiski tuleb märkida, et isegi kõige populaarsemate varade puhul on iga vara puhul omane käitumine, mis võib põhjustada probleeme protokollides, mis neid õigesti ei käsitle, näiteks USDT-ga ülekannete eest tasumine või veakoodi tagastamine edu boolean koos cTokenidega.
Järeldused
Siin tutvustame oma järeldusi.
Kriitiline raskusaste
Puudub.
Kõrge raskusastmega
[H01] Ebajärjekindlad andmed edastati _makeCall
aasta OrderMixin
leping, _makeCall
funktsiooni kasutatakse varade ülekandmiseks võtjalt tegijale ja siis tegijalt võtjale. Viimasel ülekandel on _makeCall
funktsioon on tellimusele valesti antud makerAsset
viimase parameetrina, kui see peaks olema tellimuse oma makerAssetData
.
Selle tulemusena saavad kõik puhverserveri funktsioonid, mis tuginevad makerAssetData
vaidlus katkeb.
Et olla kooskõlas varasema kõnega _makeCall
ja puhverserveri funktsionaalsuse täielikuks toetamiseks kaaluge versiooni värskendamist order.makerAsset
parameeter order.makerAssetData
.
Värskenda: Kinnitatud tõmbenumber # 57.
[H02] Osaliselt täidetud eratellimusi võivad täita kõik
Protokoll võimaldab luua era- ja avalikke tellimusi. Eratellimusel ainult allowedSender
aadress, mille tegija on tellimuse koostamisel täpsustanud, suudab tellimust täita.
Siiski OrderMixin
leping, valideerimine allowedSender
aadress on valesti reguleeritud, mis tähendab, et seda hinnatakse ainult loogikas, mis käsitleb tellimuse esimest täitmist. Kui eratellimus on osaliselt täidetud, siis tšekk allowedSender
aadress ei ole enam kättesaadav ja tellimus muutub kõigile täidetavaks.
Selgitamaks, kas mõni kasutaja peaks saama osaliselt täidetud eratellimusi täita või mitte, kaaluge praeguse käitumise põhjuse dokumenteerimist või allowedSender
aadress väljaspool esimese täitmise ulatust, et tagada selle kinnitamine iga kord, kui proovitakse täita.
Värskenda: Kinnitatud tõmbenumber # 58.
[H03] Pahatahtlik tegija võib ära kasutada osalisi täiteid, et varastada äravõtja vara
Tellimused OrderMixin
lepingut on võimalik osaliselt täita. Osalise täitmise toetamiseks nõuab protokoll vahetustehingute mõlema poole arvutamise viisi. Mõlemad getMakerAmount
ja getTakerAmount
väljad määrab tellimuse tegija täpselt selleks otstarbeks.
Tellimuse täitmisel peavad vastuvõtjad esitama kas makingAmount
või takingAmount
väärtused kui ka a thresholdAmount
väärtus. Sõltuvalt sellest, kas makingAmount
või takingAmount
oli ette nähtud.
Esimene on siis, kui makingAmount
parameeter on määratletud. Võiks küll kärpima the,en makingAmount
väärtus ja ka arvutama takingAmount
väärtus selle eest. Selles olukorras on thresholdAmount
tagab, et takingAmount
võetud väärtus on mitte ootamatult suur.
Teine on siis, kui takingAmount
parameeter on määratletud. Sellisel juhul saab arvutama makingAmount
väärtus, võimalusega selle kärpimine ja ümber arvutades takingAmount
väärtus, kui see juhtub. Selles olukorras on thresholdAmount
väärtus tagab, et makingAmount
tagastatud väärtus on mitte ootamatult väike.
On kaks kasutusmeetodit, millest igaüks on unikaalne ühele eelnimetatud kooditeedest. Need ekspluateerimismeetodid nõuavad pahatahtlikku getMakerAmount
ja getTakerAmount
funktsioonid. Nende funktsioonide lihtsal rakendamisel oleks sama käitumine AmountCalculator
s getMakerAmount
ja getTakerAmount
funktsioonid, kuid kõvakodeeritud lülitiga, mis sunnib neid vajadusel tagastama ründaja kontrollitud väärtuse.
Esimene, vähem tõsine ärakasutusmuster hõlmab esimest kooditeed, kus makingAmount
väärtus on määratud täitmise järjekorras. Pahatahtlik tegija ootaks täitmiskorraldust, mis täpsustab makingAmount
mempooli ilmuma, et seda eeskätt juhtida. Nad tühjendaksid tegija poolelt kogu väärtuse, välja arvatud 1, ja seejärel sundiksid _callGetTakerAmount
kasutaja määratud summa tagastamiseks thresholdAmount
väärtus (või nende hüvitis, kui see on väiksem). Kui kasutaja tehing lõpuks läbi saab, vahetavad nad kõik oma thresholdAmount
väärt takerAsset
ühe ühiku kohta makerAsset
. See ärakasutamine on piiratud summaga, mille annab thresholdAmount
väärtus või summa takerAsset
kasutajal lubatud LimitOrderProtocol
leping.
Teine, raskem ärakasutamismuster hõlmab teist kooditeed, kus takingAmount
väärtus on määratud. Pahatahtlik tegija ootaks samamoodi täitmiskäsku, mis täpsustab a takingAmount
väärtus mempoolis kuvamiseks. Nad käivitaksid tehingu ja sundiksid makingAmount
poolt tagastatud väärtus _callGetMakerAmount
funktsioon olema kõrgem kui mõlemad remainingMakerAmount
ja thresholdAmount
. Nad määraksid ka takingAmount
tagastas väärtuse _callGetTakerAmount
olema summa takerAsset
lubatud vara LimitOrderProtocol
võtja poolt. Kui võtja tehing läbi läheb, siis see ka läheb kärbima makingAmount
väärtus ja siis ümber arvutada takingAmount
väärtus. See ümberarvutus ei ole aga garanteeritud madalam ja sel juhul tühjendab saaja kõik takerAsset
et nad lepingusse lubasid. Sellel kooditeel on thresholdAmount
väärtus ei tagades, et makingAmount
ei ole liiga madal, nii et võttes kõik võtjad takerAsset
vara on märkimata. Kaotatud vahendid on piiratud summaga takerAsset
kasutajal lubatud vara LimitOrderProtocol
leping.
Need ärakasutamised pole võimalikud ilma osaliste korraldusteta ja täpsemalt pahatahtliku osaliste tellimusteta getMakerAmount
ja getTakerAmount
rakendused.
Peamine probleem thresholdAmount
väärtuse kontroll on see, et see katab ainult vahetustehingu ühte külge, kuid teist poolt saab manipuleerida frontrunningi kaudu. Puuduvad tagatised, et saaja algselt pakutud väärtus jääb muutumatuks. Kaaluge eemaldamist makingAmount
mõlema kooditee kärpimine ja ennistamine, kui tellimus ei toeta nii suurt täitmist, kui nõutud. Seda tehes, thresholdAmount
saab kasutada vahetustehingu teise poole piisavaks piiramiseks ja ootamatu käitumise vältimiseks isegi pahatahtlike korralduste korral.
Värskenda: Kinnitatud tõmbenumber # 83.
Keskmise raskusastmega
[M01] Staatilised argumendid edastatakse pärast dünaamilisi argumente
aasta OrderMixin
leping, getTakerAmount
ja getMakerAmount
baitide välju kasutatakse argumentidena _callGetTakerAmount
ja _callGetMakerAmount
funktsioonid. Need kõned võimaldavad arvutada vahetustehingu ühe poole teise poole põhjal ja võimaldavad kasutajatel tellimusi osaliselt täita.
. getTakerAmount
/getMakerAmount
väljad on dünaamilised muutujad ja on pakitud ees takerAmount
ja makerAmount
väärtused _callGetTakerAmount
ja _callGetMakerAmount
funktsioonid. Pahatahtlikul tegijal on võimalik esitada oodatust rohkem andmeid getTakerAmount
jagetMakerAmount
väljad suruda takerAmount
ja makerAmount
bait möödub sellest, kus nad järgmises funktsioonis dekodeerimisel eeldatavasti asuvad. See võimaldab tegijal nihutada sisestatud vastuvõtjat või tegijat täisbaitide võrra paremale ja isegi 32 lisabaidi andmemahu esitamisel need täielikult asendada.
Kasutajad peavad juba käsitsi üle vaatama getTakerAmount
ja getMakerAmount
väljad järjekorras, kuid seda tehnikat on üsna raske märgata. Samuti väärib märkimist, et see rünnak kehtib isegi sisemiselt usaldusväärsete kohta getMakerAmount
ja getTakerAmount
funktsioonid. Enamiku rünnakute puhul hoiab mõistliku lävesumma määramine ära rahaliste vahendite kadumise.
Selle vältimiseks kaaluge staatiliste argumentide kodeerimist enne dünaamilisi argumente, et vältida dünaamiliste argumentide staatiliste argumentide juhtimise meetodit.
Värskenda: Pole parandatud. 1-tolline meeskond teatas:
Oleme Getteri valideerimisega eriti ettevaatlikud. Püüame oma sdk-s juurutada getterite mõistlikkuse kontrolli, mis aitab potentsiaalselt pahatahtlikke tellimusi filtreerida.
[M02] ERC721 tellimusi saab manipuleerida
Selle kaudu on võimalik vahetada rohkem kui lihtsalt ERC20 OrderMixin
juurutades lepingu, mis jagab IERC20-ga sama funktsioonivalijat transferFrom
ja esitades selle lepingu kui makerAsset
või takerAsset
järjekorras.
Reguleerimisalast välja jäävad puhverserverid, nimelt ERC721Proxy
, ERC721ProxySafe
ja ERC1155Proxy
lepingud järgivad seda mustrit, et pakkuda toetust ERC721
ja ERC1155
märgid. Kuna puhverserverid tuleb kutsuda sama mustriga kui IERC20 transferFrom
kõne, peab allkiri algama tähega address from
, address to
ja uint256 amount
. Kõik muu, mida puhverserverid nõuavad, saab pärast sisestada ja see on määratletud järjekorras kui makerAssetData
ja takerAssetData
.
ERC1155-d võivad loomulikult edastada mitu sama ID-märki korraga, mis tähendab ERC1155Proxy
leping kasutab ära amount
valdkonnas. Teiselt poolt, ERC721
s ei ole selle jaoks ilmselget kasutust amount
valdkonnas. Kuna need esindavad mitteasendatavaid märke, on konkreetsel tokenId-l ainult üks, mis muudab amount
väli kasutu. Seetõttu rakendamine mõlema jaoks ERC721Proxy
ja ERC721ProxySafe
lepingutes kasutatakse vajalikku amount
välja nagu tokenId
asemel.
See ülekoormus amount
parameeter loob võimaluse osaliselt täita ERC721
tellimusi, et osta soodushinnaga eraldi loetletud žetoone. Näiteks võib juhtuda, et ühel kasutajal on mitu ERC721
s samast lepingust on lubatud üle anda ERC721Proxy
lepingu ja loetleb need eraldi piirmääradena.
Kui limiitkorraldused näevad ette ka getMakerAmount
ja getTakerAmount
väljad, on võimalik need osaliselt täita ERC721
korraldusi. Alates tellimusest amount
väli vastab tegelikult tokenId
, saab pahatahtlik kasutaja sisestada osalise täitmise ERC721
kõrgema tokenId-ga, mille tulemuseks on a makingAmount
/takingAmount
kohta ERC721
mis võiks vastata madalamale tokenId
. Tulemuseks on ERC721
madalamaga tokenId
võõrandataks hinnaga (higher tokenId price) * (lower tokenId's id) / (higher tokenId's id)
.
Sellel ärakasutamisel on mõned nõuded:
- mitmekordne
ERC721
s samast lepingust lubada kasERC721
volikiri ühe omaniku poolt. - Ava tellimus ühele
ERC721
s see pole madalaimtokenId
lubatutest. - Tellimusel on lubatud osatäitmine.
Osalise võimaluse täielikuks eemaldamiseks ERC721
täidab, kaaluge eraldamist amount
ja tokenId
argumendid. Olenemata sellest, kas argumendid on eraldatud või mitte, kaaluge ka selle dokumenteerimist, et hoiatada kasutajaid sellisest käitumisest ja vältida seda mustrit tulevikus.
Värskenda: Kinnitatud tõmbenumber # 59.
[M03] Dokumenteerimata kümnendkohaeeldused
. LimitOrderProtocol
leping pärib ChainlinkCalculator
lepingu kaudu OrderMixin
leping. See leping pakub kahte funktsiooni, mis võimaldavad Chainlinki oraaklite kasutamise ajal predikaatide kontroll ja otsimine tegija summa/võtja summa.
Lepingus tehakse siiski dokumenteerimata eeldusi kümnendkohtade arvu kohta, milles Chainlinki oraaklid peaksid aru andma, samuti kümnendkohtade arvu kohta, mida funktsiooni parameetrid peaksid sisaldama. Teatud stsenaariumide korral võib see kaasa tuua ootamatu käitumise, sealhulgas varade väärhinnangu ja tahtmatu raha kadumise.
Täpsemalt eeldatakse kogu lepingus, et Chainlinki oraaklid esitavad aruandeid 18 kümnendkoha täpsusega. Siiski mitte kõik Chainlinki oraaklid aruanne selle kümnendkohtade arvuga. Tegelikult, kui oraakel teatab märgipaari, mis on valuutas (näiteks USD), on selle täpsus vaid 8 kümnendkohta. Kuna piiranguid pole mis Oraakleid saab kasutada, ei tohiks teha kaudseid oletusi kümnendkohtade arvu kohta, millega nad aruandlusse esitavad.
Seoses sellega on kaudne eeldus, et amount
parameetri jaoks ChainlinkCalculator
funktsioonid kasutavad 18 kümnendkohta koos eksitava selgesõnalise deklaratsiooniga, et singlePrice
funktsioon Calculates price of token relative to ETH scaled by 1e18
. Tegelikkuses isegi oraakliga, et ei aruanne 18 kümnendkohaga, tagastatav väärtus singlePrice
funktsioon skaleeritakse kümnendkohtade arvu järgi amount
parameeter, mis ei pruugi olla 18 kümnendkohta.
Samamoodi, doublePrice
funktsioon eeldab, et kaks Chainlinki oraaklit annavad aru sama arvu kümnendkohtadega, mistõttu funktsiooni tulemus kaldub ootustest kõrvale.
Kaaluge selgesõnaliselt dokumenteerida eeldused kümnendkohtade arvu kohta, mida parameetrid ja tagastusväärtused peaksid väljendama. Lisaks kaaluge arvutuste piiramist, mis sõltuvad neid eeldusi rikkuvatest oraaklitest, või laske asjakohastes arvutustes arvesse võtta tegelikku kümnendkohtade arvu.
Värskenda: Kinnitatud tõmbenumber # 75.
Madal raskusaste
[L01] Konstandid ei ole selgesõnaliselt deklareeritud
Koodibaasis kasutatakse mõnel juhul seletamatu tähendusega sõnasõnalisi väärtusi. Näiteks:
- aasta
OrderMixin
leping,_remaining
kaardistamine on semantiliselt ülekoormatud (nagu on väljaandes selgitatud Kaardistamise semantiline ülekoormus), et jälgida osaliselt täidetud tellimuse jaoks järelejäänud varade hulka sama hästi kui kui tellimus on täielikult täidetud. Täpsemalt0
tähendab, et tellimusega seotud täitmisi pole tehtud,1
tähendab, et tellimust ei saa enam täita ja midagi suuremat kui1
tähendab, et tellimusega on seotud järelejäänud summa, mida saab potentsiaalselt täita. - aasta
ChainlinkCalculator
leping, sõnasõnaline väärtus1e18
kasutataksesinglePrice
funktsiooni.
Koodi loetavuse parandamiseks ja ümbertegemise hõlbustamiseks kaaluge iga maagilise numbri jaoks konstandi määratlemist, andes sellele selge ja arusaadava nime. Keerukate väärtuste puhul kaaluge tekstisisese kommentaari lisamist, mis selgitab, kuidas need arvutati või miks need valiti.
Värskenda: Kinnitatud tõmbenumber # 75 ja tõmbenumber # 76.
[L02] Pahatahtlikud osapooled võivad takistada lubatud korralduste täitmist
. OrderMixin
leping võimaldab tegija kasutajatel esitada lubatud tellimused nii et neid saab teha ühe tehinguga, selle asemel, et kinnitamiseks teha eraldi tehingut. Samuti saavad tellimuste vastuvõtjad esitama oma loa tellimuse täitmise ajal samal eesmärgil.
Kuna aga tegija luba sisaldub sees et, oleksid nii tegija kui ka vastuvõtja load kättesaadavad, kui tellimuse täitmise tehing on mempoolis. See võimaldaks igal pahatahtlikul kasutajal need load võtta ja täita neid vastavate varalepingute alusel täitmistehingu ajal. Kuna neil lubadel on a nonce
topeltkulutamise rünnaku vältimiseks ebaõnnestub tellimuse täitmise tehing, kui üritatakse kasutada sama luba, mida just eeljooksu ajal kasutati.
Kuigi turvarisk puudub ja tegija võib luua uue tellimuse ja tehingu eelnevalt heaks kiita, võib see rünnak kindlasti mõjutada lubatud tellimuste kasutatavust. Tõepoolest, motiveeritud ründaja võiks blokeerida kõik selle rünnakuga lubatud käsud. Kaaluge kinnitamist, kui luba oli juba esitatud või kui toetus on piisav, tellimuse täitmise ajal. Kaaluge ka kasutajatele sellest võimalikust rünnakust tellimuse koostamise ajal teada andmist.
Värskenda: Pole parandatud. 1-tolline meeskond teatab:
Meil oli varem kinnitusi kontrollitud, kuid otsustasime lubade voogu lihtsustada, et naasta ainult ebaõnnestunud kinnituste korral. Mõtleme, kuidas tootjaid probleemist teavitada.
[L03] Dubleeritud kood
Koodibaasis on dubleeritud koodi juhtumeid. Koodi dubleerimine võib arenduse elutsükli hilisemas etapis põhjustada probleeme ja muudab projekti suuremaks vigade tekkeks. Sellised vead võivad kogemata tekkida, kui funktsionaalsuse muudatusi ei korrata kõigis identsete koodijuhtumites. Dubleeritud koodi näited on järgmised:
Koodi dubleerimise asemel kaaluge ainult ühe lepingu või teegi olemasolu, mis sisaldab dubleeritud koodi, ja kasutage seda alati, kui dubleeritud funktsiooni on vaja.
Värskenda: Osaliselt fikseeritud tõmbenumber # 60.
[L04] Vigane või eksitav testikomplekt
Testkomplektis on juhtumeid, kus testid kalduvad nende eeldatavast käitumisest kõrvale. Näiteks:
- .
ChainlinkCalculator
lepingu päribOrderMixin
leping. Kuid katsete ajalAmountCalculator.arbitraryStaticCall
funktsiooni kasutatakse helistamiseksChainlinkCalculator
lepingu välise, iseseisva lepinguna. Kuigi tulemus on ootuspärane, peaks test peegeldama käitumist süsteemi praeguse kujunduse ja eeldatava kasutusjuhtumiga, helistadesChainlinkCalculator
toimib otse ilma suvalist staatilist kõnet kasutamata. - Kuigi puhverlepingud olid väljaspool rakendust, märkasime, et protokolli testimisel ERC721 varadega,
ERC721Proxy
lepingut ei kasutata selle varade vahetamiseks testipakett.
Kuna testkomplekt ise ei kuulu selle auditi ulatusse, kaaluge testkomplekti põhjalikku ülevaatamist, et veenduda, et kõik testid kulgevad edukalt vastavalt protokolli spetsifikatsioonidele.
Värskenda: Kinnitatud tõmbenumber # 57, tõmbenumber # 59ja tõmbenumber # 61.
[L05] Vead ja väljajätmised sündmustes
Kogu koodibaasi ulatuses edastatakse sündmusi tavaliselt siis, kui lepingutes tehakse tundlikke muudatusi. Paljudel sündmustel puuduvad aga indekseeritud parameetrid ja/või puuduvad olulised parameetrid. Näiteks:
Samuti on tundlikke toiminguid, millel puuduvad sündmused, näiteks:
Kaaluge olemasolevate sündmuste täielikumat indekseerimist ja uute parameetrite lisamist, kui need puuduvad. Samuti kaaluge kõigi sündmuste edastamist nii terviklikult, et neid saaks kasutada ahelaväliste teenuste abil lepingu seisukorra taastamiseks.
Värskenda: Pole parandatud. 1-tolline meeskond lisas aga ühe orderRemaining
parameetrile OrderCanceled
sündmus tõmbenumber # 62.
1-tolline meeskond teatab:
Leidsime, et kasutajaliidese vajaduste rahuldamiseks on vaja ainult piiratud alamhulka andmeid. Ulatusliku analüüsi korral on kõik soovitatud väljad jälgimise kaudu kättesaadavad. Sest
OrderRFQMixin
eeldame, et turutegijad loovad oma keeruka viisi tühistatud tellimuste jälgimiseks.
[L06] Salvestusmuudatused sündmuse emissiooni ajal
aasta NonceManager
leping, kui NonceIncreased
sündmus edastatakse, Samuti suureneb sõnumi saatja nonce.
Mitme toimingu samaaegne täitmine võib muuta koodibaasi raskemini arutletavamaks, vigadele kalduvamaks ja põhjustada toimingutest tähelepanuta jätmise või valesti mõistmise.
Koodi üldise tahtelisuse, loetavuse ja selguse parandamiseks kaaluge enne sündmuse väljastamist nonce väärtuse suurendamist.
Värskenda: Kinnitatud tõmbenumber # 63.
[L07] Ebajärjekindlad dekodeerimismeetodid võivad põhjustada tulemuste lahknevusi
Laiendatavuse ja paindlikkuse toetamiseks peab Limit Order Protocol tavaliselt tegelema dünaamiliste baitide andmete ja väliste lepingute suvaliste tagastatavate väärtustega. Selle tulemusena sisaldab protokoll an ArgumentsDecoder
teek, et muuta dünaamilised baitide väärtused tõhusamalt põhiandmetüüpideks. Kuid seda teeki ei kasutata ainult ja mõnel juhul abi.decode
selle asemel kasutatakse. Lisaks kasutatakse mõningaid lepinguid abi coder v1
samal ajal kui teised kasutavad abi coder v2
. Esimene toimib sarnasemalt ArgumentsDecoder
raamatukogu, kusjuures viimane teostab dekodeerimisel täiendavaid kontrolle.
Nende erinevate dekodeerimismetoodikate ebajärjekindel kasutamine võib põhjustada peeneid lahknevusi koodibaasi kavatsuse ja tegeliku käitumise vahel.
Näiteks simulateCalls
funktsioon kasutab ainult ArgumentsDecoder.decodeBool
funktsioon. Kui simulateCalls
funktsiooni kasutatakse kõnede kontrollimiseks, mis tehakse tellimuse predikaadiosas, siis võivad selle tulemused erineda tegelikust predikaaditingimuste hindamisel, kuna kasutatakse erinevaid dekodeerimismetoodikaid.
Näiteks kui predikaat teeb välise staticcall
mõnele funktsioonile, mis tagastab a uint256
väärtus on oodatust suurem kui üks bool
, siis kõne naaseb, sest tagastatav väärtus on dekodeeritud abi coder v2
s abi.decode
mis ei aktsepteeri selliseid väärtusi nagu bool
. Kui aga tehakse täpselt sama kõne simulateCalls
, siis see märgitakse lihtsalt kui true
, Sest decodeBool
käsitleb nullist suuremaid väärtusi kui true
.
Teha simulateCalls
funktsioon peegeldab täielikult tegelike predikaatkõnede käitumist, kaaluge selle muutmist kasutamiseks abi.decode
.
Värskenda: Kinnitatud tõmbenumber # 82.
[L08] Sisestuse kinnitamise puudumine
. fillOrderToWithPermit
ja fillOrderTo
funktsioonid OrderMixin
leping, samuti fillOrderRFQToWithPermit
ja fillOrderRFQTo
funktsioonid OrderRFQMixin
lepingut, ärge kinnitage target
aadressi parameeter.
See võimaldab kasutajal kogemata sisestada nullaadressi ja selle tulemusena lukustada varad, mille nad pärast tellimuse täitmist peavad saama.
Tagamaks, et kasutajad ei lukustaks kogemata oma raha, kaaluge selle kinnitamist target
aadress ei võrdu viidatud funktsioonide nullaadressiga.
Värskenda: Kinnitatud tõmbenumber # 78.
[L09] Madal üksuse testi katvus
Kogu projekti ühikutestide katvus on umbes 75%, kusjuures mõne lepingu katvus on eriti madal.
Arvestades ühikutestide olulisust koodi kinnitamisel ja regressioonide ärahoidmisel uute funktsioonide ümbertöötamisel ja väljatöötamisel, soovitame ühikutestide ulatust märkimisväärselt suurendada vähemalt 95% -ni ja kaasata äärmuslikud juhtumid, mis hõlmavad isegi ebatõenäolisi olukordi.
Värskenda: Pole parandatud.
[L10] Eksitav või mittetäielik tekstisisene dokumentatsioon
Kogu koodibaasi jooksul tuvastati mõned eksitava ja/või mittetäieliku tekstisisese dokumentatsiooni juhtumid ning need tuleks parandada.
Järgmised on eksitava tekstisisese dokumentatsiooni juhtumid.
- aasta
ChainlinkCalculator
leping,singlePrice
funktsiooni NatSpec@notice
silt ütleb, et seeCalculates price of token relative to ETH scaled by 1e18
, kuid tegelikult on selle tulemus väärtus ofamount
võrra skaleeritud märgid1e18
, kus oraakel ei pruugi edastada ETH-d (näiteks paari puhul, mis ei sisalda ETH-d). - aasta
OrderRFQMixin
leping,invalidatorForOrderRFQ
funktsiooni NatSpec@return
silt on eksitav, sest vastava kehtetuks tunnistamise biti määramiseks ei pruugi tsitaat olla täidetud. Tellimuse võis ka tühistada. - Liinidel 147, 165ja 188 of
OrderMixin.sol
, NatSpec@param
sildid on ebagrammatilised. - Võrgus 20 of
ERC1155Proxy.sol
,@notice
silt ütleb, et arvutatud räsi on räsimise tulemusfunc_733NCGU
funktsioon, kus see peaks olemafunc_301JL5R
funktsiooni asemel.
Järgmised on mittetäieliku tekstisisese dokumentatsiooni juhtumid.
- Funktsioonid
AmountCalculator
lepingus ei kirjeldata ühtegi parameetrit. - aasta
ChainlinkCalculator
leping,singlePrice
jadoublePrice
funktsioonid ei kirjelda kõiki parameetreid. - aasta
ImmutableOwner
lepingu, avalikul muutujal ja modifikaatoril NatSpec puudub. - aasta
InteractiveNotificationReceiver
leping,notifyFillOrder
funktsioon ei kirjelda ühtegi parameetrit. - aasta
LimitOrderProtocol
leping,DOMAIN_SEPARATOR
funktsioonil puudub NatSpec. - Sündmused ja kaardistused aastal
NonceManager
puudub NatSpec. - aasta
OrderRFQMixin
leping,cancelOrderRFQ*
funktsioonid ei kirjelda tagastusväärtusi. - aasta
OrderMixin
lepingus puudub mitmel funktsioonil täielik NatSpec. - Võrgus 168 of
OrderMixin.sol
ja võrgus 71 ofOrderRFQMixin.sol
, sellel on puudu@dev
tag. - Funktsioonid
PredicateHelper
Lepingus ei kirjeldata kõiki parameetreid.
Selge tekstisisene dokumentatsioon on koodi kavatsuste kirjeldamiseks ülioluline. Sisseehitatud dokumentatsiooni ja juurutuse vahelised mittevastavused võivad põhjustada tõsiseid väärarusaamu selle kohta, kuidas süsteem peaks käituma. Kaaluge nende vigade parandamist, et vältida segadust nii arendajate, kasutajate kui ka audiitorite jaoks.
Värskenda: Osaliselt fikseeritud. Adresseeritud eksitav dokumentatsioon tõmbenumber # 75 ja tõmbenumber # 77.
1-tolline meeskond teatab:
Parandasime eksitavad dokumendid. Dokumentide komplekteerimine toimub hiljem.
[L11] Konksude kasutamisel on võimalik tellida DoS-i
. OrderMixin
Leping rakendab funktsionaalsust üldiste ahelaväliste vahetustellimuste täitmiseks, millel võivad olla tingimused nende õnnestumiseks. Tellimuse täitmise ajal saab tellimus kontrollige eelmääratletud "predikaadi" tingimusi enne täitmisega jätkamist.
Kuna aga need predikaattingimused võivad olla suunatud mis tahes meelevaldse lepingu loogikale, võib pahatahtlik tegija petta vastuvõtjaid uskuma, et tellimus käitub õigesti ja et see kehtib ahelavälisel kontrollimisel, kuid ebaõnnestub siis, kui üritab sama tellimust täita. ahelas. Selle predikaadi käitumise muutuse saab teha kas mõne muutuva oleku, millest predikaadid sõltuvad, käivitamisega, saadetud gaasi või isegi kõnega seotud aadresside uurimisega või mõne muu loogika abil.
Lisaks, kui tegija määratles a suhtlemine vahetuse ajal, interactionTarget
leping võib tellimuste eduka täitmise takistamiseks ise tagasi pöörduda või soodustuse tühistada, mis annab sisuliselt sama tulemuse kui pahatahtlikud predikaadid.
Kuigi varad ei ole ohus, on soodsa tellimuse leidmisel kasutajatel või robotitel suurem koormus, kui nad üritavad tuvastada selliseid rämpspostitellimusi, mis võivad pealtnäha tunduda õigustatud. Kui nad seda tüüpi tellimusi ei tuvasta, kannavad nad raisatud gaasikulusid. Rämpspostitellimuste hulga vähendamiseks kaaluge nende konksude jaoks saadaolevate sihtmärkide piiramist. Kaaluge ka kasutajate hoiatamist selle võimaluse eest enne, kui nad üritavad tellimusi täita.
Värskenda: Pole parandatud. 1-tolline meeskond teatab:
Tegeleme sellega oma taustaprogrammis ja mõtleme sellele, kuidas võimalikke kasutajaid probleemist teavitada.
[L12] Ümardamine võib olla ebasoodne taker
aasta OrderMixin
ja OrderRFQMixin
lepingud, kui tellimust täidetakse ja vastuvõtja annab ainult a makingAmount
or takingAmount
Protokoll püüab arvutada vahetustehingu vastassumma.
Nende arvutustega on kaks probleemi, millest esimene on see, et puuduvad dokumendid ega loogika, mis piiraks kümnendkohtade arvu, mida summaparameetrid peaksid kasutama, mida käsitlesime Dokumenteerimata kümnendkohaeeldused probleem.
Teine probleem seisneb selles, et nende arvutuste käigus liigub protokoll tegija kasuks. Ümardamise probleem võib oluliselt süveneda, kui kaudsed kümnendkohaeeldused on rikutud, kuid isegi siis, kui kõik on oodatud tingimustes, toimub ümardamine väikeste paaritute summadega.
Kaaluge lubada võtjal määrata minimaalne summa makerAsset
vara, mida nad on nõus vastu võtma koos maksimaalse summaga takerAsset
varasid, mida nad on nõus vahetama, et ümardamise aktsepteerimine oleks selgem.
Värskenda: Pole parandatud. 1-tolline meeskond teatab:
Lävisummast peaks piisama võtja kaitseks.
[L13] Vastuoluline tellimuste käsitlemine parameetrite puudumisel
aasta OrderMixin
leping, fillOrderTo
funktsioon teeb sisekõnesid _callGetMakerAmount
ja _callGetTakerAmount
toimib alati, kui proovitakse täita ja kas makingAmount
või takingAmount
parameetrid on vastavalt nullid või kui makingAmount
väärtus on suurem kui remainingMakerAmount
väärtus.
. _callGetMakerAmount
ja _callGetTakerAmount
kõned viivad tagasipööramiseni, kui tellimust ei loodud rakendusega getMakerAmount
or getTakerAmount
parameetrid ja teostatakse osaline täitmine.
An kõrvalkommentaar _callGetMakerAmount
ja kõrvalkommentaar _callGetTakerAmount
väita, et "lubatud on ainult terved täidised", kui tellimust ei koostatud getMakerAmount
or getTakerAmount
parameetrid.
Siiski on kooditeid, mille puhul see ei kehti, kuna need teed ei kontrolli length
s mõlemast getMakerAmount
ja getTakerAmount
parameetrid.
Täpsemalt kui taker
täpsustab a takerAmount
väärtus tellimuse jaoks, millel on ainult a getMakerAmount
, kui see ei kutsu getMakerAmount
tagastab summa, mis on suurem kui remainingMakerAmount
, saab osalise täitmise teostada vastuolus tekstisisese dokumentatsiooniga.
See jätab nende kooditeede tahtlikkuse ebaselgeks. Kui see on ootuspärane käitumine, kaaluge tekstisisese dokumentatsiooni muutmist, et see oleks selgem. Kui see on tahtmatu käitumine, kaaluge alati mõlema pikkuse kontrollimist getMakerAmount
ja getTakerAmount
parameetreid samaaegselt, nii et rakendamine tugevdab tekstisiseses dokumentatsioonis kirjeldatud käitumist.
Värskenda: Kinnitatud tõmbenumber # 79.
[L14] Aegunud Chainlinki kõnede kasutamine
. ChainlinkCalculator
leping on mõeldud kasutamiseks Chainlinki oraaklite päringute tegemiseks. See teeb seda neile helistades latestTimestamp
ja latestAnswer
meetodid, mõlemad on aegunud. Tegelikult pole neid meetodeid enam Chainlinki agregaatorite API-s kolmanda versiooni seisuga.
Võimaliku tulevase Chainlinki oraaklitega kokkusobimatuse vältimiseks kaaluge rakenduse kasutamist latestRoundData
asemel meetod.
Värskenda: Kinnitatud tõmbenumber # 67.
Märkused ja lisateave
[N01] Ei impordi liideseid
. AggregatorInterface
liides näib olevat koodi alamhulk, millest on kopeeritud ChainLink
avalik koodihoidla. Täielik liides on lisatud ChainLink
lepingu npm pakett.
Võimaluse korral, et vähendada liideste mittevastavust ja sellest tulenevaid probleeme, selle asemel, et määratleda ja/või ümber kirjutada mõne teise projekti liidesed, kaaluge selle asemel ametlike npm-pakettide kaudu installitud liideste kasutamist.
Värskenda: Kinnitatud tõmbenumber # 66.
[N02] Aegunud projektisõltuvused
Paigaldamise ajal projekti sõltuvused, NPM hoiatab, et üks installitud pakettidest, Highlight
, "ei toetata enam ega saa edaspidi turvavärskendusi".
Kuigi on ebatõenäoline, et see pakett võib põhjustada turvariski, kaaluge seda paketti kasutava sõltuvuse uuendamist hooldatud versioonile.
Värskenda: Kinnitatud tõmbenumber # 64.
[N03] Väliskutsed meetodite vaatamiseks ei ole staatilised kõned
Protokoll teeb suurema osa koodibaasist väliskõnesid OpenZeppelini kaudu. functionStaticCall
meetod olekumuutuste võimaluse piiramiseks, kui need ei ole oodatud või mittesoovitavad. Kuid aastal ChainlinkCalculator
vaatamata kavatsusele teha väliskõnesid ainult view
meetodid Chainlinki oraaklites, välised kõned singlePrice
ja doublePrice
funktsioone ei tehta eksplitsiitse kaudu staticcall
s.
Kuigi me ei tuvastanud sellest tulenevaid vahetuid turvaprobleeme, kaaluge rünnakupinna vähendamiseks, järjepidevuse parandamiseks ja kavatsuste selgitamiseks selgesõnalise staticcall
s kõigi väliskõnede jaoks view
funktsioonid ChainlinkCalculator
leping.
Värskenda: Pole parandatud. 1-tolline meeskond teatab:
Arvame, et süntaksi keerukus tühistab järjepidevuse paranemise.
[N04] Kehtetute tellimuste korral varakult ebaõnnestumine
aasta OrderMixin
leping, fillOrderTo
funktsioon käsitleb eritingimust, kui tellimust pole varem esitatud (remainingMakerAmount == 0
), kuid see ei käsitle sõnaselgelt tingimust, kui tellimus enam ei kehti (remainingMakerAmount == 1
).
Viimase stsenaariumi korral taastub funktsioon lõpuks, kuid alles pärast ebaoluliste gaasikoguste põletamist. Kavatsuse selgitamiseks, loetavuse suurendamiseks ja gaasikasutuse vähendamiseks kaaluge kehtetu tellimuse stsenaariumi selgesõnalist käsitlemist funktsiooni alguses.
Värskenda: Kinnitatud tõmbenumber # 68.
[N05] Abistamislepingud pole märgitud abstraktseks
Solidity's on märksõna abstract
kasutatakse lepingute puhul, mis ei ole iseseisvad lepingud või ei ole mõeldud kasutamiseks sellisena. Selle asemel abstract
lepingud pärivad süsteemi teised lepingud, et luua iseseisvad funktsionaalsed lepingud.
Kogu koodibaasis on näiteid abistajalepingutest, mida ei ole abstraktseteks märgitud, hoolimata asjaolust, et need ei ole mõeldud iseseisvaks kasutuselevõtuks. Näiteks AmountCalculator
, ChainlinkCalculator
, ImmutableOwner
, NonceManager
ja PredicateHelper
kõik lepingud koosnevad põhifunktsioonide komplektist, mis on mõeldud kasutamiseks pärimislepingute jaoks.
Kaaluge abistajalepingute märgistamist kui abstract
anda selgelt märku, et need on loodud üksnes funktsioonide lisamiseks lepingutele, mis neid pärivad.
Värskenda: Pole parandatud. 1-tolline meeskond teatab:
Neid abilisi saab kasutada eraldi. Need on päritud ainult gaasi säästmiseks.
[N06] Ebaühtlane funktsioonide järjestus
Kogu koodibaasi ulatuses järgib funktsioonide järjestamine üldiselt järgmist soovitatav järjekord Solidity Style Guide'is, Milleks on: constructor
, fallback
, external
, public
, internal
, private
.
Siiski on OrderMixin
leping, public
checkPredicate
funktsioon kaldub stiilijuhisest kõrvale, poolitades selle external
funktsioone.
Projekti üldise loetavuse parandamiseks kaaluge funktsioonide järjestuse standardimist kogu koodibaasi ulatuses, nagu soovitab Solidity Style Guide.
Värskenda: Kinnitatud tõmbenumber # 69.
[N07] Ebaühtlane tellimuse täitmise voog
. OrderMixin
ja RFQOrderMixin
mõlemad lepingud tegelevad allkirjastatud tellimuste täitmisega, kuid üldine tellimuste voog kahe lepingu vahel on ebaühtlane.
OrderMixin
s fillOrderTo
funktsioon järgib seda üldist voogu (pseudokood):
if ((takingAmount == 0) == (makingAmount == 0))
else if (takingAmount == 0)
else (handle makingAmount == 0) THEN swapTokens
Arvestades, et RFQOrderMixin
on analoogne fillOrderRFQTo
funktsioon järgib seda voogu (pseudokood):
if (takingAmount == 0 && makingAmount == 0)
else if (takingAmount == 0)
else if (makingAmount == 0)
else revert THEN swapTokens
Dokumentatsioonist puuduvad arusaamad selle kohta, miks nende kahe funktsiooni esimene tingimuslause erineb või miks takingAmount
ja makingAmount
Viimase funktsiooni puhul ei saa mõlemad olla nullid. Samuti juhul, kui mõlemad a makingAmount
ja takingAmount
on palju lihtsam põhjendada fillOrderRFQTo
funktsioon, kuna seda käsitletakse selgelt finaalis else
blokeerida.
Kavatsuse selgitamiseks ja koodi üldise loetavuse suurendamiseks kaaluge kas nende kahe lepingu üldise tellimuste voo standardimist või erinevuste põhjuste selgesõnalist dokumenteerimist.
Värskenda: Pole parandatud. 1-tolline meeskond teatab:
See on tingitud limiittellimuste kohandatud hinnakujundusfunktsioonidest. Alates
getMakerAmount
võib potentsiaalselt oluliselt erinedagetTakerAmount
, arvasime, et parem on mitte teha võtja jaoks vaikevalikut, kuna see ajab nad tõenäoliselt segadusse juhtudel, kui need hankijad on erinevad.
[N08] Veateated on ebajärjekindlalt vormindatud või eksitavad
Kogu koodibaasi ulatuses on require
ja revert
veateated, mille eesmärk on teavitada kasutajaid konkreetsetest tingimustest, mis põhjustavad tehingu ebaõnnestumise, leiti olevat ebajärjekindlalt vormindatud.
Näiteks iga ridade veateade 85 kohta OrderMixin.sol
, 16 kohta ERC721ProxySafe.sol
ja 26 kohta Permitable.sol
kasutada teist stiili.
Lisaks on mõned veateated eksitavad:
Veateadete eesmärk on teavitada kasutajaid tõrgetest, seega peaksid need andma piisavalt teavet, et saaks süsteemiga suhtlemiseks teha asjakohaseid parandusi. Mitteinformatiivsed veateated kahjustavad oluliselt üldist kasutajakogemust, vähendades seega süsteemi kvaliteeti. Lisaks võivad ebajärjekindlalt vormindatud veateated tekitada asjatut segadust. Seetõttu kaaluge kogu koodibaasi ülevaatamist, et veenduda, et iga require
ja revert
avaldusel on veateade, mis on ühtlaselt vormindatud, täpne, informatiivne ja kasutajasõbralik.
Värskenda: Osaliselt fikseeritud tõmbenumber # 81.
[N09] Nimega tagastusmuutujate ebajärjekindel kasutamine
Nimega tagastusmuutujaid kasutatakse järjekindlalt OrderMixin
leping. Mõned funktsioonid tagastavad nimega muutujad, teised tagastavad selged väärtused, ja teised deklareerida nimega tagastusmuutuja, kuid tühistada see selgesõnalise tagastuslausega.
Kaaluge järjekindla lähenemisviisi kasutamist kogu koodibaasis väärtuste tagastamiseks, eemaldades kõik nimega tagastusmuutujad, deklareerides need selgesõnaliselt kohalike muutujatena ja lisades vajaduse korral vajalikud tagastuslaused. See parandaks nii koodi selgesõnalisust kui ka loetavust ning võib samuti aidata vähendada regressioone tulevaste koodimuutuste käigus.
Värskenda: Kinnitatud tõmbenumber # 73.
[N10] Tellimuse räsiarvutus pole API-le avatud
. external
funktsioonid remaining
, remainingRaw
ja remainingsRaw
kõik ootavad edukaks toimimiseks tellimuse räsi.
Küll aga abistaja funktsioon _hash
, mis tagastab tellimuse räsi, on private
nähtavus. See tähendab, et kasutajad peavad tellimuse räsi saamiseks käsitsi pakkima osa tellimustest ja domeenistringidest.
Et vältida võimalikke vigu tellimuse räsi arvutamisel ja pakkuda kasutajatele meetodit tellimuse vastava räsi loomiseks, kaaluge tellimuse nähtavuse laiendamist. _hash
funktsiooni public
ja nime ümberkujundamine hash
olema kooskõlas ülejäänud koodiga.
Värskenda: Kinnitatud tõmbenumber # 74.
[N11] Kaardistamise semantiline ülekoormus
. _remaining
kaardistamine OrderMixin
leping on semantiliselt ülekoormatud, et jälgida tellimuste olekut ja nende tellimuste jaoks saadaolevat järelejäänud varade hulka.
Kolm olekut, mida see võib võtta, on:
0
: Tellimuse räsi pole veel nähtud.1
: tellimus on kas tühistatud või täielikult täidetud.- mistahes
uint
suurem kui1
: AllesjäänudmakerAmount
saadaval täita tellimuse pluss1
.
See semantiline ülekoormus nõuab selle väärtuse ümber- ja lahtipakkimist ajal lookup
, cancellation
, initialization
ja storage
.
Semantiline ülekoormus ja selle võimaldamiseks vajalik loogika võivad põhjustada vigu ning muuta koodibaasi raskemini mõistetavaks ja põhjendatuks, samuti võib see avada ukse regressioonidele koodi tulevastes värskendustes.
Koodi loetavuse parandamiseks kaaluge tellimuste valmimise oleku jälgimist eraldi kaardistuses.
Värskenda: Pole parandatud. 1-tolline meeskond viitas, et parandus suurendab gaasikulusid fillOrder
funktsiooni.
[N12] Loaga tellimused võimaldavad helistada meelevaldsetele lepingutele
. OrderMixin
leping pärib Permitable
leping, mis võimaldab ühe tehingu tellimust täita varadega, mis neid aktsepteerivad permit
nõuab saastekvootide muutmist.
Kuid kõned aadressile Permitable
leping ärge kinnitage, kas sihtmärk on lubatud vara või kas see on isegi vara, mis võib lubada pahatahtlikul kasutajal edastada suvalise lepingu aadressi, mis võib käivitada uue kõne enne tellimuse täitmise lõpetamist.
Kuigi leping on kaitstud taassisenemise eest, on alati soovitatav vähendada ründepinda ja välistada väliste lepingute kutsumine täitmise ajal. Kaaluge loaga hõlmatud vara piiramist tellimusega seotud varadega või protokolli varade valgesse nimekirja.
Värskenda: Pole parandatud. 1-tolline meeskond teatab:
OrderMixin
ei oma tegelikult teavet tegelike žetoonide kohtamakerAsset
jatakerAsset
mõnikord on need puhverserverid või muud vahelepingud ja teave tegelike žetoonide kohta salvestatakse suvalistes baitides. Seega ei ole mingit mõistlikku viisi vara piiramisekspermit
kutsutakse.
[N13] solhint
ei ole kunagi uuesti lubatud
Kogu koodibaasis on paar solhint-disable
avaldused, eriti need, mis on veebis 23 ja võrgus 41 of RevertReasonParser.sol
, mis ei ole lõpetatud solhint-enable
.
Otsesõnalisuse pooldamine ja keelamisel olla võimalikult piirav solhint
, kaaluge kasutamist solhint-disable-line
or solhint-disable-next-line
selle asemel sarnaneb joonega 16 samast failist.
Värskenda: Kinnitatud tõmbenumber # 72.
[N14] Kirjavead
Koodibaas sisaldab järgmisi kirjavigu:
Lisaks projekti README
(selle auditi jaoks ei kuulu) sisaldab järgmisi kirjavigu:
Koodi loetavuse parandamiseks kaaluge nende kirjavigade parandamist.
Värskenda: Kinnitatud tõmbenumber # 71 ja tõmbenumber # 77.
[N15] Kasutamine uint
asemel uint256
Selgesõnalisuse soodustamiseks kõik juhtumid uint
tuleks deklareerida kui uint256
. Eelkõige need for
silmused joontel 98 ja 119 of OrderMixin.sol
ja jooned 16 ja 30 of PredicateHelper.sol
.
Värskenda: Kinnitatud tõmbenumber # 70.
Järeldused
Leiti 3 väga tõsist probleemi. Parimate tavade järgimiseks ja võimaliku rünnakupinna vähendamiseks tehti mõned muudatused.
- &
- 7
- MEIST
- juurdepääs
- Vastavalt
- konto
- üle
- tegu
- meetmete
- Täiendavad lisad
- aadress
- ADEelis
- Materjal: BPA ja flataatide vaba plastik
- Lubades
- juba
- Kuigi
- summad
- analüüs
- API
- lähenemine
- argumendid
- ümber
- eelis
- vara
- audit
- Back-end
- Algus
- on
- BEST
- parimaid tavasid
- Natuke
- eest
- ehitama
- helistama
- mis
- juhtudel
- Põhjus
- Chainlink
- muutma
- kontroll
- Kontroll
- kood
- keeruline
- seisund
- segadus
- ehitus
- sisaldab
- leping
- lepingud
- Parandused
- kulud
- võiks
- Paar
- looja
- valuuta
- Praegune
- andmed
- tegelema
- Denial of Service
- juurutamine
- Disain
- Arendajad
- & Tarkvaraarendus
- DID
- erinevad
- erinev
- domeen
- kahekordistada
- dünaamiline
- Varajane
- serv
- julgustama
- eriti
- ETH
- sündmus
- sündmused
- kõik
- näide
- vahetamine
- oodatav
- kogemus
- Ekspluateeri
- FUNKTSIOONID
- Valdkonnad
- Lõpuks
- esimene
- Määrama
- Paindlikkus
- voog
- järgima
- avastatud
- täis
- funktsioon
- raha
- tulevik
- mäng
- GAS
- Üldine
- andmine
- suur
- suunata
- Käsitsemine
- hash
- räsimine
- võttes
- aitama
- Suur
- kõrgelt
- Kuidas
- HTTPS
- hübriid
- identifitseerima
- mõju
- rakendada
- oluline
- importivate
- lisatud
- Kaasa arvatud
- Suurendama
- kasvanud
- info
- info
- Infrastruktuur
- teadmisi
- tahtlus
- huvi
- Interface
- seotud
- küsimustes
- IT
- suur
- suurem
- viima
- juhtivate
- Raamatukogu
- piiratud
- joon
- Likviidsus
- Loetletud
- Nimekirjad
- kohalik
- Vaatasin
- lookup
- peamine
- tegija
- Tegemine
- Turg
- Mempool
- peegel
- mudel
- kõige
- Populaarseim
- nimelt
- Uued funktsioonid
- mitte-asendatav
- mitteelustatavad märgid
- ametlik
- avatud
- Operations
- valik
- oraakel
- et
- tellimuste
- Muu
- omanik
- Muster
- populaarne
- esitada
- ennetada
- hind
- hinnapoliitika
- era-
- protsess
- projekt
- projektid
- kaitse
- protokoll
- anda
- annab
- volikiri
- avalik
- avaldama
- ostma
- kvaliteet
- tõstma
- Reaalsus
- vähendama
- sõltuvus
- aru
- Aruanded
- Hoidla
- Nõuded
- REST
- Tulemused
- Tulu
- läbi
- Oht
- voorud
- jooks
- SDK
- turvalisus
- Teenused
- komplekt
- jagatud
- Aktsiad
- suunata
- sarnane
- lihtne
- väike
- nutikas
- Tarkvaralepingud
- So
- kindlus
- spam
- eriti
- Kulutused
- Kaubandus-
- algus
- riik
- väljavõte
- Ühendriigid
- olek
- ladustamine
- stiil
- esitatud
- edu
- edukas
- Edukalt
- toetama
- Toetatud
- Pind
- Lüliti
- süsteem
- sihtmärk
- test
- Testimine
- testid
- Läbi
- läbi kogu
- aeg
- kokku
- sümboolne
- märgid
- jälgida
- Jälgimine
- tehing
- Usalda
- ainulaadne
- Uudised
- us
- kasutatavus
- USD
- USDT
- Kasutajad
- kasulikkus
- väärtus
- vaade
- nähtavus
- ootama
- M
- valgesse
- jooksul
- ilma
- Töö
- väärt
- null