DApps - Decentralized Applications

Reading time: 5 minutes

{{#include ../../banners/hacktricks-training.md}}

Τι είναι ένα DApp;

Ένα DApp είναι μια αποκεντρωμένη εφαρμογή που λειτουργεί σε ένα δίκτυο peer-to-peer, αντί να φιλοξενείται σε έναν κεντρικό διακομιστή. Τα DApps συνήθως κατασκευάζονται πάνω σε τεχνολογία blockchain, η οποία θα πρέπει να επιτρέπει τη διαφάνεια, την ασφάλεια και την αμεταβλητότητα των δεδομένων.

Αρχιτεκτονική Web3 DApp

Σύμφωνα με αυτή την ανάρτηση, υπάρχουν 3 διαφορετικοί τύποι αρχιτεκτονικής Web3 DApps:

"API-less" DApps

Αυτά τα DApps είναι κατασκευασμένα πάνω σε ένα blockchain και δεν βασίζονται σε κανένα κεντρικό API ή backend. Μπορείτε να σκεφτείτε ότι το blockchain είναι το πραγματικό backend της εφαρμογής. Είναι εντελώς αποκεντρωμένα και μπορούν να προσπελαστούν απευθείας μέσω του blockchain.

Για να αλληλεπιδράσει με το blockchain, ο πελάτης θα χρησιμοποιήσει συνήθως ένα πορτοφόλι. Το πορτοφόλι θα υπογράψει τις συναλλαγές και θα τις στείλει στο blockchain. Ο πελάτης μπορεί επίσης να χρησιμοποιήσει έναν κόμβο για να διαβάσει δεδομένα από το blockchain.

"API-Enabled" DApps

Αυτά τα DApps είναι κατασκευασμένα πάνω σε ένα blockchain αλλά βασίζονται επίσης σε κεντρικά APIs συνήθως για να συγκεντρώσουν πληροφορίες. Είναι κυρίως αποκεντρωμένα επειδή, ακόμη και αν βασίζονται σε ένα κεντρικό API, η βασική λειτουργικότητα του DApp παραμένει στο blockchain. Η επικοινωνία του πελάτη με το blockchain γίνεται συνήθως μέσω ενός πορτοφολιού.

Ένα καλό παράδειγμα αυτού του τύπου DApp είναι μια εφαρμογή minting NFT. Ο διακομιστής επιτρέπει την ανάρτηση των εικόνων, αλλά η minting γίνεται από τον πελάτη μέσω ενός πορτοφολιού.

"Full-Scale" DApps

Αυτά τα DApps είναι κατασκευασμένα πάνω σε ένα blockchain αλλά βασίζονται επίσης σε κεντρικά APIs και διακομιστές backend. Μπορεί να είναι μερικώς αποκεντρωμένα καθώς ο πελάτης μπορεί να είναι σε θέση να εκτελεί λειτουργίες στο blockchain χρησιμοποιώντας ένα πορτοφόλι. Ωστόσο, συνήθως το backend θα είναι επίσης σε θέση να εκτελεί λειτουργίες στο blockchain.

Ένα καλό παράδειγμα αυτού του τύπου DApp είναι μια γέφυρα cross-chain όπου απαιτείται ένα offchain στοιχείο για να επικοινωνήσει με έξυπνες συμβάσεις σε διαφορετικά blockchains για να εκτελέσει τη μεταφορά περιουσιακών στοιχείων.

Ευπάθειες Web2

Οι ευπάθειες Web2 επηρεάζουν ακόμα αυτούς τους τύπους εφαρμογών, αν και η επίδρασή τους μπορεί να διαφέρει:

  • Οι ευπάθειες πλευράς πελάτη έχουν αυξημένη επίδραση καθώς στα Web3 DApps ο πελάτης είναι συνήθως αυτός που εκτελεί τις λειτουργίες στο blockchain μέσω ενός πορτοφολιού. Αυτό σημαίνει ότι επιθέσεις όπως το XSS που καταφέρνουν να εκτελέσουν κώδικα JS στην πλευρά του πελάτη ή που παραποιούν το περιεχόμενο της σελίδας μπορούν να έχουν μεγαλύτερη επίδραση καθώς μπορούν να αλληλεπιδράσουν με το πορτοφόλι και να πείσουν τον χρήστη να εκτελέσει ανεπιθύμητες λειτουργίες στο blockchain.
  • Σημειώστε ότι συνήθως ακόμη και σε αυτούς τους τύπους εφαρμογών ο πελάτης μπορεί να ελέγξει τις λειτουργίες πριν τις υπογράψει με το πορτοφόλι. Ωστόσο, αν ο επιτιθέμενος είναι σε θέση να παραποιήσει το περιεχόμενο της σελίδας, μπορεί να πείσει τον χρήστη να υπογράψει μια συναλλαγή που θα εκτελέσει μια ανεπιθύμητη λειτουργία στο blockchain.
  • Οι ευπάθειες πλευράς διακομιστή είναι ακόμα παρούσες στα DApps που βασίζονται σε έναν διακομιστή backend. Η επίδραση αυτών των ευπαθειών θα εξαρτηθεί από την αρχιτεκτονική του DApp. Ωστόσο, μπορεί να είναι πολύ προβληματικές καθώς ένας επιτιθέμενος μπορεί να βρει στο backend κλειδιά της εταιρείας για να αποκτήσει πρόσβαση στα κεφάλαια των έξυπνων συμβάσεων ή μπορεί να εκτελέσει κατάληψη λογαριασμού που μπορεί να τους επιτρέψει να κλέψουν κεφάλαια ή NFTs από τους χρήστες.

Φυσικά, αν το DApp δεν χρησιμοποιεί backend ή αν το backend που χρησιμοποιείται προσφέρει μόνο δημόσια δεδομένα αλυσίδας ή στατικές σελίδες, η επιφάνεια επίθεσης του DApp μειώνεται.

Επιφάνεια επίθεσης Web3

Ακόμα και αν γενικά ένα DApp έχει μειωμένη επιφάνεια επίθεσης καθώς γίνονται πάντα αρκετοί έλεγχοι ασφαλείας στο blockchain, υπάρχουν ακόμα ορισμένα επιθετικά διανύσματα που μπορούν να εκμεταλλευτούν οι επιτιθέμενοι.

Είναι δυνατόν να ομαδοποιηθούν οι ευπάθειες των web3 DApps στις εξής κατηγορίες:

  • Κακώς διαχειριζόμενες On-Chain Συναλλαγές: εσφαλμένα μορφοποιημένα ή χωρίς περιορισμούς APIs συναλλαγών, έλλειψη λογικής αναμονής απάντησης και επιβεβαίωσης μπλοκ, έκθεση ευαίσθητων δεδομένων και ακατάλληλη διαχείριση αποτυχημένων, αντεστραμμένων ή εσωτερικά τυποποιημένων συναλλαγών που επιτρέπουν κακόβουλες ενέσεις δεδομένων.

  • Επιθέσεις Backend που καθοδηγούνται από Έξυπνες Συμβάσεις: αποθήκευση ή συγχρονισμός ευαίσθητων δεδομένων μεταξύ συμβάσεων και βάσεων δεδομένων χωρίς επικύρωση, μη ελεγχόμενες εκπομπές γεγονότων ή διευθύνσεις συμβάσεων και εκμεταλλεύσιμες ευπάθειες συμβάσεων που μπορούν να δηλητηριάσουν τη λογική του backend.

  • Ελαττωματικές Λειτουργίες Κρυπτονομισμάτων: εσφαλμένη επεξεργασία διαφορετικών τύπων tokens (native vs. ERC-20), αγνόηση της δεκαδικής ακρίβειας, αποτυχημένες μεταφορές ή εσωτερικές συναλλαγές και αποδοχή ψεύτικων, αποπληθωριστικών, αναδιορθωτικών ή επιρρεπών σε slippage tokens χωρίς επικύρωση, επιτρέποντας ενέσεις payload μέσω μεταδεδομένων token.

Ορισμένα παραδείγματα από αυτή την ανάρτηση:

Σπατάλη Κεφαλαίων: Εξαναγκασμός backend να εκτελεί συναλλαγές

Στο σενάριο Wasted Crypto in Gas via Unrestricted API, ο επιτιθέμενος μπορεί να εξαναγκάσει το backend να καλέσει συναρτήσεις μιας έξυπνης σύμβασης που θα καταναλώσουν αέριο. Ο επιτιθέμενος, απλά στέλνοντας έναν αριθμό λογαριασμού ETH και χωρίς περιορισμούς, θα εξαναγκάσει το backend να καλέσει την έξυπνη σύμβαση για να την καταχωρίσει, η οποία θα καταναλώσει αέριο.

DoS: Κακή διαχείριση χρόνου συναλλαγών

Στο σενάριο Poor Transaction Time Handling Leads to DoS, εξηγείται ότι επειδή το backend θα κρατά την HTTP αίτηση ανοιχτή μέχρι να εκτελεστεί μια συναλλαγή, ένας χρήστης μπορεί εύκολα να στείλει πολλές HTTP αιτήσεις στο backend, οι οποίες θα καταναλώσουν όλους τους πόρους του backend και θα οδηγήσουν σε DoS.

Backend<-->Blockchain desync - Συνθήκη αγώνα

Στο σενάριο Poor Transaction Time Handling Leads to Race Condition, εξηγείται ότι σε ένα παιχνίδι ήταν δυνατό για τον χρήστη να στείλει ένα αίτημα ανάληψης στο backend το οποίο θα στείλει στον χρήστη τα νομίσματά του, αλλά ενώ η συναλλαγή ήταν ακόμα σε επεξεργασία, ο χρήστης ήταν σε θέση να χρησιμοποιήσει αυτά τα νομίσματα για να αγοράσει αντικείμενα στο παιχνίδι, αποκτώντας τα δωρεάν.

Ένα άλλο παράδειγμα θα μπορούσε να είναι η δυνατότητα χρήσης των ίδιων νομισμάτων για την αγορά διαφορετικών αντικειμένων καθώς το backend δίνει αμέσως το αντικείμενο στον χρήστη χωρίς να περιμένει την επιβεβαίωση της συναλλαγής και επομένως περιμένοντας τη μείωση του υπολοίπου του χρήστη στο blockchain.

Επικύρωση διευθύνσεων έξυπνης σύμβασης

Στο σενάριο Bridge Backend Lacks Smart Contract Address Validation εξηγείται πώς το backend ελέγχει τη διεύθυνση της έξυπνης σύμβασης, έτσι ήταν δυνατό για έναν επιτιθέμενο να αναπτύξει μια ψεύτικη έξυπνη σύμβαση, να βάλει κεφάλαια σε αυτήν, να στείλει τη συναλλαγή στο backend και το backend θα σκεφτεί ότι ο χρήστης έστειλε κεφάλαια στην πραγματική έξυπνη σύμβαση και θα δώσει στον χρήστη τα tokens.

Κακή διαχείριση κατηγοριών περιουσιακών στοιχείων

Στο σενάριο Mishandling of Asset Classes, εξηγείται ότι το backend μπέρδεψε ένα NFT απάτης σε μια διεύθυνση με 1 MATIC, επιτρέποντας έτσι στον επιτιθέμενο να στείλει εκατοντάδες NFT απάτης στη διεύθυνση και να αποκτήσει 1 MATIC από την πλατφόρμα για καθένα από αυτά.

Αναφορές

{{#include ../../banners/hacktricks-training.md}}