Cross Site Request Forgery (CSRF)

Thiseas — Sun, 11 Oct 2015 18:38:01 GMT

Το παρακάτω άρθρο αποτελεί αναδημοσίευση κομματιών ή και επι του συνόλου, άρθρων του γράφοντος που είχε κάνει σε άλλα ιστολόγια. Να ξεκαθαρίσω οτι ο στόχος εδώ είναι η εκμετάλλευση της υψηλής επiσκεψιμότητας από developers του τρέχοντος forum με αντικειμενικό σκοπό την ενημέρωση τους ή πιο καλά την ενεργοποίηση της... καχυποψίας τους επάνω σε θέματα ασφάλειας κώδικα.

Ας πάμε...

Θα υποπτευόσαστε ποτέ ως διαρρήκτη τον ίδιο τον ιδιοκτήτη ενός σπιτιού (ας πούμε τον Κο Νοικοκύρη), όταν τον βλέπατε μέρα μεσημέρι να μπαίνει στο σπίτι του από την κεντρική είσοδο με τα κλειδιά στο χέρι; Οι μόνοι που θα μπορούσαν να απαντήσουν «ναι» σε ένα τέτοιο ερώτημα είναι μόνο όσοι έχουνε προβλήματα όρασης! Πώς είναι δυνατόν να υποπτευτείς αυτόν που έχει την δικαιοδοσία να κάνει κάτι; Χμ… μήπως θα πρέπει να το ξανασκεφτούμε; Θα μπορούσε να τον έχει βάλει κάποιος ο οποίος τον απείλησε και ο Κος Νοικοκύρης να το κάνει κάτω από ψυχολογική βία, ή… ακόμα χειρότερα, θα μπορούσε να τον έχει βάλει κάποιος και ο Κος Νοικοκύρης να μην το έχει καν καταλάβει! Όσο κι αν φαίνεται απίθανο και πέρα από τα όρια της λογικής, η τελευταία περίπτωση μπορεί να συμβεί. Ίσως όχι τόσο συχνά στον πραγματικό μας κόσμο, αλλά αρκετά συχνά σε έναν άλλο κόσμο, ιδεατό, εικονικό, αλλά εξίσου επικίνδυνο: Ποιόν άλλον; Τον κόσμο του διαδικτύου. Στο άρθρο αυτό θα μιλήσουμε για τέτοιες επιθέσεις.

Θα αναφερθούμε στo περίφημο Cross Site Request Forgery (CSRF) ή one-click attack ή session riding ή WRPC attack for Web based RPC attack. Όπως καταλάβατε πρόκειται για τον αρχινονό των επιθέσεων μια και με τόσα ονόματα ελπίζει να ξεγλιστρήσει και δυστυχώς, δεν είναι λίγες οι φορές που τα καταφέρνει. Πρόκειται για μια μεθοδολογία επίθεσης που μόλις το 2008 εντάχθηκε στην λίστα των γνωστών παγκόσμιων απειλές του διαδικτύου (http://is.gd/zzXP) αν και το 2006 είχε αναφερθεί ως ο Κοιμώμενος Γίγαντας στο άρθρο του Security DarkReading.

Λίγο… background

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

Ας ξεκινήσουμε με ένα απλό παράδειγμα: Έστω ότι είμαστε υπεύθυνοι (administrators) σε ένα forum που έχει να κάνει με ασφάλεια υπολογιστών. Κάθε φορά που επισκεπτόμαστε το forum με τον αγαπημένο μας Internet Browser δίνουμε κωδικό και password για να αποκτήσουμε πρόσβαση και (όπως λέμε) να μπούμε μέσα. Η διαδικασία αυτή ονομάζετε authentication ή στα «ξένα» αυθεντικοποίηση (εικόνα 1).

Εικόνα 1: Έχοντας μπει στο site μας με δικαιώματα administrator.

Όση ώρα είμαστε μέσα στο site μας μπορούμε να εκτελέσουμε διάφορες ενέργειες, όπως: Να γράψουμε ένα νέο post, να απαντήσουμε σε κάποιο άλλο κλπ. Δηλαδή ότι μπορούν και τα υπόλοιπα μέλη του forum μας. Όμως εμείς (ως Admin!!) μπορούμε να εκτελέσουμε κάποιες εργασίες που τα άλλα μέλη δεν μπορούν, όπως για παράδειγμα την διαγραφή κάποιου post ενός άλλου μέλους, ή την αποβολή του από το forum, το λεγόμενο ban και πολλά άλλα. Πως γνωρίζει ο server ποιοι είμαστε για να μας αφήσει να εκτελέσουμε αυτές τις ενέργειες; Μα φυσικά, θα σκεφτεί κάποιος, από το authentication που κάναμε στην αρχή. Χμ... τα πράγματα δεν και τόσο απλά.

Το ότι κάναμε authentication μια δεδομένη χρονική στιγμή δεν σημαίνει απολύτως τίποτε διότι το internet είναι (όπως έχουμε ξαναπεί) stateless και κάθε φορά που πατάμε μια ενέργεια στο browser μας, ο server που επισκεπτόμαστε είναι σαν να μας «βλέπει» για πρώτη φορά (http://is.gd/As3a). Αυτή η έλλειψη «μνήμης» του server (όσα Gb RΑΜ κι αν έχει!!) πρέπει με κάποιο τρόπο να «γεφυρωθεί» έτσι ώστε να μας θυμάται για να μην μας ζητά authentication κάθε φορά που του ζητάμε κάτι. Πραγματικά, το σενάριο, αν δεν είχαμε τρόπο να λύσουμε αυτό το πρόβλημα, είναι... εφιαλτικό! Κάθε στιγμή θα μας έλεγε ο server:

Server: -Συγγνώμη κύριε, ποιος είστε;

Admin: -Μα... μόλις συστηθήκαμε!

Αυτό λοιπόν το ιδιόμορφο alzheimer θεραπεύεται με μερικά... μπισκοτάκια! Μην ανησυχείτε, δεν μας έπιασε ο συνήθης παλιμπαιδισμός που μας διακρίνει συχνά και που μας κατατρέχει σχεδόν μόνιμα!, απλά, Μπισκοτάκια (Cookies) ονομάζονται κάποιες μικρού μεγέθους πληροφορίες που βάζει ο server στην μνήμη του υπολογιστή μας έτσι ώστε κάθε φορά που τον καλούμε να θυμάται ποίοι είμαστε (http://is.gd/Asgx).

Μια τέτοια πληροφορία έχει εισαχθεί και στο δικό μας PC και αναφέρει στον server της εικόνας 1 ότι εμείς είμαστε οι διαχειριστές και κατά συνέπεια έχουμε αυξημένα δικαιώματα. Δεν θα επεκταθούμε περισσότερο σε αυτό, μια και θα βγούμε «εκτός θέματος».

Η μέθοδος

Σκεφτείτε ότι εμείς, τώρα, είμαστε οι υποχθόνιοι τύποι που θέλουμε να γίνουμε διαχειριστές στη θέση του διαχειριστή αλλά βρισκόμαστε σε έναν άλλο υπολογιστή ίσως αρκετές χιλιάδες χιλιόμετρα μακριά και το μοναδικό σημείο επαφής μας είναι ο server που φιλοξενεί το forum που θέλουμε να επιτεθούμε. Τι θα συμβεί αν καταφέρουμε να έχουμε πρόσβαση στο cookie του admin; Τότε, θα μπορούσαμε να εκτελέσουμε όλες τις εντολές και τις ενέργειες που μπορεί να έχει ένας διαχειριστής.

Ας πούμε ότι έχουμε προηγούμενα με κάποιο μέλος του συγκεκριμένου forum και θέλουμε να το αποβάλουμε, κοινώς να το ban-άρουμε! Πως θα καταφέρουμε κάτι τέτοιο χωρίς να είμαστε διαχειριστές (admins);

Κατ’ αρχάς πρέπει να ξέρουμε πως όταν ο πραγματικός admin μπανάρει ένα μέλος, στην πραγματικότητα καλεί μια έτοιμη ενέργεια που παρέχει το forum μόνο σε αυτόν. Αυτή η ενέργεια μπορεί να είναι η κλήση ενός προγράμματος στον server που φιλοξενεί το forum. Μόλις κληθεί αυτή η ενέργειά, σίγουρα θα τσεκάρει το cookie (για να ελέγξει αν πρόκειται για τον admin) και μετά θα συνεχίσει το... θεάρεστο έργο της.

Εικόνα 2: Ο χρήστης έχει αποβληθεί (banned) από το forum.

Αυτό λοιπόν που θα κάνουμε συνοψίζεται τα παρακάτω βήματα:

Βήμα 1: Βρίσκουμε (ή φτιάχνουμε μόνοι μας) ένα πρόγραμμα ή μια εντολή η οποία είναι η ίδια που εκτελείτε από το forum όταν ο πραγματικός διαχειριστής αποβάλει ένα άτομο (θα πούμε παρακάτω πως θα την βρούμε κλπ).
Βήμα 2: Αφού την φτιάξουμε θα την βάλουμε σε ένα link το οποίο με κάποιο τρόπο θα στείλουμε στον διαχειριστή και θα τον ωθήσουμε να το πατήσει (με την θέληση του ή μη!). To βήμα αυτό χρειάζεται και λίγο Social Engineering (http://is.gd/AEyb). Μόλις το πατήσει, ο σκοπός έχει επιτευχθεί!

Ας δούμε, λοιπόν, πως γίνονται όλα αυτά στην πράξη!

Η υλοποίηση

Πρώτα πρέπει να υλοποιήσουμε το βήμα 1. Θα βρούμε τι ακριβώς εκτελείται από το πρόγραμμα του forum όταν ο διαχειριστής μπανάρει έναν χρήστη. Εδώ χρειάζεται λίγη πονηριά και λίγη παρατηρητικότητα. Σχεδόν όλα τα forums αναφέρουν τον κατασκευαστή και την έκδοση που βρίσκονται. Αν προσέξετε την εικόνα 1 θα δείτε ότι στο κάτω μέρος αναφέρει “Powered by BabbleBoard v.1.1.6”. To babbleboard είναι ένα γνωστό πρόγραμμα για forums και μάλιστα προσφέρεται και δωρεάν. Ας το κατεβάσουμε λοιπόν και ας το εγκαταστήσουμε στον δικό μας web server. Εδώ απαιτείται να έχουμε ένα δικό μας web server. Μην τρομάζετε, είναι απίστευτα απλό και... δωρεάν! Υπάρχουν εκατοντάδες εταιρίες στο internet που είναι πρόθυμες να σας φιλοξενήσουν (google it “hosting” και θα καταλάβετε).

Αφού λοιπόν βρούμε και κατεβάσουμε το BabbleBoard και συγκεκριμένα την έκδοση 1.1.6, φτιάχνουμε ένα τεχνητό forum, και μπαίνουμε σαν διαχειριστές. Φτιάχνουμε και 2-3 χρήστες και αρχίζουμε να τους μπανάρουμε για να δούμε ποιες ακριβώς εντολές εκτελούνται! Για να δούμε όμως κάτι τέτοιο θα χρησιμοποιήσουμε ένα πολύ χρήσιμο add-on του firefox: To Live Http Headers (http://is.gd/9j1P). Το συγκεκριμένο add-on μας δείχνει ποιές εντολές (κρυφές ή μη) εκτελούνται στον server όταν πατάμε ένα link ή μια ενέργεια στον browser μας. Απ’ ότι καταλάβατε, η ενέργεια που θα κατασκοπεύσουμε είναι η “Ban User”.

Δεν είναι ο σκοπός του άρθρου αυτού να σας δείξει πως εγκαθιστώ ένα forum ή CMS (Content Management System), ούτε και να δείξει πως ακριβώς λειτουργεί το add-on http-header. Αυτά τα βήματα θα τα θεωρήσουμε ως δεδομένα.

Ανοίγουμε, λοιπόν, το τεχνητό forum μας και μπαίνουμε σαν διαχειριστές. Πάμε στην διαχείριση Χρηστών και επιλέγουμε έναν τυχαίο χρήστη (κάποιον από αυτούς που φτιάξαμε πριν λίγο). Θα παρατηρήσουμε ότι υπάρχει (όπως σε όλα τα CMS άλλωστε) μια επιλογή «ban user». Ενεργοποιούμε το Live Http Headers και πατάμε την επιλογή. Θα δούμε ότι ο συγκεκριμένος χρήστης δεν μπορεί πια να μπει στο forum μας (εικόνα 2). Ωραίαααα! Ας δούμε τώρα τι ακριβώς έχει καταγράψει το πρόγραμμα http-headers :

Εικόνα 3: Καταγραφή των εντολών του ban, φαίνεται η βασική εντολή «εκτέλεσης».

Βλέπουμε ότι η βασική εντολή που υλοποιεί το ban είναι η παρακάτω:

http://www.ToTexnitoSiteMas.gr/index.php?page=admin&act=members&func=ban&id=2

Χμ... απ’ ότι βλέπουμε το μόνο που χρειάζεται είναι να περάσουμε το id του χρήστη που θέλουμε να μπανάρουμε στην μεταβλητή “id”. Το id ενός χρήστη είναι πάρα πολύ εύκολο να το βρούμε διότι δεν αποτελεί κάποια κρυμμένη πληροφορία. Μπορούμε να το βρούμε συνήθως πηγαίνοντας στην λίστα μελών (members) του forum και εκεί να κάνουμε click στον συγκεκριμένο χρήστη. Στην γραμμή URL του browser μας ή (πάλι με την χρήση του http-headers) θα δούμε το id του χρήστη. Μόλις ολοκληρώσαμε επιτυχώς το βήμα 1.

Ερχόμαστε τώρα στο βήμα 2. Πρέπει να φτιάξουμε ένα link κάπου το οποίο θα εκτελεί την παραπάνω εντολή ως εξής:

http://www.ToSiteStoxos.gr/index.php?page=admin&act=members&func=ban&id=245

όπου το 245 είναι το id του χρήστη που μας είναι αντιπαθής και το “www.ToSiteStoxos.gr” είναι το προς επίθεση site.

Αυτό που τώρα μένει είναι να κρύψουμε την παραπάνω εντολή μέσα σε ένα κάποιο αρχείο html και να το στείλουμε με την μορφή link στον administrator του forum. Μόλις κάνει click επάνω σε αυτό και με το δεδομένο ότι έχει μπει στο forum του (βασικό αυτό – για να έχουν ενεργοποιηθεί τα μπισκοτάκια του!), θα εκτελεστεί η εντολή αποβολής του χρήστη με id 245, στον δικό του υπολογιστή. Δηλαδή στον υπολογιστή που έχει το σωστό cookie! Έτσι ο admin χωρίς να το θέλει θα αποβάλει τον χρήστη 245.

Έχουμε όμως να ξεπεράσουμε μερικά μικρά εμπόδια: Δεν πρέπει σε καμιά περίπτωση o διαχειριστής να καταλάβει τι έκανε. Δηλαδή θα πρέπει να βλέπει στην οθόνη του κάτι τελείως άσχετο με την κρυφή ενέργεια μας ώστε να μην πονηρευτεί πως κάτι περίεργο συμβαίνει. Πώς θα το κάνουμε αυτό; Χμ... εδώ θα κάνουμε ένα μικρό trick με την html. Θα κρύψουμε την εντολή αυτή μέσα σε μια... εικόνα! Μόλις το αρχείο html θα ανοίξει από το browser του θύματος, το πρώτο πράγμα που θα κάνει ο browser είναι να πάει να ανοίξει όλες τις εικόνες που αναφέρονται μέσα στο αρχείο αυτό. Μια από αυτές όμως δεν θα είναι πραγματική εικόνα. Ο browser δεν είναι σε θέση να το γνωρίζει αυτό, οπότε θα εκτελέσει τον... κακό μας κώδικα!

Φτιάχνουμε λοιπόν το αρχείο html που θα είναι το δόλωμα μας:

ArxeioDoloma.html
<img src="http://tbn2.google.com/images?q=tbn:B6T6sKSdPglmgM:http://www.pnl.gov/breakthroughs/issues/2005-issues/fall/images/cyber_security.jpg"/>
<img src="http://tbn1.google.com/images?q=tbn:UwCxyuruNPQ90M:http://www.cbc.ca/news/background/computer-security/gfx/titlephoto.jpg"/>
<img src="http://www.ieee-security.org/Cipher/IMAGES/HORSE-nosky-red-trans2.gif>
<img src="http://tbn0.google.com/images?q=tbn:33Ss5eKab3X_fM:http://www.freedomsecurity.us/Security%20Badge.jpg"/>
<img src="http://www.s3curity.gr/babbleboard/index.php?page=admin&act=members&func=ban&id=4"/>

Απ’ ότι βλέπετε η εντολή που θα κάνει την «δουλειά» είναι η τελευταία η οποία είναι κρυμμένη μέσα σε ένα <img> tag! Το επόμενο βήμα μας είναι να ανεβάσουμε αυτό το αρχείο σε κάποιον server (π.χ. σε αυτόν που δοκιμάσαμε το forum μας στο βήμα 1) και μετά στείλουμε ένα πολύ όμορφο PM (Personal Message) στον διαχειριστή και να του λέμε τα εξής:

---

Φίλε Admin γεια χαρά,

Κατ’ αρχάς θέλω να σε συγχαρώ για την καταπληκτική δουλειά που έχει κάνει στο forum.
Είμαι 10 χρόνια web designer αλλά με ενδιαφέρει πάρα πολύ και το θέμα του security.
Στο forum σας βρήκα αυτό που ακριβώς έψαχνα: ένα χώρο αξιόπιστο και με γνώσεις για κάποιον που θέλει να μάθει.
Btw, βρίσκω τα βασικό banner του site σας μια χαρά, αλλά θα ήθελα να σε ενημερώσω ότι τεχνολογικά υπάρχουν κι άλλες νεότερες υλοποιήσεις τις οποίες έχω σχεδιάσει εγώ ο ίδιος για κάποιους πελάτες μου στο παρελθόν. Θα χαρώ να τις μοιραστώ μαζί σας, φυσικά χωρίς καμιά απολύτως χρέωση. Αν σε ενδιαφέρει ρίξε μια ματιά στο παρακάτω link για να δεις για τι πράγμα σου μιλάω:

LINK--> <a href="http://www.ToTexnitoSiteMas.gr/ArxeioDoloma.html">Οι Εκόνες μου</a>

Ζητώ συγγνώμη αν κάποιες είναι broken, μια και είναι από sites πελατών μου και μπορεί να τις έχουμε αλλάξει θέση.

Σε ευχαριστώ και πάλι για όλες τις χρήσιμες πληροφορίες που μας παρέχεις!

O_Kakos_Daimonas

---

Μόλις λοιπόν ο admin διαβάσει το παραπάνω PM θα σπεύσει (ελπίζουμε, σαν κακόπιστοι και υποχθόνιοι τύποι που είμαστε) να πατήσει το link για να δει ποιο είναι αυτό το νέο και μοντέρνο banner που θέλει να του προσφέρει δωρεάν ο φίλος “O_Kakos_Daimonas”. Θα δει λοιπόν τα παρακάτω:

Εικόνα 4: Ένα αρχείο με κάποιες εικόνες. Κάποιες είναι... broken, όχι όμως λόγο του οτι λείπει το link!

Όταν ο διαχειριστής θα δει την παραπάνω εικόνα, το κακό θα έχει ήδη γίνει και δεν θα έχει πάρει «μυρωδιά»! Οι εικόνες θα έχουν εκτελεστεί από τον web browser και ο καημένος ο χρήστης θα έχει γίνει ban χωρίς να έχει κάνει τίποτε κακό! Ένα ακόμα Cross Site Request Forgery vulnerability θα έχει επιτευχθεί!

Πιο προχωρημένες τεχνικές

Η παραπάνω τεχνική ήταν από τις πιο απλές και εύκολες στην υλοποίηση. Αυτό διότι υλοποιούσε το μοντέλο GET. Δηλαδή όλες οι απαραίτητες πληροφορίες για την επίθεση περνούσαν στον server από την γραμμή του web browser μας (στην γραμμή διευθύνσεων – το λεγόμενο URL box) σαν παράμετροι στο βασικό αρχείο index.php. Δεν λειτουργούν όμως όλες οι επιθέσεις έτσι. Πολλά και μάλιστα σοβαρά sites υλοποιούν το μοντέλο POST. Δηλαδή οι βασικές παράμετροι μιας ενέργειας περνάνε με την μορφή κρυφών μεταβλητών οι οποίες δεν είναι ορατές στο URL box. Και σε αυτές τις περιπτώσεις (δυστυχώς) μπορούμε να υλοποιήσουμε επιθέσεις, με την χρήση JavaScript.

Για παράδειγμα, έστω ότι βλέπαμε μέσω http-headers, σε κάποιο forum, πως όταν διαγράφουμε έναν χρήστη εκτελείτε η παρακάτω ενέργεια:

Εικόνα 5: Διαγραφή ενός χρήστη με την χρήση POST requests.

Εδώ δεν μπορούμε να καλέσουμε απλά μια εντολή στην την γραμμή διεύθυνσης του browser μας. Θα πρέπει να υλοποιήσουμε την επίθεση γράφοντας πρώτα τον παρακάτω κώδικα:

csrf_exploit2.php
<html>
<form name="admin" action="http://www.ToSiteStoxos.gr/index.php" method="POST">
   <input type="hidden" name="action" value="ThreadDelete">
   <input type="hidden" name="threadID" value="5">
   <input type="hidden" name="x" value="2">
   <input type="hidden" name="y" value="8">
</form>
<script>document.admin.submit()</script>
</html>

Δηλαδή υλοποιούμε τις μεταβλητές με κρυμμένες μεταβλητές html, όπως ακριβώς κάνει και το κανονικό forum-στόχος. Το αντίστοιχο αρχείο δόλωμα όμως δεν θα ήτανε το csrf_exploit2.php, αλλά κάποιο άλλο που θα καλούσε (έμμεσα) το csrf_exploit2.php. Δηλαδή κάτι σαν αυτό:

ArxeioDoloma2.html

<html>
<IFRAME src="http://www.ToSiteStoxos.gr/csrf_exploit2.php" WIDTH=0 HEIGHT=0 frameborder=0></IFRAME>
<meta HTTP-EQUIV="REFRESH" content="0; url=http://twitter.com/totalXAKER">
</html>

Το ArxeioDoloma2.html χρησιμοποιεί πιο προχωρημένη τεχνική phishing οδηγώντας το θύμα στο twitter του total Xaker, κρύβοντας εντέχνως (μέσω IFRAME με μηδενικό μέγεθος!) τον πραγματικό του στόχο που είναι η κλήση και η εκτέλεση του csrf_exploit2.php!

Η αλήθεια βρίσκεται εκεί έξω

Δυστυχώς η αλήθεια δεν βρίσκεται σε μικρά forums και σε ψευτο-διαμάχες μεταξύ χρηστών, αλλά σε πιο σοβαρά θέματα όπως η κλοπή προσωπικών δεδομένων, η κλοπή χρημάτων μέσω παράκαμψης ασφάλειας σε περιβάλλον web-banking και διάφορα άλλα τέτοια «όμορφα». H συγκεκριμένη αδυναμία είναι μεν σχετικά παλιά, αλλά είναι και αρκετά σπάνια και όχι τόσο διαδεδομένη. Είναι όμως ΠΑΡΑ ΠΟΛΥ επικίνδυνη!

Οφείλουμε να ειδοποιήσουμε όλους όσους διαβάσουν αυτό το άρθρο ότι τα παράδειγμα μας ήταν εντελώς αληθινά και δυστυχώς δεν περιορίζονταν μόνο σε μικρά forums. Ο στόχος μας όμως είναι η γνώση για την προφύλαξη και όχι για την επίθεση! Όσοι έχουν πρόσβαση σε μεγάλους οργανισμούς ή εταιρίες ας πονηρευτούν.

Η παρακάτω εικόνα (ελπίζω αρκετά καλά κρυμένη) δείχνει την υλοποίηση μιας επιτυχημένης επίθεσης σε Web Banking μεγάλης Ελληνικής Τράπεζας με αποτέλεσμα την μεταφορά χρημάτων από ένα λογ/μό σε ένα άλλο, χωρίς την... συγκατάθεση του χρήστη!

Φυσικά δεν θα ήθελα να περιμένει κάποιος να δείξουμε συγκεκριμένες λεπτομέρειες από την συγκεκριμένη επίθεση, αν και δεν διαφέρει σε τίποτα (σε μεθοδολογία) από αυτές που ήδη παρουσιάστηκαν. Η συγκεκριμένη επίθεση μετέφερε 11€ από ένα λογαριασμό (πηγή) σε ένα άλλο λογαριασμό (στόχο). Μάλιστα πριν γίνει η ανορθόδοξη μεταφορά (μέσω της επίθεσης) έγινε μια κανονική μεταφορά (10€) από τον ίδια πηγή στον ίδιο στόχο. Όπως βλέπετε η κινήσεις στον λογ/μό στόχο δεν φαίνεται να έχουν καμιά διαφορά... Αναφέρονται σαν 2 απλές καταθέσεις.

Αντίμετρα

Λάβετε σοβαρά υπ’ όψη αυτήν την αδυναμία και (για αρχή) σαν χρήστες κάντε τα παρακάτω:

Να μην αφήνετε ανοιχτό το session σε ένα ευαίσθητο site που είστε γραμμένοι. Με απλά λόγια, όταν τελειώνετε τις εργασίες σας να κάνετε πάντα logout, «έξοδος χρήστη» ή όπως αλλιώς λέγεται στο κάθε site ώστε να διαγράφονται τα session cookies.
Να χρησιμοποιείτε έναν internet browser που να εκτελείτε τις οικονομικές σας συναλλαγές και γενικά που διαχειρίζεστε προσωπικά δεδομένα και έναν άλλον internet browser που θα είστε σε sites χαμηλής ή / και αμφιβόλου αξιοπιστίας.
Να ΜΗΝ ανοίγετε και να ΜΗΝ εμπιστεύεστε ότι mail ή link σας δώσει κάποιος. Ακόμα κι αν αυτός σας είναι απόλυτα έμπιστος. Εν ανάγκη κάντε το copy και ανοίχτε το στον άλλον internet browser.

Στον internet γενικότερα να μην έχετε εμπιστοσύνη ούτε στον ίδιο σας τον εαυτό διότι ενίοτε μπορεί να είναι κάποιος... άλλος!