Κάθε φορά που ανοίγεις μια ιστοσελίδα, ο browser σου στέλνει ένα αίτημα HTTP και ο server απαντά. Σε αυτό το εργαστηριακό άρθρο για αρχάριους βλέπουμε βήμα-βήμα πώς δουλεύει το πρωτόκολλο HTTP/HTTPS — requests, headers, status codes και το TLS handshake — μέσα σε ένα απομονωμένο (isolated) lab, με έμφαση στην κατανόηση και την άμυνα.

1. Γιατί έχει σημασία να καταλάβεις το HTTP

Το HTTP (HyperText Transfer Protocol) είναι η «γλώσσα» με την οποία μιλάει ο browser σου με κάθε ιστότοπο. Είναι το θεμέλιο του παγκόσμιου ιστού: όταν πληκτρολογείς μια διεύθυνση, δεκάδες μηνύματα HTTP ταξιδεύουν στο δίκτυο μέσα σε κλάσματα του δευτερολέπτου. Αν θέλεις να ασχοληθείς με την κυβερνοασφάλεια ή το authorized penetration testing, η κατανόηση αυτού του πρωτοκόλλου δεν είναι προαιρετική — είναι το αλφάβητο.

Οι περισσότερες ευπάθειες εφαρμογών web (injection, broken authentication, misconfigurations) εκδηλώνονται μέσα σε μηνύματα HTTP. Ένας αμυντικός μηχανικός (defender) που ξέρει να διαβάζει ένα request και ένα response μπορεί να εντοπίσει ανωμαλίες στα logs, να ρυθμίσει σωστά security headers και να αναγνωρίσει ένα κακόβουλο pattern. Γι’ αυτό ξεκινάμε από τα θεμέλια.

Ένα ακόμη σημαντικό στοιχείο: το HTTP είναι stateless (χωρίς μνήμη κατάστασης). Κάθε request είναι ανεξάρτητο και ο server δεν «θυμάται» από μόνος του ποιος είσαι. Αυτόν τον περιορισμό τον λύνουν τα cookies και τα session tokens — και ακριβώς επειδή μεταφέρουν την ταυτότητα του χρήστη, γίνονται συχνά στόχος. Καταλαβαίνοντας πώς ταξιδεύει ένα cookie μέσα στα headers, μπορείς να προστατεύσεις μια εφαρμογή με σωστές σημαίες όπως HttpOnly, Secure και SameSite.

2. Βασικές έννοιες

2.1 Το μοντέλο request / response

Το HTTP είναι πρωτόκολλο αίτησης–απόκρισης (request–response). Ο client (συνήθως ο browser ή ένα εργαλείο όπως το curl) στέλνει ένα request· ο server επιστρέφει ένα response. Κάθε request περιλαμβάνει:

  • μια μέθοδο (method): GET, POST, PUT, DELETE κ.ά.·
  • ένα path (π.χ. /index.html) και την έκδοση του πρωτοκόλλου·
  • ένα σύνολο headers (μεταδεδομένα, π.χ. Host, User-Agent
  • προαιρετικά ένα body (τα δεδομένα, π.χ. σε ένα POST φόρμας).

2.2 Οι μέθοδοι GET και POST

Η GET ζητά έναν πόρο χωρίς να τον τροποποιεί — είναι «ασφαλής» και idempotent. Η POST στέλνει δεδομένα στον server (π.χ. στοιχεία σύνδεσης, ένα σχόλιο) και συνήθως αλλάζει κατάσταση. Ένας βασικός κανόνας ασφάλειας: ευαίσθητα δεδομένα δεν μπαίνουν ποτέ σε GET, γιατί καταλήγουν στα logs και στο ιστορικό του browser. Σε ένα GET, τα παραμετρικά δεδομένα ταξιδεύουν στο ίδιο το URL (query string, π.χ. ?id=5), ενώ σε ένα POST μπαίνουν στο body του request και δεν εμφανίζονται στη διεύθυνση. Υπάρχουν και άλλες μέθοδοι — PUT και PATCH για ενημέρωση πόρου, DELETE για διαγραφή, OPTIONS για ανακάλυψη των επιτρεπόμενων μεθόδων — που θα συναντήσεις κυρίως σε REST APIs.

2.3 Status codes

Κάθε response ξεκινά με έναν τριψήφιο κωδικό κατάστασης (status code) που δηλώνει το αποτέλεσμα:

  • 2xx – Επιτυχία: 200 OK, 201 Created·
  • 3xx – Ανακατεύθυνση (redirect): 301 Moved Permanently, 302 Found·
  • 4xx – Σφάλμα client: 401 Unauthorized, 403 Forbidden, 404 Not Found·
  • 5xx – Σφάλμα server: 500 Internal Server Error, 503 Service Unavailable.

2.4 Από το HTTP στο HTTPS

Το «σκέτο» HTTP στέλνει τα πάντα σε καθαρό κείμενο (plaintext): οποιοσδήποτε στο ίδιο δίκτυο μπορεί να διαβάσει τα δεδομένα. Το HTTPS προσθέτει το στρώμα TLS (Transport Layer Security), που κρυπτογραφεί την επικοινωνία και επαληθεύει την ταυτότητα του server μέσω ψηφιακού πιστοποιητικού (certificate). Σήμερα, HTTP χωρίς TLS θεωρείται μη αποδεκτό για κάθε παραγωγικό σύστημα.

3. Πρακτικό κομμάτι: εξερεύνηση HTTP με curl στο lab

Θα χρησιμοποιήσουμε το curl, ένα εργαλείο γραμμής εντολών που στέλνει HTTP requests και μας δείχνει ακριβώς τι ταξιδεύει στο δίκτυο. Ο στόχος μας είναι ένας τοπικός web server στο 10.10.10.20, μέσα στο απομονωμένο μας εργαστήριο.

3.1 Ένα «verbose» request με curl -v

Η σημαία -v (verbose) μας δείχνει και το request που στέλνουμε και το response που λαμβάνουμε. Οι γραμμές με > είναι ό,τι στέλνει ο client, οι γραμμές με < είναι η απάντηση του server:

Έξοδος curl -v που δείχνει το HTTP request με GET και τα response headers από τον server του lab
Έξοδος curl -v που δείχνει το HTTP request με GET και τα response headers από τον server του lab

Παρατήρησε τη δομή: πρώτη γραμμή GET / HTTP/1.1, μετά τα request headers, και στη συνέχεια η απάντηση 200 OK με τα δικά της headers. Αυτή είναι όλη η «μαγεία» του web σε μία οθόνη.

3.2 Μόνο τα headers με curl -I

Όταν μας ενδιαφέρουν μόνο τα μεταδεδομένα (και όχι το περιεχόμενο), η σημαία -I στέλνει ένα HEAD request και τυπώνει μόνο τα response headers. Είναι ιδανικό για γρήγορο έλεγχο security headers:

Έξοδος curl -I με τα response headers, όπου φαίνονται Server, Content-Type και ελλείψεις σε security headers
Έξοδος curl -I με τα response headers, όπου φαίνονται Server, Content-Type και ελλείψεις σε security headers

Εδώ ένας defender κοιτάζει αμέσως: υπάρχει Strict-Transport-Security; Υπάρχει X-Content-Type-Options; Η έλλειψή τους είναι εύρημα (finding) που καταγράφεται σε μια αναφορά ασφάλειας.

3.3 GET vs POST στην πράξη

Στέλνουμε τώρα ένα POST με δεδομένα φόρμας προς ένα endpoint σύνδεσης του lab και βλέπουμε πώς ο server απαντά με redirect. Πρόσεξε ότι το password είναι sanitised (…snip…) — ποτέ δεν καταγράφουμε πραγματικά credentials:

Έξοδος curl που δείχνει POST request σε endpoint σύνδεσης του lab με απάντηση 302 redirect και σύγκριση status codes
Έξοδος curl που δείχνει POST request σε endpoint σύνδεσης του lab με απάντηση 302 redirect και σύγκριση status codes

Ο server απαντά 302 Found και μας ανακατευθύνει, ένα κλασικό pattern μετά από επιτυχή POST (Post/Redirect/Get). Δίπλα βλέπουμε και ένα 404 για ανύπαρκτο path — έτσι μαθαίνεις να διαβάζεις τα status codes ζωντανά.

3.4 Το TLS handshake του HTTPS

Τέλος, στέλνουμε ένα request στην HTTPS έκδοση του server (θύρα 443) με curl -v. Το curl μας δείχνει βήμα-βήμα το TLS handshake: διαπραγμάτευση έκδοσης, αλγόριθμο κρυπτογράφησης (cipher) και έλεγχο του πιστοποιητικού. Στο lab χρησιμοποιούμε self-signed certificate, γι’ αυτό προσθέτουμε -k ώστε το curl να μη διακόψει:

Έξοδος curl -v με το TLS handshake του HTTPS: έκδοση TLS 1.3, cipher και λεπτομέρειες του self-signed certificate στο lab
Έξοδος curl -v με το TLS handshake του HTTPS: έκδοση TLS 1.3, cipher και λεπτομέρειες του self-signed certificate στο lab

Οι γραμμές με * περιγράφουν το handshake: TLS 1.3, ο cipher που συμφωνήθηκε και τα πεδία του certificate (subject, issuer, ισχύς). Αυτό είναι το «λουκέτο» του browser, εκτεθειμένο σε απλό κείμενο για να το καταλάβεις.

4. Το εργαστηριακό περιβάλλον (isolated lab)

Όλες οι εντολές εκτελέστηκαν σε πλήρως απομονωμένο εργαστήριο, χωρίς καμία σύνδεση με το Internet ή με πραγματικά συστήματα τρίτων. Το σετ-απ είναι απλό και δωρεάν να το αναπαράγεις:

  • Ένα Kali Linux VM ως σταθμός εργασίας (ο client μας)·
  • Ένα δεύτερο VM με έναν απλό web server (Apache/Nginx) στο 10.10.10.20, ως στόχος·
  • Ένα host-only δίκτυο (VirtualBox/VMware) στο εύρος 10.10.10.0/24, ώστε η κίνηση να μη βγαίνει ποτέ έξω·
  • Χρήση ουδέτερων διευθύνσεων (10.10.10.x, 127.0.0.x) και sanitised output.

Έτσι μπορείς να πειραματιστείς ελεύθερα με requests, headers και status codes χωρίς κανένα ρίσκο για τρίτους — και χωρίς να παραβιάζεις κανέναν νόμο.

5. Ηθικό & νομικό πλαίσιο

Η εξερεύνηση HTTP/HTTPS με εργαλεία όπως το curl είναι απολύτως νόμιμη μόνο σε συστήματα που σου ανήκουν ή για τα οποία έχεις ρητή, γραπτή εξουσιοδότηση (scope). Η αποστολή requests σε ξένους servers με σκοπό τον έλεγχο ή την παράκαμψη ελέγχων μπορεί να συνιστά αδίκημα βάσει του ελληνικού και ευρωπαϊκού δικαίου (π.χ. Ν. 4411/2016, GDPR για δεδομένα, οδηγία NIS2).

Το πνεύμα αυτού του άρθρου είναι εκπαιδευτικό και αμυντικό: μαθαίνεις πώς δουλεύει το πρωτόκολλο ώστε να προστατεύεις καλύτερα τις δικές σου εφαρμογές — σωστά security headers, επιβολή HTTPS, παρακολούθηση logs για ανώμαλα patterns. Δεν είναι οδηγός επίθεσης σε πραγματικό στόχο. Δούλευε πάντα μέσα στο δικό σου isolated lab.

6. Βασικά συμπεράσματα

  • Το HTTP είναι ένα πρωτόκολλο request–response: ο client στέλνει method + path + headers, ο server απαντά με status code + headers + body.
  • Οι μέθοδοι έχουν σημασία: GET για ανάγνωση, POST για αλλαγή κατάστασης· ευαίσθητα δεδομένα ποτέ σε GET.
  • Τα status codes (2xx/3xx/4xx/5xx) σου λένε αμέσως τι συνέβη — μάθε τα να διαβάζεις live.
  • Το HTTPS/TLS προσθέτει κρυπτογράφηση και επαλήθευση ταυτότητας· το handshake διαπραγματεύεται έκδοση, cipher και certificate.
  • Το curl (με -v και -I) είναι το ιδανικό εργαλείο για να «δεις» το HTTP χωρίς τον θόρυβο του browser.
  • Εξάσκηση μόνο σε isolated lab ή σε συστήματα με εξουσιοδότηση — η γνώση εδώ είναι για άμυνα, όχι για επίθεση.

Από τη θεωρία στην πράξη. Η Audax Cybersecurity προσφέρει επαγγελματικές υπηρεσίες offensive security — penetration testing & offensive validation — ενώ για όσους ξεκινούν το ταξίδι τους στο ethical hacking, το #1 ελληνικό βιβλίο «Ethical Hacking — Η Κρυφή Γνώση» είναι ο ιδανικός οδηγός.

Erevos AI · Managed CTEM

Θέλετε συνεχή επικύρωση της ασφάλειάς σας — όχι έλεγχο μία φορά τον χρόνο;

Το Erevos AI είναι η ετήσια, managed υπηρεσία CTEM της Audax — ενοποιεί exposure mapping, penetration testing, adversary emulation, detection validation & remediation σε έναν συνεχή, αποδεικτικό κύκλο. Human-led. Machine-scaled. Technically proven. Ευθυγραμμισμένο με NIS2 & DORA.

Ανακαλύψτε το Erevos AI →
Offensive Security · Penetration Testing

Χρειάζεστε Penetration Testing για τον οργανισμό σας;

Περιγράψτε το scope του ελέγχου μέσα από το δομημένο ερωτηματολόγιο και λάβετε εξατομικευμένη τεχνική & οικονομική προσφορά από την ομάδα Offensive Security της Audax. Χωρίς αυτόματη τιμή ή δέσμευση — η προσφορά αποστέλλεται μετά από τεχνική αξιολόγηση του scope.

Ζητήστε προσφορά Penetration Testing →