[PHP] beveiliging van een website, is het veilig genoeg?

[sebasmac]

Beste mede programmeurs,

Ik ben een site aan het bouwen en ik vroeg me af of ik iets over het hoofd zie wat betreft de beveiliging van alles. Volgens mij heb ik aan de meeste dingen wel gedacht maar ik vroeg me af of jullie nog iets weten waar ik nog even naar zou moeten kijken.

Hoe het nu in elkaar zit:

Allereerst heb ik in mijn PHP applicatie een database class geschreven die uiteraard helemaal PDO is daarnaast gaan alle queries eerst door de PDO prepareer heen waardoor ik er al een deel uitfilter.

Daarnaast begint het natuurlijk bij de inputs op de site al, deze worden allemaal door een class heen gehaald die de XSS filter moet voorstellen. Dit bij elkaar lijkt al een sterke basis lijkt mij?

Dan het opslaan van de userdata in de database allereest genereer ik als de user zich registreert een random id met

PHP: filename

rand()

Dan maak ik hier een sha512 hash van welke me salt moet voorstellen. Hierna gebruik ik dezelfde methode om het password te encrypten gecombineerd met uiteraard de salt.

PHP: filename

$salt = hash('sha512', rand());
$password = $input->process($_POST['password']);

$passwordenc = hash('sha512', $password . $salt);

EDIT:

Als de user ingelogt is word er een cookie aangemaakt met daarin een random session id deze word op elke pagina uiteraard gecontroleerd en deze is ook IP gebaseerd. simpel: veranderd de gebruiker van IP dan is deze gewoon weer uitgelogd

Als laatste is de hele site secure en heb ik een SSL certificaat met Uitgebreide validatieprocedure waardoor dus ook de adresbalk groen word.

Dan heb ik even een vraag over brute force attacks. Deze ga je niet tegen maar hoe kun je deze als beste afhandelen? Ik heb er een heel groot stuk over gelezen maar kom er niet helemaal uit.

Eerst had ik het plan om een gebruiker na 5 verkeerde inlogpogingen te emailen met daarin dat er iemand probeert in te loggen via zijn account. mocht hij dat zelf zijn is er niks aan de hand maar is het iemand anders ja dan? aan die gebruiker kan je niks vragen, maar wel netjes om hem te informeren leek me.

Mocht hij nog 5 keer proberen in te loggen met verkeerde gegevens dan word zijn account geblokkeerd en krijgt hij een mailtje met daarin een activatie code om het weer ongedaan te maken. Maar als de brute force attacker dan dat heel vaak bij verschillende gebruikersnamen doet zijn alle gebruikers straks geblokkeerd ook niet echt de beste oplossing leek mij.

Toen mijn volgende redenering. Als ik nou het IP gebaseerd oppak en ik blokkeer de IP adress die vaak achter elkaar proberen in te loggen voor een bepaalde tijd, dan kan ik in ieder geval die aanval stopppen. mm ook geen nut want je ziet dat een brute force attack meestal vanaf verschillende IP adressen tegelijk komt.

Toen heb ik erover nagedacht om het over een andere boeg te gooien, stel een gebruiker probeert 5x in te loggen en heeft dan nog steeds niet het juiste password dan geef je mee dat de pagina laadtijd langer duurt en na 10 inlogpogingen nog langer etc etc. Maar uiteindelijk stop je hier geen aanval mee? Want ip gebaseerd kun je die inlogpogingen niet opslaan als het ip steeds wijzigt en per gebruiker heeft het ook geen zin als de aanvaller steeds van username veranderd. daarnaast heeft die data in een cookie opslaan ook niet veel zin want deze kunnen ze ook steeds weggooien.

Mijn vraag aan jullie is, denk ik te moeilijk of zie ik echt iets over het hoofd? 1 ding is zeker ik wil in ieder geval wel een vorm van brute force preventie toevoegen. Maar is dan de enige methode die overblijft toch simpel de lettertjes en cijfertjes overtikken van een plaatje? Niet heel erg gebruiksvriendelijk lijkt mij... een Facebook of google heeft dat ook niet, aan de andere kant hendelen zij die extra requests makkelijk natuurlijk

Graag zou ik even horen wat jullie meningen in deze zijn, en of ik ergens een validatie of lek over het hoofd zie!

Bedankt alvast

[ Voor 3% gewijzigd door sebasmac op 14-09-2013 19:06 ]

[Cartman!]

sebasmac schreef op zaterdag 14 september 2013 @ 18:56:
Daarnaast begint het natuurlijk bij de inputs op de site al, deze worden allemaal door een class heen gehaald die de XSS filter moet voorstellen.

Door een class heen halen zegt niks natuurlijk

PHP:

class Acme {
    public static function antiXss($value)
    {
        return $value;
    }
}
$secureValue = Acme::antiXss($value);

Zo...klaar.

Wat doet die class dus precies?

[ Voor 3% gewijzigd door Cartman! op 14-09-2013 19:00 ]

[sebasmac]

De input filter class zit als volgt in elkaar (niet zelf gemaakt) zoals in mijn eerdere post te lezen roep ik hem aan als

PHP: filename

$input->filter($variable);

PHP: filename

class InputFilter {
    var $tagsArray;         // default = empty array
    var $attrArray;         // default = empty array

    var $tagsMethod;        // default = 0
    var $attrMethod;        // default = 0

    var $xssAuto;           // default = 1
    var $tagBlacklist = array('applet', 'body', 'bgsound', 'base', 'basefont', 'embed', 'frame', 'frameset', 'head', 'html', 'id', 'iframe', 'ilayer', 'layer', 'link', 'meta', 'name', 'object', 'script', 'style', 'title', 'xml');
    var $attrBlacklist = array('action', 'background', 'codebase', 'dynsrc', 'lowsrc');  // also will strip ALL event handlers

    /**
     * Constructor for inputFilter class. Only first parameter is required.
     * @access constructor
     * @param Array $tagsArray - list of user-defined tags
     * @param Array $attrArray - list of user-defined attributes
     * @param int $tagsMethod - 0= allow just user-defined, 1= allow all but user-defined
     * @param int $attrMethod - 0= allow just user-defined, 1= allow all but user-defined
     * @param int $xssAuto - 0= only auto clean essentials, 1= allow clean blacklisted tags/attr
     */
    function inputFilter($tagsArray = array(), $attrArray = array(), $tagsMethod = 0, $attrMethod = 0, $xssAuto = 1) {
// make sure user defined arrays are in lowercase
        for ($i = 0; $i < count($tagsArray); $i++) $tagsArray[$i] = strtolower($tagsArray[$i]);
        for ($i = 0; $i < count($attrArray); $i++) $attrArray[$i] = strtolower($attrArray[$i]);
// assign to member vars
        $this->tagsArray = (array) $tagsArray;
        $this->attrArray = (array) $attrArray;
        $this->tagsMethod = $tagsMethod;
        $this->attrMethod = $attrMethod;
        $this->xssAuto = $xssAuto;
    }

    /**
     * Method to be called by another php script. Processes for XSS and specified bad code.
     * @access public
     * @param Mixed $source - input string/array-of-string to be 'cleaned'
     * @return String $source - 'cleaned' version of input parameter
     */
    function process($source) {
// clean all elements in this array
        if (is_array($source)) {
            foreach($source as $key => $value)
// filter element for XSS and other 'bad' code etc.
                if (is_string($value)) $source[$key] = $this->remove($this->decode($value));
            return $source;
// clean this string
        } else if (is_string($source)) {
// filter source for XSS and other 'bad' code etc.
            return $this->remove($this->decode($source));
// return parameter as given
        } else return $source;
    }

    /**
     * Internal method to iteratively remove all unwanted tags and attributes
     * @access protected
     * @param String $source - input string to be 'cleaned'
     * @return String $source - 'cleaned' version of input parameter
     */
    function remove($source) {
        $loopCounter=0;
// provides nested-tag protection
        while($source != $this->filterTags($source)) {
            $source = $this->filterTags($source);
            $loopCounter++;
        }
        return $source;
    }

    /**
     * Internal method to strip a string of certain tags
     * @access protected
     * @param String $source - input string to be 'cleaned'
     * @return String $source - 'cleaned' version of input parameter
     */
    function filterTags($source) {
// filter pass setup
        $preTag = NULL;
        $postTag = $source;
// find initial tag's position
        $tagOpen_start = strpos($source, '<');
// interate through string until no tags left
        while($tagOpen_start !== FALSE) {
// process tag interatively
            $preTag .= substr($postTag, 0, $tagOpen_start);
            $postTag = substr($postTag, $tagOpen_start);
            $fromTagOpen = substr($postTag, 1);
// end of tag
            $tagOpen_end = strpos($fromTagOpen, '>');
            if ($tagOpen_end === false) break;
// next start of tag (for nested tag assessment)
            $tagOpen_nested = strpos($fromTagOpen, '<');
            if (($tagOpen_nested !== false) && ($tagOpen_nested < $tagOpen_end)) {
                $preTag .= substr($postTag, 0, ($tagOpen_nested+1));
                $postTag = substr($postTag, ($tagOpen_nested+1));
                $tagOpen_start = strpos($postTag, '<');
                continue;
            }
            $tagOpen_nested = (strpos($fromTagOpen, '<') + $tagOpen_start + 1);
            $currentTag = substr($fromTagOpen, 0, $tagOpen_end);
            $tagLength = strlen($currentTag);
            if (!$tagOpen_end) {
                $preTag .= $postTag;
                $tagOpen_start = strpos($postTag, '<');
            }
// iterate through tag finding attribute pairs - setup
            $tagLeft = $currentTag;
            $attrSet = array();
            $currentSpace = strpos($tagLeft, ' ');
// is end tag
            if (substr($currentTag, 0, 1) == "/") {
                $isCloseTag = TRUE;
                list($tagName) = explode(' ', $currentTag);
                $tagName = substr($tagName, 1);
// is start tag
            } else {
                $isCloseTag = FALSE;
                list($tagName) = explode(' ', $currentTag);
            }
// excludes all "non-regular" tagnames OR no tagname OR remove if xssauto is on and tag is blacklisted
            if ((!preg_match("/^[a-z][a-z0-9]*$/i",$tagName)) || (!$tagName) || ((in_array(strtolower($tagName), $this->tagBlacklist)) && ($this->xssAuto))) {
                $postTag = substr($postTag, ($tagLength + 2));
                $tagOpen_start = strpos($postTag, '<');
// don't append this tag
                continue;
            }
// this while is needed to support attribute values with spaces in!
            while ($currentSpace !== FALSE) {
                $fromSpace = substr($tagLeft, ($currentSpace+1));
                $nextSpace = strpos($fromSpace, ' ');
                $openQuotes = strpos($fromSpace, '"');
                $closeQuotes = strpos(substr($fromSpace, ($openQuotes+1)), '"') + $openQuotes + 1;
// another equals exists
                if (strpos($fromSpace, '=') !== FALSE) {
// opening and closing quotes exists
                    if (($openQuotes !== FALSE) && (strpos(substr($fromSpace, ($openQuotes+1)), '"') !== FALSE))
                        $attr = substr($fromSpace, 0, ($closeQuotes+1));
// one or neither exist
                    else $attr = substr($fromSpace, 0, $nextSpace);
// no more equals exist
                } else $attr = substr($fromSpace, 0, $nextSpace);
// last attr pair
                if (!$attr) $attr = $fromSpace;
// add to attribute pairs array
                $attrSet[] = $attr;
// next inc
                $tagLeft = substr($fromSpace, strlen($attr));
                $currentSpace = strpos($tagLeft, ' ');
            }
// appears in array specified by user
            $tagFound = in_array(strtolower($tagName), $this->tagsArray);
// remove this tag on condition
            if ((!$tagFound && $this->tagsMethod) || ($tagFound && !$this->tagsMethod)) {
// reconstruct tag with allowed attributes
                if (!$isCloseTag) {
                    $attrSet = $this->filterAttr($attrSet);
                    $preTag .= '<' . $tagName;
                    for ($i = 0; $i < count($attrSet); $i++)
                        $preTag .= ' ' . $attrSet[$i];
// reformat single tags to XHTML
                    if (strpos($fromTagOpen, "</" . $tagName)) $preTag .= '>';
                    else $preTag .= ' />';
// just the tagname
                } else $preTag .= '</' . $tagName . '>';
            }
// find next tag's start
            $postTag = substr($postTag, ($tagLength + 2));
            $tagOpen_start = strpos($postTag, '<');
        }
// append any code after end of tags
        $preTag .= $postTag;
        return $preTag;
    }

    /**
     * Internal method to strip a tag of certain attributes
     * @access protected
     * @param Array $attrSet
     * @return Array $newSet
     */
    function filterAttr($attrSet) {
        $newSet = array();
// process attributes
        for ($i = 0; $i <count($attrSet); $i++) {
            // skip blank spaces in tag
            if (!$attrSet[$i]) continue;
            // split into attr name and value
            $attrSubSet = explode('=', trim($attrSet[$i]));
            list($attrSubSet[0]) = explode(' ', $attrSubSet[0]);
            // removes all "non-regular" attr names AND also attr blacklisted
            if ((!eregi("^[a-z]*$",$attrSubSet[0])) || (($this->xssAuto) && ((in_array(strtolower($attrSubSet[0]), $this->attrBlacklist)) || (substr($attrSubSet[0], 0, 2) == 'on'))))
                continue;
            // xss attr value filtering
            if ($attrSubSet[1]) {
                // strips unicode, hex, etc
                $attrSubSet[1] = str_replace('&#', '', $attrSubSet[1]);
                // strip normal newline within attr value
                $attrSubSet[1] = preg_replace('/\s+/', '', $attrSubSet[1]);
                // strip double quotes
                $attrSubSet[1] = str_replace('"', '', $attrSubSet[1]);
                // [requested feature] convert single quotes from either side to doubles (Single quotes shouldn't be used to pad attr value)
                if ((substr($attrSubSet[1], 0, 1) == "'") && (substr($attrSubSet[1], (strlen($attrSubSet[1]) - 1), 1) == "'"))
                    $attrSubSet[1] = substr($attrSubSet[1], 1, (strlen($attrSubSet[1]) - 2));
                // strip slashes
                $attrSubSet[1] = stripslashes($attrSubSet[1]);
            }
            // auto strip attr's with "javascript:
            if (    ((strpos(strtolower($attrSubSet[1]), 'expression') !== false) &&    (strtolower($attrSubSet[0]) == 'style')) ||
                (strpos(strtolower($attrSubSet[1]), 'javascript:') !== false) ||
                (strpos(strtolower($attrSubSet[1]), 'behaviour:') !== false) ||
                (strpos(strtolower($attrSubSet[1]), 'vbscript:') !== false) ||
                (strpos(strtolower($attrSubSet[1]), 'mocha:') !== false) ||
                (strpos(strtolower($attrSubSet[1]), 'livescript:') !== false)
            ) continue;

            // if matches user defined array
            $attrFound = in_array(strtolower($attrSubSet[0]), $this->attrArray);
            // keep this attr on condition
            if ((!$attrFound && $this->attrMethod) || ($attrFound && !$this->attrMethod)) {
                // attr has value
                if ($attrSubSet[1]) $newSet[] = $attrSubSet[0] . '="' . $attrSubSet[1] . '"';
                // attr has decimal zero as value
                else if ($attrSubSet[1] == "0") $newSet[] = $attrSubSet[0] . '="0"';
                // reformat single attributes to XHTML
                else $newSet[] = $attrSubSet[0] . '="' . $attrSubSet[0] . '"';
            }
        }
        return $newSet;
    }

    /**
     * Try to convert to plaintext
     * @access protected
     * @param String $source
     * @return String $source
     */
    function decode($source) {
        // url decode
        $source = html_entity_decode($source, ENT_QUOTES, "ISO-8859-1");
        // convert decimal
        $source = preg_replace('/&#(\d+);/me',"chr(\\1)", $source);             // decimal notation
        // convert hex
        $source = preg_replace('/&#x([a-f0-9]+);/mei',"chr(0x\\1)", $source);   // hex notation
        return $source;
    }





}

[ Voor 7% gewijzigd door sebasmac op 14-09-2013 19:07 ]

[Cartman!]

Ik kan je aanraden deze te nemen: http://htmlpurifier.org/

Als aanvulling, als je denkt dat sha512 encryptie is dan moet je nog even goed lezen wat het verschil is tussen encrypten en hashen. Ook kun je beter gebruik maken van bcrypt of scrypt voor password hashing.

[ Voor 64% gewijzigd door Cartman! op 14-09-2013 19:26 ]

[Devil]

Wat ik doe om brute force in te perken is een gebruiker na 5 ongeldige inkogpogingen een recaptcha voorschotelen. Dat is een harde conditie, vanaf dat moment wordt bij elke inlog poging eerst de captcha input gechecked, totdat er een geldige inlog + captcha is geweest. In het ergste geval zijn dan niet al je accounts geblokkeerd, maar krijgen al je gebruikers 1 malig een captcha voor hun neus. Lastig, maar niet zo vervelend als een geblokkeerd account.

Het is wel minder veilig dan het daadwerkelijk blokkeren van een account, maar je vertraagd een brute force wel enorm. En dan is het een kwestie van goede monitoring om er op tijd bij te kunnen zijn.

[ Voor 4% gewijzigd door Devil op 14-09-2013 20:24 ]

[sebasmac]

Cartman! schreef op zaterdag 14 september 2013 @ 19:22:
Ik kan je aanraden deze te nemen: http://htmlpurifier.org/

Als aanvulling, als je denkt dat sha512 encryptie is dan moet je nog even goed lezen wat het verschil is tussen encrypten en hashen. Ook kun je beter gebruik maken van bcrypt of scrypt voor password hashing.

Dankjewel! zal hem nu gelijk doorvoeren, over de encryptie gesproken ik gebruikte md5 maar vond het tijd voor een betere encryptie al is md5 salted natuurlijk ook nog gewoon sterk. was overgegaan op sha512 maar dat word dus nu bcrypt als ik die stukken erover lees

Devil schreef op zaterdag 14 september 2013 @ 20:23:
Wat ik doe om brute force in te perken is een gebruiker na 5 ongeldige inkogpogingen een recaptcha voorschotelen. Dat is een harde conditie, vanaf dat moment wordt bij elke inlog poging eerst de captcha input gechecked, totdat er een geldige inlog + captcha is geweest. In het ergste geval zijn dan niet al je accounts geblokkeerd, maar krijgen al je gebruikers 1 malig een captcha voor hun neus. Lastig, maar niet zo vervelend als een geblokkeerd account.

Het is wel minder veilig dan het daadwerkelijk blokkeren van een account, maar je vertraagd een brute force wel enorm. En dan is het een kwestie van goede monitoring om er op tijd bij te kunnen zijn.

Over de combinatie zoals jij hem hebt draaien had ik nog niet nagedacht, bedankt voor je tip! monitoren lijkt me sowieso een must have

[Cartman!]

sebasmac schreef op zaterdag 14 september 2013 @ 21:12:
[...]


Dankjewel! zal hem nu gelijk doorvoeren, over de encryptie gesproken ik gebruikte md5 maar vond het tijd voor een betere encryptie al is md5 salted natuurlijk ook nog gewoon sterk. was overgegaan op sha512 maar dat word dus nu bcrypt als ik die stukken erover lees

Je weet het verschil tussen encryptie en hashing niet, zoek het even op

[Voutloos]

Léés vooral waarom bijvoorbeeld bcrypt() beter zou zijn.

Als je dat weet, weet je meteen waarom het hashingalgoritme gezien je huidige code niet de beperkende factor is. Kijk ook eens nogmaals naar rand() in de php docs. Deze support enkel waardes t/m getrandmax(), en dat is in het beste geval een lousy 2³¹. Iedereen die fancy algoritmes roept terwijl er enkel een dergelijke input is mag ook even 't een en ander nalezen.

Leesvoer: https://crackstation.net/hashing-security.htm

Lees ook het verschil tussen white- en blacklisting. Dat stuk PHP 4 code dat je post werkt met een blacklist. Dus wat gebeurt er dan als je het effect van een bepaald element/attribuut onderschat? Wat gebeurt er als er nieuwe attributen bij komen? Hoe kan je dan blijven garanderen dat het veilig is? Etc. etc.

[Devil]

Welke PHP versie heb je draaien? Want PHP 5.5 heeft een simpele API voor password hashing. Dat is de veiligste keus voor als je zelf eigenlijk niet helemaal weet waar je mee bezig bent: http://www.php.net/manual/en/ref.password.php

En anders is crypt een hele goede optie, als je het maar goed gebruikt. En dat komt neer op een salt die lang genoeg is en random genoeg. Voor het genereren van een salt heb je echt geen csprng nodig, de functie van de salt is voorkomen dat een aanvaller rainbow tables kan gebruiken. Je wilt dus voorkomen dat hij/zij 'toevallig' de combinatie salt + password al eens eerder is tegengekomen of heeft uitgerekend. Als je salt lang genoeg is en behoorlijk random dan is die kans al nihil.

Overigens geldt voor alles wat je beschrijft dat het valt of staat met jouw implementatie, de filosofie kan goed zijn, maar als er een halfbakken implementatie achter zit dan heb je er nog weinig aan. Hoe genereer je bijvoorbeeld sessie ids voor in je cookie? Roteer je deze en zo ja hoe vaak. Hoe lang is een cookie geldig? Waar sla je het ip adres op dat gecontroleerd wordt? etc.

[ Voor 8% gewijzigd door Devil op 14-09-2013 22:18 ]

[Gomez12]

sebasmac schreef op zaterdag 14 september 2013 @ 18:56:
Allereerst heb ik in mijn PHP applicatie een database class geschreven die uiteraard helemaal PDO is daarnaast gaan alle queries eerst door de PDO prepareer heen waardoor ik er al een deel uitfilter.

Wat bedoel je met het 2e gedeelte?

En tja, mijn algemene indruk is dat je net het laatste stukje kennis mist wat het verschil maakt tussen wel de namen van de technieken weten maar niet weten hoe die toe te passen en de technieken goed toepassen. En daardoor wordt ik altijd heel angstig dat je ergens anders een giga-gat hebt zitten wat je over het hoofd ziet.

Jouw gebruik van rand() (zonder min en max) heeft bijv leuke gevolgen op een windows platform.

Uitloggen op basis van ip vinden je mobiele gebruikers leuk...

Qua brute force zou ik wel het mailtje blijven hanteren, maar ik ben zelf meer van het verdubbelen van de inlogtijd bij elke foutieve inlogpoging, een mens merkt daar niet snel iets van, maar een brute force wordt redelijk zinloos als hij na 5 pogingen 1 sec per inlog moet wachten en poging 6 leidt tot 2 sec wachten. Je begint gewoon met 100 ms en zelfs de ergste gebruiker zal er nog na 24 uur weer inkunnen)

[HMS]

Je zou ook nog naar XSRF beveiliging kunnen kijken (XSRF = Wikipedia: Cross-site request forgery)

[sebasmac]

Cartman! schreef op zaterdag 14 september 2013 @ 21:15:
[...]

Je weet het verschil tussen encryptie en hashing niet, zoek het even op

Ik ben inmiddels weer een stuk wijzer geworden thx voor de tips!

Voutloos schreef op zaterdag 14 september 2013 @ 21:40:
Léés vooral waarom bijvoorbeeld bcrypt() beter zou zijn.

Als je dat weet, weet je meteen waarom het hashingalgoritme gezien je huidige code niet de beperkende factor is. Kijk ook eens nogmaals naar rand() in de php docs. Deze support enkel waardes t/m getrandmax(), en dat is in het beste geval een lousy 2³¹. Iedereen die fancy algoritmes roept terwijl er enkel een dergelijke input is mag ook even 't een en ander nalezen.

Leesvoer: https://crackstation.net/hashing-security.htm

Lees ook het verschil tussen white- en blacklisting. Dat stuk PHP 4 code dat je post werkt met een blacklist. Dus wat gebeurt er dan als je het effect van een bepaald element/attribuut onderschat? Wat gebeurt er als er nieuwe attributen bij komen? Hoe kan je dan blijven garanderen dat het veilig is? Etc. etc.

Heb het gelezen, en begrijp nu het hele achterliggende stuk hiervan. heb het gelijk toegepast met dat stukje PHP script wat hun toevoegen op die pagina, en dan niet het simpele kopiëren plakken maar ook uiteraard wel even bekeken hoe het precies werkt. dankjewel voor je tips!

Het stuk van de input filtering had ik al vervangen door de tip van Cartman! ik kwam mijn oud gebruikte code tegen op die site met uitleg erbij waarom het idd niet goed was en het verschil tussen black en whitelisten. Wel intresant om dat even te lezen. zo leer je nog is wat. Bedankt voor je meedenken en info!

Devil schreef op zaterdag 14 september 2013 @ 22:16:
Welke PHP versie heb je draaien? Want PHP 5.5 heeft een simpele API voor password hashing. Dat is de veiligste keus voor als je zelf eigenlijk niet helemaal weet waar je mee bezig bent: http://www.php.net/manual/en/ref.password.php

En anders is crypt een hele goede optie, als je het maar goed gebruikt. En dat komt neer op een salt die lang genoeg is en random genoeg. Voor het genereren van een salt heb je echt geen csprng nodig, de functie van de salt is voorkomen dat een aanvaller rainbow tables kan gebruiken. Je wilt dus voorkomen dat hij/zij 'toevallig' de combinatie salt + password al eens eerder is tegengekomen of heeft uitgerekend. Als je salt lang genoeg is en behoorlijk random dan is die kans al nihil.

Overigens geldt voor alles wat je beschrijft dat het valt of staat met jouw implementatie, de filosofie kan goed zijn, maar als er een halfbakken implementatie achter zit dan heb je er nog weinig aan. Hoe genereer je bijvoorbeeld sessie ids voor in je cookie? Roteer je deze en zo ja hoe vaak. Hoe lang is een cookie geldig? Waar sla je het ip adres op dat gecontroleerd wordt? etc.

Ik draai PHP 5.3.17, ik had de oplossing voor die API idd al langs zien komen, alleen ondersteund mijn versie dat dus niet binnenkort maar is een update plannen in mijn directadmin systeem. Ik genereer een sessie ID door de tijd met een aantal andere userdata te combineren en daar een md5 hash van te maken. ook dit word binnenkort dus anders, mijn cookie is 1 maand geldig en het userid word gecombineerd met het IP en het sessie ID opgeslagen in de database.

Gomez12 schreef op zaterdag 14 september 2013 @ 23:46:
[...]

Wat bedoel je met het 2e gedeelte?

En tja, mijn algemene indruk is dat je net het laatste stukje kennis mist wat het verschil maakt tussen wel de namen van de technieken weten maar niet weten hoe die toe te passen en de technieken goed toepassen. En daardoor wordt ik altijd heel angstig dat je ergens anders een giga-gat hebt zitten wat je over het hoofd ziet.

Jouw gebruik van rand() (zonder min en max) heeft bijv leuke gevolgen op een windows platform.

Uitloggen op basis van ip vinden je mobiele gebruikers leuk...

Qua brute force zou ik wel het mailtje blijven hanteren, maar ik ben zelf meer van het verdubbelen van de inlogtijd bij elke foutieve inlogpoging, een mens merkt daar niet snel iets van, maar een brute force wordt redelijk zinloos als hij na 5 pogingen 1 sec per inlog moet wachten en poging 6 leidt tot 2 sec wachten. Je begint gewoon met 100 ms en zelfs de ergste gebruiker zal er nog na 24 uur weer inkunnen)

Uitloggen op basis van IP is voor de mobiele gebruikers zeker niet handig, maar de rede waarom ik het gedaan heb is uit extra beveiligingen maatregelen. Wat betreft je stukje over kennis ben ik niet iemand die alles al weet, al zeg ik je wel dat ik niet zomaar klakkeloos iets intik in de hoop dat het werkt, ook kopiëren plakken gaat er bij mij niet in. alle code is wel ergens op gebaseerd. maar kan zeker nog het een en ander leren

Ik denk dat ik de bruteforce als volgt ga oppakken, je hebt 5x om in te loggen na deze 5x krijg je een plaatje te zien welke je moet overtikken, doe je dit 2x fout dan word het inloggen elke keer langzamer wat de aanval aanzienlijk zal afremmen. Hiernaast zal de gebruiker ook een mailtje krijgen met als voorzorgen maatregel misschien wel het wijzigen van zijn password. Wat betreft de eisen van het wachtwoord. 1 hoofdletter minimaal 6 tekens en er moet 1 "Raar" karakter inzitten denk aan een @ of & etc..

Bedankt allemaal voor jullie tips! Zo leer je nog eens wat Als jullie nog tips/opmerkingen hebben hoor ik dat graag

[Devil]

sebasmac schreef op zondag 15 september 2013 @ 02:23:
Ik genereer een sessie ID door de tijd met een aantal andere userdata te combineren en daar een md5 hash van te maken. ook dit word binnenkort dus anders, mijn cookie is 1 maand geldig en het userid word gecombineerd met het IP en het sessie ID opgeslagen in de database.


[...]


Uitloggen op basis van IP is voor de mobiele gebruikers zeker niet handig, maar de rede waarom ik het gedaan heb is uit extra beveiligingen maatregelen. Wat betreft je stukje over kennis ben ik niet iemand die alles al weet, al zeg ik je wel dat ik niet zomaar klakkeloos iets intik in de hoop dat het werkt, ook kopiëren plakken gaat er bij mij niet in. alle code is wel ergens op gebaseerd. maar kan zeker nog het een en ander leren

Het is verstandig om het sessie id met een bepaald interval te roteren zo lang de gebruiker online is. Op die manier wordt session hijacking weer een stukje lastiger. Want als de gebruiker nu een maand lang het zelfde id houdt dan wordt de kans dat iemand dat ergens een keer weet te onderscheppen weer een stukje groter.

Ip spoofen is zo iets makkelijks dat het bijna niets toevoegt qua beveiliging, maar in dit geval dus wel de gebruikers irriteert.

[xos]

sebasmac schreef op zaterdag 14 september 2013 @ 18:56:
Daarnaast begint het natuurlijk bij de inputs op de site al, deze worden allemaal door een class heen gehaald die de XSS filter moet voorstellen. Dit bij elkaar lijkt al een sterke basis lijkt mij?

XSS preventie doe je bij voorkeur niet op de input maar op de output. XSS is niet beperkt tot html/javascript maar mocht je de data in de toekomst via json, xml, pdf, of ... gaan aanbieden dan zal je de output op de juiste manier moeten sanitezen voor je specifieke output formaat voordat je het aan de client serveert.

Verder is rand() geen verstandige keuze zoals voutloos ook al aanstipt. Gebruikt van sha512(${beperkte input}) geeft niet op een "magische" manier meer bits entropy. Sterker nog, door de mogelijkheid van collisions verlies je zelfs entropy, al zal dat in de praktijk wel mee vallen.

[Zoijar]

Nou kan het geen kwaad om niet rand() te gebruiken, maar men doet nu net of het een gigantisch lek is hier. Een salt hoeft niet crypto secure random te zijn, zolang het maar niet iha van te voren te voorspellen is, wat rand() niet is (tot op zekere hoogte). Ook heeft de entropy van de salt niets met password strength te maken; het geeft slechts aan hoeveel tables je van te voren moet genereren, en/of hoeveel users je tegelijk kan checken als je de database in handen hebt. 32 bits is hier in principe wel genoeg voor, maar het kan natuurlijk geen kwaad om het langer te maken omdat het niets kost. Better safe than sorry Dus gebruik een 256 bit crypto random salt, gewoon omdat het kan, maar lek was het voorheen niet.

[ Voor 9% gewijzigd door Zoijar op 15-09-2013 11:39 ]

[orf]

Devil schreef op zondag 15 september 2013 @ 10:52:
[...]
Ip spoofen is zo iets makkelijks dat het bijna niets toevoegt qua beveiliging, maar in dit geval dus wel de gebruikers irriteert.

Dat moet je misschien even uitleggen.

[X_lawl_X]

orf schreef op zondag 15 september 2013 @ 11:44:
[...]


Dat moet je misschien even uitleggen.

IP gebruiken om de sessie te valideren is vervelend voor mensen met een vaak wisselend IP adres (e.g. mobiel netwerk met smartphone, daar moet tegenwoordig echt rekening mee gehouden worden) - je wordt dan steeds uitgelogd.

[ Voor 14% gewijzigd door X_lawl_X op 15-09-2013 11:46 ]

[orf]

Ik doelde op "Ip spoofen is zo iets makkelijks dat het bijna niets toevoegt qua beveiliging"

[Cartman!]

Of je het IP aan de sessie wil binden is imo iets wat een keuze van de gebruiker moet zijn. Zelf heb ik het als opt-out ingesteld; standaard aan ip gelinkt en met een vinkje kun je die instelling uitzetten bij het inloggen. Hetzelfde voor de useragent overigens.

[Zoijar]

Waar je nog aan kan denken is ook een client-side js hash in te voeren zodat jij op de server helemaal nooit het wachtwoord kent. Nu heb jij in principe van al je gebruikers hun plaintekst wachtwoord als je dat zou willen afvangen. *Jij* kan nu hun wachtwoorden op andere sites proberen. Merk op dat als je client side hasht, je OOK server side alsnog dat moet doen. Het idee is alleen dat je client side elk plaintekst wachtwoord omzet in een (pseudo) 512 bit wachtwoord (ook weer met salt tegen makkelijk reversen met tables. Merk ook op dat 512 bits hash ruim genoeg is voor alle wachtwoorden, omdat dat zo'n 70 vrije karakters zijn).

[Devil]

orf schreef op zondag 15 september 2013 @ 11:47:
Ik doelde op "Ip spoofen is zo iets makkelijks dat het bijna niets toevoegt qua beveiliging"

Wikipedia: Internet protocol spoofing

Als ik jouw sessie cookie te pakken krijg dan kan gegarandeerd ook je ip adres te pakken krijgen en is het verder een koud kunstje om in te loggen op jouw account. Het feit dat je een ip adres opslaat bij de sessie houdt mij dan dus niet tegen. Qua beveiliging voegt het dus weinig extra veiligheid toe, terwijl het wel irritant is voor mobiele gebruikers.

[joppybt]

Grappig zoals iedereen er direct bovenop springt en (veelal) zinvolle wijzigingen voorstelt.

Niemand gaat echter in op de oorspronkelijk vraag: is het veilig genoeg?

Afhankelijk van wat de applicatie moet doen is de veiligheid misschien al meer dan voldoende en is de rest gewoon overkill.

Dus dan maar de vraag aan TS: Hoe veilig moet de applicatie zijn? Dan kunnen we gericht adviseren of jou oplossingen inderdaad veilig genoeg zijn.

[orf]

Devil schreef op zondag 15 september 2013 @ 11:56:
[...]

Wikipedia: Internet protocol spoofing

Als ik jouw sessie cookie te pakken krijg dan kan gegarandeerd ook je ip adres te pakken krijgen en is het verder een koud kunstje om in te loggen op jouw account. Het feit dat je een ip adres opslaat bij de sessie houdt mij dan dus niet tegen. Qua beveiliging voegt het dus weinig extra veiligheid toe, terwijl het wel irritant is voor mobiele gebruikers.

En waar staat dan precies dat Ip spoofen zo iets makkelijks is dat het bijna niets toevoegt qua beveiliging?

Hoe is het precies een koud kunstje als jij mijn IP adres "te pakken krijgt" om in te loggen op mijn account?

[Zoijar]

joppybt schreef op zondag 15 september 2013 @ 11:58:
Grappig zoals iedereen er direct bovenop springt en (veelal) zinvolle wijzigingen voorstelt.

Niemand gaat echter in op de oorspronkelijk vraag: is het veilig genoeg?

Afhankelijk van wat de applicatie moet doen is de veiligheid misschien al meer dan voldoende en is de rest gewoon overkill.

Als het geen extra moeite of belangrijke performance kost zie ik niet in waarom je het niet veiliger zou maken. Zoals ik bij rand() ook zei: dat is zeer waarschijnlijk wel veilig genoeg, maar wat is de moeite om er even een andere functie-call van te maken? 30 seconden werk en voor altijd een veiliger systeem.

Maar je hebt gelijk dat veiligheid *altijd* een vraag is of het veilig genoeg is. Elk systeem heeft een zwakke plek. In dit geval bijvoorbeeld de user die gewoon een zelfgekozen wachtwoord gebruikt. Zelfs als je hem dwingt minimaal 64 bits entropie te gebruiken, dan is de user's systeem de volgende zwakke schakel: een keylogger trojan bv. Daarna social engineering. Dan met een pistool tegen je hoofd je wachtwoord in moeten typen. Etc.

[ Voor 23% gewijzigd door Zoijar op 15-09-2013 12:03 ]

[Devil]

orf schreef op zondag 15 september 2013 @ 11:59:
[...]


En waar staat dan precies dat Ip spoofen zo iets makkelijks is dat het bijna niets toevoegt qua beveiliging?

Hoe is het precies een koud kunstje als jij mijn IP adres "te pakken krijgt" om in te loggen op mijn account?

De vraag is wat wil je voorkomen door een sessie IP afhankelijk te maken? Je wilt voorkomen dat iemand die je sessie id weet kan inloggen op jouw account.

Dat kan op twee manieren gebeuren, een aanvaller kan simpelweg de juiste user_id + session_id combinatie raden of brute forcen. Maar als de sessie ids random genoeg zijn is dat bijna niet te doen. Optie twee is het stelen van een sessie cookie.

Dus daar richt ik mij als hacker op (als ik die weg wil bewandelen). Op het moment dat ik je sessie cookie kan stelen dan kan ik je garanderen dat ik je ip adres ook kan achterhalen als bijvangst. Ik gebruik jouw sessie cookie en spoof je IP adres en voila ingelogd.

De sessie afhankelijk maken van een IP houdt mij als hacker dus totaal niet tegen, het is een klein hobbeltje meer niet. Want als ik al zo ver ben dat ik aan je sessie gegevens kan komen kan ik ook aan je IP komen.

Vervolgens kun je je dan als ontwikkelaar afvragen of dit minuscule hobbeltje het rechtvaardigt om de gebruikservaring van een bepaalde groep gebruikers te verpesten.

[orf]

Devil schreef op zondag 15 september 2013 @ 12:08:
[...]Ik gebruik jouw sessie cookie en spoof je IP adres en voila ingelogd.

Ok, nog een keer. Hóé spoof je mijn IP? Melden dát je het doet heb ik nu al drie keer gelezen.

[joppybt]

Zoijar schreef op zondag 15 september 2013 @ 12:01:
[...]

Als het geen extra moeite of belangrijke performance kost zie ik niet in waarom je het niet veiliger zou maken. Zoals ik bij rand() ook zei: dat is zeer waarschijnlijk wel veilig genoeg, maar wat is de moeite om er even een andere functie-call van te maken? 30 seconden werk en voor altijd een veiliger systeem.

Sommige voorstellen zijn inderdaad simpel genoeg om onvoorwaardelijk te implementeren.

Andere voorstellen (sessies koppelen aan IP-adressen, voorkomen van te veel foute inlogpogingen, client-side hashen van wachtwoorden, PHP moeten upgraden naar 5.5) zijn allemaal veel ingrijpender met mogelijk bijkomende risico's.
Het kan beter zijn om je te concentreren op enkele veiligheids features en die helemaal correct te implementeren, dan een heleboel features die eigenlijk net niet allemaal goed zijn geimplementeerd.

[Zoijar]

joppybt schreef op zondag 15 september 2013 @ 12:11:
Sommige voorstellen zijn inderdaad simpel genoeg om onvoorwaardelijk te implementeren.

Andere voorstellen (sessies koppelen aan IP-adressen, voorkomen van te veel foute inlogpogingen, client-side hashen van wachtwoorden, PHP moeten upgraden naar 5.5) zijn allemaal veel ingrijpender met mogelijk bijkomende risico's.
Het kan beter zijn om je te concentreren op enkele veiligheids features en die helemaal correct te implementeren, dan een heleboel features die eigenlijk net niet allemaal goed zijn geimplementeerd.

Klopt. Helemaal mee eens.

Het is overigens waarschijnlijk nog beter om gewoon een bestaand time-tested systeem te pakken

[begintmeta]

Bij authenticatie over internet IPs spoofen is niet zo makkelijk toch? Je moet dan op de een of andere manier het de hele antwoordketen ook beheersen.

[Devil]

orf schreef op zondag 15 september 2013 @ 12:10:
[...]


Ok, nog een keer. Hóé spoof je mijn IP? Melden dát je het doet heb ik nu al drie keer gelezen.

Jij vraagt mij nu om jou hier uit te gaan leggen hoe je in de praktijk een ip adres kun spoofen? Stap voor stap instructie erbij toevallig?

[Verwijderd]

Een packet spoofen is doodsimpel. Een TCP sessie spoofen is via internet erg lastig.

[orf]

Devil schreef op zondag 15 september 2013 @ 12:19:
[...]

Jij vraagt mij nu om jou hier uit te gaan leggen hoe je in de praktijk een ip adres kun spoofen? Stap voor stap instructie erbij toevallig?

Nee.

Je geeft hier (tot drie keer) aan dat het heel makkelijk is en dat iedereen het kan. Als ik dan vraag hoe je dat dan zo makkelijk doet, reageer je met een link naar een wikipedia-artikel waarin staat dat het niet zo makkelijk is.

Is het makkelijk om een IP te spoofen en op die manier een sessie over te nemen als die sessie gelocked wordt aan een IP?

[mrc4nl]

Devil schreef op zondag 15 september 2013 @ 12:19:
[...]

Jij vraagt mij nu om jou hier uit te gaan leggen hoe je in de praktijk een ip adres kun spoofen? Stap voor stap instructie erbij toevallig?

proxy is een manier zover ik weet

[Gomez12]

orf schreef op zondag 15 september 2013 @ 12:22:
[...]
Is het makkelijk om een IP te spoofen en op die manier een sessie over te nemen als die sessie gelocked wordt aan een IP?

Mits je op hetzelfde eindpunt zit (inet-cafe met 1 wifi-router bijv) is het easy-peasy (gewoon harder schreeuwen dan een normale pc dat jij ip-adres x bent)

Zitten er meerdere routers tussen (zoals op het internet) dan wordt het bijna onmogelijk (om het bruikbaar te krijgen) zonder extreem veel te moeten hacken. Het probleem zit hem simpelweg in de route die de antwoorden moeten nemen, alle routers weten dat het bijv naar xs4all moet dus dumpen die het op het xs4all netwerk, wil jij als telfort-klant een xs4all adres (bruikbaar) spoofen dan zal je allerlei internet-routers moeten aanpassen zodat verkeer naar dat ene xs4all-adres op het telfort-netwerk gedumpt wordt.

Dat is echter als je echt een complete verbinding wilt spoofen. Wil je enkel maar een webserver overhoop helpen dan kan je wel gewoon je eigen "ip-adres" op tcp-niveau veranderen zodat de server denkt dat jij iemand anders bent, alleen krijg je dan totaal geen antwoord van de server (want die stuurt alles naar het ip-adres wat jij zegt te zijn) via alle bestaande routeringen die de server (en de tussenliggende routers) kent.

Dus tja, zie je iemand op een gratis wifi-punt die website browsen dan kan je je op datzelfde wifi-punt aanmelden en heb je enkel het sessie-id nodig (spoofen is dan bijna nooit noodzakelijk omdat de meeste routers NAT toepassen, maar zou er geen NAT tussenzitten dan is het simpel te spoofen omdat je enkel maar harder hoeft te schreeuwen als de andere pc)

mrc4nl schreef op zondag 15 september 2013 @ 12:36:
[...]

proxy is een manier zover ik weet

Proxy spoof je geen ip-adres mee (plus dat je nog eens de technische uitdaging hebt dat je eerst de client via die proxy moet krijgen, of je moet een proxy op die client kunnen installeren zodat je fysiek via zijn ip-adres pakketten verzend)

[Zoijar]

Ik vraag me wel af hoe je een established SSL connectie spoofed. En als je er al vanaf het begin af aan tussen zit, dan is niets veilig, mede omdat je bijvoorbeeld dan gewoon het wachtwoord kan uitlezen

[ Voor 52% gewijzigd door Zoijar op 15-09-2013 12:49 ]

[Gomez12]

Zoijar schreef op zondag 15 september 2013 @ 12:47:
Ik vraag me wel af hoe je een established SSL connectie spoofed.

Waarom zou je een established SSL connectie moeten spoofen? Dat is enkel nodig als de beveiliging ook unieke elementen uit de established SSL connectie pakt, dat heb ik eerlijk gezegd nog nooit gezien.
Oftewel alle beveiligingen die ik ken kan je gewoon een nieuwe SSL-connectie starten en de server-code checked alleen maar of je wel een SSL-connectie hebt.

Je code baseren op established SSL connecties is ook een extreem zwaar iets en kan tegen je gaan werken als je site groter wordt (de meeste grote sites gebruiken SSL-offloaders om het "zware" SSL verkeer af te handelen en dan heeft de code niets meer te maken met SSL)

[Zoijar]

Gomez12 schreef op zondag 15 september 2013 @ 12:55:
Waarom zou je een established SSL connectie moeten spoofen? Dat is enkel nodig als de beveiliging ook unieke elementen uit de established SSL connectie pakt, dat heb ik eerlijk gezegd nog nooit gezien.
Oftewel alle beveiligingen die ik ken kan je gewoon een nieuwe SSL-connectie starten en de server-code checked alleen maar of je wel een SSL-connectie hebt.

Je code baseren op established SSL connecties is ook een extreem zwaar iets en kan tegen je gaan werken als je site groter wordt (de meeste grote sites gebruiken SSL-offloaders om het "zware" SSL verkeer af te handelen en dan heeft de code niets meer te maken met SSL)

Ah ja, het ging er natuurlijk alleen om het geval dat je de sessie details al hebt. foutje

[sebasmac]

Allereerst bedankt voor al jullie info, geeft me inzicht hoe het precies in elkaar zit. Samen met wat ander leesvoer ben ik al een heel stuk wijzer geworden thx!

joppybt schreef op zondag 15 september 2013 @ 11:58:
Grappig zoals iedereen er direct bovenop springt en (veelal) zinvolle wijzigingen voorstelt.

Niemand gaat echter in op de oorspronkelijk vraag: is het veilig genoeg?

Afhankelijk van wat de applicatie moet doen is de veiligheid misschien al meer dan voldoende en is de rest gewoon overkill.

Dus dan maar de vraag aan TS: Hoe veilig moet de applicatie zijn? Dan kunnen we gericht adviseren of jou oplossingen inderdaad veilig genoeg zijn.

Wat betreft hoe veilig het moet zijn. het is eigenlijk heel simpel de gebruiker registreert zich en als hij inlogt moet hij wat persoonlijke dingetjes in kunnen stellen denk hierbij aan adres en wachtwoord veranderen etc.. meer is het niet, maar des ondanks dat wil ik wel gewoon dat het veilig is. vandaar mijn vraag.

Sessie's op IP is dus een beetje overbodig als ik gewoon zorg dat het ID gewisseld word eens in de zoveel tijd heeft de gebruiker verder ook geen last als hij wisselt met zijn telefoon via wifi of 3G. Wat betreft de brute force attacks. Ik heb het nu zo opgelost dat na 5x inloggen een CAPTCHA plaatje verschijnt. mocht deze 5x fout zijn dan word de pagina steeds langzamer wat begint met een ms of 200 verdubbeld steeds als de gebruiker nog een keer fout inlogd. Waar ik alleen even tegenaan loop is dat de gebruiker waarvan het account dan wel is ook een langzame pagina heeft als hij bijvoorbeeld 1x zijn wachtwoord verkeerd intypt omdat hij niet weet dat misschien iemand anders het al 50x geprobeerd heeft bij hem. IP kan je dan niet afschermen want een beetje slimme hacker veranderd steeds van ip. iemand ideeën?

[Gomez12]

sebasmac schreef op zondag 15 september 2013 @ 13:27:
Wat betreft hoe veilig het moet zijn. het is eigenlijk heel simpel de gebruiker registreert zich en als hij inlogt moet hij wat persoonlijke dingetjes in kunnen stellen denk hierbij aan adres en wachtwoord veranderen etc.. meer is het niet, maar des ondanks dat wil ik wel gewoon dat het veilig is. vandaar mijn vraag.

Lol, meer is het niet.

Zie ook : http://wetten.overheid.nl...ldigheidsdatum_15-09-2013
of
http://www.cbpweb.nl/Pages/home.aspx

Ik zou zeggen, blijf weg van de persoonlijke dingetjes / NAW-gegevens.

[Cartman!]

Devil schreef op zondag 15 september 2013 @ 12:08:
[...]
Dus daar richt ik mij als hacker op (als ik die weg wil bewandelen). Op het moment dat ik je sessie cookie kan stelen dan kan ik je garanderen dat ik je ip adres ook kan achterhalen als bijvangst. Ik gebruik jouw sessie cookie en spoof je IP adres en voila ingelogd.

En hoe ga jij het ip-adres precies spoofen dan? Of doe je de aanname dat je toegang hebt tot het lokale netwerk van je doelwit? Want als ik nu mijn ip-adres geef denk ik niet dat jij het voor elkaar krijgt je voor te doen als mijn ip-adres zegmaar.

[Devil]

Jongens, ik ga niet vertellen hoe je een sessie of ip adres spoofed. Gebruik Google en thinking outside of the box. Verder heeft de TS hier ook niet veel aan.

Vanuit een security oogpunt gedacht: welke grote bedrijven (Twitter,Google,Facebook) fixen je sessie aan je ip en wordt je dus uitgelogd wanneer je bijvoorbeeld switched van wifi naar 3G?

Waarom zou het bij jou dan wel nodig zijn?

[orf]

Devil schreef op zondag 15 september 2013 @ 20:36:
Jongens, ik ga niet vertellen hoe je een sessie of ip adres spoofed. Gebruik Google en thinking outside of the box. Verder heeft de TS hier ook niet veel aan.

Vanuit een security oogpunt gedacht: welke grote bedrijven (Twitter,Google,Facebook) fixen je sessie aan je ip en wordt je dus uitgelogd wanneer je bijvoorbeeld switched van wifi naar 3G?

Waarom zou het bij jou dan wel nodig zijn?

Het is heel makkelijk en iedereen kan het maar je moet "outside of the box thinken".
IP spoofen op internet is NIET makkelijk. Een pakketje kun je prima spoofen, maar het antwoord van de webserver komt dan niet bij jou terecht waardoor je er niets aan hebt. Niet zomaar wat roepen en als mensen dan doorvragen zeggen dat ze het maar moeten Googlen of smileys als deze geven:

[Zoijar]

Devil schreef op zondag 15 september 2013 @ 20:36:
Jongens, ik ga niet vertellen hoe je een sessie of ip adres spoofed. Gebruik Google en thinking outside of the box. Verder heeft de TS hier ook niet veel aan.

Vanuit een security oogpunt gedacht: welke grote bedrijven (Twitter,Google,Facebook) fixen je sessie aan je ip en wordt je dus uitgelogd wanneer je bijvoorbeeld switched van wifi naar 3G?

Waarom zou het bij jou dan wel nodig zijn?

Facebook ed. werken met predicted trusted IPs (of hoe ze het ook noemen). Als volgens jouw sociale netwerk een IP redelijkerwijs bij jou kan horen, bv als een van je veel bekeken vrienden dit IP wel eens heeft gebruikt, en het IP mapt op een geografische regio in de buurt, dan wordt er aangenomen dat het wel goed zal zijn. Echter log maar eens in via Tor met een compleet vreemd IP uit een ander land, dan lockt hij je account meteen.

(en beken gewoon je ongelijk, niks mis mee. Iedereen zegt wel eens iets te snel dat dan onderuit wordt gehaald. Zie mijzelf boven Dat kan je gewoon toegeven hoor.)

[ Voor 8% gewijzigd door Zoijar op 16-09-2013 00:12 ]

[Verwijderd]

Misschien beetje uit te scope van dit topic, maar ik raad ook zeker aan om je firewall goed in te stellen en eventueel extra controle uit te voeren alvorens de paketten geleverd worden aan de PHP engine. Zelf gebruik ik hiervoor Fail2ban, maar er zijn talloze pakketten beschikbaar en je kan eventueel je eigen scripts schrijven om je iptables te updaten. Je kan dit ook met PHP, maar ik ben hier vanaf gestapt omdat ik merkte dat dit veel meer load op je server legt. Met fail2ban worden verdachte pakketten gecontroleerd VOOR ze verwerkt worden door de processor, wat veel effecienter is.

[xehbit]

Nog niet getest, maar zou je zo iets niet kunnen gebruiken?

Voor het tegengaan dat je sessie wordt gestolen.

PHP:

    session_start();

    if(isset($_SESSION['fingerprint']))
    {
        if(strcmp($_SESSION['fingerprint'], md5($_SERVER['HTTP_USER_AGENT'])) !== 0)
        {
            unset($_SESSION);
            exit();
        }
    }
    else
    {
        $_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT']);
    }

[ Voor 6% gewijzigd door xehbit op 16-09-2013 10:32 ]

[Barryvdh]

Nog over het password hashen in 5.5; met deze library: https://github.com/ircmaxell/password_compat kan je het gewoon gebruiken in versies van 5.3.7, met precies dezelfde API en soortgelijke implementatie (in PHP ipv C). Maakt het een stuk makkelijker om goede salts ed. te maken.

En wil je HTML laten zien op je website? Zo niet, kan je ook gewoon standaard htmlentities() toepassen.
En ipv IP koppelen zie je volgens mij ook vaak dat je wel kan inloggen via cookies, maar dat je dan geen wachtwoord kan aanpassen of gevoelige informatie kan zien (en dus nogmaals je wachtwoord moet invullen)

[ Voor 36% gewijzigd door Barryvdh op 16-09-2013 09:45 ]