SQL veilig maken

[Verwijderd]

Ik weet dat er al heel wat hierover neer getypt is alsook vind je er zoveel over terug op google, zoals ik kan zien zijn er ook verschillende manieren..

onderstaand voorbeeld wil ik bvb (nog) veilig maken tegen SQL injectie wat is hiervoor de beste manier (in begrijpbare taal voor iemand die SQL aan het leren is )

$con= mysqli_connect("*************","****************","***************","*********************");
$id = (int) $_GET['id'];

$datum = $_POST['kalender_datum']);
$titel = $_POST['kalender_titel']);

$escapedatum = mysqli_real_escape_string($datum);
$escapetitel = mysqli_real_escape_string($titel);

$query = "UPDATE `kalender`
SET `kalender_datum` = '$escapedatum',
`kalender_titel`= '$escapetitel',

WHERE `kalender_id`= $id" ;

$result = mysqli_query($con, $query);
if (!$result) {
printf("error: %s\n", mysqli_error($con));
}

Zou leuk zijn om over dit typisch voorbeeld even een korte uitleg te krijgen.

[RedHat]

Zoek anders eens op prepared statements. Daar is een hoop informatie over beschikbaar.

[jbdeiman]

Wat je hier wil doen (als ik het goed begrijp) is een bepaalde waarde bijwerken in de database.
Je krijgt het id binnen via de GET variabele, die in een URL wordt meegegeven (na het vraagteken) en de overige gegevens gaan via de POST?

Op zich is er niet heel veel mis met wat je nu doet qua veiligheid (vooral het typecasten naar een integer van het ID is een goed gebruik!) en eigenlijk kan er met de manier waarop je dit doet niet zoveel gebeuren, echter mag je dit voorbeeld nooit en te nimmer op een productieomgeving plaatsen, omda je daarin geen mysql fouten zomaar terug mag geven, dat is een veiligheidsissue.

Wat ik nog wel even aan wil snijden is het volgende:
Je datum hoeft nu helemaal geen datum te zijn, daar kunnen foute query's door ontstaan. Foute query's leveren een vergroot risico op lekken en andere problemen.

Wat je, aan PHP kant, nog kan / moet doen om dat op te lossen is dat je de ( geldigheid van de )datum gaat bepalen, hier zijn verschillende methoden voor die PHP aanbiedt:
- Je kan via date('Y-m-d', strtotime( $_POST['kalender_datum'])) de datum omzetten naar iets waar je zeker van weet dat de query mee om kan gaan, je moet hierbij wel nog fouten afhandelen.

- Door de datum op te knippen kan je via "checkdate" bepalen of het een geldige datum is.

- http://nl3.php.net/datetime: Hier heb je een hele boel functionaliteiten t.a.v het werken met datums in PHP.


Wat RedHat zegt is op zich wel een goede, dat maakt het schrijven van query's wat eenvoudiger, doordat je een aantal losse stukken schrijft. Je lost er alleen het probleem met "ik verwacht een datum, maar kan er ook tekst in gooien" niet mee op.

[Verwijderd]

Je kunt het best nooit mysql_* of mysqli_* functies aanroepen. In plaats daarvan kun je gebruik maken van een solide framework dat dat voor je doet. Dat voorkomt veel ellende. Heel vaak werken frameworks al met prepared statements en zit er goede (basis-)bescherming in tegen allerlei beveiligingsrisico's, zoals SQL injection, cross-site scripting (XSS of CSS), cross-site request forgery (XSRF of CSRF), etcetera.

[jbdeiman]

Verwijderd schreef op maandag 30 december 2013 @ 19:24:
Je kunt het best nooit mysql_* of mysqli_* functies aanroepen. In plaats daarvan kun je gebruik maken van een solide framework dat dat voor je doet. Dat voorkomt veel ellende. Heel vaak werken frameworks al met prepared statements en zit er goede bescherming in tegen allerlei beveiligingsrisico's, zoals SQL injection, cross-site scripting (XSS of CSS), cross-site request forgery (XSRF of CSRF), etcetera.

Leuk idee, maar daar leert hij natuurlijk niets van, uiteindelijk is het doel dat hij zelf ziet/ snapt waar mogelijke risico's zitten, via een Framework werk je daar vooral omheen. Dat is bij veel ontwikkelaars tegenwoordig het probleem, als je ze vraagt of e.e.a. goed beveiligd is en hoe dat dan is, is een veelgehoorde reactie "dat doet het framework", maar "ik heb gelezen dat het goed is".
Tjah, het beste is altijd nog als je zelf (voor een groot deel) weet hoe/ wat je in de gaten moet houden voor beveiligingsproblemen, je kan daarbij best ervoor kiezen een framework maar een stuk kennis moet je echt zelf meebrengen.

mysqli_ functies op zichzelf zijn helemaal niet verkeerd, het is hoe je ermee omgaat.

[ Voor 3% gewijzigd door jbdeiman op 30-12-2013 19:29 ]

[NMe]

Verwijderd schreef op maandag 30 december 2013 @ 19:06:
onderstaand voorbeeld wil ik bvb (nog) veilig maken tegen SQL injectie

Dat voorbeeld ís al veilig tegen SQL-injectie.

jbdeiman schreef op maandag 30 december 2013 @ 19:28:
[...]

Leuk idee, maar daar leert hij natuurlijk niets van, uiteindelijk is het doel dat hij zelf ziet/ snapt waar mogelijke risico's zitten, via een Framework werk je daar vooral omheen.

Een framework hoeft niet uit te sluiten dat je ook nog leert hoe het onder water werkt. Desnoods schrijf je zelf een frameworkje om je dat soort kennis eigen te maken. Dan blijft alsnog staan dat het absoluut een goed plan is om nooit zélf een mysql_ of mysqli_ functie aan te roepen vanuit je business logic.

Anyway: Waar hoort mijn topic? staat er niet voor niets.
WEB >> PRG

[Verwijderd]

jbdeiman schreef op maandag 30 december 2013 @ 19:24:
Wat je hier wil doen (als ik het goed begrijp) is een bepaalde waarde bijwerken in de database.
Je krijgt het id binnen via de GET variabele, die in een URL wordt meegegeven (na het vraagteken) en de overige gegevens gaan via de POST?

Inderdaad, in mijn URL zit mijn ID vanuit mijn vorige pagina hier wil ik op werken om een aanpassing te doen in mijn database en natuurlijk op de goede lijn!

Op zich is er niet heel veel mis met wat je nu doet qua veiligheid (vooral het typecasten naar een integer van het ID is een goed gebruik!) en eigenlijk kan er met de manier waarop je dit doet niet zoveel gebeuren, echter mag je dit voorbeeld nooit en te nimmer op een productieomgeving plaatsen, omda je daarin geen mysql fouten zomaar terug mag geven, dat is een veiligheidsissue.

O dat wist ik niet... Ik wou voorkomen dat de gebruiker dacht dat alles goed was verlopen ook al is het niet zo. Hoe escape ik dan het best in zo een situatie? Ik kan toch niet gewoon een DIE doen veronderstel ik?

Wat ik nog wel even aan wil snijden is het volgende:
Je datum hoeft nu helemaal geen datum te zijn, daar kunnen foute query's door ontstaan. Foute query's leveren een vergroot risico op lekken en andere problemen.

Wat je, aan PHP kant, nog kan / moet doen om dat op te lossen is dat je de ( geldigheid van de )datum gaat bepalen, hier zijn verschillende methoden voor die PHP aanbiedt:
- Je kan via date('Y-m-d', strtotime( $_POST['kalender_datum'])) de datum omzetten naar iets waar je zeker van weet dat de query mee om kan gaan, je moet hierbij wel nog fouten afhandelen.

- Door de datum op te knippen kan je via "checkdate" bepalen of het een geldige datum is.

- http://nl3.php.net/datetime: Hier heb je een hele boel functionaliteiten t.a.v het werken met datums in PHP.

Bedankt voor u tip, zal ik zeker eens doornemen! In een ander project zat ik te werken met de datetime maar misschien idd een goed idee om dit te herzien.
Alsook bedankt voor uw duidelijk antwoord!


Wat RedHat zegt is op zich wel een goede, dat maakt het schrijven van query's wat eenvoudiger, doordat je een aantal losse stukken schrijft. Je lost er alleen het probleem met "ik verwacht een datum, maar kan er ook tekst in gooien" niet mee op.
[/quote]

[NMe]

Verwijderd schreef op maandag 30 december 2013 @ 20:04:
[...]

O dat wist ik niet... Ik wou voorkomen dat de gebruiker dacht dat alles goed was verlopen ook al is het niet zo. Hoe escape ik dan het best in zo een situatie? Ik kan toch niet gewoon een DIE doen veronderstel ik?

Dat heeft niks te maken met beveiliging tegen SQL-injectie maar de manier waarop je omgaat met fouten. Als je je site goed opgezet hebt of een framework gebruikt dat dit voor je regelt hoef je vaak maar een exception te throwen wanneer er iets fout gaat en dan zorgt je foutafhandelingscode wel voor de juiste afhandeling, maar dan moet die code er wel zijn.

[CaVeFiSh]

Aan de SQL kant kun je ook met stored procedures werken, op die manier voorkom je dat er een stuk code direct op de database wordt afgevuurd en je daarmee eventueel teveel prijs geeft over je datastructuur. Ook is dat makkelijk voor het bepalen van rechten, zou kun kun je ervoor zorgen dat webusers wel rechten krijgen voor het uitvoeren van de stored procedure maar niet op de brontabellen.

[Gomez12]

@CaVeFiSh : Imho is 100% SP's alleen handig als je ook een 100% DBA'er hebt. Dan kan je data-logica en app-logica scheiden op functioneel gebied. In een mindere situatie zie ik het voornamelijk gebeuren dat de logica een beetje in de dbase en een beetje in de app komt te liggen.

[Amanush]

De enige manier om SQL te 'beveiligen', is door "user input" niet te vertrouwen en als onveilig te zien. Dit kan bijvoorbeeld via een encoding, dan kan de "input" namelijk opeens vrij weinig.

[Gomez12]

??? Encoding ??? Kan je eens uitleggen hoe dat in hemelsnaam iets veilig maakt? Ik zie even niet hoe Latin1 veiliger of onveiliger zou moeten zijn dan UTF-16...

[Daos]

Hij bedoelt vast zoiets: http://nl1.php.net/urlencode

Voor SQL is het eigenlijk standaard dat je niet je query opbouwt uit losse stukken, maar zoals eerder al genoemd iets als prepared statements gebruikt (elke taal waarin je SQL kan gebruiken heeft dit; het heet wel soms anders en ook de syntax kan afwijken)

[NMe]

CaVeFiSh schreef op woensdag 01 januari 2014 @ 14:55:
Aan de SQL kant kun je ook met stored procedures werken, op die manier voorkom je dat er een stuk code direct op de database wordt afgevuurd en je daarmee eventueel teveel prijs geeft over je datastructuur. Ook is dat makkelijk voor het bepalen van rechten, zou kun kun je ervoor zorgen dat webusers wel rechten krijgen voor het uitvoeren van de stored procedure maar niet op de brontabellen.

SP's gebruiken is een draak. Code hoort in je codebase waar je behoorlijk versiebeheer hebt en niet in je database. Daarmee zeg ik niet dat SP's per definitie fout zijn maar ik zou er wel een verdomd goede reden voor nodig hebben om ze te gebruiken in plaats van een stuk code dat hetzelfde doet.

Amanush schreef op woensdag 01 januari 2014 @ 16:48:
De enige manier om SQL te 'beveiligen', is door "user input" niet te vertrouwen en als onveilig te zien. Dit kan bijvoorbeeld via een encoding, dan kan de "input" namelijk opeens vrij weinig.

Encoding heeft - zoals gezegd - niks te maken met beveiliging tegen SQL-injectie. Escaping wel, maar er zijn modernere manieren om met query's om te gaan dan door zelf met strings te gaan knutselen, wederom zoals hierboven beschreven.

[Amanush]

Uhh, 'escaping' is een bepaald soort van 'encoding', sterker nog, het is gewoon 'encoding'. Geen twijfel mogelijk!

Daarnaast, als je alles via base64 gaat coderen is het hele SQL-injection probleem opgelost (niet dat ik het aanraad, het is namelijk verre van ideaal).

Je zou inderdaad stored procedures kunnen gebruiken. "Moderne manieren" is trouwens geen reden. We hebben te maken met afwegingen. er is niks (lees: weinig) mis met "met strings rommelen". "Storage procedures" is naar mijn mening vrij brak en ook niet helemaal wat je wilt bereiken.

Niet altijd heb je veel rechten, permissies, etc. Soms werk je wel eens via een hosting die niet vanalles toestaat. Misschien was escapen/encoden toch een goed idee..

Fouten maken is menselijk, hoor.

Daos schreef op woensdag 01 januari 2014 @ 18:07:
Hij bedoelt vast zoiets: http://nl1.php.net/urlencode

Voor SQL is het eigenlijk standaard dat je niet je query opbouwt uit losse stukken, maar zoals eerder al genoemd iets als prepared statements gebruikt (elke taal waarin je SQL kan gebruiken heeft dit; het heet wel soms anders en ook de syntax kan afwijken)

Klopt, PHP heeft bijvoorbeeld PDO. Uit ervaring kan ik je vertellen dat het er wellicht raar uitziet, maar het werkt prima. zelf gebruik ik Medoo, deze 'class' doet dat allemaal zelf voor me.

[ Voor 39% gewijzigd door Amanush op 01-01-2014 18:34 ]

[NMe]

Amanush schreef op woensdag 01 januari 2014 @ 18:29:
Uhh, 'escaping' is een bepaald soort van 'encoding', sterker nog, het is gewoon 'encoding'. Geen twijfel mogelijk!

Grapjas. Encoding geeft aan op welke manier elk karakter gelezen moet worden. Escaping vertelt alleen aan de parser/interpreter/compiler dat hij al dan niet iets bijzonders moet doen bij het in het geheugen zetten van die string.

[Amanush]

NMe schreef op woensdag 01 januari 2014 @ 18:33:
[...]

Grapjas. Encoding geeft aan op welke manier elk karakter gelezen moet worden. Escaping vertelt alleen aan de parser/interpreter/compiler dat hij al dan niet iets bijzonders moet doen bij het in het geheugen zetten van die string.

Beiden veranderen bepaalde strings in bepaalde andere strings..

De function "mysql_escape_string" vervangt bijvoorbeeld de character " ' " in " \' " terwijl urlrawencode een spatie (" ") veranderd in "%20". Beide dus encoding. Spreek me maar tegen.

Edit: Excuses, je hebt gelijk! Helemaal gelijk! Ken je die Twix reclame? Het verschil tussen encoding en escaping is net zo groot als de ene fabriek en de andere fabriek..

[ Voor 16% gewijzigd door Amanush op 01-01-2014 18:39 ]

[NMe]

Amanush schreef op woensdag 01 januari 2014 @ 18:37:
[...]

Beiden veranderen bepaalde strings in bepaalde andere strings..

Helemaal niet. Een encoding verandert niks, tenzij je de encoding daadwerkelijk verandert. En ook escaping verandert niks, het vertelt alleen de compiler dat het volgende karakter anders gelezen moet worden. Ik zou me er als ik jou was nog eens in verdiepen. The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) is een mooi begin.

[Daos]

"met strings rommelen" ziet eruit als gerommel. Kijk maar eens naar de "prepared statements". Dat ziet er mooier uit, het is soms sneller en je hebt geen last van sql-injection.

"Stored procedures" is code die op de database draait. Dat staat los van sql-injectie De theorie was dat als het op de db draait je webserver minder weet over de db (denk aan tabelnamen etc) en ook minder prijs kan geven (denk aan foutmeldingen met tabelnamen er in of erger nog dat de webserver gehackt wordt).

Over de "encoding" zeg ik verder maar niets...

[Amanush]

Ze veranderen niks? Waarom gebruik je ze dan, eigenlijk?

Klik maar hier en je ziet dat beiden eigenlijk stiekem "encoding" zijn.. En ja, Content-Type heeft een relatie met "encoding". Als je denk dat ik daarop doel mag je wel opnieuw naar de MAVO gaan..

[ Voor 70% gewijzigd door Amanush op 01-01-2014 18:48 ]

[Verwijderd]

NMe schreef op woensdag 01 januari 2014 @ 18:33:

Grapjas. Encoding geeft aan op welke manier elk karakter gelezen moet worden.

En base64 dan?

Ik denk dat je over het hoofd ziet dat "encoding" een te algemene term is en dat dit een spraakverwarring betreft.

Als we het zouden hebben over "content encoding" versus "character encoding" zou het helderder zijn. Maar basically is het zo dat je ook bijvoorbeeld base64 kunt gebruiken om content "veilig" over te brengen omdat een base64 encoded string geen bijzondere tekens zal bevatten. Zo kun je elke vorm van content en/of character encoding gebruiken waar dat ook voor geldt.

Het was echter niet zo handig van Amanush om encoding te noemen zonder context. Escaping is wel een vorm van encoding, maar encoding is niet zonder meer "veilig". Het gaat erom dat de methode die je gebruik de eigenschap heeft dat het resultaat niet misbruikt kan worden.

[dcm360]

Een encoding is het opslaan van gegevens in een (gelimiteerde) set van karakters. In een URI is de ' ' niet aanwezig in de set van karakters, dus verzin je een manier om de spatie (en andere tekens die niet aanwezig zijn in de karakterset) te kunnen representeren in de set.

Escaping is het geven van een hint aan een tokenizer/parser/compiler. In een bepaalde taal wordt de ' gebruikt om een tekenreeks af te sluiten. Nu wil je echter in de tekenreeks ook een ' gebruiken, dus geef je de hint dat die ' niet de reeks afsluit maar het teken ' is.

[Amanush]

Ik denk dat Cheatah gelijk heeft en dat hier gewoon spraakverwarring is ontstaan en dat ik inderdaad over "character encoding" zat te praten terwijl NMe over "content encoding" zat te praten.

[NMe]

Amanush schreef op woensdag 01 januari 2014 @ 18:55:
Ik denk dat Cheatah gelijk heeft en dat hier gewoon spraakverwarring is ontstaan en dat ik inderdaad over "character encoding" zat te praten terwijl NMe over "content encoding" zat te praten.

Juist precies andersom.

[Amanush]

Kan ook kloppen

[.oisyn]

dcm360 schreef op woensdag 01 januari 2014 @ 18:54:
Een encoding is het opslaan van gegevens in een (gelimiteerde) set van karakters. In een URI is de ' ' niet aanwezig in de set van karakters, dus verzin je een manier om de spatie (en andere tekens die niet aanwezig zijn in de karakterset) te kunnen representeren in de set.

Escaping is het geven van een hint aan een tokenizer/parser/compiler. In een bepaalde taal wordt de ' gebruikt om een tekenreeks af te sluiten. Nu wil je echter in de tekenreeks ook een ' gebruiken, dus geef je de hint dat die ' niet de reeks afsluit maar het teken ' is.

Encoding is een manier om informatie te representeren in een bepaald tekenset. Escaping is een specifieke manier om encoding te bewerkstelligen. Het woord "escaping" slaat op het feit dat je even uit de normale 1-op-1 transformatie stapt, met een specifiek teken(reeks). Zowel de \n in een C string als een %20 in een URL zijn vormen van escaping. De niet-geëscapete tekens worden gewoon direct doorgegeven, en de geëscapete tekenreeks wordt op een bepaalde manier geïnterpreteert en omgezet. Escaping is dus altijd een vorm van encoding, maar andersom uiteraard niet. Overigens, ook in UTF-8 en UTF-16 wordt er gebruik gemaakt van escaping.

[ Voor 6% gewijzigd door .oisyn op 02-01-2014 12:59 ]