php haalt veilig sessiegegevens op

Ik ben hashing-wachtwoorden, matchende user-agents bij het lezen van sessiegegevens en alles wat nodig is om gebruikers veilig in te loggen. Ik ben geïnteresseerd in manieren om sessiegegevens veilig te achterhalen/lezen. Ik gebruik bijvoorbeeld een functie die de gebruikers-ID uit een sessiegegevensmatrix haalt ...

In db-tabel:

a:6:{s:9:"user_data";s:0:"";s:7:"user_id";s:1:"3";s:9:"firstname";s:4:"Tina";s:8:"lastname";s:3:"Fey";s:8:"username";s:8:"lizlemon";s:6:"status";s:1:"1";}

Functie (Codeigniter):

    function get_user_id()
    {
        if (is_numeric($this->ci->session->userdata('user_id'))) 
        {
            return $this->ci->session->userdata('user_id');
        }
        else
        {
            exit();
        }
    }

Ik controleer alleen of het ID numeriek is. Moeten we ons zorgen maken over het ophalen van sessiegegevens, ook al is deze veilig toegevoegd aan de database?

3
@JaredFarrish Ik heb niet geprobeerd er mee te knoeien. Ik probeer zo veel mogelijk beveiliging toe te voegen omdat alle db-interacties afhankelijk zijn van het gebruikers-ID.
toegevoegd de auteur CyberJunkie, de bron
Waarschuwing: als u te maken hebt met een externe service zoals een cloudserver of iets anders, waar u een tijdje geen toegang hebt, moet u proberen de integriteit te controleren en opnieuw te valideren wat nodig is om te vertrouwen.
toegevoegd de auteur Jared Farrish, de bron
Als je door het proces van integriteitscontrole gaat nadat je het terughaalt in het geheugen van de db, vermoed ik dat ik het opnieuw valideer? Het lijkt niet nodig, maar ik weet zeker dat er een hoek is die iemand heeft of kan bedenken. Als JIJ het daar neerlegt, zou je het moeten kunnen vertrouwen, maar werd er in die staat mee geknoeid?
toegevoegd de auteur Jared Farrish, de bron

1 antwoord

U moet NOOIT uw eigen sessie-afhandelingsprogramma schrijven. Gebruik sesion_start() en de $ _ SESSION [] super globaal. Dit opent ook de deur naar het gebruik van de PHP-beveiligingssessie functies , zoals cooke_secure, http_only cookies en use_only_cookies.

session_start() genereert een zeer veilige sessie-id die een cryptografische nonce is. U kunt PHP configureren om deze waarde uit /dev/urandom te halen, wat een zeer veilige entropiepool is en waarschijnlijk de beste manier om een ​​sessie-ID te genereren.

4
toegevoegd
@ Cyber-Guard Enterprise in mijn bericht zeg ik om/dev/urandom te gebruiken als de bron van entropie, wat een eenvoudige wijziging is in je php.ini.
toegevoegd de auteur rook, de bron
@poncha het lijkt een abstractie bovenop php's sessies omdat het veel van dezelfde functies heeft. Ik zou het mis hebben.
toegevoegd de auteur rook, de bron
@ unity100 Wat? PHP sessie handler is peer-reviewed en heeft veel patches ondergaan. Tenzij je een Fortune 500-bedrijf bent, heb je niet zoveel middelen om je eigen sessie-afhandelaar te verbeteren. Je kunt de sessie-afhandelaar van PHP veiliger maken door je php.ini aan te passen. U kunt LFI-aanvallen en sessieopeningsaanvallen voorkomen door PHP correct te configureren.
toegevoegd de auteur rook, de bron
@ unity100 als je naar mijn exploits kijkt, zie je dat ik de/tmp-map gebruik in exploitatie. (Kijk naar het beveiligingslek met betrekking tot het uitvoeren van externe code-code) ... en gebruik de verdomdesession-handler die in je platform is ingebouwd! Wees niet een dwaas!
toegevoegd de auteur rook, de bron
@ unity100 Als pentester zijn de beste exploits die ik heb geschreven voor een stukje code wanneer de programmeur denkt dat hij iets slims doet, terwijl het in feite ontzettend gevaarlijk is.
toegevoegd de auteur rook, de bron
@ unity100 Stel het wiel niet opnieuw uit. Bouw voort op de veilige systemen die aan u zijn gegeven. Schrijf exploit-code.
toegevoegd de auteur rook, de bron
@ unity100 exploit-db.com/author/?a=628 hebben een mooie dag!
toegevoegd de auteur rook, de bron
@ unity100 Ik denk dat je nog nooit een systeem hebt geëxploiteerd in je hele leven en je begrijpt de bedreigingen die we allemaal tegenkomen niet. De draad is gevallen.
toegevoegd de auteur rook, de bron
Vertel dat aan CodeIgniter-ontwikkelaars (want dat is wat OP gebruikt ...) codeigniter.com/user_guide/libraries /sessions.html
toegevoegd de auteur poncha, de bron
Het is misschien het vermelden waard (hoewel ik het volledig eens ben met het antwoord) dat zelfs de php-gegenereerde sessie-id tijdens het teruggaan op facebook in gevaar is gekomen, met behulp van een combinatie van informatieverzameling en brute force-aanvallen; dus ik zou zeggen dat php-sessies relatief veilig zijn (de bug is verholpen door meer willekeurige entropie toe te voegen in latere versies)
toegevoegd de auteur cyber-guard, de bron
Als u de/tmp-map in exploitatie gebruikt, waarom raadt u de OP aan om NOOIT iets te gebruiken buiten de sessieaanpak van php? Zodat er meer webservers/sites zullen worden geëxploiteerd? Het toegeven dat php-sessies worden getarget door/tmp-exploits en vervolgens iemand aanbevelen om NOOIT iets anders te gebruiken dan php-sessies die standaard tmp-map gebruiken, is in tegenspraak.
toegevoegd de auteur unity100, de bron
Afgezien van het krijgen van een 404-pagina, is het volkomen dwaas om expertise op een breed terrein te claimen door te proberen te bewijzen dat je een paar exploits hebt geschreven. Ik zal de achtervolging in de wacht slepen en je net informeren: de meest voorkomende aanval die tegen php-websites op het internet komt, is afkomstig van webshells die worden verwijderd door bestandsuploads naar/tmp-mappen, die dan de leiding over de/tmp-map proberen te nemen . Wat tientallen honderden websites die in één keer op gedeelde hosts zitten gemakkelijk kan schaden. En php-sessies gebruiken standaard de map/tmp. Krijg een opleiding. verruim uw horizon. En zeg nooit nooit meer.
toegevoegd de auteur unity100, de bron
Of je hebt niet begrepen wat ik zojuist heb beantwoord, of je bent gewoon gefixeerd en vasthoudend. In beide gevallen laat ik deze thread vallen. Mijn laatste woord is - iemand die zich er niet eens van bewust is dat/tmp-directory's, plaatsen waar lamp-webservers hun php-sessiebestanden behouden een van de topdoelen voor webshells zijn, anderen niet adviseren over de veiligheid en beveiliging van sessiesystemen. En voor het geval je het niet weet, zijn er eindeloos veel websites nog steeds op gedeelde hosts.
toegevoegd de auteur unity100, de bron
Vertel dat aan de eindeloze aantallen bots die door het internet zwerven webshells en soortgelijke naar/tmp-mappen van webservers te droppen en de mensen die niet in staat zijn te veranderen waar ze php-sessiebestanden bewaren, laten ze opzij om ze in het geheugen te houden, als gevolg van gedeelde hostbeperkingen . dit is waarom ik je vertelde wat ik eerder vertelde - er zijn eindeloze omstandigheden bij i.t. wereld. het woord 'nooit' is nooit correct.
toegevoegd de auteur unity100, de bron
Flexibel zijn en dingen op een andere manier moeten doen is geen monopolie van 'fortune 500'-bedrijven, noch de rest van het internet die niet wordt omringd door een Fortune 500-bedrijf, zijn mensen met' mindere behoeften 'en daarom' kan doe met minder '. Er zijn veel verschillende soorten bedrijven, applicaties die internet vullen met veel verschillende behoeften en doelstellingen. De stelling dat 'sommige mensen misschien iets niet nodig hebben' is een algemene verklaring die ongeldig wordt op het moment dat ze wordt uitgegeven.
toegevoegd de auteur unity100, de bron
NOOIT zijn eigen sessie-afhandelaar schrijven en in plaats daarvan alleen php-sessies gebruiken? Waarom is dat ? PHP-sessies zijn kwetsbaar voor aanvallen vanuit verschillende invalshoeken - een van de meest misbruikte methoden bij het infecteren van webserver is het droppen van een webshell en het overnemen van de/tmp-map - dat is waar de meeste servers php-sessiebestanden bewaren. Zelfs als je de map van de standaard wijzigt, kun je nog steeds op dezelfde manier gecompromitteerd raken als je bestandssysteem om welke reden dan ook in gevaar wordt gebracht. De logica voor het genereren van PHP-sessies is op een zonnige dag niet zomaar uit de hemel gevallen. U kunt een veiliger systeem maken door dat te verbeteren.
toegevoegd de auteur unity100, de bron