Εν ολίγοις: Ένα code review ασφαλείας για PHP είναι η στοχευμένη ανάγνωση του πηγαίου κώδικα με ένα ερώτημα: Πού μπορούν ξένες είσοδοι να κάνουν κάτι που δεν επιτρέπεται; Δύο μορφές έχουν αποδειχθεί αποτελεσματικές, ένα review κάθε αλλαγής και ένα βασικό review ολόκληρου του έργου, με υποστήριξη από στατική ανάλυση με PHPStan ή Psalm. Ευπάθειες στον διερμηνέα PHP όπως το PHP2Shell δεν τις βρίσκει ένα review, βρίσκει όμως τα πολλά σφάλματα που προκύπτουν στον δικό σας κώδικα.
Γιατί να κοιτάξετε τον δικό σας κώδικα ακριβώς τώρα;
Το PHP2Shell απασχόλησε την τελευταία εβδομάδα του Οκτωβρίου 2026 κυρίως τους διαχειριστές. Patch, επανεκκίνηση, απόδειξη: η δουλειά βρισκόταν στον διακομιστή. Για τις ομάδες ανάπτυξης μένει μετά ένα άβολο ερώτημα. Αν ένας επιτιθέμενος μπορεί μέσω άλλης ευπάθειας να εκτελέσει κώδικα, τι βρίσκει στην εφαρμογή μας; Και πόσες από αυτές τις ευπάθειες γράψαμε οι ίδιοι;
Το OWASP Top 10 δείχνει εδώ και χρόνια ότι οι περισσότερες αδυναμίες στις εφαρμογές ιστού δεν είναι εξωτικές. Η ελλιπής έλεγχος πρόσβασης, το injection και η ανασφαλής διαμόρφωση βρίσκονται πολύ ψηλά. Πρόκειται για σφάλματα που ένα εξασκημένο βλέμμα βρίσκει στον πηγαίο κώδικα, πολύ πριν τα δοκιμάσει ένας επιτιθέμενος.
Προστίθεται ένας πρακτικός λόγος. Πολλές επιχειρήσεις ελέγχουν, ενημερώνουν και σκληραίνουν ούτως ή άλλως αυτή την περίοδο τους διακομιστές τους. Όποιος εξετάζει ταυτόχρονα και τη δική του εφαρμογή, κλείνει το κενό ανάμεσα στη λειτουργία και την ανάπτυξη. Ένας σκληρυμένος διακομιστής με ευάλωτη εφαρμογή παραμένει ευάλωτος, και μια καλογραμμένη εφαρμογή σε PHP χωρίς patch επίσης.
Βασικό review ή review αλλαγής;
Το OWASP Cheat Sheet για το Secure Code Review διακρίνει δύο είδη που αλληλοσυμπληρώνονται στην πράξη:
| Είδος | Πότε | Έκταση | Στόχος |
|---|---|---|---|
| Βασικό review (baseline) | νέο έργο, μεγάλο release, μετά από περιστατικό | ολόκληρο το έργο, ζυγισμένο ανάλογα με τον κίνδυνο | καταγραφή του αποθέματος αδυναμιών |
| Review αλλαγής (diff) | κάθε pull request | μόνο ο κώδικας που άλλαξε | αποτροπή νέων σφαλμάτων |
Ένα βασικό review μετά από ένα περιστατικό είναι ιδιαίτερα πολύτιμο. Όποιος μόλις καθάρισε έναν διακομιστή, πρέπει να γνωρίζει αν η εφαρμογή προσφέρει και άλλα σημεία εισόδου. Το review αλλαγής κρατά την κατάσταση καθαρή στη συνέχεια, επειδή κάθε αλλαγή διαβάζεται πριν τη συγχώνευση και από πλευράς ασφάλειας.
Code review στην PHP: πού συσσωρεύονται τα σφάλματα ασφαλείας
Στα έργα PHP αξίζει μια στοχευμένη ματιά σε ορισμένες συναρτήσεις και μοτίβα. Δεν απαγορεύονται, αλλά κάθε εύρημα αξίζει το ερώτημα αν μπορούν να φτάσουν εκεί ξένα δεδομένα.
| Μοτίβο στον κώδικα | Πιθανός κίνδυνος | Εμβάθυνση |
|---|---|---|
| SQL με συνένωση strings και μεταβλητές | SQL injection | Αποτροπή του SQL injection στην PHP |
unserialize() σε δεδομένα απ' έξω |
Object injection | Ανασφαλής αποσειριοποίηση στην PHP |
include ή require με μεταβλητή διαδρομή |
Ενσωμάτωση ξένων αρχείων | Αποτροπή του Local και Remote File Inclusion |
exec(), system(), shell_exec(), proc_open() |
Εκτέλεση εντολών | Command Injection |
Έξοδος χωρίς htmlspecialchars() |
Cross-Site Scripting | escaping ανάλογα με το πλαίσιο |
== σε tokens ή hashes |
Η μετατροπή τύπων παρακάμπτει ελέγχους | hash_equals(), αυστηρές συγκρίσεις |
eval(), extract() σε εισόδους |
Injection κώδικα ή μεταβλητών | συνήθως διαγραφή χωρίς αντικατάσταση |
Μια γρήγορη πρώτη επισκόπηση επιτυγχάνεται με μια απλή αναζήτηση. Δεν αντικαθιστά ένα review, δείχνει όμως από πού να ξεκινήσετε:
# Σημεία επικίνδυνων συναρτήσεων στον δικό σας κώδικα (εξαιρείται το vendor)
grep -rnE "\b(unserialize|eval|extract|shell_exec|exec|system|passthru|proc_open)\s*\(" src/ app/ 2>/dev/null
Τουλάχιστον εξίσου σημαντικό είναι ό,τι λείπει από τον κώδικα. Ελέγχει κάθε controller αν ο συνδεδεμένος χρήστης επιτρέπεται να δει ή να αλλάξει ακριβώς αυτή την εγγραφή; Περιορίζονται τα uploads ως προς τύπο και θέση αποθήκευσης; Τέτοιες αδυναμίες δεν τις βρίσκει καμία αναζήτηση ονομάτων συναρτήσεων, μόνο η ανάγνωση της ροής.
Εργαλεία που στηρίζουν το review
Η στατική ανάλυση ελέγχει κώδικα χωρίς να τον εκτελεί. Τα PHPStan και Psalm βρίσκουν σφάλματα τύπων, μη προσβάσιμο κώδικα και λανθασμένες παραδοχές για τιμές επιστροφής. Το Psalm προσφέρει επιπλέον taint analysis, που παρακολουθεί αν δεδομένα από αιτήματα ρέουν αδιάκριτα σε κρίσιμα σημεία. Και τα δύο μπορούν να γίνουν σταδιακά αυστηρότερα, ώστε να ξεκινήσουν και παλαιότερα έργα. Μια επισκόπηση δίνει το Στατική ανάλυση: PHPStan και Psalm.
# Στατική ανάλυση στο έργο, ανεβάστε σταδιακά το επίπεδο
vendor/bin/phpstan analyse src --level=5
# Taint analysis με το Psalm
vendor/bin/psalm --taint-analysis
Τα εργαλεία δίνουν υποδείξεις και όχι αποφάσεις. Κάθε εύρημα χρειάζεται αξιολόγηση και μια κενή αναφορά δεν σημαίνει ότι η εφαρμογή είναι ασφαλής.
Εξίσου σημαντικό με την εύρεση είναι η καταγραφή. Κάθε εύρημα πρέπει να καταγράφεται με το σημείο, σύντομη περιγραφή, εκτίμηση του κινδύνου, προτεινόμενη διόρθωση και κατάσταση, κατά προτίμηση απευθείας στο σύστημα tickets της ομάδας. Έτσι γίνεται κατανοητό τι διορθώθηκε, τι έγινε συνειδητά αποδεκτό και τι είναι ακόμη ανοιχτό. Μετά τη διόρθωση αξίζει μια δεύτερη ματιά: Αφαιρέθηκε η αιτία ή μόνο το ένα σύμπτωμα; Εμφανίζεται το ίδιο μοτίβο και σε άλλα σημεία του κώδικα; Ένα σφάλμα που έγινε μία φορά, κατά την εμπειρία σπάνια βρίσκεται μόνο σε ένα σημείο.
Μια λίστα ελέγχου για τη δική σας ομάδα
Για τα reviews αλλαγών έχει αποδειχθεί χρήσιμη μια σύντομη, σταθερή λίστα. Ανήκει στο πρότυπο για τα pull requests:
- Από πού προέρχονται όλα τα δεδομένα που επεξεργάζεται αυτή η αλλαγή και ελέγχονται από την πλευρά του διακομιστή;
- Χτίζονται τα ερωτήματα βάσης δεδομένων αποκλειστικά με placeholders;
- Έχει γίνει escaping κάθε εξόδου για το πλαίσιό της, δηλαδή HTML, attribute, JavaScript ή URL;
- Ελέγχει ο κώδικας το δικαίωμα για ακριβώς αυτό το αντικείμενο και όχι μόνο τη σύνδεση;
- Καταλήγουν κωδικοί, tokens ή προσωπικά δεδομένα σε αρχεία καταγραφής ή μηνύματα σφάλματος;
- Υπάρχουν μυστικά στον κώδικα ή σε αρχεία υπό έλεγχο εκδόσεων;
- Προστέθηκαν νέες εξαρτήσεις και συντηρούνται;
Αφήστε κρίσιμα για την ασφάλεια μέρη όπως η σύνδεση, η διαχείριση δικαιωμάτων, οι διαδικασίες πληρωμής και τα uploads να τα διαβάζει πάντα ένα δεύτερο άτομο που δεν συμμετείχε στον κώδικα. Το ξένο βλέμμα βρίσκει παραδοχές που ο συντάκτης θεωρεί αυτονόητες.
Πώς βοηθά συγκεκριμένα η PHP SOS;
- Πραγματοποιούμε με εξειδικευμένους συνεργάτες ένα βασικό review της εφαρμογής PHP σας, ζυγισμένο ανάλογα με τα μέρη με τον υψηλότερο κίνδυνο.
- Ρυθμίζουμε το PHPStan ή το Psalm ανάλογα με την κατάσταση του έργου σας και γράφουμε τη λίστα ελέγχου για τα pull requests σας.
- Συνδέουμε το review με μια ματιά στον διακομιστή και στη διαμόρφωση, γιατί πολλές ευπάθειες προκύπτουν μόνο από τη συνεργασία.
- Όπου επιθυμείτε έλεγχο από έξω, συμπληρώνουμε το review με έλεγχο ασφαλείας και δοκιμή διείσδυσης.
Συμπέρασμα: Ένα code review είναι το φθηνότερο σημείο για να διορθωθούν σφάλματα ασφαλείας, δηλαδή προτού παραδοθούν. Όποιος ελέγχει κάθε αλλαγή με μια σύντομη λίστα και εξετάζει περιστασιακά πλήρως το έργο, μικραίνει μόνιμα την επιφάνεια επίθεσης.
Συχνές ερωτήσεις
Ποια είναι η διαφορά ανάμεσα σε code review και δοκιμή διείσδυσης;
Ένα code review διαβάζει τον πηγαίο κώδικα και βρίσκει σφάλματα προτού παραδοθούν. Μια δοκιμή διείσδυσης επιτίθεται από έξω στην εκτελούμενη εφαρμογή. Και τα δύο αλληλοσυμπληρώνονται: το review βρίσκει τις αιτίες, η δοκιμή δείχνει τι μπορεί πραγματικά να εκμεταλλευτεί κανείς.
Βρίσκει ένα code review ευπάθειες όπως το PHP2Shell;
Όχι. Το PHP2Shell βρίσκεται στον διερμηνέα PHP και όχι στον κώδικα της εφαρμογής. Απέναντι σε αυτό βοηθά μόνο μια ενημέρωση της PHP με επανεκκίνηση. Ένα review βρίσκει σφάλματα στον δικό σας κώδικα, όπως injection, ελλιπείς ελέγχους δικαιωμάτων ή ανασφαλή αποσειριοποίηση.
Αρκούν το PHPStan ή το Psalm για ένα review ασφαλείας;
Αποτελούν καλή βάση και βρίσκουν αυτόματα πολλά σφάλματα. Λογικά σφάλματα, ελλιπείς ελέγχους δικαιωμάτων και λανθασμένες παραδοχές για τις διαδικασίες τα αναγνωρίζει όμως μόνο ένας άνθρωπος που γνωρίζει τι πρέπει να κάνει η εφαρμογή.
Πόσο διαρκεί ένα code review ασφαλείας;
Εξαρτάται από την έκταση. Ένα review κάθε αλλαγής στο pull request κοστίζει λίγο χρόνο. Ένα πλήρες review ενός έργου που έχει μεγαλώσει με τον καιρό είναι ξεχωριστό εγχείρημα, που περιορίζεται ανάλογα με τον κίνδυνο στα σημαντικότερα μέρη.