|
|
Δημοσιεύτηκε στις 20/2/2021 7:57:29 μ.μ.
|
|
|
|
Για την αποτροπή επιθέσεων CSRF, asp.net mvc παρέχει τη δυνατότητα ValidateAntiForgeryToken κατά της επίθεσης παραχάραξης και στη νέα έκδοση του asp.net βασικού πλαισίου, η Microsoft παρέχει τη δυνατότητα AutoValidateAntiforgeryToken, συγκεκριμένα ValidateAntiForgeryToken και AutoValidateAntiforgeryToken Ποια είναι η διαφορά, αυτό το άρθρο θα εξηγήσει λεπτομερώς.
Έννοια ΚΣΠΑ
Το CSRF Cross-Site Request Forgery, όπως και οι επιθέσεις XSS, είναι εξαιρετικά επιβλαβές, μπορείτε να το καταλάβετε ως εξής: ο εισβολέας κλέβει την ταυτότητά σας και στέλνει ένα κακόβουλο αίτημα στο όνομά σας, το οποίο είναι απολύτως νόμιμο για τον διακομιστή, αλλά ολοκληρώνει μια ενέργεια που περιμένει ο εισβολέας, όπως η αποστολή email και μηνυμάτων στο όνομά σας, η κλοπή του λογαριασμού σας, η προσθήκη διαχειριστών συστήματος ή ακόμα και η αγορά αγαθών, μεταφορές εικονικών νομισμάτων κ.λπ. Το Web A είναι ένας ιστότοπος με ευπάθεια CSRF, το Web B είναι ένας κακόβουλος ιστότοπος που δημιουργήθηκε από έναν εισβολέα και ο χρήστης C είναι νόμιμος χρήστης του Web A.
ASP.NET MVC κατά των επιθέσεων CSRF
Στη σελίδα προβολής, χρησιμοποιήστε το @Html.AntiForgeryToken() για να προσθέσετε μια ετικέτα και όταν ο χρήστης αποκτήσει πρόσβαση στη σελίδα, το backend θα δημιουργήσει αυτόματα έναν κρυφό κώδικα html με την ετικέτα, ως εξής:
<όνομα εισαγωγής="__RequestVerificationToken" type="κρυφό" value="CfDJ8FBn4LzSYglJpE6Q0fWvZ8WDMTgwK49lDU1XGuP5-5j4JlSCML_IDOO3XDL5EOyI_mS2Ux7lLSfI7ASQnIIxo2ScEJvnABf9v51TUZl_iM2S63zuiPK4lcXRPa_KUUDbK-LS4HD16pJusFRppj-dEGc" />
Το ValidateAntiForgeryToken και το AutoValidateAntiforgeryToken είναι διαφορετικά
Το AutoValidateAntiforgeryTokenAuthorizationFilter κληρονομεί το ValidateAntiforgeryTokenAuthorizationFilter, αλλά ξαναγράφει μόνο τη μέθοδο ShouldValidate σε αυτό.
AutoValidateAntiforgeryToken που προκαλεί επικύρωση διακριτικών κατά της παραχάραξης για όλες τις μη ασφαλείς μεθόδους HTTP.Οι μέθοδοι HTTP εκτός από τις GET, HEAD, OPTIONS και TRACE απαιτούν όλες ένα διακριτικό κατά της παραχάραξης。 Αυτό μπορεί να εφαρμοστεί ως καθολικό φίλτρο για να ενεργοποιήσει την επικύρωση διακριτικού κατά της παραχάραξης της εφαρμογής από προεπιλογή.
Η σύνδεση με υπερσύνδεσμο είναι ορατή.
Το AutoValidateAntiforgeryTokenAttribute επικυρώνει την κλήση στο AutoValidateAntiforgeryTokenAuthorizationFilter, το οποίο κληρονομεί από ValidateAntiforgeryTokenAuthorizationFilter,Η μέθοδος ShouldValidate έχει ξαναγραφτεί, η επιστροφή true σημαίνει ότι πρέπει να επικυρωθεί και η επιστροφή false δεν θα επικυρωθεί, όπως φαίνεται στο παρακάτω σχήμα:
Αναλύστε τον πηγαίο κώδικα:
Το AutoValidateAntiforgeryTokenAttribute επιτρέπει την καθολική εφαρμογή της επικύρωσης διακριτικών κατά της παραχάραξης σε όλες τις μη ασφαλείς μεθόδους, όπως POST, PUT, PATCH και DELETE. Επομένως, δεν χρειάζεται να προσθέσετε την ιδιότητα [ValidateAntiForgeryToken] σε κάθε ενέργεια που την απαιτεί.
Για να το χρησιμοποιήσετε, προσθέστε τον ακόλουθο κώδικα στη μέθοδο κλάσης εκκίνησης του ConfigureServices:
Αν πρέπει να αγνοήσετε τον έλεγχο ταυτότητας κατά της παραχάραξης, μπορείτε να προσθέσετε την επιλογή [Παράβλεψη AntiforgeryTokenστην ενέργεια.
Μερικές φορές μπορεί να χρειαστεί να προσθέσετε ετικέτες σε πολλά αιτήματα σε έναν ελεγκτή, ενώ χρειάζεστε ορισμένα αιτήματα που δεν χρειάζεται να πλαστογραφηθούν, όπως διάφορες λειτουργίες που βασίζονται σε GET. Υπάρχουν πολλά εργαλεία που μπορείτε να χρησιμοποιήσετε για να κάνετε τη διαδικασία πιο βολική και άνετη. Η πρώτη είναι η ιδιότητα AutoValidateAntiforgeryToken. Συμπεριφέρεται όπως η ιδιότητα ValidateAntiForgeryToken. Ωστόσο, θα αγνοήσει αυτόματα τις ενέργειες που καλούνται από μεθόδους που έχουν σχεδιαστεί για ανάκτηση δεδομένων: GET, HEAD, OPTIONS και TRACE. Αυτό σας επιτρέπει να προσθέτετε γρήγορα και εύκολα μεθόδους κατά της παραχάραξης σε όλες τις μεθόδους που μπορούν να αλλάξουν δεδομένα χωρίς να επηρεάσουν τον τρόπο ανάκτησης δεδομένων.
Ο παρακάτω κώδικας είναι ένα παράδειγμα της ιδιότητας AutoValidateAntiforgeryToken:
Σε αυτό το παράδειγμα, και οι δύο κανονικές λειτουργίες ευρετηρίου (GET) θα λειτουργούν ανεξάρτητα από την προέλευση, ενώ τόσο η λειτουργία ευρετηρίου με τη μέθοδο POST όσο και η λειτουργία RemoveUser ως μέθοδος διαγραφής θα απαιτούν από τον υπολογιστή-πελάτη να χρησιμοποιήσει ένα διακριτικό κατά της παραχάραξης.
Προσαρμόστε τις σχετικές πληροφορίες
Πολλοί άνθρωποι μπορεί να αναρωτιούνται εάν το όνομα του κρυφού τομέα που δημιουργήθηκε μπορεί να αντικατασταθεί με το δικό τους και εάν το όνομα του cookie μπορεί να αλλάξει στο δικό τους.
Η απάντηση είναι ναι, ας δείξουμε εν συντομία:
Στη μέθοδο ConfigureServices της εκκίνησης, προσθέστε τα ακόλουθα για να τροποποιήσετε ανάλογα το προεπιλεγμένο όνομα.
Σημείωση: Η μεγαλύτερη διαφορά μεταξύ asp.net πυρήνα και asp.net είναι,Το Core υποστηρίζει τη διαβίβαση παραμέτρων επικύρωσης ζητώντας μια κεφαλίδα, όχι για να σχηματίσουν φόρμες!
συμβολοσειρά private const AntiforgeryTokenFieldName = "__RequestVerificationToken";
συμβολοσειρά private const AntiforgeryTokenHeaderName = "RequestVerificationToken";
Μπορείτε να δείτε τον πηγαίο κώδικα:Η σύνδεση με υπερσύνδεσμο είναι ορατή.
Κωδικός δοκιμής:
Αποτέλεσμα: Η προσπάθεια πρόσβασης στη μέθοδο test1 επιστρέφει ένα σφάλμα 400, η πρόσβαση στη μέθοδο test2 επιστρέφει την παράμετρο str που περάσαμε και μπορείτε να δείτε ότι η δυνατότητα AutoValidateAntiforgeryToken δεν παρεμποδίζει το αίτημα GET.
(Τέλος)
|
Προηγούμενος:Ο Βιολιστής αντικαθιστά συνδέσμους, ζητά ανακατευθύνσεις προώθησηςΕπόμενος:[στροφή] Πλήθος SQL Server SQL
|
Σπιτονοικοκύρης|
Δημοσιεύτηκε στις 8/7/2023 10:07:08 μ.μ.
|
