Πόσο συχνά ελέγχετε τον κώδικά σας για κενά ασφαλείας;

[incomniac]

Ορμώμενος από αυτά τα στατιστικά:

Site: https://laurent22.github.io/so-injections/

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

[defacer]

Every. Single. Time.

 

Αν και για πράγματα όπως SQL injection και τις βασικές (πιο συνηθισμένες) περιπτώσεις XSS, δεν έχει και τίποτα να σκεφτείς. Είναι απλά θέμα απόκτησης των σωστών συνηθειών. Άμα έχεις μάθει να βουρτσίζεις δόντια κάθε βράδυ δε χρειάζεται να σκέφτεσαι πώς θα μπορούσαν τα γλυκά που τρως να σου χαλάσουν τα δόντια.

[παπι]

 

που χαθηκες εσυ;

 

 

Sql query γραφω μονο για τεστ. Αλλιως prepare. Οχι οτι υπαρχει ατομο το οποιο θα μπει στη διαδικασια να με χακαρει.... αλλα τζζστ σεινγκ.

[DevFromHell]

Το testing για κενά ασφαλείας με JUnit γίνεται?

[CtrlFreak]

Το testing για κενά ασφαλείας με JUnit γίνεται?

 

Το JUnit είναι framework για test driven development σε Java. Υπάρχουν και άλλα Unit test για άλλες γλώσσες. Δεν έχει να κάνει με την ασφάλεια. 

 

Για ασφάλεια υπάρχουν άλλες πλατφόρμες και τεχνικές (βλ. fuzzing) αλλά επειδή τα πράγματα δεν είναι τόσο απλά τον έλεγχο για την ασφάλεια τον κάνει άνθρωπος. 

[The Void]

Η λύση είναι πολύ απλή μάγκες!

 

πολύ απλά η εφαρμογή του Client δεν πρέπει να έχει καν την δυνατότητα πρόσβασης σε ευαίσθητες πληροφορίες. Ακόμα και με Authentication/Authorization.

 

ή

 

Παράδειγμα: το League of Legends πριν κάνα χρόνο περίπου είχε ένα Exploit με το Recall {B}. Οι μάγκες της RIOT για να γλιτώσουν πράξεις στον Server, βάλανε Client-Side τον υπολογισμό του χρόνου που κάνει {B} o παίχτης:

while(passedTime < 8s){
   // wait
}

player.Teleport(Base);

Ε! αυτό το βρήκανε και ο άλλος έκανε B σε 1 Second. Πήγαινε σε Fights, έπεφτε η ζωή του και κοπάναγε {B}

Ορμώμενος από αυτά τα στατιστικά:

Site: https://laurent22.github.io/so-injections/

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

 

Σώπα ρε! τι στατιστικά του κ@ωου είναι αυτά;

 

Όταν εγώ ανεβάζω 10-20 γραμμές κώδικα πως εσύ θεωρείς ότι ο κώδικας αυτός είναι ευάλωτος; και που ξέρεις εσύ τι κάνω εγώ πιο πριν ή πιο μετά;

 

Θέλω να σου πω ότι μπορεί πιο πριν να έχω κάνει parse-check το SQLQUERY string.

 

ή

 

μπορεί κάπου ενδιάμεσα να έχω (...) όπου εκεί γίνεται κάποιος έλεγχος του string. 

[defacer]

Η λύση είναι πολύ απλή μάγκες!

 

πολύ απλά η εφαρμογή του Client δεν πρέπει να έχει καν την δυνατότητα πρόσβασης σε ευαίσθητες πληροφορίες. Ακόμα και με Authentication/Authorization.

Με ποιό τρόπο είναι αυτό λύση για SQL injection ή κενά ασφαλείας γενικότερα;

 

Στη συντριπτική πλειοψηφία των περιπτώσεων (injection, ή για να πιάσουμε κάτι τελείως διαφορετικό πές π.χ. heartbleed) ο client είναι μια χαρά, τα προβλήματα βρίσκονται στο server.

 

Το παράδειγμα που φέρνεις με το LoL δεν είναι καν κενό ασφαλείας. 

 

Σώπα ρε! τι στατιστικά του κ@ωου είναι αυτά;

 

Όταν εγώ ανεβάζω 10-20 γραμμές κώδικα πως εσύ θεωρείς ότι ο κώδικας αυτός είναι ευάλωτος; και που ξέρεις εσύ τι κάνω εγώ πιο πριν ή πιο μετά;

 

Θέλω να σου πω ότι μπορεί πιο πριν να έχω κάνει parse-check το SQLQUERY string.

 

ή

 

μπορεί κάπου ενδιάμεσα να έχω (...) όπου εκεί γίνεται κάποιος έλεγχος του string.

Ο τίτλος στη σελίδα λέει "SQL injections vulnerabilities in Stack Overflow PHP questions". Με ποιό ακριβώς τρόπο δεν ανταποκρίνεται στην πραγματικότητα και άρα είναι "του κώλου";

 

Όσο για τους ελέγχους απλά θα πω ότι αυτό το επιχείρημα ισχύει μόνο σε επίπεδο χόμπι.

[Επισκέπτης]

Η λύση είναι πολύ απλή μάγκες!

 

πολύ απλά η εφαρμογή του Client δεν πρέπει να έχει καν την δυνατότητα πρόσβασης σε ευαίσθητες πληροφορίες. Ακόμα και με Authentication/Authorization.

 

Μόλις ακύρωσες το web banking, το paypal, το amazon, το ebay και το μισό Internet.

[The Void]

Μόλις ακύρωσες το web banking, το paypal, το amazon, το ebay και το μισό Internet.

 

Έχει το Web Banking, Paypal, Amazon, ebay, το μισό Internet φόρα παρτίδα τις χρεωστικές μας κάρτες; χωρίς κρυπτογράφηση; 

 

όχι.

 

οπότε μια τρύπα στο νερό.

[Επισκέπτης]

Η κρυπτογράφηση είναι το πρόβλημα σου; Γιατί πριν μίλησες για client γενικά κι αόριστα. Μιλώντας δε για κρυπτογράφηση, κι επειδή μαντεύω ότι έχεις μαύρα μεσάνυχτα, η κρυπτογράφηση δεν σου λύνει προβλήματα ασφάλειας.

[incomniac]

 

Σώπα ρε! τι στατιστικά του κ@ωου είναι αυτά;

 

Όταν εγώ ανεβάζω 10-20 γραμμές κώδικα πως εσύ θεωρείς ότι ο κώδικας αυτός είναι ευάλωτος; και που ξέρεις εσύ τι κάνω εγώ πιο πριν ή πιο μετά;

 

Θέλω να σου πω ότι μπορεί πιο πριν να έχω κάνει parse-check το SQLQUERY string.

 

ή

 

μπορεί κάπου ενδιάμεσα να έχω (...) όπου εκεί γίνεται κάποιος έλεγχος του string. 

 

Αν και ο πιο ενδεδειγμένος τρόπος είναι τα prepared statements αντί να δημιουργείς queries ενώνοντας strings, από τη στιγμή που θα μπεις στον κόπο να κάνεις spacial character escaping και ελέγχους στις τιμές πάει να πει ότι το έχεις στο μυαλό σου και κινείσαι στην σωστή κατεύθυνση. Αλλά και πάλι την μεγαλύτερη κάλυψη θα σου τη δώσουν οι prepared statements.

 

Το θέμα όμως είναι άλλο. Πολλοί(και ειδικά αρχάριοι στο είδος) μπορεί να αντιγράψουν τον κώδικα και να μην κάτσουν να ασχοληθούν με το πριν και το μετά και το πώς μπορεί να είναι ευάλωτος, ή να νομίσουν ότι επειδή το είδαν τόσες φορές έτσι, ότι έτσι είναι και το σωστό. Οπότε για κάθε ερώτηση ή απάντηση που γράφεις στην οποία κολλάς strings και τα δίνεις στην sql(ή οποιαδήποτε άλλη κακή πρακτική) είναι σαν να βάζεις και εσύ το λιθαράκι σου στο σπιτάκι του χάκερ, επειδή σπρώχνεις το συλλογικό mindset στη λάθος κατεύθυνση.

[The Void]

...

Το θέμα όμως είναι άλλο. Πολλοί(και ειδικά αρχάριοι στο είδος) μπορεί να αντιγράψουν τον κώδικα και να μην κάτσουν να ασχοληθούν με το πριν και το μετά και το πώς μπορεί να είναι ευάλωτος, ή να νομίσουν ότι επειδή το είδαν τόσες φορές έτσι, ότι έτσι είναι και το σωστό. Οπότε για κάθε ερώτηση ή απάντηση που γράφεις στην οποία κολλάς strings και τα δίνεις στην sql(ή οποιαδήποτε άλλη κακή πρακτική) είναι σαν να βάζεις και εσύ το λιθαράκι σου στο σπιτάκι του χάκερ, επειδή σπρώχνεις το συλλογικό mindset στη λάθος κατεύθυνση.

 

και ποια η πιθανότητα δηλαδή ένα software να γίνει στόχος των μεγάλων χάκερς; άλλη δουλειά δεν είχαν αυτοί από το να χακάρουν μια σελίδα επιχείρησης ή οτιδήποτε.

 

Καλά κάνετε βέβαια και λέτε όλα αυτά που λέτε. Απλά είμαι λίγο της άποψης -> "μην σκας καθόλου. κοίτα να μην έχεις πολύ απόρρητα δεδομένα, ή έστω κρυπτογραφημένα και άσε τα διάφορα hashes να κυκλοφορούν στο διαδίκτυο. Κλαιν μαιν. μέχρι να τα σπάσουν τους έχεις βάλει να τα αλλάξουν (pwd reset)"

[Kercyn]

Γιατί έχεις την εντύπωση ότι "κρυπτογραφημένα" == "100% ασφαλή";

[Επισκέπτης]

και ποια η πιθανότητα δηλαδή ένα software να γίνει στόχος των μεγάλων χάκερς; άλλη δουλειά δεν είχαν αυτοί από το να χακάρουν μια σελίδα επιχείρησης ή οτιδήποτε.

 

Καλά κάνετε βέβαια και λέτε όλα αυτά που λέτε. Απλά είμαι λίγο της άποψης -> "μην σκας καθόλου. κοίτα να μην έχεις πολύ απόρρητα δεδομένα, ή έστω κρυπτογραφημένα και άσε τα διάφορα hashes να κυκλοφορούν στο διαδίκτυο. Κλαιν μαιν. μέχρι να τα σπάσουν τους έχεις βάλει να τα αλλάξουν (pwd reset)"

 

Ωραία, μπαίνει κάποιος και σου διαγράφει όλη τη database. Ή κάνει inject κώδικα και μετά το site σου σερβίρει malware. Ή κάνει hijack τις διαφημίσεις και δείχνεις διαφημίσεις πορνό ή affiliate για αμφιλεγόμενα προϊόντα. Υπάρχουν εκατοντάδες πράγματα που μπορεί να σου κάνει κάποιος αν έχεις κενά ασφαλείας, εκτός από το να σου κλέψει τα data.

 

Η κρυπτογράφηση δεν λύνει προβλήματα ασφάλειας.