Register_Globals

Θα ξεκινήσουμε με κάτι απλό που έχει ειπωθεί αρκετές φορές – μια και που είναι αρκετά παλιά “τρύπα” – το register globals. Το register_globals είναι ένα directive στο php.ini το οποίο κάνει register ως μεταβλητές οτιδήποτε υπάρχει στο $_COOKIE, το $_SESSION, το $_POST και το $_GET. Με άλλα λόγια αν για παράδειγμα κάποιος καλέσει ένα url και προσθέσει στο τέλος “?a=1″, μέσα στην εφαρμογή θα υπάρχει η μεταβλητή $a που θα έχει τιμή 1.

Με μια πρώτη ματιά δέν φαίνεται να υπάρχει πρόβλημα, ωστόσο φανταστείτε τί μπορεί να γίνει στο παρακάτω παράδειγμα αν ο χρήστης έχει προσθέσει στο url το εξής: “?admin=1″

if ( isset( $_SESSION['admin']) && $_POST['security_code'] == '12345' ){
$admin = true;
}

eval

Η eval() είναι μια function που εξ’ορισμού θέλει πολύ προσοχή αφού η λάθος χρήση της μπορεί να επιτρέψει σε κάποιον να τρέξει οτιδήποτε στον server μας. Το σημαντικό είναι να μήν χρησιμοποιούμε ποτέ δεδομένα απο τον χρήστη($_POST, $_GET) μέσα στην eval() ή αν το κάνουμε αυτό τουλάχιστον να είμαστε σίγουροι πως ο χρήστης δέν μπορεί να “βγεί” απο την εντολή που θέλουμε (αυτό κυρίως γίνεται με την εισαγωγή ενός ελληνικού ερωτηματικού)

Remote file inclusion

Ακόμα ένα σημαντικό θέμα είναι το remote file inclusion. Στα περισσότερα default setup της php είναι ενεργοποιημένο, και αυτό που κάνει είναι να επιτρέπει να κάνουμε include scripts απο άλλους servers. Για το συγκεκριμένο vurnerability έχουν γραφτεί αρκετά exploits τα οποία μπορούν να δώσουν full access στον server. Για να σιγουρευτείτε οτι δέν έχετε πρόβλημα πρέπει αφενός να μήν χρησιμοποιείτε ποτέ στην include δεδομένα που σας δίνει ο χρήστης (αυτό είναι γενικά πρόβλημα, όχι μόνο για τα remote file inclusions) ενώ παράλληλα φροντίστε στο php.ini το directive allow_url_include να είναι Off.

Session fixation

Το session fixation είναι ένα σχετικά χαμηλού ρίσκου vurnerability, το οποίο ουσιαστικά επιτρέπει σε κάποιον “κακόβουλο” να πάρει πρόσβαση με τα στοιχεία κάποιου χρήστη της εφαρμογής μας. Για το συγκεκριμένο θέμα μπορούμε να κάνουμε δύο κινήσεις. Το πρώτο να έχουμε διαφορετικά path για τα session ανα domain (αλλάζοντας το session.save_path στο htaccess του κάθε site) και το δεύτερο είναι το να χρησιμοποιούμε συχνά μέσα στην εφαρμογή μας την εντολή session_regenerate_id(). Βέβαια η απόλυτη λύση – η οποία βοηθάει γενικότερα – είναι το να έχουμε custom session handler, ωστόσο αυτό είναι κάπως advanced θέμα.

Error reporting

Ένα απλό αλλα εξίσου σημαντικό θέμα είναι πως στον production server πρέπει να μήν εμφανίζονται τα λάθη της php γιατί εφόσον εμφανίζονται κάνουμε την ζωή του hacker πολύ πιο εύκολη . Ο τρόπος να το λύσουμε αυτό είναι απλά να αλλάξουμε το directive display_errors σε Off. Φυσικά για να μπορούμε να παρακολουθούμε τα προβλήματα που έχει η εφαρμογή μας σε production περιβάλλον μπορούμε να χρησιμοποιήσουμε log files (directive: log_errors) ή ακόμα και να δημιουργήσουμε custom error handlers.


PhP Security scripts

Για το τέλος άφησα μερικά scripts που έχω ανακαλύψει και μπορούν να σας βοηθήσουν στο να ανακαλύπτετε security προβλήματα με τις εφαρμογές σας.

• PhpSecInfo
• PHP Security Scanner
• Spike PHP Security Audit Tool

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

1. /wp-includes/post.php
2. /wp-includes/version.php
3. /wp-includes/feed.php
4. /xmlrpc.php
5. /wp-admin/users.php

Οπότε τρεχάτε ποδαράκια μου πρίν βγεί το επόμενο exploit

Γενικά περι ασφάλειας

Αρχικά πρέπει να πούμε κάποια πράγματα γενικά. Το θέμα “ασφάλεια” είναι κάτι πολύ υποκειμενικό και ποτέ δέν υπάρχει 100% διασφάλιση. Για να λέμε τα πράγματα όπως έχουν, είναι γεγονός πως σε γενικές γραμμές άν κάποιος σε βάλει στο μάτι συνήθως είναι εφικτό να προσπεράσει οποιαδήποτε δικλείδα ασφαλείας και αν έχουμε θέσει.

Αυτό μπορεί να συμβαίνει για πολλούς λόγους. Θα προσπεράσω τους λόγους όπως πχ. οτι έχουμε παλιό software (web servers, database servers, κτλ) και θα εστιάσω καθαρά στο θέμα του web developer:

1. Όσο καλός web developer και άν είναι κάποιος – και βάζω και τον εαυτό μου στην λίστα – σίγουρα δέν είναι ειδικός ασφαλείας πληροφοριακών συστημάτων.
2. Προσθέτουμε στο παραπάνω οτι κανείς php developer δέν γνωρίζει επ’ ακριβώς πώς δουλεύει εσωτερικά η php, μιά και που δέν είναι αυτη η δουλειά του. Αυτό ωστόσο μπορεί να δημιουργήσει προβλήματα.
3. Οι ανάγκες και οι προθεσμίες που θέτουν οι πελάτες ποτέ δέν λαμβάνουν υπ’όψιν τον παράγοντα “ασφάλεια” και εδώ ίσως φταίμε που δέν ενημερώνουμε σωστά τους πελάτες μας.

Προσωπικά έχω αντιμετωπίσει πολλές φορές προβλήματα ασφαλείας, και μάλιστα πρόσφατα πέσαμε θύμα ενός απο τα μεγαλύτερα botnets το οποίο ακόμα δέν είμαι σίγουρος αν έχουμε αντιμετωπίσει επαρκώς. Αυτό κυρίως γιατί το συγκεκριμένο botnet μπορεί να χρησιμοποιήσει με αυτόματο τρόπο πολλαπλά exploits και ουσιαστικά δέν ξέρεις απο πού έρχεται το πρόβλημα κάθε φορά. Αυτή την φορά την “πατήσαμε” γιατί απλούστατα όπως και σε κάθε server και στον δικό μας υπήρχαν μή ενημερωμένα software. Πάμε όμως να δούμε κάποια πράγματα που πρέπει να γνωρίζουμε όταν γράφουμε εφαρμογές σε Php και τα πιό απλά – αλλά και πιό συνηθησμένα – προβλήματα ασφαλείας που μπορεί να προκύψουν.

SQL Injection attack

To SQL injection θεωρείται ίσως ως ο πιό απλός τρόπος για να hackέψεις ένα site και γενικά οι περισσότεροι developers – αν όχι όλοι – το γνωρίζουν. Ωστόσο γνωρίζατε οτι μια εντολή σαν την addslashes() δέν είναι αρκετή για να μας σώσει;

Προτού συνεχίσουμε να εξηγήσουμε λίγο τί είναι το SQL injection. To σενάριο είναι το εξής:

• Η εφαρμογή χρησιμοποιεί κάποια $_GET ή $_POST μεταβλητή για να λάβει δεδομένα απο τον SQL server (mysql, oracle, sybase, κτλ)
• Ο επιτηθέμενος την “πειράζει” ωστε να αλλάξει το query ή να τρέξει και κάποιο άλλο query (στην mysql γίνεται κυρίως με UNION() )

Δέν θα επεκταθώ στο πώς γίνεται μια και που το google μπορεί να σας δώσει όλες τις απαραίτητες πληροφορίες

Το ουσιαστικό με αυτή την μορφή επίθεσης είναι οτι πρέπει ουσιαστικά να μήν επιτρέπουμε τον χαρακτήρα quote (‘) να μπεί σε ένα query απο τον χρήστη. Για αυτό οι περισσότεροι developers χρησιμοποιούν την addslashes() η οποία με τις κατάλληλες συνθήκες μπορεί να προσπεραστεί….

Για αυτό πρέπει να χρησιμοποιούμε την mysql_real_escape_string()

File system attacks

Μιά άλλη κλασσική μέθοδος είναι τα remote includes. Για παράδειγμα έχουμε τον παρακάτω κώδικα:

<?php

include $_GET['action'];

?>

Αυτό που ενδεχομένως δέν γνωρίζουμε, είναι πως ο επιτηθέμενος μπορει στο $_GET['action'] να δώσει ένα url (πχ. απο ένα file browser script) και να πάρει full access στο μηχάνημα, ή έστω στο directory του site μας εφόσον παίζουμε σε safe_mode

Η σωστή έκδοση για το παραπάνω θα ήταν :

<?php

include '/some/path/' . $_GET['action'] . '.php';

?>

ή ακόμα καλύτερα :

<?php

switch ( $_GET['action'] ){

case 'x' : include 'x.php'; break;

case 'y' : include 'y.php'; break;

....

}

?>

XSS attacks

To XSS ή αλλιώς cross site scripting, είναι η τεχνική κατα την οποία ο χρήστης βάζει κάποιο – javascript συνήθως – html σε δεδομένα που εμείς θα εμφανίσουμε αργότερα στο site. Ένα απο τα χαρακτηριστηκότερα παραδείγματα ήταν όταν στο myspace καταφέραν κάποιοι να φορτώσουν σε αρκετά profiles ένα flash το οποίο χρησιμοποιόντας το session του επισκέπτη του profile έκανε κάποια πράγματα στο myspace (πχ. έστελνε ένα shout σε όλους τους φίλους σου)

Για να αποφύγουμε κάτι τέτοιο καλό είναι να μετατρέπουμε ότι δεδομένα μας δίνει ο χρήστης με την function htmlentities()

Πώς να έχουμε το κεφάλι μας ήσυχο

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

1. Κάνουμε subscribe στα releases απο τα open source software που χρησιμοποιούμε. Είναι γνωστό οτι δημοφηλή projects όπως το wordpress, το joomla και άλλα, βγάζουν ενημερώσεις ασφαλείας πολύ συχνά. Σε αυτές τις περιπτώσεις επειδή είναι συχνά τα μαζικά exploits, η άμεση ενημέρωση είναι αναγκαία.
2. Ενημερωνόμαστε απο κοινότητες που ασχολούνται με την ασφάλεια πληροφοριακών συστημάτων.
3. Σκανάρουμε τις εφαρμογές μας πρίν τις βγάλουμε στον αέρα.
4. Χρησιμοποιούμε κάποιο module που μπορεί να μας βοηθήσει.

Ξέχασα κάτι; Αν ναί μήν διστάζετε να αφήσετε ένα σχόλιο. Καλώς η κακώς η ασφάλεια είναι κάτι που πρέπει να κοιτάξουμε ώς κλάδος και όχι μεμονομένα. Ελπίζω το σημερινό άρθρο – αν και διαφορετικό απο τα συνηθησμένα – να σας άρεσε.