Χρειάζομαι έναν προσανατολισμό σχετικά με θέματα ασφάλειας που πρέπει να προσέξει κάποιος σε μία asp.net (με sql server) εφαρμογή.
Ποιοι είναι οι κίνδυνοι για τους οποίους πρέπει κάποιος να ανησυχεί; Από τη βάση δεδομένων μέχρι τον κώδικα.
Η ερώτηση είναι πολύ γενική, αλλά θέλω ένα μπούσουλα για να ξεκινήσω.
ευχαριστώ.

Ξεκίνα από εδώ:

http://msdn2.microsoft.com/en-us/library/ms998411.aspx

Καλό διάβασμα!

---

Vir prudens non contra ventum mingit

Η ασφάλεια είναι ένα τεράστιο θέμα, όσο και παρεξηγημένο.
Αυτό που έχει σημασία είναι η φύση της εφαρμογής σου και μέχρι ποιό επίπεδο θέλεις να την αφαλίσεις καθώς και τι εργαλεία έχεις στα "χέρια" σου...
Από τον Web Server (π.χ. IIS, Apache, Sun) μέχρι και ειδικό software προστασίας (software ή hardware firewall, antispy, antiviruses.... κλπ)  και την γλώσσα ανάπτυξης (php, asp).

Ασφάλεια Εφαρμογής
1. Θα εφαρμόσεις Security σε επίπεδο χρήστη. Να μην μπαίνει κανένας μη εξουσιοδοτημένος?. Η εφαρμογή π.χ. να ζητάει login/password...?
2. Τα προγράμματα σου δεν πρέπει να έχουν βασικές αδυναμίες σε επιθέσεις από άτομα που δεν έχουν τι να κάνουν και δοκιμάζουν φτηνά κόλπα για να κάνουν τους έξυπνους... που δηστυχώς υπάρχει περίπτωση να σου προκαλέσουνε ζημιά.

Μια και ζητάς όμως έναν μπούσουλα θα σου πρότεινα να μάθεις τις δυο βασικές μορφές επίθεσης καθώς και τρόπους προστασίας:
1. XSS και
2. SQL Injection

Πολύ πολύ γενικά με κίνδυνο να σε αποπροσανατολίσω... θα ήθελα να σου πω τα εξής:
1. Για τα sources, include files nα χρησιμοποιείς .asp ή .aspx ή .php ή τέλος πάντων ένα extention που είναι δηλωμένο στον web server σου και δεν θα δείξει τα περιεχόμενα του στον χρήστη αν κάποιος τα αναφέρει στο url box.

2. Να κάνεις πάντα έλεγχο παραμέτρων πριν τις βάλεις σε κάποια εντολή SQL ως εξής:

2.α. Έλεγχο του τύπου της παραμέτρου. Π.χ. οι αριθμοί να είναι αριθμοί, αλλιώς μύνημα κάθους του στυλ.... "Μη αποδεκτοί χαρακτήρες"!

2.β. Αν είναι string η παράμετρος, έλεγχο του μεγέθους του και έλεγχο αν υπάρχουν μέσα περίεργοι χαρακτήρες που είναι απαραίτητοι για XSS html injections, όπως:
'/>', '<', κλπ κλπ....

3. Να αποφεύγεις γενικά να χρησιμοποιείς παραμέτρους από το url.... καθώς να ελέγχεις όλες τις τιμές που δίνει ο χρήστης από όλα τα text boxes.

4. Αν χρησιμοποιείς passwrods να χρησιμοποιείς encryption. Να ξέρεις οτι ποτέ δεν πρέπει να μετακινείς το password από εδώ κι από εκεί από την μια φόρμα στην άλλη κλπ κλπ. Προτείνω να χρησιμοποιήσεις την εξής τεχνική:
Έστω οτι χρησιμοποιείς MD5 encryption.
Να χρησιμοπoιήσεις ένα πεδίο στην βάση σου (το λεγόμενο salt) το οποίο θα προστίθετε στο πραγματικό password που δίνει ο χρήστης και θα παραμένει π.χ. στο current session μέσα σε ένα cookie.
Κάθε χρήστης να έχει το δικό του salt.
Παραδειγμα:

Έστω οτι pasword ενός χρήστη είναι 'xamenos' και το salt του είναι 'stimetafrasi' !
Η κρυπτογράφηση του xamenos είναι 84AD2C74D0A4EE1A557912A781EBE20C.
Η κρυπτογράφηση του xamenosstimetafrasi είναι 39A4C3BB0095C083ADAEC3A8387B594C.

Στο cookie θα αναφέρεται το 39A4C3BB0095C083ADAEC3A8387B594C. Σπάζοντας το κάποιος θα πάρει το xamenosstimetafrasi που δεν είναι το πραγματικό password.... Θα πάει λοιπόν γεμάτος "χαρά" να δώσει το xamenosstimetafrasi σαν password και θα πάρει.... ένα "Unkonown Password!"

Πιο εξελιγμένη περίπτωση είναι να χρησιμοποιείς 2 Salt: Ένα σαν prefix κι ένα σαν suffix....

Τεσπα.... μπορείς να κάνεις άπειρους συνδιασμούς με μόνο εμπόδιο.... την φαντασία σου.

 

 

---

Nothing to declare...

Εδω απλως θα ηθελα να κάνω μια παρατηρηση :

Για την αποθήκευση των password στη βάση (αν επιθυμούμε να φτιάξουμε δική μας βάση) δεν χρησιμοποιούμε encryption αλλά hashing (αποφευγοντας τον MD5 ο οποιος δεν θεωρείται secure hashing αλγοριθμος πια). (Για μεγαλύτερη ασφάλεια μπορούμε να χρησιμοποιήσουμε και συνδυσμό encryption στην αρχή και hashing στο τέλος)

Ο λόγος που χρησιμοποιούμε salt δεν είναι για να μπορούμε να έχουμε το hashed password σε cookie.  Χρησιμοποιωντας salt στο hashing αυτό που πετυχαίνουμε είναι ότι αν 2 χρηστες έχουν το ίδιο password, στη βάση μας τα αντίστοιχα hash values να είναι διαφορετικά. Αυτό όμως πολλές φορές δεν είναι αρκετό.

Αν κάποιος χρήστης αποκτήσει πρόσβαση στον Db server με τα hashed passwords, μπορει αντι να προσπαθησει να σπάσει το hash value,  να αντικαταστήσει το hash και το salt μιας εγγραφής με το  αντίστοιχο hash και salt της δικής του εγγραφής. Αυτή ήταν η τεχνική π.χ. που μπορούσε να χρησιμοποιησει κάποιος παλια για να κάνεις override το root password  σε ένα unix μηχάνημα (οι πιο παλιοί ίσως και να θυμούντε το "πανηγύρι" που γινόταν μια εποχή στα Unix του ΕΜΠ)

Για να ξεπεραστει και το παραπάνω θα μπορούσε κατά τον σχηματισμό του string προς hashing να προστεθεί και κάποιος μετασχηματισμός του κωδικού εισόδυ.

---

jsr

Προσφέροντας και εγώ τον οβολό μου στην συζήτηση, καλό θα είναι να εξασφαλίσεις και κάποιο SSL certificate για να μπορέσεις να κρυπτογραφήσεις το κανάλι επικοινωνίας (κοινώς γνωστό ως https). Παρόλο που πολλοί το αμελούν, το να σου μυριστούν (sniff) τον κωδικό που μεταδίδεις ενώ κάνεις log in είναι από τα πιο απλά πράγματα και επομένως ότι ασφάλεια και να έχεις στην εφαρμογή και στο πως αποθηκεύεις τα password, ο κακόβουλος χρήστης απλά θα σου κάνει post τα credentials που διάβασε από το request του χρήστη. Επειδή τα αναγνωρισμένα SSL certificates κοστίζουν, αν δεν θες να μπλέξεις με ετήσια πάγια, μπορείς να καταφύγεις και σε τσάμπα λύσεις όπως http://www.cacert.org/ ή αν θα κάνεις host την εφαρμογή σου σε κάποιον provider, υπάρχουν κάποιοι οι οποίοι δίνουν ssl στο βασικό πακέτο.

Όσον αφορά την βάση, η συνταγή της επιτυχίας λέγεται stored procedures. Γρήγορα και ασφαλή (εκτός και αν εκτελείς εσωτερικά καμία exec η οποία θέλει ιδιαίτερη προσοχή). Χρησιμοποιώντας τα stored procedures, γλυτώνεις αρκετά SQL Injections μιας και τα πάντα περνάνε typed. 
Όσον αφορά τον κώδικα. Αντί να φτιάξεις το δικό σου security framework, μπορείς να δοκιμάσεις το asp.net Membership provider model το οποίο είναι Microsoft και άμα θες μπορείς πολύ απλά να κάνεις inherit τον MembershipProvider και τον RoleProvider και να κουμπώσεις το έτοιμο framework (μαζί με τα έτοιμα controls κτλ κτλ) στην εφαρμογή σου.
Τέλος, δεν πρέπει να πιστεύουμε ότι ο χρήστης έχει ενεργοποιημένη javascript. Οπότε όλα τα ωραία javascript validation είναι απλά και μόνο για να αποτρέψουμε λάθος data entry, όχι να αποτρέψουμε τον κακόβουλο να μας στείλει κείμενο εκεί που περιμένουμε νούμερο. Ιδιαίτερη έμφαση πρέπει να δοθεί στο γεγονός ότι ποτέ μα ποτέ και για κανέναν λόγο δεν πρέπει να θεωρείς ότι ο χρήστης θα σου στείλει την σωστή πληροφορία. Ότι και να στείλει πρέπει να ελεγχτεί αν είναι αναμενόμενο...
Κατά τα άλλα οι προλαλίσαντες με κάλυψαν...

Καλή τύχη και εδώ είμαστε για επιμέρους λεπτομέρειες...

Υ.Γ. Ξέχασα να αναφέρω στο αρχικό Post ότι χρησιμοποιώντας μόνο stored procedures, μπορείς να φτιάξεις ένα ξέχωρο sql user ο οποίο να έχει πρόσβαση μόνο στα stored procedures και όχι στους πίνακες (για να αποτρέψεις κατά μια έννοια το εύκολο database fishing που θα μπορέσει να κάνει κάποιος αν αξιοποιήσει sql injection). Το θέμα του sql χρήστη είναι μια μεγάλη ιστορία αφού όσοι παίζουν με sa και unencrypted connection string είναι ευάλωτοι άμα κάποιος αποκτήσει πρόσβαση στο web.config.

---

jsr

....Πώς κάποιος μπορεί να αποκτήσει πρόσβαση στο web.config ?

Απο ότι είδα το CAcert's Root cert  (http://wiki.cacert.org/wiki/InclusionStatus ) δέν είναι included στον IE (και δέν πρόκειται  μάλλον να είναι oύτε στο μέλλον).

Αυτό σημαίνει ότι οσοι συνδέονται σε μια σελίδα που εχει SSL μέσο του συγκεκριμένου οργανισμού , με IE , δέν θα βλέπουν τη σελίδα ως Trusted ?

 

 

Σε αυτό το event έχει ένα καλό, γενικό session για security:

http://www.dotnetzone.gr/cs/forums/thread/33102.aspx

 

---

Patrick

pan:

....Πώς κάποιος μπορεί να αποκτήσει πρόσβαση στο web.config ?

Ένας από τους πολλούς τρόπους είναι:

1. Μέσω (ας πούμε) SQL Injection να βρει το MD5 password του admin.
2. Με γνωστά εργαλεία (brute forcing, online tools, rainbow tables) να σπάσει το password και να μπει σαν διαχειριστής.
3. Αφού έχει δικαιώματα διαχειριστή είναι πολύ πιθανόν να του επιτρέπεται να κάνει upload αρχεία. Κάνει, λοιπόν, upload ένα web shell για windows.
   
4. Με το web shell έχει πρόσβαση πλέον στα directories του server άρα μπορεί να δεί το web.config.
   

---

Nothing to declare...