Preventing CSRF attacks

[flienky]

Οποτε πρέπει να προστατευθούμε απο τα CSRF attacks. Το motto οταν προσπαθουμε να κανουμε πιο Secure ενα web application, ειναι το "αν το κανεις μονος σου ειναι λαθος".

Αλλά διαβάζοντας αρκετά για τις CSRF attacks, πολλοι ποστατεύονται μόνοι τους χωρίς βιβλιοθήκες τρίτων.

Οπότε αυτό έκανα και εγώ.

Σε κάθε form που θέλω να προστατέψω, δημιουργώ ένα input το οποίο είναι hidden και έχει property: value=token.

Μια χαρα μεχρι εδω, με το token να υπολογίζεται με php και χωρίς javascript. Κατα την δημιουργία του, αποθηκεύεται και στην session.

 

Ο κώδικας για την δημιουργία του:

$token = base64_encode(openssl_random_pseudo_bytes(40)); //generate the token 
$_SESSION['CSRF_token']=$token;//store the token in to session

Αλλά και για την επαλήθευσή του, εφόσον έχει γίνει submit στην form:

if((isset($_POST['CSRF_token'])) && ($_POST['CSRF_token']==$_SESSION['CSRF_token'])){
    return ; //ειναι μεσα σε function οποτε οκ.
}else{
    throw new Exception('Invalid CSRF token.');
}catch ...

To generating του token ειναι per request και οχι per session.

 

Έχετε να προτείνεται κάτι? Είναι ασφαλές? Το κομμάτι του generating του token είναι random (ειναι αφου το προτείνει η php)?

 

Thanks.

[defacer]

Χεχ, "ασφαλές".

 

Ακόμα και τέλειο να είναι κάτι και θεωρητικά ασφαλές, παραμένει ασφαλές μόνο όσο παίζεις αποκλειστικά με τους κανόνες που λειτουργεί το σύστημα. Η ασφάλεια σε τέτοια πράγματα συνήθως χάνεται όχι γιατί υπάρχει κάποιο χοντρό λάθος στην υλοποίηση, αλλά επειδή κάπου βγαίνουμε εκτός προδιαγραφών χωρίς να το καταλάβουμε οπότε εκείνο το σημείο δεν είναι πλέον ασφαλές. Οπότε δε γίνεται να δει κανείς οποιδήποτε snippet και να σου πει είναι ΟΚ και αυτό να σημαίνει πως όσο δεν αλλάζεις αυτό το snippet είναι αδύνατον να κάνεις άλλη μαλακία.

 

Στην περίπτωσή σου πέραν του ότι πρέπει να το ελέγχεις ευλαβικά και να έχουν όλες οι φόρμες CSRF protection (που το θεωρώ δεδομένο) τα θέματα που βλέπω είναι τα εξής:

1. Ο τρόπος με τον οποίο ελέγχεις (αν όχι isset τότε τίποτα) σημαίνει πως είναι trivial να γίνει το attack -- δημιουργείς μια φόρμα χωρίς το token σε σελίδα σου, φέρνεις το θύμα εκεί και πάπαλα.
2. Αν χρησιμοποιείς πουθενά άλλα HTTP verbs τότε ο παραπάνω κώδικας δεν είναι αρκετός για να σε προστατέψει. Και επειδή σίγουρα χρησιμοποιείς επιπλέον τουλάχιστον GET στην εφαρμογή, ο παραπάνω κώδικας σίγουρα δεν είναι αρκετός για εγγυημένη προστασία. Υπογραμμίζω ότι αν χρησιμοποιείς και άλλα εκτός GET τότε έχεις όλες τις προϋποθέσεις για το καλύτερο είδος προβλήματος: αυτό που φαίνεται ότι δεν υπάρχει εκτός κι αν κάνεις ανατριχιαστικά λεπτομερή και ανατριχιαστικά σωστή ανάλυση.
3. Ο έλεγχος που κάνεις με == θα μπορούσε ίσως κάποτε αν συγκλίνουν οι πλανήτες (αν το ένα από τα δύο που συγκρίνεις κάπως γίνει integer) να είναι γιαλαντζί, ξεβρακώνοντας έτσι το protection. Θεωρητικό σενάριο αλλά γιατί να το συζητάμε, η λύση είναι απλή, βάζεις === και τέλος.
4. Κάνοντας refresh per-request δυσκολεύεις τη ζωή του χρήστη που μπορεί να θέλει να έχει ανοιχτά πολλά tabs μαζί στην εφαρμογή σου. You might care, or not.
5. Nitpick για την random_pseudo_bytes: υποθέτω τη χρησιμοποιείς γιατί cryptographically strong moar security. Αλλά θεωρητικά υπάρχει περίπτωση να σου γυρίσει non-crypto strength αποτέλεσμα και δεν ελέγχεις γι' αυτό. Πρακτικά βέβαια δεν υπάρχει.
6. Nitpick για την random_pseudo_bytes: από τη στιγμή που κάνεις per-request refresh δεν είναι απαραίτητο να την καλείς κάθε φορά (είναι ακριβή). Μπορείς απλά να έχεις ένα hardcoded secret στην εφαρμογή σου, να καλείς την pseudo_bytes once per session για να πάρεις ένα initial token και από κει και πέρα $nextToken = sha1($oldToken . $hardcodedSecret).

Και τέλος, ξαναδιάβασε την πρώτη παράγραφο.

[flienky]

Καταρχήν ευψαριστώ. Απλώς δεν κατάλλαβα σωστά το πρώτο που είπες. Μπορείς να το αναλύσεις καλύτερα?

Αν χρησιμοποιώ και άλλα HTTP verbs εννοείς πως μπορεί να γίνει CSRF attacks από αυτά?

Τα == θα φυγουν και θα πανε τα ===. Και εγω το σκεφτηκα αλλα λεω τι διαλο, πρεπει να ειμαι σε πολυ κακη μερα για τα === να βγουν καλύτερα!

 

Καλά ποτε δεν αναζητουμε να το κανουμε 100% ασφαλές καθως αυτο δεν γινεται. Απλώς αναζητω μην εχω κανει καμία γερή γερή πατάτα που κάνει μπαμ απο χιλιόμετα!

[Επισκέπτης]

Άλλο τα CRSF κι άλλο τα XSS. Ο κώδικας που έχεις γράψει σε προστατεύει υποτυπωδώς από XSS.

[defacer]

Καταρχήν ευψαριστώ. Απλώς δεν κατάλλαβα σωστά το πρώτο που είπες. Μπορείς να το αναλύσεις καλύτερα?

Ούπς, διάβασα το snippet λάθος. Αν δε στείλεις CSRF_token τότε exception, οπότε είσαι ΟΚ εκεί. Μι σκούζι.

 

Αν χρησιμοποιώ και άλλα HTTP verbs εννοείς πως μπορεί να γίνει CSRF attacks από αυτά?

Αν έχεις οτιδήποτε που γίνεται με GET και "κάνει πράγματα" έχεις πρόβλημα (θεωρητικά αυτό "απαγορεύεται" έτσι κι αλλιώς για σημασιολογικούς λόγους HTTP verbs κλπ αλλά famous last words).

 

Για άλλα verbs τότε εξαρτάται πολύ από το context και γενικά όλο τον υπόλοιπο κώδικα που δε γίνεται να δούμε.

 

Παράδειγμα, αν ποτέ αυτός ο κώδικας χρησιμοποιηθεί στο context άλλου κώδικα που σου επιτρέπει να κάνεις fake το HTTP verb (fake όσον αφορά την εφαρμογή, τεχνικά το verb δε θα αλλάξει) από τον client μέσω μεταβλητής (ξέρω, ακούγεται ανατριχιαστικό αλλά συμβαίνει και στις καλύτερες οικογένειες) τότε μπορεί κάποιος να δοκιμάσει σου κάνει CSRF με μια φόρμα που κάνει submit GET και fake κάτι άλλο (PUT, DELETE). Αν το επιτρέψεις αυτό είσαι vulnerable και ακόμα χειρότερα θα νομίζεις ότι δεν είσαι.

Άλλο τα CRSF κι άλλο τα XSS. Ο κώδικας που έχεις γράψει σε προστατεύει υποτυπωδώς από XSS.

 

Όχι, είσαι εντελώς λάθος.

[flienky]

Κατάλλαβα. Αν εχεις την enableHttpMethodParameterOverride() -> on θα πρέπει να τσεκάρεις και το PUT και DELETE για CSRF. Thanks

[0verc0me]

Για οποιον (αλλον) ενδιαφερεται για προστασια apo csrf attacks και θελει μια ετοιμη λυση ας κοιταξει αυτο της paragonie: https://github.com/paragonie/anti-csrf

[defacer]

Κατάλλαβα. Αν εχεις την enableHttpMethodParameterOverride() -> on θα πρέπει να τσεκάρεις και το PUT και DELETE για CSRF. Thanks

 

Βασικά η ιδέα είναι ότι επειδή μπορεί κάποια routes στην εφαρμογή σου να αποκρίνονται μόνο σε PUT/DELETE, και επειδή PUT/DELETE δε μπορείς να χρησιμοποιήσεις από φόρμα, η εφαρμογή σου θα παίρνει ένα POST και θα προσποιείται ότι είναι ξερωγώ PUT.

 

Το πρόβλημα θα ήταν να σου στείλει κάποιος τη φόρμα με GET, ο κώδικάς σου να μη κάνει CSRF check επειδή είναι GET, και λίγο παρακάτω άλλος κώδικας να αρχίσει να μεταχειρίζεται το GET σαν PUT (το οποίο θα έπρεπε να προστατεύεται από CSRF).

 

Αυτά όλα δεν ισχύουν για XHR επειδή εκεί σε προστατεύει το SOP, μόνο προσοχή σε περίπτωση που έχεις χαλαρώσει την προστασία με CORS.

[flienky]

Απλώς για να δώ λιγο αν κατάλλαβα σωστά.

Στο παρακάτω παραδειγμα ας πούμε πως οι servers δεν προσποιούνται ότι μερικά requests είναι PUT ή DELETE.

 

Έστω, λοιπόν ένα request στο οποίο θα πρέπει να έχει response, δηλαδή το site A να διαβάσει data από το site B.

Ο attacker στέλνει ένα XHR request από το site A σε cross domain site B.

Το x-requested-with header δεν υπάρχει κάθως ο server που δέχετε τα requests δεν έχει σετάρει CORS ώστε να βάζει το προηγούμενο header (αν είχε σεταριστεί με CORS τότε θα το έβαζε, σωστά?).

Έτσι το site A δεν θα διαβάσει ποτε data από το Site B.

Αν μπορούσε να διαβάσει δεδομένα, τότε θα μπορούσε να κάνει GET στην φόρμα και να πάρει το token.

 

 

Αν όμως το request είναι ένα απλο request, POST ή GET, χωρίς απάντηση, τότε το SCRF attack θα πραγματοποιηθεί σωστά, ασχέτως αν υπάρχει CORS ή όχι καθως το same origin policy το επιτρέπει.

[defacer]

Απλώς για να δώ λιγο αν κατάλλαβα σωστά.

Στο παρακάτω παραδειγμα ας πούμε πως οι servers δεν προσποιούνται ότι μερικά requests είναι PUT ή DELETE.

 

Έστω, λοιπόν ένα request στο οποίο θα πρέπει να έχει response, δηλαδή το site A να διαβάσει data από το site B.

 

Με μπερδεύεις. Εδώ λες ότι το site A "πρέπει να" διαβάσει από το site B. Άρα το site B πρέπει να συνεργαστεί.

 

Ο attacker στέλνει ένα XHR request από το site A σε cross domain site B.

 

Αλλά τότε πώς γίνεται ο Α να είναι attacker? Αν ο Α δεν είναι attacker "κανονικά" αλλά λόγω άλλου κενού ασφαλείας (π.χ. είχε XSS) έχει έρθει υπό τον έλεγχο του attacker τότε κάπου εδώ ψιλοτελειώνει η συζήτηση γιατί το threat model κάνει την υπόθεση πως ο Α είναι φίλος.

 

Το x-requested-with header δεν υπάρχει κάθως ο server που δέχετε τα requests δεν έχει σετάρει CORS ώστε να βάζει το προηγούμενο header (αν είχε σεταριστεί με CORS τότε θα το έβαζε, σωστά?).

 

Ναι δεν υπάρχει το header αλλά γιατί ο Β δεν έχει σετάρει CORS αφού "πρέπει να" διαβάζεται από τον Α;

 

Έτσι το site A δεν θα διαβάσει ποτε data από το Site B.

 

Αυτό είναι το default... άρα τι εννοείς "έτσι"?

 

Γενικά έχω χάσει το νόημα.

[stamatis1970]

μαργαριτες μεντολες σε IIS γινεται με 1 Line Code.

[defacer]

Ναι ακριβώς όπως τα λες είναι. Τα θέματα ασφαλείας λύνονται με μια γραμμη κώδικα, δε χρειάζεται να ξέρεις τίποτα άλλο.

 

 

 

 

[Muahahahaha]

Ναι ακριβώς όπως τα λες είναι. Τα θέματα ασφαλείας λύνονται με μια γραμμη κώδικα, δε χρειάζεται να ξέρεις τίποτα άλλο.

 

 

απο οτι καταλαβα κανεις τον ειδικο.

Εχεις να μου δειξεις κατι που εχεις φτιάξει και το θεωρεις ασφαλές περιβαλλον?

 

Η απλα μονο θεωρια ξερεις ( clopy paste ) klp?

λες λες λες λες αλλα απο την απαντηση που εδωσες οσον αφορα την μια γραμμη κωδικα φαινετε οτι εισαι ασχετουλης στον real world

εκει που ειναι οι Pro.

 

δείξε μας κατι που εχεις Online και το θεωρεις "ασφαλές" να μαθουμε και εμεις οι "οπως τα λες ειναι" 

 

 

Αλλα βαζω και 100 ευρώπουλα στοίχημα οτι δεν εχεις τα @@ να μας δειξεις .

 

 

 

 

[defacer]

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

[Muahahahaha]

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

 

μεχρι εκει φτανει η τεχνογνωσια σου παλουκαρακι μου ?

 

μπεεεεεεεεεεεεε ρε