nsterg Δημοσ. 9 Οκτωβρίου 2011 Δημοσ. 9 Οκτωβρίου 2011 Παιδιά καλημέρα! Θέλω να αναπτύξω ένα web application (e-shop τύπου) και ψάχνω την πιο κατάλληλη τεχνολογία. Γενικά έχω κάποια εμπειρία με asp.net (c#) αλλά δεν έχω πρόβλημα να ασχοληθώ και με php. Αυτό που κυρίως με απασχολεί είναι το θέμα της ασφάλειας. O Apache σε Linux μηχάνημα σίγουρα υπερέχει έναντι των "ευάλωττων" windows. Παρόλαυτα η Micrososft έχει κάνει σημαντικές προόδους σε αυτό το θέμα με τις νέες εκδόσεις Windows Server και IIS. Εσείς τι θα συμβουλεύατε;
defacer Δημοσ. 9 Οκτωβρίου 2011 Δημοσ. 9 Οκτωβρίου 2011 Κατ' αρχήν δεν καταλαβαίνω γιατί στα Windows το έδεσες κόμπο ότι θα παίξεις με IIS (υπάρχει και Apache) και ότι, αν όντως πας σε IIS, θα χρησιμοποιήσεις ASP.NET (υπάρχει και PHP). Το βλέπεις το θέμα τελείως ανάποδα: εσύ επιλέγεις σε τι γλώσσα θα γράψεις, και σε πολύ δεύτερο χρόνο σε τι θα κάνεις host (αν υπάρχει επιλογή για τη συγκεκριμένη γλώσσα). Άσε που αν δώσεις την εφαρμογή παραέξω δε θα είναι και στο χέρι σου σε τι θα γίνει host. Τέλος, αυτά τα γραφικά περι "ευάλωτων" Windows και apache που "σίγουρα υπερέχει" δε μπορώ να φανταστώ που τα βασίζεις. Όταν (αν) σε κάνουν hack δε θα φταίει ο web server, ούτε το λειτουργικό. Η δική σου εφαρμογή θα φταίει.
_tasos Δημοσ. 9 Οκτωβρίου 2011 Δημοσ. 9 Οκτωβρίου 2011 Προτίμησε την τεχνολογία με την οποία μπορείς να δουλέψεις πιο παραγωγικά. Το eshop που θέλεις να φτιάξεις είναι κάτι που θα πουλήσεις ή είναι κάποια άσκηση / προσωπικό project; Ο defacer έχει δίκιο στο θέμα security. Όταν συμβαίνει κάποιο hack φταίει κατά πάσα πιθανότητα κάποιος κώδικας ή κάποιο κακό configuration του web server. Ο IIS τρέχει σε Windows Server (μιλάω για web servers), και δεν έχει καμία σχέση με XP / Vista / 7 όσο αφορά το θέμα security.
terminal_hell Δημοσ. 9 Οκτωβρίου 2011 Δημοσ. 9 Οκτωβρίου 2011 O IIS απο την εκδοση 6.0 και μετα, δηλαδη απο τα Windows Server 2003 και μετα, ειναι εξαιρετικα ασφαλης και ειναι πολυ λιγα τα bugs που εχουν βρεθει. Εχουν περασει οι εποχες που ειχαμε remote command execution σε NT4.0 Server (IIS4) με τα unicode exploits. Πανε αυτα... Btw, IIS εχουν και τα XP, και τα Vista/7. Χωρις ολες τις δυνατοτητες ομως του πακετου που υπαρχει στις Server εκδοσεις... O apache επισης εχει βελτιωθει στο θεμα της ασφαλειας και γενικως ειναι μια σταθερη επιλογη των admins. Bugs ανακαλυπτονται διαρκως, αλλα διορθωνονται γρηγορα. Γενικως η ασφαλεια του Server εξαρταται κατα κυριο λογο απο τον ανθρωπινο παραγοντα. Ο ανθρωπος ειναι ο αδυναμος κρικος, και οχι o web server. Αν ο ανθρωπος ενδιαφερεται για την ασφαλεια, θα κραταει και τον server ασφαλη. Τωρα αν πεσεις σε κανα 0day exploit πριν βγει το patch (αν μιλαμε για win) ή η νεα εκδοση (αν μιλαμε για linux), εκει ειναι στο προγραμμα να σε χακαρουν... Και υπαρχει και το μερος την ιδιας της εφαρμογης το οποιο οπως ειπε ο defacer μπορει να οδηγησει σε hack. Οποτε και εδω ο ανθρωπος ειναι παλι ο αδυναμος κρικος και οχι η εφαρμογη απο μονη της. Οποτε, οτι και να διαλεξεις να προσεχεις των κωδικα σου...
παπι Δημοσ. 9 Οκτωβρίου 2011 Δημοσ. 9 Οκτωβρίου 2011 Τι exploit μπορει να εχει ενας web server; Ενα socket που ακουει σε port 80 δεν ειναι;
thanocaster Δημοσ. 9 Οκτωβρίου 2011 Δημοσ. 9 Οκτωβρίου 2011 Προτίμησε την τεχνολογία με την οποία μπορείς να δουλέψεις πιο παραγωγικά. Αυτό ακριβώς. Εάν υπάρχει κάποια διαφορά στην ασφάλεια, το κέρδος που θα έχεις διαλέγοντας την πιο ασφαλή πλατφόρμα θα είναι ανάξιο αναφοράς μπροστά στο κέρδος που θα έχεις δουλεύοντας σε ένα περιβάλλον το οποίο γνωρίζεις καλύτερα και δουλεύεις πιο άνετα.
_tasos Δημοσ. 10 Οκτωβρίου 2011 Δημοσ. 10 Οκτωβρίου 2011 Τι exploit μπορει να εχει ενας web server; Ενα socket που ακουει σε port 80 δεν ειναι; Αν ένας web server σέρβιρε μόνο στατικό περιεχόμενο τότε τα πράγματα θα ήταν τόσο απλά όσο λες. Θα κινδύνευε μόνο με DOS attacks. Όμως, τα περισσότερα exploits γίνονται επειδή υπάρχουν κενά σε επίπεδο εφαρμογής, τόσο του web server, αλλά και (κυρίως) του κώδικα (php, asp.net, κτλ) που βρίσκεται σε αυτόν. Ένα πολύ απλό παράδειγμα είναι το sql injection. Γενικά πάντως, παραδείγματα υπάρχουν πολλά κ αν ανοίξει η κουβέντα, δεν θα κλείσει...
defacer Δημοσ. 10 Οκτωβρίου 2011 Δημοσ. 10 Οκτωβρίου 2011 Τι exploit μπορει να εχει ενας web server; Ενα socket που ακουει σε port 80 δεν ειναι; Με την ίδια λογική κανένα πρόγραμμα ή λειτουργικό δε θα έπρεπε να έχει remote exploit. Ένα socket δεν είναι; Αν ένας web server σέρβιρε μόνο στατικό περιεχόμενο τότε τα πράγματα θα ήταν τόσο απλά όσο λες. Θα κινδύνευε μόνο με DOS attacks. Όμως, τα περισσότερα exploits γίνονται επειδή υπάρχουν κενά σε επίπεδο εφαρμογής, τόσο του web server, αλλά και (κυρίως) του κώδικα (php, asp.net, κτλ) που βρίσκεται σε αυτόν. Ένα πολύ απλό παράδειγμα είναι το sql injection. Γενικά πάντως, παραδείγματα υπάρχουν πολλά κ αν ανοίξει η κουβέντα, δεν θα κλείσει... Το SQL injection δεν έχει καμία σχέση με τα exploit για τα οποία συζητάμε (των web servers/OS), γιατί δεν βασίζεται σε συμπεριφορά που ο κατασκευαστής του software δεν έχει λάβει υπόψη. Βασίζεται στην άγνοια κάποιων που έχει σαν αποτέλεσμα το να μπορέσει κάποιος τρίτος να χρησιμοποιήσει γνωστή συμπεριφορά χωρίς ο server admin να το θέλει. Τώρα σαν παράδειγμα για το παπί και σαν αντιπαράδειγμα γι' αυτό που λες με το στατικό περιεχόμενο: Σύμφωνα με το RFC του HTTP, δεν υπάρχει μέγιστο όριο για "σωστές" URL σε μία GET request. Παρόλα αυτά κανένα πρόγραμμα (web server) όταν διαβάζει από το TCP stream δε μπορεί να συνεχίσει να διαβάζει επ' άπειρο μέχρι να βρει το newline που σηματοδοτεί το τέλος του URL (αν το κάνεις έτσι ορίστε ήδη ένα denial of service vulnerability). Επομένως κάπου πρέπει να αποθηκεύεις αυτά που διαβάζεις μέχρι να αποφασίσεις ότι το URL τελείωσε (θεωρώ ότι το URL το δίνει ο attacker οπότε δεν θα τελειώσει από μόνο του...). Εδώ έρχεται το γνωστό γραφικό από φοιτητικές εργασίες >char url[1000]; Οπότε ανάλογα με το πόσο προσεκτικός (δεν) είσαι, αν αντιγράφεις στο buffer χωρίς να μετράς πόσο αντέγραψες έχουμε ένα υπέροχο stack overflow, το οποίο ανάλογα την κατάσταση μπορεί να γίνει arbitrary code execution, κλπ κλπ. Και όχι απλά δε σερβίραμε content, ούτε την πρώτη γραμμή από το ΗTTP request δε διαβάσαμε ακόμα.
nsterg Δημοσ. 10 Οκτωβρίου 2011 Μέλος Δημοσ. 10 Οκτωβρίου 2011 Παιδιά ευχαριστώ για τα posts. Κατάλαβα ότι το ευάλωττο σημείο είναι ο κώδικας και όχι τόσο το λειτουργικό ή ο web server. Έχω επιλέξει να χρησιμοποποιήσω ASP.net (C#) με SQL Server. Θα είναι ένα e-shop για λογαριασμό ενός φίλου. Εδώ είναι ένα χρήσιμο tutorial, που περιγράφει πιθανά hacks με SQL injections κλπ. http://en.csharp-online.net/ASP.NET_Security_Hacks
defacer Δημοσ. 10 Οκτωβρίου 2011 Δημοσ. 10 Οκτωβρίου 2011 Παιδιά ευχαριστώ για τα posts. Κατάλαβα ότι το ευάλωττο σημείο είναι ο κώδικας και όχι τόσο το λειτουργικό ή ο web server. Έχω επιλέξει να χρησιμοποποιήσω ASP.net (C#) με SQL Server. Θα είναι ένα e-shop για λογαριασμό ενός φίλου. Εδώ είναι ένα χρήσιμο tutorial, που περιγράφει πιθανά hacks με SQL injections κλπ. http://en.csharp-online.net/ASP.NET_Security_Hacks Μην το πάρεις στραβά αυτό που θα πω, αλλά νομίζω δεν είσαι ακόμα έτοιμος να γράψεις e-shop. Αν δεν ξέρεις τι είναι SQL injection, XSS και CSRF τόσο καλά που να μπορείς να τα εξηγήσεις στον ύπνο σου και να απαριθμήσεις αρκετά διαφορετικά παραδείγματα για την κάθε περίπτωση, μάθε πρώτα πάνω σε πιο ακίνδυνα projects και μετά.
terminal_hell Δημοσ. 10 Οκτωβρίου 2011 Δημοσ. 10 Οκτωβρίου 2011 Και όχι απλά δε σερβίραμε content, ούτε την πρώτη γραμμή από το ΗTTP request δε διαβάσαμε ακόμα. Μιλωντας για HTTP requests, υπαρχουν επισης τα PUT και DELETE, τα οποια εχω δει να επιτρεπονται (σε κακοστημενους IIS φυσικα) και με τα οποια το dfc ειναι υποθεση ενος λεπτου... Απλα ανοιγεις putty και στελνεις ενα PUT request... >PUT /index.html HTTP/1.0 . . . . Αν το index.html υπαρχει, το κανει overwrite και παιρνεις πισω 200 ΟΚ, αν δεν υπαρχει δημιουργειται εκεινη τη στιγμη και παιρνεις πισω 201 created... Δεν σε αφηνει να ανεβασεις asp, αλλα το index.html ή το main.html ή το default.html ή κλπ κλπ ειναι αρκετο για να κανεις το dfc.
Προτεινόμενες αναρτήσεις
Αρχειοθετημένο
Αυτό το θέμα έχει αρχειοθετηθεί και είναι κλειστό για περαιτέρω απαντήσεις.