Τι είναι τελικά το Hypertext Transfer Protocol (HTTP);

Η δημιουργία του World Wide Web τελειοποιήθηκε στα χρόνια περίπου από το 1988 έως το 1991.

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

• Σελίδα του Tim Berners-Lee στη Wikipedia

(hr)

Τα αρχικά συστατικά πίσω από την εφεύρεση του Tim Berners-Lee χρησιμοποιούνται ακόμη σήμερα. Μάλιστα, κάποιοι σύγχρονοι web servers καταλαβαίνουν ακόμη την αρχική προδιαγραφή HTTP (αν και θεωρείται ξεπερασμένη σήμερα):

Βασικά συστατικά του World Wide Web:

• ένας web server
• ένας user agent
• κειμενική απεικόνιση
• τύποι μέσων (Media Types)
• ένα πρωτόκολλο που επιτρέπει τη μεταφορά εγγράφων, το HTTP

Το σύγχρονο W.W.W.
web server	IIS, Apache, NGiNX
user agent	CuRL, Chrome, Firefox, RSS Readers
κειμενικά δεδομένα	UTF-8, ASCII, JSON, HTML, XML, CSS
τύποι μέσων	κειμενικά δεδομένα, εικόνες, βίντεο, animations
προδιαγραφές HTTP	HTTP/1.1 (RFC 9112), HTTP/2 (RFC 9113) και HTTP/3 (RFC 9114), με κοινή σημασιολογία στο RFC 9110

Δύο κύριοι φορείς είναι επιφορτισμένοι με τον ορισμό της εξέλιξης του σύγχρονου HTTP:

• W3C World Wide Web Consortium Το W3C ασχολείται με τη λειτουργικότητα των web servers, τις μελλοντικές ανάγκες προδιαγραφών, τους user agents (ή web browsers), την HTML, την XML, το βίντεο, τις εικόνες και τις τεχνολογίες διανομής περιεχομένου. Λίγο πολύ, το W3C ασχολείται με τις επιπτώσεις του HTTP στο επίπεδο εφαρμογής.
• IETF Internet Engineering Task Force Η IETF ασχολείται με το πώς θα δουλεύει και θα λειτουργεί το HTTP σε χαμηλότερο τεχνικό επίπεδο. Το HTTP δουλεύει πάνω σε υποκείμενες τεχνολογίες όπως IPv4, TCP, UDP, Ethernet και πολλά ακόμη πρωτόκολλα χαμηλότερων επιπέδων. Όλα τα χαμηλότερα πρωτόκολλα συνεργάζονται για να φτάσουν τα δεδομένα από τον user agent στον web server, και πίσω στον user agent.

Από τον ιστότοπο του καθενός, το W3C και η IETF αυτοπεριγράφονται με τα δικά τους λόγια:

• Το World Wide Web Consortium (W3C) είναι μια διεθνής κοινότητα όπου οργανισμοί-μέλη, προσωπικό πλήρους απασχόλησης και το κοινό συνεργάζονται για την ανάπτυξη προτύπων του Web. (https://www.w3.org/Consortium/)
• Ο στόχος της IETF είναι να κάνει το Internet να δουλεύει καλύτερα. Η αποστολή της IETF είναι να κάνει το Internet να δουλεύει καλύτερα παράγοντας υψηλής ποιότητας, σχετικά τεχνικά έγγραφα που επηρεάζουν τον τρόπο με τον οποίο οι άνθρωποι σχεδιάζουν, χρησιμοποιούν και διαχειρίζονται το Internet. (https://www.ietf.org)

Πώς ορίζονται πρότυπα όπως το HTTP; (h2, anchor section01)

Όταν ένα πρωτόκολλο του Internet όπως το HTTP υιοθετείται ή αναθεωρείται, τα πρότυπα ορίζονται σε έγγραφα που λέγονται RFC.

RFC σημαίνει Request For Comments.

Κάθε αναγνωρισμένο πρωτόκολλο επικοινωνίας δεδομένων που γίνεται αποδεκτό για γενική χρήση στο Internet ορίζεται σε μια σειρά εγγράφων RFC. Τεχνολογίες όπως HTTP, IPv4, TLS, PKI, SNMP, POP3 και ακόμη και το Ethernet δεν είναι τεχνολογίες που ανήκουν στη Microsoft, στην Apple ή στην Google.

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

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

• Οι τρέχουσες προδιαγραφές HTTP: RFC 9110 HTTP Semantics, RFC 9112 HTTP/1.1, RFC 9113 HTTP/2 και RFC 9114 HTTP/3

(hr)

HTTP είναι το ακρωνύμιο του Hyper Text Transfer Protocol. Το HTTP είναι ένα stateless πρωτόκολλο επιπέδου εφαρμογής σχεδιασμένο για την επικοινωνία ανταλλαγών πληροφορίας μεταξύ συστημάτων μέσω του Internet. Ως τέτοιο, το HTTP ορίζει ένα σύνολο κανόνων που επιτρέπουν τόσο τη μεταφορά όσο και την πρόσβαση σε απομακρυσμένα έγγραφα. Το HTTP έχει επίσης χρησιμοποιηθεί για μεταφορά πληροφορίας με άλλους τρόπους, όπως το SSDP που χρησιμοποιεί UDP και multicast διευθύνσεις (υιοθετημένο ως HTTPU) για μεταφορές πληροφορίας.

Τι ΔΕΝ είναι το HTTP;

Το HTTP και ο παγκόσμιος ιστός δεν είναι το Internet. Το HTTP είναι ένα πρωτόκολλο που κινεί ένα εξαιρετικά δημοφιλές τμήμα του Internet, γνωστό ως ο παγκόσμιος ιστός.

Το HTTP λειτουργεί πάνω από τα υποκείμενα πρωτόκολλα επικοινωνίας δικτύου στο μοντέλο TCP/IP. Το TCP/IP είναι ένας μηχανισμός για μεταφορά δεδομένων, πλαισίωση πληροφορίας και δεδομένα επιπέδου εφαρμογής μέσω του Internet. Το HTTP είναι ένα πρότυπο επιπέδου εφαρμογής που εξειδικεύεται στη μεταφορά ενός συγκεκριμένου τύπου δεδομένων. Τα HTTP/1.1 και HTTP/2 τρέχουν πάνω από TCP, ενώ το HTTP/3 τρέχει πάνω από QUIC, που είναι χτισμένο πάνω στο UDP.

Το TCP/IP είναι μια σουίτα πρωτοκόλλων επικοινωνίας δεδομένων που αναπτύχθηκε από το Υπουργείο Άμυνας των ΗΠΑ. Το TCP/IP αναφέρεται μερικές φορές ως «το δικτυακό μοντέλο του DoD».

Στα πρώτα του χρόνια το Internet και το TCP/IP δωρίστηκαν από τα εργαστήρια της DARPA στην ακαδημαϊκή κοινότητα. Αφού τελειοποιήθηκε για ακαδημαϊκή χρήση, το Internet υιοθετήθηκε από καταναλωτές και εταιρείες για να γίνει αυτό που ξέρουμε σήμερα ως Internet. Στην περίοδο μετάβασης από την ακαδημαϊκή στην πρώιμη δημόσια χρήση εισήχθησαν το HTTP και ο παγκόσμιος ιστός.

TCP/IP	Πρωτόκολλα επιπέδου
Επίπεδο εφαρμογής	HTTP: παγκόσμιος ιστός · FTP: πρωτόκολλο μεταφοράς αρχείων · POP3 και IMAP: εισερχόμενο email · SMTP: εξερχόμενο email · HTML: σήμανση για την απεικόνιση ιστοσελίδων · JPEG: μορφή γραφικών για την απεικόνιση εικόνων
Επίπεδο μεταφοράς	TCP: επικοινωνία με σύνδεση μεταξύ hosts · UDP: επικοινωνία χωρίς σύνδεση μεταξύ hosts (το QUIC, που χρησιμοποιεί το HTTP/3, τρέχει πάνω του)
Επίπεδο Internet	IPv4: διευθυνσιοδότηση για απομακρυσμένα δίκτυα · IPv6: διευθυνσιοδότηση για απομακρυσμένα δίκτυα · BGP: δρομολόγηση κίνησης μεταξύ παρόχων Internet · OSPF: δρομολόγηση κίνησης σε εσωτερικά δίκτυα · ICMP: δομή για τη μετάδοση διαγνωστικών
Επίπεδο ζεύξης	Ethernet φυσικό μέσο και σηματοδοσία για μεταφορά δεδομένων χαμηλού επιπέδου · Token Ring ανταγωνιστής του Ethernet που σπάνια συναντάται πλέον · 802.11 προδιαγραφές για ασύρματες επικοινωνίες · Bluetooth προδιαγραφή για ασύρματη σύνδεση συσκευών · Frame Relay φυσικές προδιαγραφές και προδιαγραφές δεδομένων για δίκτυα ευρείας περιοχής

Ο παραπάνω πίνακας είναι μια αναπαράσταση του πώς το HTTP εντάσσεται στο Internet και στο TCP/IP.

(hr)

Προδιαγραφές για το HTTP (h2, anchor section02)

Πρωτίστως, το HTTP είναι για την επικοινωνία μεταφορών εγγράφων μεταξύ ενός user agent και ενός web server.

Οι ανταλλαγές HTTP συνήθως αποτελούνται από τον user agent που ζητά μια σειρά εγγράφων από έναν web server. Όταν ένα αίτημα HTTP ληφθεί από τον web server, αυτός θα το αναλύσει. Τέλος, ο web server είτε επιστρέφει ένα έγγραφο και έναν κωδικό κατάστασης, είτε μπορεί να αρνηθεί ένα αίτημα επιστρέφοντας έναν κωδικό κατάστασης για το γιατί απορρίφθηκε.

• Για λεπτομέρειες σχετικά με το γιατί ένας web server μπορεί να αρνηθεί ένα αίτημα client, ανατρέξτε στην ενότητα των κωδικών κατάστασης HTTP 400

User-Agent είναι ένας φανταχτερός όρος για μια εφαρμογή που ζητά πόρους HTTP από έναν web server. Πιο συχνά οι user agents είναι γνωστοί ως web browsers. Ωστόσο, RSS Readers, bots web scraping, web spiders και βιβλιοθήκες HTTP όπως το CURL είναι επίσης user agents.

Web Server είναι ένας daemon που συνήθως τρέχει στη θύρα 80 (HTTP) και στη θύρα 443 (HTTPS), με συγκεκριμένο σκοπό την ανάκτηση εγγράφων από ένα καθορισμένο τμήμα του συστήματος αρχείων του server για παράδοση σε έναν user agent.

Οι τρεις πιο συνηθισμένοι web servers υψηλού φορτίου στο Internet σήμερα είναι οι Apache, Nginx (προφέρεται Engine-X) και IIS (από τη Microsoft).

Ας δούμε ένα απλό αίτημα HTTP με μια εφαρμογή user agent που λέγεται Fiddler.

Το Fiddler είναι ένας proxy debugging HTTP για APIs και web εφαρμογές. Τα εργαλεία προγραμματιστή που έχει κάθε σύγχρονος browser δείχνουν μεγάλο μέρος της ίδιας πληροφορίας.

• Σύνδεσμος για το Fiddler της Telerik

(hr)

Μέθοδοι αιτήματος HTTP (h2, anchor section03)

Όπως ακριβώς φαίνεται στο πρώτο διάγραμμα μιας ανταλλαγής αιτήματος/απόκρισης HTTP, ο user agent ζητά ένα έγγραφο και μετά ένας web server ικανοποιεί ένα έγκυρο αίτημα HTTP.

Όπως φαίνεται στο πάνω τμήμα του παραθύρου του Fiddler, το Fiddler, ο user agent, έστειλε τρεις γραμμές δεδομένων:

1. Το GET προσδιορίζει αρχείο και μονοπάτι
2. Το User-Agent αναγνωρίζει το λογισμικό του client
3. Το HOST προσδιορίζει τον host όπου βρίσκεται το περιεχόμενο

Η μέθοδος αιτήματος είναι GET σε αυτό το αίτημα. Θα μάθουμε για άλλες μεθόδους αιτήματος HTTP σε αυτόν τον οδηγό.

Η συμβολοσειρά User-Agent: Μια συμβολοσειρά User-Agent είναι ο τρόπος με τον οποίο το λογισμικό του web client αυτοπροσδιορίζεται στον web server. APIs και websites συχνά παραχωρούν ή αρνούνται δικαιώματα πρόσβασης και ρυθμίσεις απεικόνισης με βάση τη συμβολοσειρά User-Agent του client.

Οι σωστοί crawlers αυτοπροσδιορίζονται ειλικρινά στη συμβολοσειρά User-Agent τους και ακολουθούν τους κανόνες που δημοσιεύει ένα site στο αρχείο robots.txt.

Μερικά παραδείγματα συμβολοσειρών User-Agent (οι αριθμοί έκδοσης αλλάζουν σε κάθε κυκλοφορία):
Chrome σε Windows 7	Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Internet Explorer 11	Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Googlebot	Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Play Station 4	Mozilla/5.0 (PlayStation 4 4.71) AppleWebKit/601.2 (KHTML, like Gecko)

Host

Η κεφαλίδα Host προσδιορίζει τον server (και το domain) που κατέχει το ζητούμενο έγγραφο. Από το HTTP/1.1 και μετά η κεφαλίδα Host είναι υποχρεωτική (τα HTTP/2 και HTTP/3 μεταφέρουν την ίδια πληροφορία στο πεδίο :authority). Είναι υποχρεωτική επειδή πολλά websites μοιράζονται έναν server και μία διεύθυνση IP, μια διάταξη που λέγεται name-based virtual hosting, και ο server χρειάζεται την κεφαλίδα Host για να ξέρει για ποιο site προορίζεται ένα αίτημα.

Μια διεύθυνση IP host 192.168.1.98 μπορεί να έχει εξωτερικό όνομα DNS web3.biga-hosting.com. Αυτός ο server με όνομα web3.biga-hosting.com μπορεί να φιλοξενεί εκατοντάδες domains. Με τη σειρά της, η κεφαλίδα Host του HTTP θα ενημερώσει τον server σε ποιο φιλοξενούμενο domain προορίζεται ένα αίτημα. Πολλαπλά εικονικά domains μπορούν να έχουν την ίδια διεύθυνση IPv4 192.168.1.98 (το reverse DNS συνήθως θα δείχνει στο web3.biga-hosting.com).

(hr)

Ανατομία του HTTP

Αυτή η ενότητα θα εμβαθύνει λίγο περισσότερο στους εσωτερικούς μηχανισμούς του πρωτοκόλλου HTTP. Τα θέματα που συζητούνται για μια επισκόπηση του HTTP περιλαμβάνουν:

• Έννοιες URI και URL
• Ρήματα HTTP: GET, POST, PUT, DELETE, HEAD, TRACE, OPTIONS
• Τύποι μέσων
• Κοινά χαρακτηριστικά του HTTP: stateless, χωρίς ενσωματωμένη κρυπτογράφηση, ταυτοποίηση HTTP

(hr)

Έννοιες URI και URL (h2, anchor section04)

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

URI είναι ακρωνύμιο του Uniform Resource Identifier. URL είναι ακρωνύμιο του Uniform Resource Locator.

Ας ορίσουμε το καθένα με τους απλούστερους δυνατούς όρους, με μια αναλογία. Στο σενάριό μας ας πούμε ότι το URI αντιστοιχεί στον όρο αυτοκίνητο. Ένα URL είναι ένας συγκεκριμένος τύπος URI. Ας πούμε λοιπόν ότι το URL αντιστοιχεί σε ένα «επιβατικό» αλλά όχι σε φορτηγό ή βαν.

Ωστόσο, συνιστάται να χρησιμοποιείτε πάντα τον όρο URI αν η διαφορά έχει κάποια σημασία.

Για να κατανοήσουμε περαιτέρω την έννοια του URI, ας πούμε τώρα ότι θέλουμε να εντοπίσουμε ένα βιβλίο. Αλλά δεν ξέρουμε πού βρίσκεται το βιβλίο. Δεν θα μπορούσαμε να χρησιμοποιήσουμε URL, αφού ένα URL είναι συγκεκριμένο ως προς τον host. Θα μπορούσαμε, όμως, να χρησιμοποιήσουμε ένα URN:

urn:isbn:0451450523

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

Ας πούμε στην αναλογία μας ότι ένα URN είναι ένα βαν, ένας άλλος συγκεκριμένος τύπος αυτοκινήτου. Ένα URI ορίζει ένα URN και ένα URL. Ένα URN αναγνωρίζει έναν συγκεκριμένο πόρο, στο παράδειγμά μας ένα βιβλίο. Ενώ ένα URL αναγνωρίζει τοποθεσία και άλλα μέσα πρόσβασης σε έναν πόρο.

Ανατομία ενός URL

Ένα URL, αλλιώς Uniform Resource Locator, είναι το πιο συνηθισμένο URI σε χρήση στον παγκόσμιο ιστό. Είναι αυτό που πληκτρολογούμε στη γραμμή διευθύνσεων ενός web browser για να πάμε στο https://www.google.com.

Ας δούμε ένα πιο σύνθετο URL και ας αναλύσουμε κάθε μέρος του:

http://admin:password@web5.acmeco.com:8080/admin-docs/2017/ins/infrastructure.xlsx

Είναι συντακτικά έγκυρο, αλλά δείχνει κάτι που δεν πρέπει να κάνετε ποτέ.

Η μορφή user:password σε ένα URL έχει καταργηθεί (RFC 3986), και οι σύγχρονοι browsers την αφαιρούν ή την μπλοκάρουν. Διαπιστευτήρια σε ένα URL καταλήγουν σε logs server, στο ιστορικό του browser και σε κεφαλίδες Referer. Ποτέ μη βάζετε διαπιστευτήρια, hashed ή όχι, σε ένα URL.

Διαπιστευτήρια σε URL
scheme	http://
διαπιστευτήρια	admin:password
πόρος/host	web5.acmeco.com
θύρα	8080
μονοπάτι	/admin-docs/2017/ins/
έγγραφο	infrastructure.xlsx

Το http://www.acmeco.com/ είναι επίσης έγκυρο URL.

Η κάθετος στο τέλος λέει στον web server ότι θέλουμε το προεπιλεγμένο έγγραφο στο webroot. Παραδοσιακά αυτό το έγγραφο ονομάζεται index.html, αλλά μπορεί να αλλάξει σε οτιδήποτε από τον διαχειριστή του server.

Ένα άλλο έγκυρο URL μπορεί να είναι: mailto:user@example.com. Αντί να ζητά ένα έγγραφο, αυτό το URL ανοίγει τον προεπιλεγμένο client email, έτοιμο για γράψιμο προς αυτή τη διεύθυνση.

Μερικά έγκυρα σχήματα πρωτοκόλλου URL είναι: https://, http://, ftp://, file://, mailto:, tel:, και μάλλον μερικά ακόμη. Τα http και https είναι, ωστόσο, τα πιο συχνά χρησιμοποιούμενα πρωτόκολλα στον παγκόσμιο ιστό.

Query strings

Υπάρχει ένας ακόμη συνηθισμένος τρόπος προσδιορισμού ενός URL που χρησιμοποιείται ευρέως στον παγκόσμιο ιστό. Λέγεται query string. Ένα query string χρησιμοποιείται συνήθως σε συνδυασμό με μια backend web εφαρμογή ή ένα CGI script.

Ένα παράδειγμα προσαρτάται στο προηγούμενο αίτημα GET, προσπελαύνοντας απευθείας την αναζήτηση της Google:

https://www.google.com/search?q=euro+vps

Τα query strings χρησιμοποιούνται συνήθως για να περάσουν παραμέτρους σε ένα backend script. Το query string κωδικοποιείται από τον web browser, παραδίδεται σε έναν web server, αποκωδικοποιείται από τον web server ή την εφαρμογή, και τέλος επεξεργάζεται από τη web εφαρμογή.

Τα query strings είναι γνωστό ότι έχουν γίνει αντικείμενο εκμετάλλευσης με το πέρασμα κακών παραμέτρων σε προσπάθειες χειραγώγησης της λειτουργικότητας μιας web εφαρμογής.

https://www.acmeco.com/auth/auth.php?user=acmeuser&password=EXAMPLE

Παραπάνω είναι ένα παράδειγμα του τι δεν πρέπει να κάνετε ποτέ. Τα διαπιστευτήρια, hashed ή όχι, δεν πρέπει ποτέ να ταξιδεύουν σε URL: καταλήγουν σε logs HTTP, στο ιστορικό του browser και σε κεφαλίδες Referer. Στείλτε τα στο σώμα ενός POST μέσω HTTPS, ή σε μια κεφαλίδα Authorization.

(hr)

Ρήματα HTTP (h2, anchor section05)

Τώρα που έχουμε μια καλή ιδέα του τι είναι ένα URL και πώς χρησιμοποιούνται τα query strings, θα παρουσιάσουμε τα ρήματα που χρησιμοποιούνται στα αιτήματα HTTP. Τα πιο συχνά χρησιμοποιούμενα ρήματα HTTP είναι:

• POST και GET
• PUT
• DELETE
• HEAD
• TRACE
• OPTIONS
• CONNECT

1. POST και GET

Το GET είναι η προεπιλεγμένη μέθοδος όταν πληκτρολογείτε ένα website στη γραμμή διευθύνσεων ενός browser ή κάνετε κλικ σε έναν υπερσύνδεσμο. Όταν ζητείται μια ιστοσελίδα, ο browser μπορεί στην πραγματικότητα να κάνει πολλά αιτήματα GET ή POST κατεβάζοντας όλους τους πόρους που συνθέτουν μια ιστοσελίδα, όπως εικόνες, stylesheets, scripts πλευράς client, πόρους τυπογραφίας και άλλα:

Υπερσύνδεσμος είναι ο τεχνικός όρος για τη σύνδεση με δευτερεύουσες ιστοσελίδες. Όταν ο χρήστης κάνει κλικ σε έναν σύνδεσμο (ή υπερσύνδεσμο), ο browser στέλνει ένα αίτημα GET για τη συνδεδεμένη σελίδα

Αιτήματα POST

Οι δύο πιο συχνά χρησιμοποιούμενες μέθοδοι αιτήματος είναι οι GET και POST. Έχουμε ήδη αναλύσει ένα αίτημα GET. Ας εξετάσουμε λοιπόν ένα αίτημα POST.

Τι θα γινόταν αν θέλαμε να μεταφορτώσουμε ένα αρχείο 1GB μέσω ενός script PHP ή asp; Φυσικά, ένα URL δεν μπορεί να χωρέσει μια δυαδική συμβολοσειρά 1GB. Σε αυτό το σενάριο θα χρησιμοποιούσαμε τη μέθοδο POST.

Το POST μοιάζει με το GET στο ότι το POST μπορεί να περάσει παραμέτρους όπως ένα query string. Ωστόσο, τα δεδομένα POST δεν προσαρτώνται σε ένα URL όπως με το query string.

Αντίθετα, τα δεδομένα POST ταξιδεύουν στο σώμα του αιτήματος HTTP, μετά τις κεφαλίδες. Το POST χρησιμοποιείται πιο συχνά με δεδομένα φορμών HTML.

Η μέθοδος POST χρησιμοποιείται συνήθως όταν χρειάζονται τα παρακάτω χαρακτηριστικά:

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

Ας συγκρίνουμε με μερικά πλεονεκτήματα της μεθόδου GET με query string προσαρτημένο στο URL

• μπορεί να αποθηκευτεί ως σελιδοδείκτης
• μπορεί να γίνει cache
• τα αποτελέσματα ερωτήματος μπορούν να μοιραστούν με έναν σύνδεσμο

2. PUT

Η μέθοδος PUT χρησιμοποιείται πιο συχνά σε RESTful web APIs. Το PUT δημιουργεί ή αντικαθιστά τον πόρο στο URI που δίνεται στο αίτημα, ενώ το POST ζητά από τον server να επεξεργαστεί τα δεδομένα, συχνά δημιουργώντας έναν νέο πόρο σε URI που επιλέγει ο server.

Το PUT είναι συνήθως απενεργοποιημένο εξ ορισμού στις εγκαταστάσεις web server.

Το να μείνει το PUT ενεργοποιημένο θα μπορούσε δυνητικά να επιτρέψει σε επιτιθέμενους να μεταφορτώσουν και να εκτελέσουν αρχεία στον web server.

3. DELETE

Όπως το PUT, η μέθοδος DELETE χρησιμοποιείται πιο συχνά σε RESTful APIs. Η χρήση του DELETE θα πρέπει να εκτελεί μια ενέργεια διαγραφής σε ένα αντικείμενο URI:

DELETE http://acmeco.com/customers/{customer-id}

Το DELETE είναι απενεργοποιημένο εξ ορισμού στις περισσότερες εγκαταστάσεις web server. Η ενεργοποίηση του DELETE όταν δεν χρειάζεται θα μπορούσε να είναι κίνδυνος ασφαλείας, επιτρέποντας σε επιτιθέμενους να διαγράψουν έγγραφα από ένα website.

4. HEAD

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

5. TRACE

Το TRACE είναι διαγνωστική μέθοδος και συνήθως είναι απενεργοποιημένο στους περισσότερους web servers. Πολλοί ερευνητές ασφαλείας έχουν ανακαλύψει πιθανές ευπάθειες με τις μεθόδους TRACE. Το ρίσκο υπερβαίνει κατά πολύ τη χρησιμότητα του TRACE τις περισσότερες φορές.

6. OPTIONS

Το OPTIONS ρωτά τον server ποιες μεθόδους και δυνατότητες υποστηρίζει για έναν πόρο. Μην το απενεργοποιείτε: οι browsers στέλνουν αίτημα OPTIONS ως CORS preflight πριν από πολλές κλήσεις API μεταξύ διαφορετικών origins, και το μπλοκάρισμά του χαλάει αυτές τις εφαρμογές. Αντίθετα, επιτρέψτε μόνο τις μεθόδους που πραγματικά χρειάζεται η εφαρμογή σας, και απενεργοποιήστε το TRACE.

7. CONNECT

Το CONNECT χρησιμοποιείται από proxies και δεν θα πρέπει να είναι ενεργοποιημένο σε έναν συνηθισμένο web server. Όταν είναι ενεργοποιημένο και λάθος ρυθμισμένο, το CONNECT μπορεί να επιτρέψει συνδέσεις που προωθούν αιτήματα σε άλλους servers. Αυτές οι προωθημένες συνδέσεις μπορούν να χρησιμοποιηθούν για επιθέσεις ή για λήψη παράνομων αρχείων.

Εξ ορισμού, το περισσότερο λογισμικό web server έχει το CONNECT απενεργοποιημένο.

Η νόμιμη χρήση του CONNECT είναι η διοχέτευση συνδέσεων HTTPS και άλλων συνδέσεων TLS μέσω ενός forward proxy.

(hr)

Τύποι μέσων (h2, anchor section06)

Ένας τύπος μέσου (Media Type) ορίζει τα αρχεία με βάση τη φύση και τη μορφή τους για απεικόνιση ή επεξεργασία. Η κεφαλίδα Content-Type χρησιμοποιείται σε μια απόκριση HTTP επιτρέποντας σε έναν web browser να εμφανίσει το κείμενο της απόκρισης, να φορτώσει ένα plugin για έναν υποστηριζόμενο τύπο αρχείου, ή απλώς να κατεβάσει ένα αρχείο για προβολή σε άλλη εφαρμογή.

Αρχικά ο Media Type υλοποιήθηκε για συνημμένα email και ονομάστηκε MIME Types. MIME σημαίνει Multipurpose Internet Mail Extension.

Κάποιοι Media Types μπορεί να έχουν πρόθεμα «x-» ή «vnd». Το «x» σημαίνει ότι ένας Media Type δεν είναι επίσημα καταχωρημένος από την IANA (Internet Assigned Numbers Authority). Το μέρος «vnd» σημαίνει ότι ένας Media Type είναι συγκεκριμένος ενός κατασκευαστή (για παράδειγμα application/vnd.ms-excel).

Προβολή των Media Types στον Firefox

• πληκτρολογήστε «about:config» στη γραμμή διευθύνσεων.
• στο πλαίσιο αναζήτησης ρυθμίσεων πληκτρολογήστε «mime»

image: src /blog/wp-content/uploads/2017/12/rNTzwB7-e1513109426632.jpg (unchanged); alt: Ρυθμίσεις MIME Type του Firefox σε Linux

Σε πλατφόρμα Linux βλέπουμε ότι ο Firefox χρησιμοποιεί το αρχείο /etc/mime.types

Ας δούμε ένα τμήμα του αρχείου /etc/mime.types:

$ head -n 40 /etc/mime.types | grep -v "^#" application/activemessage application/andrew-inset ez application/annodex anx application/applefile application/atom+xml atom application/atomcat+xml atomcat application/atomicmail application/atomserv+xml atomsrv application/batch-SMTP application/bbolin lin application/beep+xml application/cals-1840 application/commonground application/cu-seeme cu application/cybercash $ wc -l /etc/mime.types 835 /etc/mime.types

Όπως φαίνεται, πάνω από 800 συγκεκριμένοι mime types αναγνωρίζονται από αυτό το σύστημα. Ουσιαστικά αυτό λέει στον Firefox για τις επεκτάσεις που σχετίζονται με ορισμένους τύπους αρχείων.

ΣΗΜΕΙΩΣΗ: Οι Media Types είναι διαφορετικοί από τις «προεπιλεγμένες εφαρμογές» του λειτουργικού συστήματος. Αν και παρόμοιοι ως έννοια, οι mime types χρησιμοποιούνται για εφαρμογές που γνωρίζουν το Internet, ενώ ένα λειτουργικό σύστημα κρατά ξεχωριστό αρχείο τύπων αρχείων και των σχετικών προγραμμάτων προβολής.

Όταν γίνεται ένα αίτημα GET για ένα φύλλο Excel, η κεφαλίδα Content-Type επιστρέφει application/vnd.ms-excel. Έτσι ο web browser ξέρει ότι το αρχείο δεν πρέπει να εμφανιστεί ως κείμενο στο παράθυρο του browser. Αντίθετα, το αρχείο είτε φορτώνεται σε ένα plugin προβολής είτε κατεβαίνει για μεταγενέστερη προβολή σε άλλη εφαρμογή.

Ένας web server Unix ή Linux χρησιμοποιεί επίσης το /etc/mime.types για την κεφαλίδα Content-Type. Επιπλέον, πρέπει να οριστεί ένας handler για μια γλώσσα scripting όπως η php, ώστε τα αρχεία PHP να εκτελούνται αντί να στέλνονται στον browser ως κείμενο. Σε RHEL, το /etc/httpd/conf.d/php.conf του Apache τα παραδίδει στο PHP-FPM:

<FilesMatch \.(php|phar)$> SetHandler "proxy:unix:/run/php-fpm/www.sock|fcgi://localhost" </FilesMatch>

Παραπάνω: τα αρχεία που τελειώνουν σε .php (και .phar) περνούν στην υπηρεσία PHP-FPM μέσω του socket της, αντί να εξυπηρετούνται ως απλά αρχεία.

Αν έχετε ποτέ κάνει κλικ σε έναν σύνδεσμο και ο browser σας εμφάνισε ένα γραφικό ή άλλα δυαδικά δεδομένα ως ASCII, ή σας ζήτησε να κατεβάσετε μια ιστοσελίδα, σημαίνει ότι οι mime types του browser ή του server ήταν λάθος ρυθμισμένοι.

Για την αντιμετώπιση του προβλήματος, δείτε την κεφαλίδα Content-Type στα εργαλεία προγραμματιστή του browser σας (καρτέλα Network):

image: src /blog/wp-content/uploads/2017/12/FTSurmm-e1513109444640.jpg (unchanged); alt: Κεφαλίδα Content-Type στο HTTPFox

Βλέπουμε ότι ο σωστός content-type προσδιορίστηκε σε μια απόκριση του server. Αν ο browser ζητούσε να αποθηκεύσουμε την εικόνα που ζητήθηκε με το αίτημα GET, θα ξέραμε ότι ο mime type του browser για image/jpeg χρειάζεται επαναρύθμιση.

Λανθασμένες ρυθμίσεις server-side scripting ή δυαδικών mime types μπορούν να οδηγήσουν σε ζητήματα ασφαλείας στον server ή στον client.

Η IANA (Internet Assigned Numbers Authority) είναι επιφορτισμένη με την τήρηση επίσημης αντιστοίχισης των media types μέσω της διαδικασίας RFC.

IANA Media Type RFC

(hr)

Χαρακτηριστικά του HTTP

Σε αυτή την ενότητα θα συζητήσουμε χαρακτηριστικά του πρωτοκόλλου HTTP. Οι πιο σημαντικές έννοιες που πρέπει να ξέρετε όταν δουλεύετε με HTTP είναι:

• Το HTTP είναι stateless
• Το HTTP δεν προσφέρει ενσωματωμένη κρυπτογράφηση

Τι είναι ένα stateless πρωτόκολλο;

Το HTTP είναι stateless εκ σχεδιασμού: κάθε αίτημα μεταφέρει ό,τι χρειάζεται ο server για να το απαντήσει. Το HTTP δεν είναι, όμως, connectionless. Τα HTTP/1.1 και HTTP/2 κρατούν ανοιχτές συνδέσεις TCP και τις επαναχρησιμοποιούν για πολλά αιτήματα, και το HTTP/3 κάνει το ίδιο πάνω από QUIC.

Stateless σημαίνει απλώς ότι οι συναλλαγές HTTP ζητούνται από έναν user agent και μετά απαντώνται από τον web server. Αν ένας client δεν κάνει cache τους ζητούμενους πόρους, πρέπει να εκδώσει ξανά την ίδια μέθοδο για να αποκτήσει και πάλι τον πόρο. Ένας web server HTTP δεν έχει πίνακα κατάστασης για να αναζητήσει προηγούμενες επικοινωνίες με έναν user agent.

HTTP Cookies: τα cookies μπορούν να βοηθήσουν έναν web server να αναφερθεί σε προηγούμενες αλληλεπιδράσεις HTTP με έναν user agent. Το ίδιο το πρωτόκολλο παραμένει stateless: κάθε αίτημα στέκεται μόνο του, ακόμη κι όταν ταξιδεύει μέσα από μια σύνδεση που επαναχρησιμοποιείται.

Οι περισσότερες γλώσσες backend προγραμματισμού, όπως το Django Framework της Python, η PHP και το ASP .Net, προσφέρουν βιβλιοθήκες για τη διατήρηση κατάστασης εφαρμογής με ενσωματωμένα frameworks sessions. Αυτή η προσέγγιση προσθέτει κατάσταση σε μια web εφαρμογή, αλλά είναι αφηρημένη σε υψηλότερο επίπεδο από το HTTP.

Το HTTP δεν παρέχει κρυπτογράφηση

Το ίδιο το HTTP δεν παρέχει ενσωματωμένους μηχανισμούς κρυπτογράφησης. Η κρυπτογράφηση αφήνεται σε άλλα πρωτόκολλα που ορίζουν το HTTPS. Το HTTPS χρησιμοποιεί το Transport Layer Security ή TLS, τον διάδοχο του SSL.

Το TLS δουλεύει με πολλά πρωτόκολλα, όχι μόνο με το HTTP. Το HTTPS είναι σχεδιασμένο για τη μεταφορά δεδομένων περιεχομένου HTTP και κεφαλίδων HTTP μέσω ασφαλών συνδέσεων TLS. Το SSL αναπτύχθηκε αρχικά τη δεκαετία του 1990 από τη Netscape. Η IETF αργότερα τυποποίησε τον διάδοχό του ως TLS. Όλες οι εκδόσεις του SSL είναι πλέον ξεπερασμένες. Τρέχουσες είναι οι TLS 1.2 και TLS 1.3.

Ο προσεκτικός αναγνώστης μπορεί να αναρωτηθεί: «Άρα το HTTPS είναι stateful; Σωστά; Κάθε session έχει κλειδί; Σωστά;». Τα κλειδιά αποθηκεύονται από τον client, ναι. Αλλά το TLS λειτουργεί ακόμη σε χαμηλότερο επίπεδο από τον πυρήνα HTTP του HTTPS. Οι αλληλεπιδράσεις με τον web server εξακολουθούν να χρησιμοποιούν τις ίδιες μεθόδους HTTP: GET, POST, PUT και DELETE.

(hr)

Ταυτοποίηση HTTP (h2, anchor section07)

Η ταυτοποίηση, σε αντίθεση με την κρυπτογράφηση, είναι ενσωματωμένη στο HTTP. Το HTTP υποστηρίζει πολλούς τύπους ταυτοποίησης, μεταξύ των οποίων:

1. Basic
2. Bearer
3. Digest
4. HOBA
5. Mutual
6. Negotiate
7. OAuth
8. SCRAM-SHA1
9. SCRAM-SHA256
10. vapid

Basic Authentication

Η μακράν πιο συνηθισμένη μέθοδος ταυτοποίησης HTTP είναι η Basic Authentication. Η Basic Authentication είναι συνηθισμένη επειδή είναι απλή στην υλοποίηση, όχι επειδή είναι ασφαλής. Άλλα σχήματα ταυτοποίησης είναι πιο ασφαλή, και η Basic Authentication πρέπει να χρησιμοποιείται μόνο μέσω HTTPS.

Το μεγαλύτερο ζήτημα ασφαλείας με την Basic Authentication είναι ότι τα διαπιστευτήρια στέλνονται σε καθαρό κείμενο. Αν και τα διαπιστευτήρια κωδικοποιούνται σε Base-64, η κωδικοποίηση δεν είναι κρυπτογράφηση, στην καλύτερη περίπτωση είναι συσκότιση. Τα διαπιστευτήρια μπορούν εύκολα να εκτεθούν όταν δεν χρησιμοποιείται TLS ή όταν η κίνηση TLS πέφτει θύμα επίθεσης man-in-the-middle.

Αδυναμίες της Basic Authentication:

• κωδικοποιεί τα διαπιστευτήρια μόνο σε BASE 64
• τα διαπιστευτήρια αποθηκεύονται στον browser, αφήνοντας ακόμη έναν φορέα επίθεσης
• τα διαπιστευτήρια μπορούν να αποθηκευτούν μόνιμα στον browser
• κακόβουλοι proxy servers μπορούν δυνητικά να καταγράψουν τα διαπιστευτήρια
• τα διαπιστευτήρια βρίσκονται στην κεφαλίδα HTTP

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

Όταν υλοποιείτε ένα σχήμα ταυτοποίησης HTTP, σκεφτείτε την Basic Authentication ως έναν κωδικό εισόδου που επιτρέπει την εξουσιοδοτημένη είσοδο σε ένα κτίριο ή γραφείο μόνο όταν το προσωπικό ασφαλείας είναι παρόν. Μετά το ωράριο, οι ίδιες πόρτες κλειδώνουν με πιο ασφαλή μηχανισμό για να ασφαλιστεί το κτίριο.

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

Παρακάτω είναι μια απεικόνιση αιτήματος/απόκρισης Basic Authentication:

images: src /blog/wp-content/uploads/2017/12/fvNIZLj-e1513109471712.jpg and /blog/wp-content/uploads/2017/12/Svu1sFi-e1513109482792.jpg (unchanged); alts: Basic Authentication 1, Basic Authentication 2

1. Ο user agent κάνει αίτημα για ένα έγγραφο
2. Ο web server απαντά με κωδικό HTTP 401: Authorization Required
3. Ο user agent επαναλαμβάνει το αίτημα με διαπιστευτήρια
4. Ο web server επιτρέπει ή αρνείται την πρόσβαση με βάση την εγκυρότητα των διαπιστευτηρίων

Ως επίδειξη των αδυναμιών της Basic Authentication, δοκιμάστε να βρείτε τα διαπιστευτήρια από την εικονιζόμενη συμβολοσειρά BASE64.

Ταυτοποίηση με Bearer Token

Η ταυτοποίηση με Bearer Token είναι δημοφιλής ανάμεσα στους παρόχους frameworks ταυτοποίησης. Η Bearer Authentication μπορεί επίσης να αναπτυχθεί ως αυτόνομη λύση, ανά περίπτωση.

Η Bearer Authentication βασίζεται σε tokens και χρησιμοποιείται τόσο στο OAuth όσο και στο OpenID. Τυπικά το OAuth χρησιμοποιείται για εξουσιοδότηση ενώ το OpenID για ταυτοποίηση. Ωστόσο, υπάρχουν αρκετές γκρίζες ζώνες που θολώνουν τα όρια μεταξύ ταυτοποίησης και εξουσιοδότησης σε κάθε framework.

• Το OpenID παρέχει ομοσπονδιακή ταυτοποίηση ή υπηρεσίες σύνδεσης
• Το OAuth παρέχει εκχωρημένη εξουσιοδότηση

Το GitHub παρέχει έναν οδηγό OAuth για προγραμματιστές εφαρμογών τρίτων που θέλουν να προσπελάσουν πόρους του GitHub για λογαριασμό ενός τελικού χρήστη. Οδηγός OAuth App του GitHub

Μεγάλοι πάροχοι ταυτότητας όπως η Google προσφέρουν σύνδεση μέσω OpenID Connect, του τρέχοντος προτύπου OpenID, που είναι χτισμένο πάνω στο OAuth 2.0.

Σύνδεση με OpenID Connect με λογαριασμό Google:

image: src /blog/wp-content/uploads/2017/12/BMtbtwA.jpg (unchanged); alt: Πάροχος ταυτοποίησης Google Open ID

Digest Authentication

Η Digest Authentication είναι πιο ασφαλής από την Basic Authentication. Ωστόσο, η Digest Authentication παραμένει ανεπαρκής για την ασφάλιση ευαίσθητου υλικού στο Internet. Η Digest Authentication δεν κρυπτογραφεί τα διαπιστευτήρια, τα κάνει hash, και αν αυτά τα hashes υποκλαπούν, ένας επιτιθέμενος μπορεί να εξαπολύσει offline επίθεση brute-force ή λεξικού.

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

Άλλα σχήματα ταυτοποίησης βασισμένα στο HTTP

Το NTLM, γνωστό ως NT Lan Manager Authentication, είναι τεχνολογία της Microsoft με plugins για πολλά προϊόντα, λειτουργικά συστήματα και υπηρεσίες τρίτων.

Σε domains Windows η προτιμώμενη επιλογή είναι το Negotiate, που χρησιμοποιεί Kerberos και καταφεύγει στο NTLM μόνο όταν πρέπει. Η Microsoft αποσύρει σταδιακά το NTLM. Με Kerberos, οι χρήστες του domain που έχουν ήδη συνδεθεί μπορούν να προσπελάσουν εξουσιοδοτημένους πόρους χωρίς να εισάγουν ξανά τα διαπιστευτήριά τους.

Τα μεγαλύτερα μειονεκτήματα της ταυτοποίησης με NTLM είναι:

• μπορεί να είναι δύσχρηστη στην υλοποίηση σε πλατφόρμες εκτός Windows
• μπορεί να χάσει πολλά χαρακτηριστικά ασφαλείας αν αναπτυχθεί εκτός ενός Windows Domain
• το NTLM είναι τόσο ασφαλές όσο το εταιρικό δίκτυο
• οι παλαιότερες εκδόσεις του NTLM θεωρούνται ανασφαλείς

SCRAM-SHA1 και SCRAM-SHA256

SCRAM είναι ακρωνύμιο του Salted Challenge Response Authentication Mechanism

Όταν χρειάζεται να ταυτοποιηθούν εσωτερικοί εργαζόμενοι, η ταυτοποίηση SCRAM σε συνδυασμό με OpenLDAP μπορεί να είναι καλή λύση για περιβάλλοντα με εξοπλισμό πολλών κατασκευαστών.

Το SCRAM μπορεί να είναι πιο περίπλοκο στην ανάπτυξη από το NTLM για ένα Windows Domain. Αλλά το SCRAM μπορεί να είναι εξαιρετική επιλογή σε ένα δίκτυο με clients Linux, MacOS Server, Windows και Unix, ακόμη και μέσω του Internet.