Μια γρήγορη εισαγωγή στην ασφάλεια Ιστού

Ένα βασικό πρόγραμμα ανάπτυξης ιστοσελίδων σε CORS, CSP, HSTS και όλα τα ακρωνύμια ασφάλειας ιστού!

Υπάρχουν πολλοί λόγοι για να μάθετε για την ασφάλεια στον ιστό, όπως:

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

και ούτω καθεξής.

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

Πριν το κάνουμε αυτό, ας βεβαιωθούμε ότι κατανοούμε μερικές από τις βασικές έννοιες της ασφάλειας.

Δύο βασικές έννοιες της ασφάλειας

Κανείς δεν είναι ποτέ 100% ασφαλής.

Δεν υπάρχει καμία έννοια ότι προστατεύεται 100% από την παραβίαση. Αν κάποιος σας το πει ποτέ, είναι λάθος.

Ένα στρώμα προστασίας δεν είναι αρκετό.

Δεν μπορείτε απλά να πείτε…

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

Ίσως αυτό δίνεται σε μερικούς, αλλά είναι εύκολο να βρεθείτε να σκέφτεστε με αυτόν τον τρόπο. Νομίζω ότι ένας λόγος που οι προγραμματιστές μπορούν εύκολα να σκεφτούν έτσι είναι επειδή τόσο μεγάλο μέρος της κωδικοποίησης είναι ασπρόμαυρο, 0 ή 1, αληθινό ή λάθος. Η ασφάλεια δεν είναι τόσο απλή.

Θα ξεκινήσουμε με αυτό που όλοι συναντούν αρκετά νωρίς στο ταξίδι ανάπτυξης ιστού τους. Και μετά κοιτάζετε στο StackOverflow και βρείτε πολλές απαντήσεις που σας λένε πώς να το παρακάμψετε.

Διαμοιρασμός πόρων μεταξύ προέλευσης (CORS)

Έχετε ποτέ λάθος που μοιάζει με αυτό;

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

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

Τέλεια, σωστά;

Το CORS είναι εκεί για να σας προστατεύσει, όχι να σας βλάψει!

Για να εξηγήσουμε πώς σας βοηθά το CORS, ας μιλήσουμε πρώτα για τα cookies, ειδικά για τα cookie ελέγχου ταυτότητας . Τα cookie ελέγχου ταυτότητας χρησιμοποιούνται για να ενημερώσουν έναν διακομιστή ότι είστε συνδεδεμένοι και αποστέλλονται αυτόματα με οποιοδήποτε αίτημα υποβάλλετε σε αυτόν τον διακομιστή.

Ας υποθέσουμε ότι είστε συνδεδεμένοι στο Facebook και χρησιμοποιούν cookie ελέγχου ταυτότητας. Κάνετε κλικ στο bit.ly/r43nugiοποίο σας ανακατευθύνει superevilwebsite.rocks. Ένα σενάριο εντός superevilwebsite.rocksκάνει ένα αίτημα από την πλευρά του πελάτη στο facebook.comοποίο στέλνει το cookie ελέγχου ταυτότητας!

Σε έναν κόσμο χωρίς CORS, θα μπορούσαν να κάνουν αλλαγές στον λογαριασμό σας χωρίς καν να το γνωρίζετε. Μέχρι, φυσικά, δημοσιεύουν bit.ly/r43nugiστο χρονολόγιό σας και όλοι οι φίλοι σας κάνουν κλικ σε αυτό, και στη συνέχεια δημοσιεύουν bit.ly/r43nugiσε όλα τα χρονοδιαγράμματα των φίλων σας και στη συνέχεια ο κύκλος συνεχίζεται σε ένα κακό σχέδιο πρώτου εύρους που κατακτά όλους τους χρήστες του Facebook, και ο κόσμος καταναλώνεται από superevilwebsite.rocks. ;

Σε έναν κόσμο CORS, ωστόσο, το Facebook επιτρέπει μόνο αιτήματα με προέλευση facebook.comτην επεξεργασία δεδομένων στον διακομιστή τους. Με άλλα λόγια, θα περιόριζαν την κοινή χρήση πόρων μεταξύ προέλευσης. Μπορείτε τότε να ρωτήσετε ...

Λοιπόν μπορεί το superevilwebsite.rocks να αλλάξει την κεφαλίδα προέλευσης κατόπιν αιτήματός τους, έτσι ώστε να φαίνεται ότι προέρχεται από το facebook.com;

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

Εντάξει, αλλά τι γίνεται αν το superevilwebsite.rocks έκανε το αίτημα από την πλευρά του διακομιστή;

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

Πολιτική ασφάλειας περιεχομένου (CSP)

Για να κατανοήσουμε το CSP, πρέπει πρώτα να μιλήσουμε για μια από τις πιο κοινές ευπάθειες στον Ιστό: το XSS, το οποίο σημαίνει scripting μεταξύ ιστότοπων (yay - άλλο ακρωνύμιο).

Το XSS είναι όταν κάποιο κακό άτομο εισάγει JavaScript στον κωδικό του πελάτη σας. Μπορεί να σκεφτείτε…

Τι πρόκειται να κάνουν? Αλλαγή χρώματος από κόκκινο σε μπλε;

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

Τι θα μπορούσαν να κάνουν που θα ήταν κακόβουλο;

  • Θα μπορούσαν να κάνουν αιτήματα HTTP σε έναν άλλο ιστότοπο που προσποιούνται ότι είστε εσείς.
  • Θα μπορούσαν να προσθέσουν μια ετικέτα αγκύρωσης που σας στέλνει σε έναν ιστότοπο που μοιάζει πανομοιότυπος με αυτόν στον οποίο βρίσκεστε με κάποια ελαφρώς διαφορετικά, κακόβουλα χαρακτηριστικά.
  • Θα μπορούσαν να προσθέσουν μια ετικέτα σεναρίου με ενσωματωμένο JavaScript.
  • Θα μπορούσαν να προσθέσουν μια ετικέτα σεναρίου που παίρνει ένα απομακρυσμένο αρχείο JavaScript κάπου.
  • Θα μπορούσαν να προσθέσουν ένα iframe που καλύπτει τη σελίδα και μοιάζει με μέρος του ιστότοπου που σας ζητά να εισαγάγετε τον κωδικό πρόσβασής σας.

Οι πιθανότητες είναι ατελείωτες.

Το CSP προσπαθεί να αποτρέψει αυτό να συμβεί περιορίζοντας:

  • τι μπορεί να ανοίξει σε ένα iframe
  • ποια φύλλα στυλ μπορούν να φορτωθούν
  • όπου μπορούν να γίνουν αιτήσεις κ.λπ.

Πως λειτουργεί, λοιπόν?

When you click on a link or type a website URL in the address bar of your browser, your browser makes a GET request. It eventually makes its way to a server which serves up HTML along with some HTTP headers. If you’re curious about what headers you receive, open up the Network tab in your console, and visit some websites.

You might see a response header that looks like this:

content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

That is the content security policy of facebook.com. Let’s reformat it to make it easier to read:

content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

Now, let’s break down the directives.

  • default-src restricts all other CSP directives that are not explicitly listed.
  • script-srcrestricts the scripts that can be loaded.
  • style-src restricts the stylesheets that can be loaded.
  • connect-src restricts the URLs which can be loaded using script interfaces, so fetch, XHR, ajax, etc.

Σημειώστε ότι υπάρχουν πολλές περισσότερες οδηγίες CSP από αυτές που αναφέρονται παραπάνω. Το πρόγραμμα περιήγησης θα διαβάσει την κεφαλίδα CSP και θα εφαρμόσει αυτές τις οδηγίες σε όλα τα αρχεία HTML που προβλήθηκαν. Εάν οι οδηγίες έχουν οριστεί κατάλληλα, επιτρέπουν μόνο ό, τι είναι απαραίτητο.

Εάν δεν υπάρχει κεφαλίδα CSP, τότε όλα πηγαίνουν και τίποτα δεν περιορίζεται. Όπου βλέπετε *, αυτό είναι ένα μπαλαντέρ. Μπορείτε να φανταστείτε την αντικατάσταση *με οτιδήποτε και αυτό θα επιτρέπεται.

HTTPS ή HTTP Secure

Σίγουρα έχετε ακούσει για το HTTPS. Ίσως έχετε ακούσει μερικούς ανθρώπους να λένε…

Γιατί νοιάζομαι για τη χρήση HTTPS εάν βρίσκομαι μόνο σε ιστότοπο που παίζει ένα παιχνίδι.

Ή ίσως έχετε ακούσει την άλλη πλευρά…

Είστε τρελοί εάν ο ιστότοπός σας δεν διαθέτει HTTPS. Είναι 2018! Μην εμπιστεύεστε κανέναν που λέει διαφορετικά.

Ίσως ακούσατε ότι το Chrome θα επισημάνει τώρα τον ιστότοπό σας ως μη ασφαλές εάν δεν είναι HTTPS.

Στον πυρήνα του, το HTTPS είναι αρκετά απλό. Το HTTPS είναι κρυπτογραφημένο και το HTTP δεν είναι.

Γιατί λοιπόν αυτό έχει σημασία εάν δεν στέλνετε ευαίσθητα δεδομένα;

Ετοιμαστείτε για ένα άλλο ακρωνύμιο… MITM, που σημαίνει Man in the Middle.

Εάν χρησιμοποιείτε δημόσιο Wi-Fi χωρίς κωδικό πρόσβασης σε μια καφετέρια, είναι πολύ εύκολο για κάποιον να ενεργήσει όπως ο δρομολογητής σας, έτσι ώστε όλα τα αιτήματα και οι απαντήσεις να περάσουν από αυτά. Εάν τα δεδομένα σας δεν είναι κρυπτογραφημένα, τότε μπορούν να κάνουν ό, τι θέλουν μαζί τους. Μπορούν να επεξεργαστούν το HTML, το CSS ή το JavaScript πριν φτάσουν στο πρόγραμμα περιήγησής σας. Δεδομένων όσων γνωρίζουμε για το XSS, μπορείτε να φανταστείτε πόσο κακό θα μπορούσε να είναι αυτό.

Εντάξει, αλλά πώς μπορεί ο υπολογιστής μου και ο διακομιστής να γνωρίζουν πώς να κρυπτογραφούν / αποκρυπτογραφούν αλλά αυτό το MITM δεν το κάνει;

That’s where SSL (Secure Sockets Layer) and more recently, TLS (Transport Layer Security) come in. TLS took over for SSL in 1999 as the encryption technology used within HTTPS. Exactly how TLS works is outside of the scope of this post.

HTTP Strict-Transport-Security (HSTS)

This one is pretty straightforward. Let’s use Facebook’s header as an example again:

strict-transport-security: max-age=15552000; preload
  • max-age specifies how long a browser should remember to force the user to access a website using HTTPS.
  • preload is not important for our purposes. It is a service hosted by Google and not part of the HSTS specification.

This header only applies if you accessed the site using HTTPS. If you accessed the site via HTTP, the header is ignored. The reason is that, quite simply, HTTP is so insecure that it can’t be trusted.

Let’s use the Facebook example to further illustrate how this is helpful in practice. You are accessing facebook.com for the first time, and you know HTTPS is safer than HTTP, so you access it over HTTPS, //facebook.com. When your browser receives the HTML, it receives the header above which tells your browser to force-redirect you to HTTPS for future requests. One month later, someone sends you a link to Facebook using HTTP, //facebook.com, and you click on it. Since one month is less than the 15552000 seconds specified by the max-age directive, your browser will send the request as HTTPS, preventing a potential MITM attack.

Closing Thoughts

Η ασφάλεια του Ιστού είναι σημαντική ανεξάρτητα από το πού βρίσκεστε στο ταξίδι ανάπτυξης ιστού. Όσο περισσότερο εκτίθενται στον εαυτό σας, τόσο καλύτερα θα είστε. Η ασφάλεια είναι κάτι που πρέπει να είναι σημαντικό για όλους, όχι μόνο τα άτομα που το έχουν ρητά κατονομαστεί στον τίτλο εργασίας τους! ;