Προγραμματισμός

Δεκατρείς κανόνες για την ανάπτυξη ασφαλών εφαρμογών Java

Η ασφάλεια είναι μια από τις πιο περίπλοκες, ευρείες και σημαντικές πτυχές της ανάπτυξης λογισμικού. Η ασφάλεια του λογισμικού παραβλέπεται επίσης συχνά, ή απλοποιείται σε μερικές μικρές προσαρμογές στο τέλος του κύκλου ανάπτυξης. Μπορούμε να δούμε τα αποτελέσματα στην ετήσια λίστα σημαντικών παραβιάσεων της ασφάλειας δεδομένων, η οποία το 2019 ανήλθε σε περισσότερα από 3 δισεκατομμύρια εκτεθειμένα αρχεία. Εάν μπορεί να συμβεί στο Capital One, μπορεί να συμβεί σε εσάς.

Τα καλά νέα είναι ότι η Java είναι μια μακροχρόνια πλατφόρμα ανάπτυξης με πολλά ενσωματωμένα χαρακτηριστικά ασφαλείας. Το πακέτο Java Security έχει υποβληθεί σε εντατικές δοκιμές μάχης και ενημερώνεται συχνά για νέες ευπάθειες ασφαλείας. Το νεότερο Java EE Security API, που κυκλοφόρησε τον Σεπτέμβριο του 2017, αντιμετωπίζει τις ευπάθειες στις αρχιτεκτονικές cloud και microservices. Το οικοσύστημα Java περιλαμβάνει επίσης ένα ευρύ φάσμα εργαλείων για τη δημιουργία προφίλ και την αναφορά ζητημάτων ασφάλειας.

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

Οι ακόλουθοι βασικοί κανόνες προσφέρουν μια καλή βάση για τη δημιουργία πιο ασφαλών εφαρμογών Java.

Κανόνας ασφαλείας Java # 1: Γράψτε καθαρό, ισχυρό κώδικα Java

Οι ευπάθειες λατρεύουν να κρύβονται στην πολυπλοκότητα, οπότε διατηρήστε τον κωδικό σας όσο το δυνατόν πιο απλός χωρίς να θυσιάσετε τη λειτουργικότητα. Η χρήση αποδεδειγμένων αρχών σχεδίασης όπως το DRY (μην επαναλαμβάνετε τον εαυτό σας) θα σας βοηθήσει να γράψετε κώδικα που είναι πιο εύκολο να ελέγξετε για προβλήματα.

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

  • Χρησιμοποιήστε τους τροποποιητές πρόσβασης Java. Η γνώση του τρόπου δήλωσης διαφορετικών επιπέδων πρόσβασης για τάξεις, μεθόδους και τα χαρακτηριστικά τους θα συμβάλει σημαντικά στην προστασία του κώδικα σας. Ό, τι μπορεί να γίνει ιδιωτικό, πρέπει να είναι ιδιωτικό.
  • Αποφύγετε τον προβληματισμό και την ενδοσκόπηση. Υπάρχουν ορισμένες περιπτώσεις όπου αξίζουν τέτοιες προηγμένες τεχνικές, αλλά ως επί το πλείστον πρέπει να τις αποφύγετε. Η χρήση του προβληματισμού εξαλείφει την ισχυρή πληκτρολόγηση, η οποία μπορεί να εισαγάγει αδύνατα σημεία και αστάθεια στον κώδικά σας. Η σύγκριση των ονομάτων τάξεων με συμβολοσειρές είναι επιρρεπής σε σφάλματα και μπορεί εύκολα να οδηγήσει σε σύγκρουση χώρου ονομάτων.
  • Να ορίζετε πάντα τις μικρότερες δυνατές επιφάνειες API και διασύνδεσης. Αποσυνδέστε τα εξαρτήματα και αφήστε τα να αλληλεπιδράσουν στη μικρότερη δυνατή περιοχή. Ακόμα κι αν μια περιοχή της εφαρμογής σας έχει μολυνθεί από παραβίαση, άλλες θα είναι ασφαλείς.

Κανόνας ασφαλείας Java # 2: Αποφύγετε τη σειριοποίηση

Αυτή είναι μια άλλη συμβουλή κωδικοποίησης, αλλά είναι αρκετά σημαντικό να είναι ο δικός του κανόνας. Η σειριοποίηση παίρνει μια απομακρυσμένη είσοδο και τη μετατρέπει σε ένα πλήρως προικισμένο αντικείμενο. Διανέμει κατασκευαστές και τροποποιητές πρόσβασης και επιτρέπει τη ροή άγνωστων δεδομένων σε κώδικα JVM. Ως αποτέλεσμα, η σειριοποίηση Java είναι βαθιά και εγγενώς ανασφαλής.

Το τέλος της σειριοποίησης Java

Εάν δεν έχετε ακούσει, η Oracle έχει μακροπρόθεσμα σχέδια για την κατάργηση της σειριοποίησης από την Java. Ο Mark Reinhold, επικεφαλής αρχιτέκτονας της ομάδας πλατφόρμας Java στην Oracle, δήλωσε ότι πιστεύει ότι το ένα τρίτο ή περισσότερο από όλα τα τρωτά σημεία της Java περιλαμβάνουν σειριοποίηση.

Όσο το δυνατόν περισσότερο, αποφύγετε τη σειριοποίηση / αποεστερίωση στον κώδικα Java. Αντ 'αυτού, σκεφτείτε να χρησιμοποιήσετε μια μορφή σειριοποίησης όπως JSON ή YAML. Ποτέ, μην εκθέτετε ποτέ ένα μη προστατευμένο τελικό σημείο δικτύου που λαμβάνει και ενεργεί σε μια ροή σειριοποίησης. Αυτό δεν είναι παρά ένα καλωσόρισμα για χάος.

Κανόνας ασφαλείας Java # 3: Μην εκθέτετε ποτέ μη κρυπτογραφημένα διαπιστευτήρια ή PII

Είναι δύσκολο να πιστέψουμε, αλλά αυτό το λάθος που μπορεί να αποφευχθεί προκαλεί πόνο κάθε χρόνο.

Όταν ένας χρήστης εισάγει έναν κωδικό πρόσβασης στο πρόγραμμα περιήγησης, αποστέλλεται ως απλό κείμενο στον διακομιστή σας. Αυτή πρέπει να είναι η τελευταία φορά που βλέπει το φως της ημέρας. Εσείς πρέπει κρυπτογραφήστε τον κωδικό πρόσβασης μέσω μονόδρομου κρυπτογράφησης πριν τον διατηρήσετε στη βάση δεδομένων και, στη συνέχεια, κάντε τον ξανά κάθε φορά που συγκρίνετε την τιμή.

Οι κανόνες για τους κωδικούς πρόσβασης ισχύουν για όλες τις προσωπικά αναγνωρίσιμες πληροφορίες (PII): πιστωτικές κάρτες, αριθμούς κοινωνικής ασφάλισης κ.λπ. Οποιαδήποτε προσωπική πληροφορία που έχει ανατεθεί στην αίτησή σας θα πρέπει να αντιμετωπίζεται με το υψηλότερο επίπεδο φροντίδας.

Μη κρυπτογραφημένα διαπιστευτήρια ή PII σε μια βάση δεδομένων είναι μια κενή τρύπα ασφαλείας, περιμένοντας να ανακαλύψει ένας εισβολέας. Ομοίως, μην γράφετε ποτέ ακατέργαστα διαπιστευτήρια σε ένα αρχείο καταγραφής ή μεταφέρετε με άλλο τρόπο σε αρχείο ή δίκτυο. Αντ 'αυτού, δημιουργήστε ένα αλατισμένο κατακερματισμό για τους κωδικούς πρόσβασης. Βεβαιωθείτε ότι έχετε κάνει την έρευνά σας και χρησιμοποιήστε έναν προτεινόμενο αλγόριθμο κατακερματισμού.

Μετάβαση στον Κανόνα # 4: χρησιμοποιείτε πάντα μια βιβλιοθήκη για κρυπτογράφηση. μην κυλήσετε το δικό σας.

Κανόνας ασφαλείας Java # 4: Χρησιμοποιήστε γνωστές και δοκιμασμένες βιβλιοθήκες

Προσπαθήστε να κοιτάξετε αυτό το ερώτημα-απάντηση σχετικά με την ανάπτυξη του δικού σας αλγορίθμου ασφαλείας. Το μάθημα tl; dr είναι: χρήση γνωστών, αξιόπιστων βιβλιοθηκών και πλαισίων όποτε είναι δυνατόν. Αυτό ισχύει σε όλο το φάσμα, από κατακερματισμό κωδικού πρόσβασης έως εξουσιοδότηση API REST.

Ευτυχώς, η Java και το οικοσύστημά της έχουν την πλάτη σας εδώ. Για την ασφάλεια εφαρμογών, το Spring Security είναι το de facto πρότυπο. Προσφέρει ένα ευρύ φάσμα επιλογών και την ευελιξία που ταιριάζει με οποιαδήποτε αρχιτεκτονική εφαρμογών και ενσωματώνει μια σειρά προσεγγίσεων ασφαλείας.

Το πρώτο σας ένστικτο στην αντιμετώπιση της ασφάλειας πρέπει να είναι να κάνετε την έρευνά σας. Ερευνήστε τις βέλτιστες πρακτικές και, στη συνέχεια, ερευνήστε ποια βιβλιοθήκη θα εφαρμόσει αυτές τις πρακτικές για εσάς. Για παράδειγμα, εάν θέλετε να χρησιμοποιήσετε τα Διακριτικά Ιστού JSON για να διαχειριστείτε τον έλεγχο ταυτότητας και την εξουσιοδότηση, ανατρέξτε στη βιβλιοθήκη Java που ενσωματώνει το JWT και, στη συνέχεια, μάθετε πώς να το ενσωματώσετε στο Spring Security.

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

Κανόνας ασφαλείας Java # 5: Να είστε παρανοϊκοί σχετικά με την εξωτερική είσοδο

Είτε προέρχεται από έναν χρήστη που πληκτρολογεί μια φόρμα, ένα κατάστημα δεδομένων ή ένα απομακρυσμένο API, ποτέ δεν εμπιστεύεστε την εξωτερική είσοδο.

Το SQL injection και το cross-site scripting (XSS) είναι μόνο οι πιο γνωστές επιθέσεις που μπορεί να προκύψουν από κακή διαχείριση εξωτερικών εισόδων. Ένα λιγότερο γνωστό παράδειγμα - ένα από τα πολλά - είναι η "δισεκατομμύρια επίθεση γέλια", σύμφωνα με την οποία η επέκταση οντοτήτων XML μπορεί να προκαλέσει επίθεση άρνησης υπηρεσίας.

Κάθε φορά που λαμβάνετε στοιχεία, θα πρέπει να ελέγχεται και να απολυμαίνεται. Αυτό ισχύει ιδιαίτερα για οτιδήποτε μπορεί να παρουσιαστεί σε άλλο εργαλείο ή σύστημα για επεξεργασία. Για παράδειγμα, αν κάτι θα μπορούσε να καταλήξει ως επιχείρημα για μια γραμμή εντολών OS: προσέξτε!

Μια ειδική και γνωστή παρουσία είναι η ένεση SQL, η οποία καλύπτεται στον επόμενο κανόνα.

Κανόνας ασφαλείας Java # 6: Χρησιμοποιείτε πάντα προετοιμασμένες δηλώσεις για τον χειρισμό παραμέτρων SQL

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

Γνωρίζοντας αυτό, είναι μια καλή πρακτική πάντα χρησιμοποιήστε την κλάση java.sql.PreparedStatement για να δημιουργήσετε SQL. Παρόμοιες εγκαταστάσεις υπάρχουν για καταστήματα NoSQL όπως το MongoDB. Εάν χρησιμοποιείτε ένα επίπεδο ORM, η εφαρμογή θα χρησιμοποιηθεί Προετοιμασμένη δήλωσηγια εσάς κάτω από την κουκούλα.

Κανόνας ασφαλείας Java # 7: Μην αποκαλύπτετε την εφαρμογή μέσω μηνυμάτων σφάλματος

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

Οι ειδοποιήσεις αποτυχίας σύνδεσης εμπίπτουν επίσης σε αυτήν την κατηγορία. Είναι γενικά αποδεκτό ότι ένα μήνυμα σφάλματος πρέπει να δοθεί ως "Η σύνδεση απέτυχε" έναντι "Δεν βρήκε αυτόν τον χρήστη" ή "Λανθασμένος κωδικός πρόσβασης." Προσφέρετε όσο το δυνατόν λιγότερη βοήθεια σε δυνητικά άθλους χρήστες.

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

Κανόνας ασφαλείας Java # 8: Διατηρήστε ενημερωμένες τις κυκλοφορίες ασφαλείας

Από το 2019, η Oracle έχει εφαρμόσει ένα νέο πρόγραμμα αδειοδότησης και πρόγραμμα κυκλοφορίας για την Java. Δυστυχώς για προγραμματιστές, ο νέος ρυθμός κυκλοφορίας δεν διευκολύνει τα πράγματα. Ωστόσο, είστε υπεύθυνοι για τον συχνά έλεγχο για ενημερώσεις ασφαλείας και για την εφαρμογή τους στο JRE και στο JDK.

Βεβαιωθείτε ότι γνωρίζετε ποια κρίσιμα μπαλώματα είναι διαθέσιμα ελέγχοντας τακτικά την αρχική σελίδα του Oracle για ειδοποιήσεις ασφαλείας. Κάθε τρίμηνο, η Oracle παρέχει μια αυτόματη ενημέρωση κώδικα για την τρέχουσα έκδοση LTS (μακροπρόθεσμη υποστήριξη) της Java. Το πρόβλημα είναι ότι αυτή η ενημέρωση κώδικα είναι διαθέσιμη μόνο εάν πληρώνετε για άδεια υποστήριξης Java.

Εάν ο οργανισμός σας πληρώνει για μια τέτοια άδεια, ακολουθήστε τη διαδρομή αυτόματης ενημέρωσης. Εάν όχι, πιθανότατα χρησιμοποιείτε το OpenJDK και θα πρέπει να κάνετε μόνοι σας την ενημέρωση κώδικα. Σε αυτήν την περίπτωση, θα μπορούσατε να εφαρμόσετε το δυαδικό έμπλαστρο ή απλώς να αντικαταστήσετε την υπάρχουσα εγκατάσταση του OpenJDK με την πιο πρόσφατη έκδοση. Εναλλακτικά, θα μπορούσατε να χρησιμοποιήσετε ένα OpenJDK που υποστηρίζεται από το εμπόριο, όπως το Azul's Zulu Enterprise.

Χρειάζεστε κάθε ενημερωμένη έκδοση κώδικα ασφαλείας;

Εάν παρακολουθείτε προσεκτικά τις ειδοποιήσεις ασφαλείας, ενδέχεται να διαπιστώσετε ότι δεν χρειάζεστε ένα συγκεκριμένο σύνολο ενημερώσεων. Για παράδειγμα, η κυκλοφορία του Ιανουαρίου 2020 εμφανίζεται να είναι μια κρίσιμη ενημέρωση Java. Ωστόσο, μια προσεκτική ανάγνωση δείχνει ότι η ενημέρωση επιδιορθώνει μόνο τρύπες στην ασφάλεια applet Java και δεν επηρεάζει τους διακομιστές Java.

Κανόνας ασφαλείας Java # 9: Αναζητήστε ευπάθειες εξάρτησης

Υπάρχουν πολλά διαθέσιμα εργαλεία για αυτόματη σάρωση της βάσης κώδικα και των εξαρτήσεων σας για ευπάθειες. Το μόνο που έχετε να κάνετε είναι να τα χρησιμοποιήσετε.

Το OWASP, το Open Web Application Security Project, είναι ένας οργανισμός αφιερωμένος στη βελτίωση της ασφάλειας κώδικα. Η λίστα αξιόπιστων, υψηλής ποιότητας αυτοματοποιημένων εργαλείων σάρωσης κώδικα της OWASP περιλαμβάνει πολλά εργαλεία προσανατολισμένα σε Java.

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

Κανόνας ασφαλείας Java # 10: Παρακολούθηση και καταγραφή δραστηριότητας χρήστη

Ακόμη και μια απλή επίθεση brute-force μπορεί να είναι επιτυχής εάν δεν παρακολουθείτε ενεργά την αίτησή σας. Χρησιμοποιήστε εργαλεία παρακολούθησης και καταγραφής για να παρακολουθείτε την υγεία των εφαρμογών.

Εάν θέλετε να είστε πεπεισμένοι γιατί η παρακολούθηση είναι σημαντική, απλώς καθίστε και παρακολουθήστε πακέτα TCP στη θύρα ακρόασης των εφαρμογών σας. Θα δείτε όλα τα είδη δραστηριότητας, πέρα ​​από τις απλές αλληλεπιδράσεις των χρηστών. Μερικές από αυτές τις δραστηριότητες θα είναι bots και κακοποιοί που αναζητούν ευπάθειες.

Θα πρέπει να καταγράφετε και να παρακολουθείτε αποτυχημένες προσπάθειες σύνδεσης και να αναπτύξετε αντίμετρα για να αποτρέψετε τους απομακρυσμένους πελάτες να επιτεθούν με ατιμωρησία.

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

Κανόνας ασφαλείας Java # 11: Προσέξτε για επιθέσεις άρνησης υπηρεσίας (DoS)

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

Η Oracle διατηρεί μια λίστα πιθανών διανυσμάτων για αυτόν τον τύπο προβλήματος στις Οδηγίες ασφαλούς κωδικοποίησης για το έγγραφο Java SE, στην επικεφαλίδα "Άρνηση υπηρεσίας".

Βασικά, οποτεδήποτε πηγαίνετε για να εκτελέσετε μια ακριβή λειτουργία, όπως η αποσυμπίεση ενός συμπιεσμένου αρχείου, θα πρέπει να παρακολουθείτε την έκρηξη της χρήσης πόρων. Μην εμπιστεύεστε τις δηλώσεις αρχείων. Εμπιστευτείτε μόνο την πραγματική κατανάλωση στο δίσκο ή στη μνήμη, παρακολουθήστε το και προφυλάξτε από τις υπερβολές του διακομιστή-προς-στα-γόνατά σας.

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

Κανόνας ασφαλείας Java # 12: Εξετάστε το ενδεχόμενο χρήσης του διαχειριστή ασφαλείας Java

Η Java διαθέτει έναν διαχειριστή ασφαλείας που μπορεί να χρησιμοποιηθεί για να περιορίσει τους πόρους στους οποίους έχει πρόσβαση μια διαδικασία που εκτελείται. Μπορεί να απομονώσει το πρόγραμμα σε σχέση με το δίσκο, τη μνήμη, το δίκτυο και την πρόσβαση JVM. Ο περιορισμός αυτών των απαιτήσεων για την εφαρμογή σας μειώνει το αποτύπωμα πιθανής βλάβης από μια επίθεση. Μια τέτοια απομόνωση μπορεί επίσης να είναι άβολη, και για αυτό το λόγο ΥΠΕΥΘΥΝΟΣ ΑΣΦΑΛΕΙΑΣ δεν είναι ενεργοποιημένο από προεπιλογή.

Θα πρέπει να αποφασίσετε μόνοι σας αν εργάζεστε ΥΠΕΥΘΥΝΟΣ ΑΣΦΑΛΕΙΑΣΟι ισχυρές απόψεις αξίζουν το επιπλέον επίπεδο προστασίας για τις εφαρμογές σας. Ανατρέξτε στα έγγραφα της Oracle για να μάθετε περισσότερα σχετικά με τη σύνταξη και τις δυνατότητες του διαχειριστή ασφαλείας Java.

Κανόνας ασφαλείας Java # 13: Εξετάστε το ενδεχόμενο να χρησιμοποιήσετε μια εξωτερική υπηρεσία ελέγχου ταυτότητας cloud

Ορισμένες εφαρμογές πρέπει απλά να κατέχουν τα δεδομένα χρήστη τους. για τα υπόλοιπα, ένας πάροχος υπηρεσιών cloud θα μπορούσε να έχει νόημα.

Κάντε αναζήτηση γύρω και θα βρείτε μια σειρά παρόχων ελέγχου ταυτότητας cloud. Το πλεονέκτημα μιας τέτοιας υπηρεσίας είναι ότι ο πάροχος είναι υπεύθυνος για την ασφάλεια ευαίσθητων δεδομένων χρήστη, όχι εσείς. Από την άλλη πλευρά, η προσθήκη μιας υπηρεσίας ελέγχου ταυτότητας αυξάνει την πολυπλοκότητα της αρχιτεκτονικής της επιχείρησής σας. Ορισμένες λύσεις, όπως το FireBase Authentication, περιλαμβάνουν SDK για ενοποίηση σε ολόκληρη τη στοίβα.

συμπέρασμα

Έχω παρουσιάσει 13 κανόνες για την ανάπτυξη πιο ασφαλών εφαρμογών Java. Αυτοί οι κανόνες είναι δοκιμασμένοι και αληθινοί, αλλά ο μεγαλύτερος κανόνας είναι: να είστε ύποπτοι. Να προσεγγίζετε πάντα την ανάπτυξη λογισμικού με επιφυλακτικότητα και με προοπτική με γνώμονα την ασφάλεια. Αναζητήστε ευπάθειες στον κώδικά σας, εκμεταλλευτείτε τα API ασφαλείας και τα πακέτα Java και χρησιμοποιήστε εργαλεία τρίτων για παρακολούθηση και καταγραφή του κωδικού σας για ζητήματα ασφαλείας.

Ακολουθούν τρεις καλοί πόροι υψηλού επιπέδου για να παρακολουθείτε το συνεχώς μεταβαλλόμενο τοπίο ασφαλείας Java:

  • Κορυφαία 10 OWASP
  • Κορυφαία 25 CWE
  • Οδηγίες ασφαλούς κώδικα της Oracle

Αυτή η ιστορία, "Δεκατρείς κανόνες για την ανάπτυξη ασφαλών εφαρμογών Java" δημοσιεύθηκε αρχικά από την JavaWorld.

$config[zx-auto] not found$config[zx-overlay] not found