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, αν πιστεύετε οτι μου διέφυγε κάτι αφήστε ένα σχόλιο

Φυσικά αυτά είναι τα ομορφότερα προβλήματα που μπορείτε να συναντήσετε σαν publisher, χωρίς αυτό να σημαίνει οτι δέν πρέπει να είμαστε προετοιμασμένοι. Παρακάτω σας περιγράφω κάποιες λύσεις που δούλεψαν για εμάς και εύχομαι να σας χρειαστούν

Apache optimization

Καταρχήν είναι πολύ σημαντικό να είναι σωστά configured ο web server σας. Στην περίπτωση που είστε σε shared hosting μάλλον δέν σας ενδιαφέρει, ωστόσο αν έχετε dedicated server μπορείτε να χρησιμοποιήσετε κάποια απο τις testing εφαρμογές για Apache που μπορούν να σας βοηθήσουν με το σωστό configuration του server.

Static vs Dynamic content

Ας δούμε λίγο πώς σερβίρει ένας web server μία σελίδα, και πιό συγκεκριμένα ο Apache. Όταν ζητάμε μία σελίδα, ουσιαστικά κάνουμε ένα request για κάθε αντικείμενο αυτής (html, τα css, τις εικόνες, κτλ) Για κάθε request ο server απασχολεί ένα process το οποίο ασχολείται με το “σερβίρισμα”. Όταν κάποιο process τελιώσει, τότε περιμένει κάποιο διάστημα, και αν δέν του ζητηθεί κάποια άλλη σελίδα τότε “πεθαίνει”.

Μέχρι εδώ όλα καλά, ωστόσο σε ένα site με μεγάλο load, υπάρχει ένα σημαντικό πρόβλημα. Ας υποθέσουμε οτι ένα process σερβίρει μία δυναμική σελίδα. Ενδεχομένως να χρησιμοποιηθούν 30mb μνήμης απο το script που παράγει την σελίδα. Όταν τελειώσει το parsing, το process δέν θα ελευθερώσει την μνήμη και ακόμα αν στο επόμενο request σερβίρει μιά εικόνα θα χρησιμοποιεί πάλι 30mb μνήμης. Σε ένα φυσιολογικό server αυτό δέν είναι πρόβλημα ωστόσο σε ένα απαιτητικό περιβάλλον δέν μπορούμε να σπαταλάμε μνήμη. Συμπληρωματικά πολλές βασικές διεργασίες του κάθε request δέν χρειάζονται για το σερβίρισμα στατικού περιεχομένου οπότε πάλι υπάρχει σπατάλη πόρων του συστήματος.

Η λύση που ανακάλυψα σε αυτό το πρόβλημα είναι η εξής. Χρησιμοποιούμε ένα web server για δυναμικό περιεχόμενο και έναν για στατικό. Έτσι – και στο ίδιο μηχάνημα – μπορούμε να βάλουμε έναν Apache με mod_rewrite, logging και ότι άλλο θέλουμε, και σε μιά άλλη ip βάζουμε έναν lighttpd με απενεργοποιημένα όλα τα modules για να σερβίρει το στατικό περιεχόμενο. Φυσικά αν όλο αυτό σας φαίνεται δύσκολο μπορείτε απλώς να χρησιμοποιήσετε μια υπηρεσία σαν το amazon ec2 για να κάνετε hosting το στατικό περιεχόμενο

Η συγκεκριμένη λύση βοήθησε το webdigity να αντέξει ένα digg/stumbleupon/reddit κύμα που δέχτηκε με 1600 online visitors χωρίς κανένα πρόβλημα (ενώ παλιότερα έτρεχα με τα restart)

MySQL

Στην MySQL όπως και σε κάθε server το πιό βασικό είναι το configuration. Ένα πολύ καλό εργαλείο που μπορεί να σας βοηθήσει είναι το MySQLTuner το οποίο βοηθάει στο στήσιμο του server. Παράλληλα κάτι που πρέπει οπωσδήποτε να βλέπετε είναι τα queries που καθυστερούν με το slow query log. Όσο αφορά τα queries το πιό βασικό που πρέπει να σας πώ είναι να αποφεύγετε τα RAND() και να χρησιμοποιείτε οπωσδήποτε την LIMIT.

PHP opcode caching

Το opcode caching μπορεί να κάνει την php πολλές φορές πιό γρήγορη και το συνιστώ ανεπιφύλαχτα. Υπάρχουν διάφορες λύσεις για opcode caching. Εγώ θα σας προτείνω την XCache που είναι stable και φυσικά open source

PHP data caching

Για να “ξεκουράζουμε” τον database server καλό είναι να κάνουμε και ένα caching των δεδομένων σε επίπεδο εφαρμογής. Αυτό μπορεί να γίνει σε αρχεία στο file system (δείτε ένα tutorial που έγραψα παλιότερα) ή με την χρήση του memcached.

Αυτά τα λίγα για server optimisation, ελπίζω να σας άρεσε το άρθρο

[photo credit]

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

Αρχικά πρέπει να πούμε κάποια πράγματα γενικά. Το θέμα “ασφάλεια” είναι κάτι πολύ υποκειμενικό και ποτέ δέν υπάρχει 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 που μπορεί να μας βοηθήσει.

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

Το παρακάτω παράδειγμα είναι για wordpress, ωστόσο είναι πολύ εύκολο να το προσαρμόσετε σε οποιοδήποτε CMS. Λοιπόν έχουμε και λέμε:

Ανοίξτε απο τον κατάλογο με το θέμα που χρησιμοποιείτε (/wp-content/themes/…) το αρχείο single.php. Εκεί που θέλετε να προστεθεί ο κώδικας για το twitter προσθέστε τα παρακάτω:

<?php
$twit = get_the_title();
$turl = file_get_contents('http://th8.us/api.php?url=' . urlencode(get_permalink()));
if ( (strlen(utf8_decode($twit)) + strlen($turl)) > 139 )
substr($twit, 0, (136 - strlen($turl))) . '... ' . $turl ;
else
$twit .= ' ' . $turl;
echo '<a href="http://twitter.com/home?status=', $twit , '">Twitter</a>';
?>

Update : Δέν δουλεύει σωστά με ελληνικά URL. Το διορθώνω

Update: Τώρα δουλεύει άψογα. Απ’ότι φένεται το tinyurl έχει πρόβλημα οπότε χρησιμοποίησα άλλη υπηρεσία

Happy twitting