Door
Jan R
op 23-06-2019 07:02
gewijzigd op 23-06-2019 12:49
2.865 views
Hi,
Iemand heeft geprobeerd om mij te hacken. Dit van dit gedeeltelijke IP xx.xx.xx.xx en volgende login
105 OR 1=1
Indien dit hier iemand zou zijn, en dit is geen verwijt nog een betichting, gelieve je kenbaar te maken.
Ik zou graag hebben dat iemand mij zegt waar er eventueel zwakke of open plekken zijn echter niet zonder mij op voorhand te waarschuwen.
Nogmaals! Ik beticht niemand gezien ik jullie helemaal niet ken behalve de login en dat ik hier al veel hulp heb gehad. Zelf probeer ik dit ook te doen maar de meesten zijn hier wel slimmer dan ik:)
De enige reden waarom ik dit hier vraag is omdat dit het enige forum is in NL waar ik mee werk.
Gelieve me dus te vergeven, niet met vergif, mocht iemand zich aangevallen voelen.
$name = mysqli_real_escape_string($con, $_POST['name']);
$pwsite = mysqli_real_escape_string($con, $_POST['pw']);
$sql='SELECT
concat(voornaam, " " , achternaam) as naam,
l.id,
password,
t.id tid,
r.rol,
t.taak
FROM
post_emails e
INNER JOIN post_leden l
ON e.ID = l.ID
left JOIN post_member2rol mr
ON l.id = mr.member
left JOIN post_rollen r
ON mr.rol = r.id
left JOIN post_rol2taak rt
ON rt.rol = r.id
left JOIN post_taken t
ON t.id = rt.taak
WHERE
((actief=1) and
(t.id in (' . functiecode() . ')) and
(e.email="' . $name . '") and
(password="' . hash('sha512', $pwsite) . '"))';
met dit als resultaat
SELECT
concat(voornaam, " " , achternaam) as naam,
l.id,
password,
t.id tid,
r.rol,
t.taak
FROM
emails e
INNER JOIN leden l
ON e.ID = l.ID
left JOIN member2rol mr
ON l.id = mr.member
left JOIN rollen r
ON mr.rol = r.id
left JOIN rol2taak rt
ON rt.rol = r.id
left JOIN taken t
ON t.id = rt.taak
WHERE
((actief=1) and
(t.id in (13)) and
(e.email="[email protected]") and
(password="a26e2d...9d612f"))
de taakid komt uit defines en uit de database. Beiden moeten dezelfde zijn. Deze "t.id in (13)" is voor de schaaktoernooien.
Zodoende log ik overal in met hetzelfde script.
De rechten worden op deze manier verdeeld.
Zoals je kan zien hebben we een secretaris die geen klop doet :)
"Inderdaad. dan zie ik ook wie of waarom. enorm veel proberen in te loggen met een oud e-mailadres of hun naam."
Ah oké ... maar dit zegt dus verder niks over sql injection. Dit zegt alleen dat het inloggen niet geslaagd is, omdat de combinatie gebruikersnaam/wachtwoord niet klopt.
Het is de bedoeling dat DATA die de SQL in gaat niet als SQL geïnterpreteerd kan worden. Daartoe maak je DATA net voor het gebruik in de SQL bij uitvoering van de query onschadelijk door de daarvoor bestemde escaping-functie toe te passen (in combinatie met quotes).
Maar wat jij in zekere zin met je wachtwoord doet is input escaping. Immers, je escapet het oorspronkelijke wachtwoord voordat deze door de hashingfunctie gaat. Als je dit consequent doet (bij opslaan en wijzigen) gaat dit niet fout, maar dit is wel de verkeerde volgorde.
Het is zaak dat je de DATA-delen escapet, en in zekere zin is het niet eens nodig om de hash te escapen, maar dat is wel weer handig om te doen om gewoon overal hetzelfde -en simpele- stramien toe te passen zodat je hier verder niet over na hoeft te denken. Maar op voorhand het oorspronkelijke wachtwoord escapen voor SQL-gebruik, nog voordat je deze hasht is gewoon verkeerd. Je escapet op de verkeerde plaats.
Stel dat je de implementatie van het inloggen straks verandert, en de enige info die je hebt is "gebruikers worden geïdentificeerd aan de hand van hun e-mailadres in combinatie met een SHA512 hash van hun wachtwoord.". Mocht je op dat moment de escaping wel goed hebben geregeld (of je bent inmiddels overgestapt op een andere database, maar je hebt de gegevens meegenomen via een importscript ofzo) dan werken ineens al je een aantal logins mogelijk niet meer omdat er een real_escape_string()-encodering zit op het oorspronkelijke wachtwoord... Dat kan echt nooit de bedoeling zijn.
Voorbeeld:
<?php
$password = "asdf'\"hello"; // wachtwoord waar real_escape_string() aanpassingen in doet
$db = new mysqli('127.0.0.1', 'test', 'test', 'test');
$db->set_charset('utf8'); // <-- DIT BEPAALT TEVENS HOE ESCAPING WERKT! ESCAPING FUNCTIONALITEIT IS AFHANKELIJK VAN DE GEBRUIKTE CHARACTER ENCODERING
?><pre><?php
echo $password.'<br>';
echo $db->real_escape_string($password).'<br>';
// de foute manier - je escapet INPUT
echo hash('SHA512', $db->real_escape_string($password)).'<br>';
// de goede manier - je escapet de uiteindelijke OUTPUT
echo $db->real_escape_string(hash('SHA512', $password)).'<br>';
?></pre>
@thomas
het is consequent dat ik het zo gebruik. ps: naar een voorbeeld dat ik hier in een ver verleden vond :)
Voor de toekomst zal ik het goed doen.
echter een vraagje ivm realescape de hash.
Returns a string containing the calculated message digest as lowercase hexits unless raw_output is set to true in which case the raw binary representation of the message digest is returned.
Simpelweg omdat iets werkt, maakt het nog niet juist :p.
naar een voorbeeld dat ik hier in een ver verleden vond :)
Dat klopt dan niet. Heb je de bron hiervan nog?
Waarom hexdata escapen?
Dat is in principe niet nodig, maar het is veel belangrijker dat je een consequente manier van escapen hebt, en je altijd bewust bent van de aanwezigheid van externe data. Dit is wellicht lastig uit te leggen, but here goes.
Je bent altijd in een of andere context bezig: in SQL, in HTML, in JavaScript. Binnen zo'n context hebben bepaalde karakters mogelijk een speciale betekenis. Zo hebben <hoekige haken>, ampersands (&) en dubbele quotes (") een speciale betekenis binnen X/HTML. Wanneer bepaalde DATA -die mogelijk afkomstig is van een externe bron-, niet als zodanig in die context geïnterpreteerd zou moeten worden, dan is het zaak dat je de speciale betekenis die die DATA mogelijk heeft ontdoet met de voor die context bestemde escaping-functies en hulpmiddelen (quotes).
Stel bijvoorbeeld dat iemand bij zijn profiel een korte omschrijving van zijn hobby's kan opgeven. En vervolgens geef je die tekst in een HTML-document weer. Wat nu als deze omschrijving HTML bevat, of mogelijk JavaScript die stiekem informatie steelt? Deze tekst wil je dus onschadelijk maken om dit soort potentiële gevaren te neutraliseren.
Nu zou je voor elke DATA-snippet die ooit ergens gebruikt wordt (in HTML, SQL et cetera) kunnen gaan inspecteren of die een potentieel veiligheidsrisico bevat of niet. Kun je ervan verzekerd zijn dat je altijd de goede inschatting maakt? (spoiler: nee). Dus dat is een reden om altijd te escapen, je hoeft dan die overweging niet (telkens opnieuw) te maken.
Of je zou ervoor kunnen kiezen om dit soms toch niet te doen omdat de DATA-passages triviaal zijn, omdat je inderdaad weet dat dit nooit iets schadelijks oplevert (als je dit bijvoorbeeld door een hashingfunctie haalt, dit levert nagenoeg altijd output op die geen speciale betekenis heeft in de SQL context, of een andere).
Maar wat als het niet zo evident is. Is het ontbreken van escaping dan bewust zo gedaan, of is dit mogelijk toch vergeten? Vervolgens moet je dan zo'n passage gaan interpreteren, en vaak is dan (enige tijd later) toch de conclusie dat het niet per se nodig was. DIT DOE JIJ (of iemand anders) DAN MOGELIJK ELKE KEER DAT JE DIE CODE TEGENKOMT. Dit is je reinste tijdsverspilling. Het is gewoon veel simpeler en consequenter om gewoon overal alle (externe) USER DATA te escapen (Don't Make Me Think). En bovendien ook veel veiliger, het kan dan simpelweg nooit fout gaan. Je hoeft verder helemaal niet meer na te denken over het escapen van output mits je dit overal consequent (en op de juiste wijze) doet.
Een andere fout die vaak wordt gemaakt is aannames doen over de context waarin DATA gebruikt gaat worden. En die dan vervolgens op voorhand escapen (escape on input). Ook dat is een slecht idee. Want mogelijk moet je bij gebruik eerst de DATA weer un-escapen (wat zelf ook weer voor een hoop problemen kan zorgen) om die in een bepaalde context te gebruiken.
Als je gewoon overal en altijd de volgende regel toepast: filter input, escape output
Dan kom je een heel eind.
Maar dan moet je wel:
- inhouden wat dit precies betekent
- en het vervolgens ook op de juiste wijze toepassen
Iets wat nauw samenhangt met escaping-functionaliteit zijn character encoderingen van de data. Maar dat is zelf ook een compleet hoofdstuk.
Indien dit hier iemand zou zijn, en dit is geen verwijt nog een betichting, gelieve je kenbaar te maken.
Het lijkt me onwaarschijnlijk dat het een forumlid is, maar onderschat het probleem vooral niet: inbraakpogingen met SQL-injectie zie ik minstens wekelijks bij verschillende sites, met IP-adressen van over de hele wereld.
Ik heb er zelfs een leuke honeypot voor ingericht. ;-)
[quote="Jan R op 23/06/2019 07:02:25"]
Indien dit hier iemand zou zijn, en dit is geen verwijt nog een betichting, gelieve je kenbaar te maken.
Het lijkt me onwaarschijnlijk dat het een forumlid is,
[/quote]
Ik hoop het echt! Ik heb al te veel hulp door velen van jullie gehad. Waarvoor nogmaals dank.
Was gewoon op je antwoord van 24/6 14:32 paragraaf 4
Dat snap ik, maar als ik code zie dan probeer ik ook na te gaan wat iemand heeft bewogen om iets op een bepaalde manier aan te pakken. Dit moet dan wel een goede motivatie zijn. Een aanpak waarbij de motivatie neerkomt op "het werkt" waarbij je situaties kunt verzinnen waarin het fout kan gaan kun je beter vermijden. Een beetje defensief programmeren kan geen kwaad.
Over of het al dan niet een forumlid zou zijn:
Aan de andere kant, als iemand een site linkt met code waar 'ie mee worstelt, dan zit het toch ook een beetje in de aard van een programmeur om een beetje rond te neuzen en eens aan wat deurklinken te hangen.
Ik zou mij dan ook niet zozeer druk maken over wie dit soort dingen precies uitspookt, maar meer met welke motivatie. Maar dit (een of een aantal pogingen) hoeft verder niet eens iets te betekenen. Als het een enkele poging was dan was dit waarschijnlijk een schot in het donker. En als die dan direct doel had getroffen dan verdien je wat mij betreft de consequenties eigenlijk wel ;).
