PHP forms og sikkerhet

En tråd i 'PHP, SQL og databaser' startet av Zolic, 20 Aug 2009.

  1. Zolic Medlem

    Innlegg:
    52
    Om du bruker singel- eller double-quotes skal være ett fett, men det må brukes konsekvent i start og slutt.
    Men om du ser det jeg har uthevet, så er den escapet i PHPen, fordi jeg bruker singel-quotes. Og det med understrek skal ikke være der, da det legges til etter addcslashen... og må ha singel-quote, da det er det som er brukt i starten.
     
    Tonny Kluften liker dette.
  2. Tonny Kluften

    Tonny Kluften Administrator

    Innlegg:
    15.966
    Tja.

    Zolic sin:
    gir:

    Warning: preg_match() [function.preg-match]: No ending delimiter '^' found in ...

    Det samme gjør erlinglothe sin.
     
    Sist redigert: 20 Aug 2009
  3. Zolic Medlem

    Innlegg:
    52
    Kode:
    function genVal($str)
    {
    	if(empty($str))
    	{
    		return false;
    	}	
    	$TryggeChars = addcslashes('.!?.\'*|$[]%#^/:;', '.!?.\'*|$[]<>%#^/:;').'\\w\\pL \\(\\)\\&-';
    	if(preg_match('/^['.$TryggeChars.']+\\z/um', $str))
    	{
    		return $str;
    	}
    	return false;
    }
    Denne er testet...
     
    Tonny Kluften liker dette.
  4. Tonny Kluften

    Tonny Kluften Administrator

    Innlegg:
    15.966
  5. Mr Vest

    Mr Vest Sjefen over alle sjefer!

    Innlegg:
    2.079
    Tror jeg ble litt klokere her av denne tråden, så nå har jeg kommet meg fra amatør på sikkerhet til litt mindre amatør på sikkerhet, dog enda amatør.

    Hele greia er altså at det holder og bare sperre alle inputs som printes ut på nettsiden for html / javascript, mens alt som forsåvidt kjører innhold opp i databasen kan inneholde så mye html/javascript det bare vil, uten at det på noen måte vil kunne ødelegge for sikkerheten? Det holder altså?
     
  6. Zolic Medlem

    Innlegg:
    52
    PÅ veldig generelt basis så skal en alltid validere eller vaske inndataen, så den dataen som blir sendt videre i applikasjonen kun innholder det som forventes.

    Når dataen skal sendes til et subsystem(database, nettleser, e-post, andre programmer) så skal dataen, som nå er blitt en utdata, escapes.
    Og her er det viktig at riktig medtode brukes. Eksempel vis, så skal ikke data som skal til databasen bli escapet med htmlentities, og utdata som skal til nettlesern skal ikke escapes av en database funksjon.

    Poenget med å escape er å uskadeligjøre meta-tegn, altså tegn med en betydning for subsystemet det blir sendt til.

    @Atle: så ja, data som lagres i databaser tar ikke skade av å HTML/javascript, så lenge meta-tegnene til databasen er escapet i $stringen.
    Men det er også viktig at når denne dataen blir hentet utigjen for å vises på en side, at den blir escapet for html... om det ikke er meningen at HTMLen skal vises.

    Så kan en jo også da det lengre, noe HTML skal være lov, annet ikke ;)
     
    Sist redigert: 21 Aug 2009
  7. Mr Vest

    Mr Vest Sjefen over alle sjefer!

    Innlegg:
    2.079
    Dette første eksempelet henter ut all html dra databasen med sql-query. Her har jeg lagt inn verdiene som den egentlig henter ut fra databasen.

    PHP:
    $url='<a href="http://google.com" title="Google.com">';
    echo 
    $url;
    Blir dette galt, og vil være en sikkerhetsrisiko? Mens den egentlig burde være som følger?:

    PHP:
    $url='http://google.com';
    $url_ut htmlspecialchars($urlENT_QUOTES);
    $tittel='Google.com';
    $tittel_ut htmlspecialchars($tittelENT_QUOTES);
    echo 
    '<a href="$url_ut" title="$tittel_ut">';
    Mulig jeg er helt på jordet her nå? Jeg skal lese litt mer om dette her for og forstå det, men spør nå også litt for og få et par kakk i hodet før jeg lærer meg mye med det.
     
    Sist redigert: 21 Aug 2009
  8. Zolic Medlem

    Innlegg:
    52
    det kommer jo litt ann på, om det bare er du som har lov til å legge inn linkene, så er det jo ikke noe problem...

    Men om det er andre bruker som kan legge inn, så ja da burde det deles opp, slik du sier. Men Det burde ikke være nødvendig å outputespace selve URLen. Det som er viktig er at den blir validert på vei inn, sjekke om det faktisk er en url.
    Men Tittelen kan gjerne bli outpu-escaped da den kan inneholde tegn som kan ha betydning i html.
    (forskjellen er at urlen trenger disse tegnene for å fungere)

    Så om jeg har forstått det du spørr om rett, så blir da slik:

    PHP:
    $url='http://google.com';
    $tittel='Google.com';
    $tittel_ut htmlspecialchars($tittelENT_QUOTES);
    echo 
    '<a href="'.$url.'" title="'.$tittel_ut.'">';
    Om du hadde output-escaped URLen, så ville du ha ødlagt linker på dette formate http://link.tld/id=0&sid=23
    der hadde & til &amp;
     
    Sist redigert: 21 Aug 2009
    Mr Vest liker dette.
  9. Mr Vest

    Mr Vest Sjefen over alle sjefer!

    Innlegg:
    2.079
    Ja, det har du jo ret ti ja. Tenkte jeg ikke på i farten når jeg skrev dette over.

    Men altså, du sier.: "det kommer jo litt ann på, om det bare er du som har lov til å legge inn linkene, så er det jo ikke noe problem..." Det kan jeg jo forstå, men allikevel blir jeg litt nysjerrig da.

    Hvorfor er det da en "sikkerhetsrisiko" med tallet i denne URL?:

    Gaveland.com - Gratis gavekort for alle

    Det er jo bare jeg som har rettigheter til og skrive inn tallet som skal printes ut.
     
  10. Zolic Medlem

    Innlegg:
    52
    Men du kan ikke stoppe noen i å endre tallet som står i adressefeltet til noe annet, så trykke enter på nytt.

    Linken du lager en ut-data, men i det øyeblikket det er hos brukeren, og den bestemmer seg for å sende en request... så blir det inn-data, og da må det på nytt valideres, for å se at ikke det har blitt endret.

    For det er ingen ting som stopper meg i å endre det fra ?id=23 til ?id=23;DROP TABLE tbl_innhold
     
  11. skogtrollet

    skogtrollet Medlem

    Innlegg:
    208
    DROP TABLE tbl_innhold

    I mysql går det ikke an å ha mange querys i en spørring. Menne likevel går det an å hente ut hele databasen, noe som er skummelt.

    Men du blander mellom xss og sql injection. Det vi egentlig snakker om her, er hvordan forhindre alle typer angrepsklasser.
     
  12. Mr Vest

    Mr Vest Sjefen over alle sjefer!

    Innlegg:
    2.079
    Hehe, jeg blander nok sikkert mellom litt av hvert på dette området. Det er jo slik det er og være totalt amatør, og det forandrer seg jo ikke uten og spørre. :)
     
  13. Zolic Medlem

    Innlegg:
    52
    Må rette litt på meg selv her, i PHP med vanlig MySQL extension så er ikke akkurat denne typen injection mulig. Da mysql_query har noen innebygde sperrer... Om det faktisk er riktig måte å håndtere sikkerhet kan diskuteres, for de fjerer en del muligheter for litt mer avanserte spørringer.

    Men for all del: ikke tro at mysql_query er trygt å bruke blindt for det, alle de andre metodene er fortsatt reelle trusler.
     

Del denne siden