Gathering of Tweakers

.oisyn

dummy@example.com (.oisyn) — Thu, 22 May 2008 11:48:32 GMT

donderdag 22 mei 2008 13:48
Waar zit de kwestbaarheid, en wat is het doel van het script? Voor de goede orde, het gaat hier om normale applicaties die fouten in hun code hebben die uitgebuit kunnen worden door 'hackers' om zo dingen te doen die eigenlijk niet zouden mogen (zoals een systeem overnemen, gegevens opvragen die ze niet zouden mogen opvragen, etc.).

Jouw script doet niets anders dan in een oneindige loop dezelfde regel uitvoeren. Hoe kan dat uitgebuit worden?

rwb

dummy@example.com (rwb) — Thu, 22 May 2008 12:11:16 GMT

donderdag 22 mei 2008 14:11

quote:
Onbekend schreef op woensdag 21 mei 2008 @ 23:09:
[...]
is_int(intval($Donation))

Dit returned toch altijd true? wat de inhoud van $Donation ook is.

quote:
Onbekend schreef op woensdag 21 mei 2008 @ 23:09:
[...]
In de regel if ( isset($Donation) && is_numeric($Donation) && is_int(intval($Donation)) && ( $Donation <= $AccountThisUser ))
wordt dan bijvoorbeeld eerst van $Donation een nummeric getal gemaakt, en daarna gaat hij kijken of $Donation is geset.

Maar $Donation word toch helemaal geen numeric getal gemaakt? Ik zie nergens dat $Donation geset word en in de documentatie zie ik ook niet staan dat de functie iets aan de waarde veranderd die je meegeeft. Dus IMHO zou de volgorde van uitvoeren hier niet zoveel uitmoeten halen.

Guillome

dummy@example.com (Guillome) — Thu, 22 May 2008 13:02:32 GMT

donderdag 22 mei 2008 15:02

quote:
.oisyn schreef op donderdag 22 mei 2008 @ 13:48:
Waar zit de kwestbaarheid, en wat is het doel van het script? Voor de goede orde, het gaat hier om normale applicaties die fouten in hun code hebben die uitgebuit kunnen worden door 'hackers' om zo dingen te doen die eigenlijk niet zouden mogen (zoals een systeem overnemen, gegevens opvragen die ze niet zouden mogen opvragen, etc.).

Jouw script doet niets anders dan in een oneindige loop dezelfde regel uitvoeren. Hoe kan dat uitgebuit worden?

zucht ....
@hydra: het was als grapje bedoeld op de post boven mij. Zal ik niet weer doen. Sorry, ga maar weer ontopic, das veel interessanter dan zo over een geintje tussendoor te vallen...

Hydra

dummy@example.com (Hydra) — Thu, 22 May 2008 13:07:19 GMT

donderdag 22 mei 2008 15:07

quote:
Guillome schreef op donderdag 22 mei 2008 @ 15:02:
zucht ....

Euh? Geef anders antwoord op z'n vraag?

Patriot

dummy@example.com (Patriot) — Thu, 22 May 2008 14:20:28 GMT

donderdag 22 mei 2008 16:20

quote:
Guillome schreef op donderdag 22 mei 2008 @ 15:02:
[...]

zucht ....
@hydra: het was als grapje bedoeld op de post boven mij. Zal ik niet weer doen. Sorry, ga maar weer ontopic, das veel interessanter dan zo over een geintje tussendoor te vallen...

Waarom quote je .oisyn dan? Natuurlijk denkt iedereen dan dat het daar een reactie op is..

Ik snap overigens ook niet helemaal wat de exploit in dat script is. Overigens maakt het ook weinig uit, want ik denk dat hier wel wat dingen mogen komen te staan die in de praktijk ook voorkomen.

Guillome

dummy@example.com (Guillome) — Thu, 22 May 2008 14:30:39 GMT

donderdag 22 mei 2008 16:30
eh juist ja ga aub door met het topic, je maakt van de mug alleen maar een grote vage olifant

ZktaS

dummy@example.com (ZktaS) — Thu, 22 May 2008 14:35:32 GMT

donderdag 22 mei 2008 16:35

quote:
Cartman! schreef op zaterdag 17 mei 2008 @ 11:41:
PHP:
1 2 3 4 5 6 7
$strSql = ' INSERT INTO video SET filename = "' . $strFilename . '", hash = "' . sha1(time()) . '" '; ?>

Over het dubbele hashes, je kan natuurlijk het veld op PRIMARY zetten zodat er enkel unique strings in mogen staan. Het haalt de bug er niet 100% uit, maar het is al iets beter aangezien de dubbele string niet in de database komt.

CyCloneNL

dummy@example.com (CyCloneNL) — Fri, 23 May 2008 08:11:13 GMT

vrijdag 23 mei 2008 10:11

quote:
Cartman! schreef op dinsdag 20 mei 2008 @ 21:10:
Het is sowieso niet handig om in de rechtentabel de naam te gebruiken ipv. het userid, is dat wat je bedoeld?

Al ben ik het wel met je eens, maar waarom?
Waarom precies wil je een id gebruiken, ipv een naam?

Patriot

dummy@example.com (Patriot) — Fri, 23 May 2008 08:21:23 GMT

vrijdag 23 mei 2008 10:21

quote:
CyCloneNL schreef op vrijdag 23 mei 2008 @ 10:11:
[...]

Al ben ik het wel met je eens, maar waarom?
Waarom precies wil je een id gebruiken, ipv een naam?

Naast dat het een gevoelskwestie is, scheelt het ruimte. Bovendien weet je zeker dat je geen rare dingen krijgt i.v.m. bepaalde encoding etc. van de naam.

EDIT: En wat dacht je als de naam veranderd? Dan moet je dat in alle tabellen gaan doen.

Voutloos

dummy@example.com (Voutloos) — Fri, 23 May 2008 08:26:28 GMT

vrijdag 23 mei 2008 10:26
Plus dat een dergelijke synthetische key gewoon constant kan blijven, ook al wil jij je username veranderen en ga zo maar door met alle standaard datamodel argumenten.
Maar goed, dit is wel offtopic allemaal...

edit:
spuit 11 na bovenstaande edit Maar dan nog zijn dit toch echt wel standaard puntjes uit datamodel 101)

CyCloneNL

dummy@example.com (CyCloneNL) — Fri, 23 May 2008 08:30:03 GMT

vrijdag 23 mei 2008 10:30
Ok, thanks.

Zelf zou ik ook een ID gebruiken, maar alleen voor de 'gevoelskwestie'. Nu weet ik dus waarom

.oisyn

dummy@example.com (.oisyn) — Fri, 23 May 2008 09:08:04 GMT

vrijdag 23 mei 2008 11:08
En 't is gewoon sneller, een index van integers tov een index van varchars

CyCloneNL

dummy@example.com (CyCloneNL) — Thu, 29 May 2008 12:01:40 GMT

donderdag 29 mei 2008 14:01
Ok, nog eentje, niet echt een kwetsbaarheid maar wel een fout.

Een nieuws systeem, waar de tekst na 100 karakters wordt afgekapt en er een 'Lees meer' link wordt gegeven.
PHP:

$maxLength = 100; //Maximum tekst length.



$result = (Haal data uit MYSQL database)



while($row = mysql_fetch_array($result))

{

   $titel = $row['titel'];

   $text = strlen($row['tekst']) > $maxLength ? $row['tekst'] : substr($row['tekst'],0,$maxLength) . "Lees meer!";



   echo "$titel 

            $text";

}

?>

-FoX-

dummy@example.com (-FoX-) — Thu, 29 May 2008 12:20:27 GMT

donderdag 29 mei 2008 14:20
De substring zal altijd in de fout gaan, aangezien de text in die case altijd kleiner zal zijn dan 100?

MueR

dummy@example.com (MueR) — Thu, 29 May 2008 12:22:40 GMT

donderdag 29 mei 2008 14:22
Hij kapt hard op 100 karakters, niet netjes einde woord etc, geen tags afsluitend. Alleen jammer dat ie daar niet komt, alleen wanneer de tekst niet groter is als $max, wat dus loos kapwerk is.

Voutloos, ik was nog aan het editen

Voutloos

dummy@example.com (Voutloos) — Thu, 29 May 2008 12:22:45 GMT

donderdag 29 mei 2008 14:22

offtopic:
Je kan voor PHP code [php][/php] tags gebruiken.

En dit is wel een heel suf foutje. Je kan hier wellicht gewoon altijd substr() doen, lekker boeiend als je een handjevol calls hebt waarbij de tekst reeds binnen length viel, 't leest wel een stuk eenvoudiger.

quote:
MueR schreef op donderdag 29 mei 2008 @ 14:22:
Hij kapt hard op 100 karakters, niet netjes einde woord etc, geen tags afsluitend.

Zat ik eerst ook aan te denken, maar het is idd vooral verkeerd om.

quote:
Voutloos, ik was nog aan het editen

Yeah right.

PrisonerOfPain

dummy@example.com (PrisonerOfPain) — Thu, 29 May 2008 12:23:44 GMT

donderdag 29 mei 2008 14:23
Tenzij de titel en de tekst al escaped (htmlentities / htmlspecialchar) in de database staan heb je last van XSS.

Muthas

dummy@example.com (Muthas) — Thu, 29 May 2008 12:26:25 GMT

donderdag 29 mei 2008 14:26
Het is sowieso onzin om te escapen/XSS filteren bij het weergeven van data, imo moet je dat doen zodra je het in je de database zet.

Bosmonster

dummy@example.com (Bosmonster) — Thu, 29 May 2008 12:27:39 GMT

donderdag 29 mei 2008 14:27

quote:
PrisonerOfPain schreef op donderdag 29 mei 2008 @ 14:23:
Tenzij de titel en de tekst al escaped (htmlentities / htmlspecialchar) in de database staan heb je last van XSS.

Maar dat ligt dan meer aan het feit dat je dat zo in de database hebt staan. Das al een WTF op zich.

PrisonerOfPain

dummy@example.com (PrisonerOfPain) — Thu, 29 May 2008 12:30:15 GMT

donderdag 29 mei 2008 14:30

quote:
Muthas schreef op donderdag 29 mei 2008 @ 14:26:
Het is sowieso onzin om te escapen/XSS filteren bij het weergeven van data, imo moet je dat doen zodra je het in je de database zet.

Párdon? De data in de database heeft níets te maken met de weergave van de betreffende content, escapen van de data met htmlentities ed. doe je gewoon in de view layer.

Muthas

dummy@example.com (Muthas) — Thu, 29 May 2008 12:33:13 GMT

donderdag 29 mei 2008 14:33
En dat je weet ik het hoeveel keer hetzelfde met je data doet terwijl je die data altijd ge-escaped nodig zal hebben maakt niet uit?

CyCloneNL

dummy@example.com (CyCloneNL) — Thu, 29 May 2008 12:34:03 GMT

donderdag 29 mei 2008 14:34

quote:
PrisonerOfPain schreef op donderdag 29 mei 2008 @ 14:23:
Tenzij de titel en de tekst al escaped (htmlentities / htmlspecialchar) in de database staan heb je last van XSS.

Hij is escaped enzo.

PrisonerOfPain

dummy@example.com (PrisonerOfPain) — Thu, 29 May 2008 12:45:41 GMT

donderdag 29 mei 2008 14:45

quote:
Muthas schreef op donderdag 29 mei 2008 @ 14:33:
En dat je weet ik het hoeveel keer hetzelfde met je data doet terwijl je die data altijd ge-escaped nodig zal hebben maakt niet uit?

Dat is nogal een non-optimalisatie; zodra dit een bottleneck word doet de view layer z'n eigen caching maar. In een database wil je dit soort dingen gewoon niet hebben omdat op dat punt helemaal nog niet vast staat wat het output formaat gaat worden.

Voutloos

dummy@example.com (Voutloos) — Thu, 29 May 2008 12:45:48 GMT

donderdag 29 mei 2008 14:45

quote:
Muthas schreef op donderdag 29 mei 2008 @ 14:33:
En dat je weet ik het hoeveel keer hetzelfde met je data doet terwijl je die data altijd ge-escaped nodig zal hebben maakt niet uit?

Escapen is niet generiek, maar doe je voor een bepaalde context. Pas als jij zeker weet welke context altijd gebruikt wordt kan dit een vd bewuste optimalisatie trucs zijn.

edit:
...waarbij het compleet cachen van grote blokken van je site idd krachtiger kan zijn. Maar wellicht ook lastiger.

CyCloneNL

dummy@example.com (CyCloneNL) — Thu, 29 May 2008 15:21:05 GMT

donderdag 29 mei 2008 17:21
In ieder geval, een fout is dat alle open HTML tags niet worden afgesloten.
Dus als er net een h1 tag geopend is, wordt de hele pagina dik gedrukt.