[alg] Slechtste programmeervoorbeelden deel 4

Waarschijnlijk een site alleen bezocht door digibeten

quote:

kenneth schreef op woensdag 01 oktober 2008 @ 23:52:
Waarschijnlijk een site alleen bezocht door digibeten

Zo had mijn school eerder een pakket om toetsen af te nemen, voor elke toets stond een wachtwoord, in de bron ;')

Kon je dus ver van te voren al de toets inzien

quote:

Gomez12 schreef op woensdag 01 oktober 2008 @ 22:30:
He, niet denigrerend doen he, het is wel waarschijnlijk versleuteld door een lettertype wat geen duidelijk onderscheid maakt tussen een 0 en een O...

logisch natuurlijk als je zo openbarend bent met je passwords

Ook leuk als iemand direct naar show_news.php gaat linken.

quote:

IceManX schreef op woensdag 01 oktober 2008 @ 13:48:
[...]

Custom attribute?
HTML:

1	<input type="text" name="name" optional="true">

JavaScript:

1 2 3 4 5 6 7 8 9 10 11 12 13

function CheckForm(Form) {     for (var i = 0; i < Form.Elements.Length; i++)     {         if(Form.Elements\[i].value == '' && !Form.Elements\[i].getAttribute("optional"))         {             alert('Vul aub alle velden in!');             return false;         }     }      Form.submit();     return true; }

Let ook op de return values zodat je in een submit button het submitten kan tegenhouden:
HTML:

1	<input type="submit" name="submit" value="Verstuur" onclick="return CheckForm(...);">

Nee, veel beter is een class te geven voor optionele parameters.
HTML:

1	<input type="text" name="name" class="optionalFormField">

Daarna javascript gebruiken om de class uit te lezen.

quote:

CyCloneNL schreef op woensdag 01 oktober 2008 @ 22:05:
Oeh, ik weet het wachtwoord!

Zullen die mensen nou echt niet snappen dat iedereen dat wachtwoord kan zien.

quote:

Voutloos schreef op donderdag 02 oktober 2008 @ 08:25:
Ook leuk als iemand direct naar show_news.php gaat linken.

De echte WTF is natuurlijk hoe de maker van die site een 10 voor Nederlands heeft kunnen krijgen.

quote:

Tiemez schreef op donderdag 02 oktober 2008 @ 09:27:
[...]


Zullen die mensen nou echt niet snappen dat iedereen dat wachtwoord kan zien.

Tja... ik denk dat meisjes van 12 niet echt bezig zijn met of de beveiliging op de site goed werkt

nvm.

Cr1mp wijzigde dit bericht 02-10-2008 09:53 (98%)

quote:

Tiemez schreef op donderdag 02 oktober 2008 @ 09:27:
[...]


Zullen die mensen nou echt niet snappen dat iedereen dat wachtwoord kan zien.

Richt-click disablen, jeweettoch!

quote:

GuShe schreef op woensdag 01 oktober 2008 @ 21:28:
Misschien niet echt een Slecht programmeervoorbeeld, mar veilig zal het ook wel niet zijn als je een dergelijk beveiligingssysteem hebt, dat gewoon in de Broncode van je website staat:
(Rechtstreekse Copy/Paste)
JavaScript:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<script language="javascript"> <!--// /*Dit script verplicht de bezoekers een password en ID...*/ function pasuser(form) { <!--//verander hier onder je eigen ID if (form.id.value=="BLOG01") {  <!--//verander hier onder je eigen logincode if (form.pass.value=="OYEAH") {               <!--//verander hier onder de pagina die beveiligd moet worden location=""  } else { alert("Invalid Password") } } else {  alert("Invalid UserID") } } //--> </script>

Je had die location="..." ook even weg kunnen editten, want daar gaat het natuurlijk niet om. Nu krijg je allemaal weer vreemde figuren die zo nodig moeten gaan reageren daar .

Verder is zoiets natuurlijk te verwachten van iemand die voor het eerst een website maakt, die plukt de makkelijkste scriptjes van het internet...en als simpelste vorm van beveiliging werkt het, zolang de gebruiker geen kennis heeft van HTML .

ik kwam deze laatst nog tegen
PHP:

1 2 3 4 5 6 7

<?php $query = "SELECT * FROM tabel"; if($_SESSION["zoeken"]["betaal_status"] == "-"){         $query .= " WHERE status != 'eenletterdienietvoorkomt'";     } else {         $query .= " WHERE status = '".$_SESSION["zoeken"]["status"]."'";         $zoeken = 'ja';     } ?>

En vandaag kwam ik nog een script pagina tegen met een if-constructie met 10 else-ifs, waarbij alleen in de "else" code staat. (oftewel, die if had anders gekunt gemoeten.)

quote:

.oisyn schreef op donderdag 02 oktober 2008 @ 10:46:
[...]

Richt-click disablen, jeweettoch!

Ik lach elke keer weer als iedereen zit te klagen dat right-click niet werkt. Opera negeert die code namelijk nog steeds

quote:

Tiemez schreef op donderdag 02 oktober 2008 @ 12:21:
ik kwam deze laatst nog tegen
PHP:

1 2 3 4 5 6 7

<?php $query = "SELECT * FROM tabel"; if($_SESSION["zoeken"]["betaal_status"] == "-"){         $query .= " WHERE status != 'eenletterdienietvoorkomt'";     } else {         $query .= " WHERE status = '".$_SESSION["zoeken"]["status"]."'";         $zoeken = 'ja';     } ?>

En vandaag kwam ik nog een script pagina tegen met een if-constructie met 10 else-ifs, waarbij alleen in de "else" code staat. (oftewel, die if had anders gekunt gemoeten.)

Ik vraag me af wat ik dommer vind. De overduidelijke SQL-injection-waiting-to-happen, of het toevoegen van een feitelijke TRUE statement als WHERE clause. Waarbij helaas de performance slechter wordt omdat voor elk record wel de status moet worden vergeleken met 'eenletterdienietvoorkomt'.

Ik zal maar niks zeggen over $zoeken. Nederlands in code, brrrr...
(maar goed, dat is persoonlijke voorkeur )

quote:

IceManX schreef op donderdag 02 oktober 2008 @ 12:39:
[...]

Ik lach elke keer weer als iedereen zit te klagen dat right-click niet werkt. Opera negeert die code namelijk nog steeds

Of je drukt gewoon op de context-menu toets die naast de rechter CTRL zit

quote:

IceManX schreef op donderdag 02 oktober 2008 @ 12:39:
[...]

Ik lach elke keer weer als iedereen zit te klagen dat right-click niet werkt. Opera negeert die code namelijk nog steeds

offtopic:
Ctrl-F12, Geavanceerd, Inhoud, Javascript opties..., Ontvangen van rechter-muisklikken toestaan Staat gelukkig standaard uit!

quote:

IceManX schreef op donderdag 02 oktober 2008 @ 12:39:
[...]

Ik lach elke keer weer als iedereen zit te klagen dat right-click niet werkt. Opera negeert die code namelijk nog steeds


[...]

Ik vraag me af wat ik dommer vind. De overduidelijke SQL-injection-waiting-to-happen, of het toevoegen van een feitelijke TRUE statement als WHERE clause. Waarbij helaas de performance slechter wordt omdat voor elk record wel de status moet worden vergeleken met 'eenletterdienietvoorkomt'.

Ik zal maar niks zeggen over $zoeken. Nederlands in code, brrrr...
(maar goed, dat is persoonlijke voorkeur )

Ja, het is een stuk code van een collega van me. Die zelf ook niet (meer?) wist waarom dit er in zat.

ik gebruik zelf overigens ook altijd engelse variabelen en functienamen. En gebruik voor Database-query's het liefst PDO of ZEND_DB die het escapen voor je doen. (en anders mysql_real_escape_string())

Tiemez wijzigde dit bericht 02-10-2008 13:09 (6%)

Vorige week een dikke bug die een collega (inmiddels vertrokken) had gemaakt en ik kon gaan zoeken. Het ging om een simpele webshop waar je een paar producten in een shoppingcart kunt plaatsen en afrekenen.
Bij het opslaan maakt ie een ordernummer aan en zet die in de database en daar koppelt ie de klantgegevens aan. Wat deed ie nu... hij pakte <jaar><maand><nr> waarbij <nr> ooit begon met 1 en bij het aanmaken van het ordernummer checkte die de laatste order en pakte de laatste 3 getallen van dat ordernummer, hoogde dat op met 1, en dat plakte die dus achter <jaar><maand>.

Toevallig was dit de eerste maand waarbij het aantal bestellingen over de 1000 ging, dus zorge dat voor problemen, want de laatste 3 getallen van 2008091000 wordt...000 en + 1 = 1. Dus begon ie opnieuw met tellen en liep de boel de zeik in

Gelukkig heb ik snel een workaround ingebakken (substr op de getallen na jaar/datum) en dat + 1; maar wat een methode

autoincrement/sequence? order nummer = <jaar><dag><db_id> is wel makkelijker dan

quote:

Salandur schreef op vrijdag 03 oktober 2008 @ 16:16:
autoincrement/sequence? order nummer = <jaar><dag><db_id> is wel makkelijker dan

Brrrr.... db_id lijkt me niet zo handig. Krijg je gaten in je overzicht van orders (ten minste, als je je id's globaal nummert ipv per tabel.

Dan liever een dedicated sequence voor de ordernummers.

Kwam eergisteren dit tegen in vb...
code:

if i = 130 Then
i = i
End if

Neem aan dat het gewoon nog een stukje code was om te testen of iets dergelijks.

quote:

IceManX schreef op donderdag 02 oktober 2008 @ 12:39:
[...]

Ik lach elke keer weer als iedereen zit te klagen dat right-click niet werkt. Opera negeert die code namelijk nog steeds


[...]

Ik vraag me af wat ik dommer vind. De overduidelijke SQL-injection-waiting-to-happen, of het toevoegen van een feitelijke TRUE statement als WHERE clause. Waarbij helaas de performance slechter wordt omdat voor elk record wel de status moet worden vergeleken met 'eenletterdienietvoorkomt'.

Ik zal maar niks zeggen over $zoeken. Nederlands in code, brrrr...
(maar goed, dat is persoonlijke voorkeur )

Nu ben ik toch nieuwsgierig, de $_SESSION variabele bevat toch gegevens die door je applicatie gevuld is en niet de gebruiker? Hoe kan dit dan SQL injection veroorzaken? (mits je applicatie de $_SESSION var zelf goed vult natuurlijk).

Goed punt. Maar iemand die dit soort code schrijft zie ik ook goed in staat zijn input niet te controleren.

Toch had ik daar niet vanuit mogen gaan nee.

Het is inderdaad twijfelachtig of waardes in de $_SESSION variabele wel ge-escaped zijn.

Ik bedacht me later ook dat ik zelf pas de waardes zou gaan escapen net voordat ik ze in een query zou gebruiken. Het is logischer om de originelen in de $_SESSION variabele op te slaan.

quote:

Mitrilvich schreef op zaterdag 04 oktober 2008 @ 14:20:
[...]
Nu ben ik toch nieuwsgierig, de $_SESSION variabele bevat toch gegevens die door je applicatie gevuld is en niet de gebruiker? Hoe kan dit dan SQL injection veroorzaken? (mits je applicatie de $_SESSION var zelf goed vult natuurlijk).

Je app kan de session variabelen nog zo goed vullen, je kan je inputvelden nog zo goed controleren.
In wezen moet je alles controleren, anders heb je altijd het risico op een domino-effect door een oude db-entry ( van voordat je input-velden controleerde ) die in combinatie met een bugje in het vullen van session variabelen je app rare dingen laat doen.

Ten allen tijde heb je een risico op bugs, als je de resultaten opslaat heb je een kans dat je ongefilterde data in je dbase hebt zitten vanwege een oude bug.

En hoeveel moeite is het nou om 1 extra check uit te voeren? ( lijkt mij persoonlijk juist een rare situatie om 1 gegeven door je hele app heen als onbetrouwbaar te classificeren totdat hij opeens in je $_SESSION zit, dan is hij opeens magisch betrouwbaar geworden? Terwijl hij het zelfde moet voorstellen )

quote:

Gomez12 schreef op zaterdag 04 oktober 2008 @ 16:38:
[...]

Je app kan de session variabelen nog zo goed vullen, je kan je inputvelden nog zo goed controleren.
In wezen moet je alles controleren, anders heb je altijd het risico op een domino-effect door een oude db-entry ( van voordat je input-velden controleerde ) die in combinatie met een bugje in het vullen van session variabelen je app rare dingen laat doen.

Ten allen tijde heb je een risico op bugs, als je de resultaten opslaat heb je een kans dat je ongefilterde data in je dbase hebt zitten vanwege een oude bug.

En hoeveel moeite is het nou om 1 extra check uit te voeren? ( lijkt mij persoonlijk juist een rare situatie om 1 gegeven door je hele app heen als onbetrouwbaar te classificeren totdat hij opeens in je $_SESSION zit, dan is hij opeens magisch betrouwbaar geworden? Terwijl hij het zelfde moet voorstellen )

Ik denk dat je altijd waardes moet escapen voordat je ze gebruikt in een query. Ongeacht of ze van je applicatie of van de gebruiker af komen. (Tenzij je 200% zeker ben dat de waardes in een veilige range van tekens zitten).

Het speciale was de combinatie van $_SESSION en de term "sql injection". Het is niet duidelijk of $_SESSION gegevens bevat die ingegeven is door de gebruiker (zoals een zoekterm) en die daarmee bewust een SQL string manipuleert.

quote:

Cartman! schreef op vrijdag 03 oktober 2008 @ 16:10:
Vorige week een dikke bug die een collega (inmiddels vertrokken) had gemaakt en ik kon gaan zoeken. Het ging om een simpele webshop waar je een paar producten in een shoppingcart kunt plaatsen en afrekenen.
Bij het opslaan maakt ie een ordernummer aan en zet die in de database en daar koppelt ie de klantgegevens aan. Wat deed ie nu... hij pakte <jaar><maand><nr> waarbij <nr> ooit begon met 1 en bij het aanmaken van het ordernummer checkte die de laatste order en pakte de laatste 3 getallen van dat ordernummer, hoogde dat op met 1, en dat plakte die dus achter <jaar><maand>.

Toevallig was dit de eerste maand waarbij het aantal bestellingen over de 1000 ging, dus zorge dat voor problemen, want de laatste 3 getallen van 2008091000 wordt...000 en + 1 = 1. Dus begon ie opnieuw met tellen en liep de boel de zeik in

Gelukkig heb ik snel een workaround ingebakken (substr op de getallen na jaar/datum) en dat + 1; maar wat een methode

het klinkt als een stukje software die een heel aantal jaar terug heb geschreven. Alleen heb ik dit principe toen toegepast voor een administratie systeem. Echt precies hetzelfde. Alleen had ik toen opzettelijk het risico genomen. Als hij meer orders wou moest hij zelf maar een betere nummering kiezen.