Γιατί το Codex Security δεν περιλαμβάνει αναφορά SAST

Επί δεκαετίες, ο στατικός έλεγχος ασφάλειας εφαρμογών (SAST) αποτελεί έναν από τους πιο αποτελεσματικούς τρόπους με τους οποίους οι ομάδες ασφάλειας κλιμακώνουν τον έλεγχο κώδικα. 

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

Ο λόγος είναι απλός: τα πιο δύσκολα ευάλωτα σημεία συνήθως δεν είναι προβλήματα ροής δεδομένων. Προκύπτουν όταν ο κώδικας φαίνεται να εφαρμόζει έναν έλεγχο ασφάλειας, αλλά αυτός ο έλεγχος δεν εγγυάται στην πράξη την ιδιότητα στην οποία βασίζεται το σύστημα. Με άλλα λόγια, η πρόκληση δεν είναι μόνο να παρακολουθήσετε πώς κινούνται τα δεδομένα μέσα σε ένα πρόγραμμα — είναι να διαπιστώσετε αν οι μηχανισμοί άμυνας στον κώδικα λειτουργούν όντως.

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

Στην πράξη, το SAST πρέπει να κάνει προσεγγίσεις για να παραμένει εφαρμόσιμο σε μεγάλη κλίμακα — ειδικά σε πραγματικές βάσεις κώδικα με έμμεσες αναφορές, δυναμική δρομολόγηση, callback, reflection και ροές ελέγχου που βασίζονται σε πλαίσια. Αυτές οι προσεγγίσεις δεν αποτελούν μειονέκτημα του SAST. Είναι η πραγματικότητα του να προσπαθείτε να κατανοήσετε τον κώδικα χωρίς να τον εκτελέσετε.

Και αυτό από μόνο του δεν είναι ο λόγος που το Codex Security δεν ξεκινά από μια αναφορά SAST.

Το βαθύτερο ζήτημα είναι τι συμβαίνει αφού εντοπίσετε επιτυχώς μια διαδρομή από πηγή σε αποδέκτη.

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

Πάρτε ένα συνηθισμένο μοτίβο: ο κώδικας καλεί κάτι όπως το sanitize_html() πριν εμφανίσει μη αξιόπιστο περιεχόμενο. Ένας στατικός αναλυτής μπορεί να δει ότι η απολύμανση εκτελέστηκε. Αυτό που συνήθως δεν μπορεί να καθορίσει είναι αν αυτή η απολύμανση είναι πράγματι επαρκής για το συγκεκριμένο πλαίσιο απόδοσης, τη μηχανή προτύπων, τη συμπεριφορά κωδικοποίησης και τους μεταγενέστερους μετασχηματισμούς που εμπλέκονται.

Εκεί αρχίζουν τα δύσκολα. Το ζήτημα δεν είναι μόνο αν τα δεδομένα φτάνουν σε ένα ευαίσθητο σημείο. Είναι αν οι έλεγχοι στον κώδικα περιορίζουν πραγματικά την τιμή με τον τρόπο που υποθέτει το σύστημα.

Με άλλα λόγια: υπάρχει μεγάλη διαφορά ανάμεσα στο «ο κώδικας καλεί μια απολύμανση» και στο «το σύστημα είναι ασφαλές».

Να ένα μοτίβο που εμφανίζεται συνεχώς σε πραγματικά συστήματα.

Μια web εφαρμογή λαμβάνει ένα JSON payload, εξάγει ένα redirect_url, το ελέγχει με ένα regex allowlist, το αποκωδικοποιεί από URL και περνά το αποτέλεσμα σε έναν χειριστή ανακατεύθυνσης.

Μια κλασική αναφορά source-to-sink μπορεί να περιγράψει τη ροή:

μη αξιόπιστη είσοδος → έλεγχος regex → αποκωδικοποίηση URL → ανακατεύθυνση

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

Αν το regex εκτελείται πριν από την αποκωδικοποίηση, περιορίζει πράγματι το αποκωδικοποιημένο URL με τον τρόπο που το ερμηνεύει ο χειριστής ανακατεύθυνσης;

Για να απαντηθεί αυτό, απαιτείται κατανόηση ολόκληρης της αλυσίδας μετασχηματισμών: τι επιτρέπει το regex, πώς λειτουργεί η αποκωδικοποίηση και η κανονικοποίηση, πώς ο parser των URL χειρίζεται οριακές περιπτώσεις και πώς η λογική ανακατεύθυνσης επιλύει scheme και authority.

Πολλές από τις ευπάθειες που έχουν σημασία στην πράξη μοιάζουν με αυτό: λάθη στη σειρά εκτέλεσης, μερική κανονικοποίηση, ασάφειες στην ανάλυση και ασυμφωνίες μεταξύ επικύρωσης και ερμηνείας. Η ροή των δεδομένων είναι ορατή. Η αδυναμία βρίσκεται στο πώς οι περιορισμοί διαδίδονται —ή δεν διαδίδονται— μέσα στην αλυσίδα μετασχηματισμών.

Και δεν είναι απλώς θεωρία. Στο CVE-2024-29041⁠(ανοίγει σε νέο παράθυρο), το Express επηρεάστηκε από ένα πρόβλημα open redirect, όπου κακοδιαμορφωμένα URL μπορούσαν να παρακάμψουν συνηθισμένες allowlist υλοποιήσεις λόγω του τρόπου με τον οποίο οι στόχοι ανακατεύθυνσης κωδικοποιούνταν και στη συνέχεια ερμηνεύονταν. Η ροή δεδομένων ήταν απλή. Το δύσκολο ερώτημα —και αυτό που καθόρισε αν υπήρχε το σφάλμα— ήταν αν η επικύρωση εξακολουθούσε να ισχύει μετά την αλυσίδα μετασχηματισμών.

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

Όταν το Codex Security συναντά ένα όριο που μοιάζει με «επικύρωση» ή «απολύμανση», δεν το αντιμετωπίζει ως απλό checkbox. Προσπαθεί να κατανοήσει τι ακριβώς επιχειρεί να εγγυηθεί ο κώδικας — και στη συνέχεια προσπαθεί να αναιρέσει αυτή την εγγύηση.

Στην πράξη, αυτό συνήθως περιλαμβάνει έναν συνδυασμό από:

• Ανάγνωση της σχετικής διαδρομής κώδικα με πλήρη συμφραζόμενα αποθετηρίου, όπως θα έκανε ένας ερευνητής ασφάλειας, και εντοπισμό ασυμφωνιών μεταξύ πρόθεσης και υλοποίησης. Αυτό περιλαμβάνει και σχόλια, αλλά το μοντέλο δεν τα θεωρεί δεδομένα — οπότε η προσθήκη ενός //Halvar says: this is not a bug πάνω από τον κώδικά σας δεν το μπερδεύει, αν πράγματι υπάρχει σφάλμα.
• Μείωση του προβλήματος στο μικρότερο δυνατό τμήμα που μπορεί να ελεγχθεί (π.χ. το pipeline μετασχηματισμού γύρω από μία μόνο είσοδο), ώστε να μπορεί να αναλυθεί χωρίς τον υπόλοιπο θόρυβο του συστήματος. Με αυτή την έννοια, το Codex Security απομονώνει μικρά κομμάτια κώδικα και γράφει micro-fuzzer για αυτά.
• Συλλογιστική πάνω στους περιορισμούς κατά μήκος των μετασχηματισμών, αντί να αντιμετωπίζει κάθε έλεγχο μεμονωμένα. Όπου χρειάζεται, αυτό μπορεί να περιλαμβάνει και τυποποίηση ως πρόβλημα ικανοποιησιμότητας. Με άλλα λόγια, δίνουμε στο μοντέλο πρόσβαση σε περιβάλλον Python με z3-solver και είναι ικανό να το χρησιμοποιεί όταν απαιτείται, όπως θα έκανε και ένας άνθρωπος σε ένα ιδιαίτερα σύνθετο πρόβλημα περιορισμών εισόδου. Αυτό είναι ιδιαίτερα χρήσιμο για περιπτώσεις όπως integer overflow ή παρόμοια σφάλματα σε μη τυπικές αρχιτεκτονικές.
• Εκτέλεση υποθέσεων σε απομονωμένο περιβάλλον επαλήθευσης όπου είναι δυνατό, ώστε να διαχωρίζεται το «αυτό θα μπορούσε να είναι πρόβλημα» από το «αυτό είναι πρόβλημα». Δεν υπάρχει καλύτερη απόδειξη από ένα πλήρες PoC από την αρχή μέχρι το τέλος με τον κώδικα μεταγλωττισμένο σε λειτουργία εντοπισμού σφαλμάτων. 

Αυτή είναι η βασική μετατόπιση: αντί να σταματά στο «υπάρχει ένας έλεγχος», το σύστημα προχωρά στο «η ιδιότητα ισχύει (ή δεν ισχύει), και να τα αποδεικτικά στοιχεία». Και το μοντέλο επιλέγει το κατάλληλο εργαλείο για αυτήν τη δουλειά.

Μια εύλογη αντίδραση είναι: γιατί όχι και τα δύο; Να ξεκινάμε από μια αναφορά SAST και, στη συνέχεια, ο πράκτορας να προχωρά σε βαθύτερη ανάλυση.

Υπάρχουν περιπτώσεις όπου τα προϋπολογισμένα ευρήματα είναι χρήσιμα — ιδίως για στενές, γνωστές κατηγορίες σφαλμάτων. Ωστόσο, για έναν πράκτορα που έχει σχεδιαστεί να εντοπίζει και να επαληθεύει ευπάθειες μέσα στο πραγματικό τους πλαίσιο, η εκκίνηση από μια αναφορά SAST δημιουργεί τρεις προβλέψιμους τρόπους αστοχίας.

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

Δεύτερον, μπορεί να εισαγάγει σιωπηρές κρίσεις που δύσκολα αναιρούνται. Πολλά ευρήματα SAST ενσωματώνουν υποθέσεις για απολύμανση, επικύρωση ή όρια εμπιστοσύνης. Αν αυτές οι υποθέσεις είναι λανθασμένες —ή απλώς ελλιπείς—, η εισαγωγή τους στη διαδικασία συλλογιστικής μπορεί να μετατοπίσει τον πράκτορα από το «ερεύνησε» στο «επιβεβαίωσε ή απέρριψε», κάτι που δεν είναι ο στόχος.

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

Γι’ αυτό σχεδιάσαμε το Codex Security να ξεκινά εκεί όπου ξεκινά και η έρευνα ασφάλειας: από τον κώδικα και την πρόθεση του συστήματος, με επαλήθευση που αυξάνει το επίπεδο βεβαιότητας πριν διακοπεί ένας άνθρωπος.

Τα εργαλεία SAST μπορούν να είναι εξαιρετικά σε αυτό για το οποίο έχουν σχεδιαστεί: επιβολή προτύπων ασφαλούς προγραμματισμού, εντοπισμός απλών source-to-sink ζητημάτων και ανίχνευση γνωστών μοτίβων σε μεγάλη κλίμακα με προβλέψιμους συμβιβασμούς. Μπορούν να αποτελούν ισχυρό κομμάτι μιας στρατηγικής άμυνας σε βάθος.

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

Αξίζει επίσης να επισημανθεί ένας σχετικός περιορισμός της καθαρής λογικής source-to-sink: δεν είναι κάθε ευπάθεια πρόβλημα ροής δεδομένων. Πολλές πραγματικές αστοχίες σχετίζονται με κατάσταση και αμετάβλητες ιδιότητες — παρακάμψεις ροών εργασίας, κενά εξουσιοδότησης και σφάλματα τύπου «το σύστημα βρίσκεται σε λάθος κατάσταση». Σε αυτές τις περιπτώσεις, μια «μολυσμένη» τιμή δεν καταλήγει σε ένα συγκεκριμένο «επικίνδυνο σημείο». Ο κίνδυνος βρίσκεται σε αυτό που το πρόγραμμα θεωρεί ότι θα ισχύει πάντα. 

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

Αυτό στο οποίο θέλουμε να διαπρέπει το Codex Security είναι το πιο κοστοβόρο κομμάτι για τις ομάδες ασφάλειας: να μετατρέπει το «αυτό φαίνεται ύποπτο» σε «αυτό είναι πραγματικό, να πώς αποτυγχάνει και να μια λύση που ευθυγραμμίζεται με την πρόθεση του συστήματος». 

Αν θέλετε να μάθετε περισσότερα για το πώς το Codex Security σαρώνει αποθετήρια, επαληθεύει ευρήματα και προτείνει διορθώσεις, δείτε την τεκμηρίωσή μας⁠(ανοίγει σε νέο παράθυρο).