PHP forms og sikkerhet

[Zolic]

Er vel fortsatt bom?

Denne er vel bedre

$TryggeChars = addcslashes(".!?.\'*|$[]%#^/:;", ".!?.\'*|$[]<>%#^/:;').'\\w\\pL \\(\\)\\&-");

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]

Tja.

Zolic sin:

$TryggeChars = addcslashes('.!?.\'*|$[]%#^/:;', '.!?.\'*|$[]<>%#^/:;').'\\w\\pL \\(\\)\\&-';
if(preg_match('^['.$TryggeChars.']\\z/um', $str))

gir:

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

Det samme gjør erlinglothe sin.

 

[Zolic]

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]

Perfekt. Tusen takk.

 

[Mr Vest]

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å?

 

[Zolic]

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

 

[Mr Vest]

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.

$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?:

$url='http://google.com';
$url_ut = htmlspecialchars($url, ENT_QUOTES);
$tittel='Google.com';
$tittel_ut = htmlspecialchars($tittel, ENT_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.

 

[Zolic]

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:

$url='http://google.com';
$tittel='Google.com';
$tittel_ut = htmlspecialchars($tittel, ENT_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;

 

[Mr Vest]

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.

 

[Zolic]

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

 

[skogtrollet]

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.

 

[Mr Vest]

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.

 

[Zolic]

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

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.