Onderwerp: PHP - Veilige SQL injectie Deel 2

Aangaande op wat ik in eerder discussies en via Google etc gelezen heb ben
ik een hoop wijzer geworden maar nog steeds heb ik niet het hele plaatje
compleet. Stapsgewijs zou ik nu als volgt programmeren:

1) In principe maakt het allemaal niet zo gek veel uit of je gebruik maakt
van $_SESSION variabelen of niet. Ik zal dat wel doen omdat je dan heel
makkelijk tussen verschillende pagina's van een uit meerdere pagina's
bestaand formulier kan manouvreren. Tenzij je een hele diepe beveiliging
gaat toepassen met vastleggen van IP-adressen etc. etc. kan iedereen met een
beetje moeite je sessie kapen en misbruiken. Als je daarvan uitgaat kan je
een hoop ellende voorkomen.
2) Controleer de invoer. Niet met Javascript ( clientside ) want dat heeft
dus weinig nut wanneer iemand kans ziet een variablele bijvoorbeeld via de
URL mee te sturen. Bijvoorbeeld een postcode; je controleert of de variablel
$postcode bestaat uit 4 cijfers, eventueel een spatie en vervolgens weer 2
letters. Maar als iemand bijvoorbeeld na het lezen van je broncode in de
adresbalk van je browser intypt :
http://www.jouwdomein.ha/form_handle..._kan_verzinnen
heb je alsnog een probleem.
3) Controleer de invoer; Comboboxes controleer je serverside door te kijken
of de waarde van de variabele met 1 van de mogelijkheden waaruit gekozen kon
worden. Van telefoonnummers kun je verwijderen wat geen cijfers, haakjes of
een plus is( +31(0)10123456789 ), e-mailadressen kun je valideren en de rest
verwijderen, numeriek bedoelde velden numeriek houden en probeer het aantal
maximale tekens dat voor een veld opgegeven wordt zo laag mogelijk te houden
( een telefoonnummer bijvoorbeeld niet langer als 15 cijfers ) zodat de kans
op een 'lange' SQL injectie verkleind wordt.
3a) Controleer de invoer; iemand die mij kan vertellen hoe ik bijvoorbeeld
een omschrijving van een wandelroute ( textarea ) moet controleren op SQL
injecties of andere foute code?????
4) Controleer de invoer; maar niet door te zeggen; deze dingen mogen niet
maar juist; deze dingen mogen wel.
5) Als je variabele INCLUDES gebruikt gebruik dan als waardes geen
pagina-namen ( script1.php , script2.php, scrip3.php ) maar cijfers of
letters en verwerk deze via de SWITCH / CASE / DEFAULT manier. ( Case "1" :
include("script1.php") ; Break ; Default : include("warning.php") ; )
6) Bij ECHO laat je variabelen altijd buiten de quotes, volgens mij zo :
echo "dit is nummer".$n." van zovelen ";
7) Bij INSERT of UPDATE naar een MySQL db zal ik in ieder geval ADDSLASHES
gebruiken, ik neem aan dat die alle quotes en andere speciale tekens
onschadelijk maakt door er slashes voor te plaatsen.
8) Plaats ook te inserten variabelen tussen single quotes ( en tussen
accolades {}????? al snap ik nog steeds niet waarom )
9) Bij het weergeven van data uit een DB de code dmv bestaande functies
zuiveren van HTML/ SCRIPT codes etc. Dit moet ik nog allemaal uitzoeken.

Ben ik zo op de goede weg?

Alvast bedankt.


Haico

Haico wrote:
> Aangaande op wat ik in eerder discussies en via Google etc gelezen heb ben
> ik een hoop wijzer geworden maar nog steeds heb ik niet het hele plaatje
> compleet. Stapsgewijs zou ik nu als volgt programmeren:
>
> 1) In principe maakt het allemaal niet zo gek veel uit of je gebruik maakt
> van $_SESSION variabelen of niet. Ik zal dat wel doen omdat je dan heel
> makkelijk tussen verschillende pagina's van een uit meerdere pagina's
> bestaand formulier kan manouvreren. Tenzij je een hele diepe beveiliging
> gaat toepassen met vastleggen van IP-adressen etc. etc. kan iedereen met een
> beetje moeite je sessie kapen en misbruiken. Als je daarvan uitgaat kan je
> een hoop ellende voorkomen.
> 2) Controleer de invoer. Niet met Javascript ( clientside ) want dat heeft
> dus weinig nut wanneer iemand kans ziet een variablele bijvoorbeeld via de
> URL mee te sturen. Bijvoorbeeld een postcode; je controleert of de variablel
> $postcode bestaat uit 4 cijfers, eventueel een spatie en vervolgens weer 2
> letters. Maar als iemand bijvoorbeeld na het lezen van je broncode in de
> adresbalk van je browser intypt :
> http://www.jouwdomein.ha/form_handle..._kan_verzinnen
> heb je alsnog een probleem.

Repareer liever niks. Geef een error dat de invoer niet klopt en weiger
die invoer.

> 3) Controleer de invoer; Comboboxes controleer je serverside door te kijken
> of de waarde van de variabele met 1 van de mogelijkheden waaruit gekozen kon
> worden. Van telefoonnummers kun je verwijderen wat geen cijfers, haakjes of
> een plus is( +31(0)10123456789 ), e-mailadressen kun je valideren en de rest
> verwijderen, numeriek bedoelde velden numeriek houden en probeer het aantal
> maximale tekens dat voor een veld opgegeven wordt zo laag mogelijk te houden
> ( een telefoonnummer bijvoorbeeld niet langer als 15 cijfers ) zodat de kans
> op een 'lange' SQL injectie verkleind wordt.
> 3a) Controleer de invoer; iemand die mij kan vertellen hoe ik bijvoorbeeld
> een omschrijving van een wandelroute ( textarea ) moet controleren op SQL
> injecties of andere foute code?????
> 4) Controleer de invoer; maar niet door te zeggen; deze dingen mogen niet
> maar juist; deze dingen mogen wel.
> 5) Als je variabele INCLUDES gebruikt gebruik dan als waardes geen
> pagina-namen ( script1.php , script2.php, scrip3.php ) maar cijfers of
> letters en verwerk deze via de SWITCH / CASE / DEFAULT manier. ( Case "1" :
> include("script1.php") ; Break ; Default : include("warning.php") ; )

include in ieder geval nooit user invoer, zoals bijvoorbeeld
include($_GET['page']);

> 6) Bij ECHO laat je variabelen altijd buiten de quotes, volgens mij zo :
> echo "dit is nummer".$n." van zovelen ";
> 7) Bij INSERT of UPDATE naar een MySQL db zal ik in ieder geval ADDSLASHES
> gebruiken, ik neem aan dat die alle quotes en andere speciale tekens
> onschadelijk maakt door er slashes voor te plaatsen.

Ja, maar hou hierbij in de gaten of je magic_quotes_gpc aan hebt staan of
niet. Dit is in de php configuratie te regelen.

> 8) Plaats ook te inserten variabelen tussen single quotes ( en tussen
> accolades {}????? al snap ik nog steeds niet waarom )
> 9) Bij het weergeven van data uit een DB de code dmv bestaande functies
> zuiveren van HTML/ SCRIPT codes etc. Dit moet ik nog allemaal uitzoeken.
>

Puntje 9 is vrij belangrijk i.v.m. XSS oftwel cross site scripting. Verder
ben je wel op de goede weg denk ik.

"Michiel de Roo" <yourlove@welovespam.nl> schreef in bericht
news:43984806$0$11068$e4fe514c@news.xs4all.nl...
> Haico wrote:
>> 2) Controleer de invoer. Niet met Javascript ( clientside ) want dat
>> heeft
>> dus weinig nut wanneer iemand kans ziet een variablele bijvoorbeeld via
>> de
>> URL mee te sturen. Bijvoorbeeld een postcode; je controleert of de
>> variablel
>> $postcode bestaat uit 4 cijfers, eventueel een spatie en vervolgens weer
>> 2
>> letters. Maar als iemand bijvoorbeeld na het lezen van je broncode in de
>> adresbalk van je browser intypt :
>> http://www.jouwdomein.ha/form_handle..._kan_verzinnen
>> heb je alsnog een probleem.
>
> Repareer liever niks. Geef een error dat de invoer niet klopt en weiger
> die invoer.

Juist ja. Probleem wat ik heb is dat ik een formulier van ongeveer 10
pagina's heb wat niet perse in 1 keer hoeft te worden ingevuld. Ik heb dus
geen verplichte velden voordat ze op het allerlaatste moment ( en dat mag na
weken zijn ) het formulier definitief willen opslaan en activeren. Om niet
continue foutmeldingen te krijgen verander ik de foute ingevulde waarde in
een berichtje zoals bijv "ongeldig e-mailadres". Dat komt dan weer te staan
in de <input type="text" value="foutmelding"> , maar dan in PHP.

Ik schrijf nu maar een paar functies die verschillende invoer checken op
toegestane waarden, bijv:

function check_integer($waarde,$minimale_waarde,$maximale_w aarde){
// controle $waarde
// geef intval($waarde) of $waarde="verkeerde invoer"
return $waarde ;
}
$schone_integer_invoer= check_integer($waarde,1,100) ;





>> 9) Bij het weergeven van data uit een DB de code dmv bestaande functies
>> zuiveren van HTML/ SCRIPT codes etc. Dit moet ik nog allemaal uitzoeken.
>>
>
> Puntje 9 is vrij belangrijk i.v.m. XSS oftwel cross site scripting. Verder
> ben je wel op de goede weg denk ik.

Ik wil eventueel alleen de <a> tag toestaan maar dan alleen
"www.domein.qq/bestand.html?varibel=waarde&variabel2=waarde2" en geen
OnChange() etc etc

Er is nog een lange weg te gaan maar ik zie lichtjes branden.

Haico