Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Waarom zijn mijn SQL statements onveilig?

08-05-2020, 15:14 door Anoniem, 43 reacties
Ik had een sollicitatie gesprek en moest een stukje code schrijven. Nou gaf de werkgever een opdracht (heb gefaald) in Java maar gaf aan dat mijn SQL opdrachten onveilig zouden zijn.

Waarom is dat en hoe doe ik het beter?

Mijn code:

import java.util.List;
import javax.sql.DataSource;
import org.springframework.jdbc.core.JdbcTemplate;

public class KlantJDBCTemplate implements KlantDAO {
private DataSource dataSource;
private JdbcTemplate jdbcTemplateObject;

public void setDataSource(DataSource dataSource) {
this.dataSource = dataSource;
this.jdbcTemplateObject = new JdbcTemplate(dataSource);
}
public void create(String naam, Integer leeftijd) {
String SQL = "insert into Klant (naam, leeftijd) values (?, ?)";
jdbcTemplateObject.update( SQL, naam, leeftijd);
System.out.println("Created Record naam = " + naam + " leeftijd = " + leeftijd);
return;
}
public Klant getKlant(Integer id) {
String SQL = "select * from Klant where id = ?";
Klant Klant = jdbcTemplateObject.queryForObject(SQL,
new Object[]{id}, new KlantMapper());

return Klant;
}
public List<Klant> listKlants() {
String SQL = "select * from Klant";
List <Klant> Klants = jdbcTemplateObject.query(SQL, new KlantMapper());
return Klants;
}
public void delete(Integer id) {
String SQL = "delete from Klant where id = ?";
jdbcTemplateObject.update(SQL, id);
System.out.println("Deleted Record with ID = " + id );
return;
}
public void update(Integer id, Integer leeftijd){
String SQL = "update Klant set leeftijd = ? where id = ?";
jdbcTemplateObject.update(SQL, leeftijd, id);
System.out.println("Updated Record with ID = " + id );
return;
}
}
Reacties (43)
09-05-2020, 07:00 door Erik van Straten - Bijgewerkt: 09-05-2020, 07:02
Ik weet niet waar de inhoud van o.a. de parameter 'naam' vandaan komt in de functie Create(), maar als een gebruiker daarvoor kan invoeren wat zij wil, bijvoorbeeld iets als:
<script>alert(42)</script>
en die string ongewijzigd in de database terechtkomt, dan moet je je wellicht niet alleen zorgen maken om SQL injection attacks - die je lijkt te hebben voorkomen met parameterized queries, verzorgd door jdbcTemplateObject - maar (hoewel ik op Java gewoond heb) ik heb geen ervaring met die programmeertaal en zeker niet met frameworks als Spring.

Misschien kan een Java+Spring guru hier uitsluitsel over geven? Anders kun je met dit soort vragen wellicht beter naar StackOverflow. Security is een gigantisch groot vakgebied; ook als je er bakken tijd aan besteedt kun je absoluut niet overal "specialist" (het woord zegt het al) in zijn.
09-05-2020, 07:44 door Anoniem
Disclaimer: ik ben ook geen dagelijkse Java/Spring programmeur.

Het voornaamste probleem van injecties lijk je inderdaad te voorkomen door parameterized queries te gebruiken. Blijft ook vreemd dat het bedrijf waar je gesolliciteerd wel zegt dat het onveilig is, maar vervolgens zelf niet uitlegt waarom. Je mag wel verwachten dat als je op basis hier van niet door de selectie komt, je wel te horen krijgt wát er dan mis mee is. Dan kan je er ieder geval nog wat van leren voor een volgende keer.

Wat ik nog zou kunnen bedenken:
Parameter validatie: een NULL check op de strings en een range check op de gegevens ID's. Al zal in het geval van een probleem je waarschijnlijk een exceptie krijgen, wat mij brengt op het tweede punt
Exception handling: de update() en queryForObject() kunnen een DataAccessException terug geven. Er mist nu code om daar iets mee te doen, wat ze verwacht hadden dat je hier aan zou denken

Wat betreft het sanitizen van input, zoals Erik noemt, kan je beargumenteren dat het beter is om dat te vervangen door het sanitizen van de output. Immers kun je niet van te horen weten op welke andere plekken deze gegevens terecht komen - dat hoeft niet altijd een website te zijn geschreven in HTML te zijn - waarmee het onduidelijk is waarop je precies zou moeten filteren.
09-05-2020, 07:55 door Anoniem
De code is onveilig omdat er injecties kunnen worden gedaan in de sql-string die je opbouwt.

Lees phrack.org eens.
09-05-2020, 10:22 door Erik van Straten
Door Anoniem: De code is onveilig omdat er injecties kunnen worden gedaan in de sql-string die je opbouwt.
Wat ik ervan begrijp, als leek, is dat jdbcTemplateObject.update( ) SQL injectie voorkomt mits je de parameters separaat doorgeeft, dus juist niet als onderdeel van de SQL opdracht. Ik heb er te weinig inzicht in of de TS dit in alle gevallen goed gedaan heeft, maar -met mijn gebrekkige kennis van Java en Spring- zie ik de fouten er op dat punt niet vanaf spatten.

Door Anoniem: Lees phrack.org eens.
Of de Max Havelaar, ook interessant (zullen sommigen vinden). Als je niet met een verwijzing komt naar een artikel waarin klip en klaar staat waarom het goed of fout is wat de TS doet, blijft het gissen zo.
09-05-2020, 10:47 door Anoniem
Door Anoniem:
Wat betreft het sanitizen van input, zoals Erik noemt, kan je beargumenteren dat het beter is om dat te vervangen door het sanitizen van de output. Immers kun je niet van te horen weten op welke andere plekken deze gegevens terecht komen - dat hoeft niet altijd een website te zijn geschreven in HTML te zijn - waarmee het onduidelijk is waarop je precies zou moeten filteren.
Inderdaad, ik zie in die hele vraag het woord website niet genoemd dus waarom zou je dan moeten filteren op dingen die
op een website misschien problemen zouden kunnen geven in basis routines om een database te benaderen?
Dat lijkt me iets om in een hogere laag te doen.

Ik zou zelf nooit "SELECT *" gebruiken behalve in zelf ingetikte queries in een commandline tool om dingen te debuggen,
maar dat is denk ik niet waar ze op doelen.

Het belangrijkste van het hele verhaal is dat als je als bedrijf iemand een dergelijke opdracht geeft, en je gaat daar
dan vervolgens een waardering voor geven, je die redelijkerwijs wel aan die persoon moet terug geven, en niet
"NEE, FOUT. AFGEWEZEN". Voor hetzelfde geld zit de beoordelaar fout omdat bij bij een vluchtige blik die constructie
om die logmelding te printen door wat strings aan elkaar te plakken aanzag voor een constructie om SQL te bakken.
(wat WEL fout zou zijn geweest!)
09-05-2020, 12:47 door Anoniem
Check het eens online hier: https://www.eversql.com/sql-syntax-check-validator/

luntrus
09-05-2020, 14:11 door Anoniem
Mijn ervaring met SQL is maar oppervlakkig en roestig, en met het Spring-framework heb ik nooit gewerkt, maar ik heb uit nieuwsgierigheid even in de API-documentatie daarvan geneusd, en daar viel me iets op dat mogelijk relevant is.

De docstring van de update()-method bevat: "... (leaving it to the PreparedStatement to guess the corresponding SQL type); ...". Het woordje guess zette mij op scherp, en PreparedStatement wees meteen de weg naar een manier van aansturen die het niet aan het toeval overlaat, want als je daar kijkt zie je dat die per SQL-type methods heeft om parameters in te stellen.

Je gebruikt dus een method waarbij onduidelijk kan zijn hoe de invoer geïnterpreteerd zal gaan worden en die laat je los op invoer waarvan je niet onder controle hebt wat die kan bevatten. Dat klinkt als iets dat potentiëel te misbruiken is.

Zelfs als dat goed is dichtgetimmerd in het Spring-framework (ik weet niet of dat zo is), dan nog zou ik als op veiligheidslekken bedachte programmeur altijd kiezen voor een variant waar de manier van verwerken expliciet is en niet voor een variant waar die impliciet is. Zelfs als het in de huidige versie van Spring goed gaat kan de manier waarop een SQL-type geraden wordt in de toekomst wellicht anders zijn en wie weet gaat er dan iets mis.

Expliciet regelen wat je code doet is domweg voorspelbaarder en daarmee veiliger dan code waarin van alles impliciet gebeurt. En de code wordt ook nog eens zelfdocumenterender en daarmee leesbaarder ervan.

Ik weet natuurlijk niet of dit is waar men over viel, maar ik kan me er iets bij voorstellen.
09-05-2020, 17:03 door karma4
Let even op de voorbeelden: https://docs.spring.io/spring/docs/2.0.x/reference/jdbc.html
Je leert de taal maar hardcoded user id's en passwordt zitten er standaard in. De mogelijkheden van code injection worden niet echt benoemd. Daarvoor moet je veel verder zoals [urlhttps://www.baeldung.com/sql-injection[/url]
Als de het coderen enkel bedoeld was om de kennis van onbedoelde effecten en wat er tegen te doen te verifieren, dan is dat in hun kaders gedaan. Het hoeft niet exact jouw kaders te zijn.
09-05-2020, 18:33 door The FOSS
String SQL = "insert into Klant (naam, leeftijd) values (?, ?)";
jdbcTemplateObject.update( SQL, naam, leeftijd);

Die parameters voor die placeholders moeten toch in een array worden meegegeven aan update()?
09-05-2020, 18:42 door Anoniem
Nog even los van het "zoek de fout" denk ik dat het selecteren van personeel op deze manier wellicht gerechtvaardigd
is als je bijvoorbeeld een Corona tracking app moet maken die komend weekend (of binnen 3 weken) af moet zijn en je
daar snel wat code klopvolk voor moet scoren wat zonder tijdverlies de door jou gewenste code kan kloppen, maar als
je gewoon op zoek bent naar een nieuw teamlid is het nou niet bepaald een geweldige methode.

Veel belangrijker dan dat een sollicitant alle wanen-van-de-dag uit zijn hoofd kent en deze meteen toepast volgens het
template wat je in gedachten had lijkt me dat je iemand aanneemt die dit soort dingen begrijpt en toepast op het moment
dat ze uitgelegd worden. Dat je met prepared statements gewerkt hebt is al een indicatie dat je basiskennis hebt die
een PHP-voor-dummies programmeur niet heeft (reden dat we het ene na het andere securitylek vinden in PHP producten)
en als men dan zo omgaat met sollicitanten zou ik er niet eens WILLEN werken. Waarschijnlijk sta je buiten als de baas
de eerste week dat je daar werkt een bug vindt in code die je geschreven hebt!
09-05-2020, 23:35 door Anoniem
Door Erik van Straten:
Door Anoniem: De code is onveilig omdat er injecties kunnen worden gedaan in de sql-string die je opbouwt.
Wat ik ervan begrijp, als leek, is dat jdbcTemplateObject.update( ) SQL injectie voorkomt mits je de parameters separaat doorgeeft, dus juist niet als onderdeel van de SQL opdracht. Ik heb er te weinig inzicht in of de TS dit in alle gevallen goed gedaan heeft, maar -met mijn gebrekkige kennis van Java en Spring- zie ik de fouten er op dat punt niet vanaf spatten.
Met string opbouw kun je altijd de latere escaping voorkomen/saboteren, mits je weet hoe het filter werkt.


Door Anoniem: Lees phrack.org eens.
Of de Max Havelaar, ook interessant (zullen sommigen vinden). Als je niet met een verwijzing komt naar een artikel waarin klip en klaar staat waarom het goed of fout is wat de TS doet, blijft het gissen zo.

phrack.org is een mooie plek om idioten met wanen en phreaks met serieuze hacks te leren onderscheiden. Hacken is iets dat in het hart ligt, niet dat je leert door een cursus. Snap je phrack.org, dan lees je de artikelen met een glimlach, en lees je tussen de regels de echte geheimen.
10-05-2020, 01:21 door Anoniem
Door The FOSS:
String SQL = "insert into Klant (naam, leeftijd) values (?, ?)";
jdbcTemplateObject.update( SQL, naam, leeftijd);

Die parameters voor die placeholders moeten toch in een array worden meegegeven aan update()?

Jij snapt het!
10-05-2020, 06:35 door Anoniem
Door The FOSS: Die parameters voor die placeholders moeten toch in een array worden meegegeven aan update()?
RTFM, die is online beschikbaar.
10-05-2020, 08:40 door The FOSS - Bijgewerkt: 10-05-2020, 08:41
Door Anoniem:
Door The FOSS: Die parameters voor die placeholders moeten toch in een array worden meegegeven aan update()?
RTFM, die is online beschikbaar.

Dank je voor de ratificatie ter finesse majeure (maar hoezo is die online beschikbaar?)

Dus die parameters kunnen niet worden doorgegeven zoals hierboven? Dan is dat dus het probleem.
10-05-2020, 09:36 door Erik van Straten
Door The FOSS:
Door Anoniem:
Door The FOSS: Die parameters voor die placeholders moeten toch in een array worden meegegeven aan update()?
RTFM, die is online beschikbaar.

Dank je voor de ratificatie ter finesse majeure (maar hoezo is die online beschikbaar?)

Dus die parameters kunnen niet worden doorgegeven zoals hierboven? Dan is dat dus het probleem.
Pakt handje van "Waarom? Waarom?" vrager in de hoop dat deze wat leert...

1) Google: JdbcTemplate

2) Klik op "JdbcTemplate (Spring Framework 5.2.6.RELEASE API) https://docs.spring.io › org › jdbc › core" (bij mij het bovenste zoekresultaat)

3) Scroll naar de "update" functies met "args" parameters

4) Klik op "update" ZONDER array params, of klik meteen op de link die ik geef: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/core/JdbcTemplate.html#update-java.lang.String-java.lang.Object...-

Als je Googled naar "JdbcTemplate.update(" (inclusief aanhalingstekens) vind je tal van voorbeelden met losse (dus geen arrays) "vraagtekenparameters".
10-05-2020, 09:42 door The FOSS
Door Erik van Straten:
Door The FOSS:
Door Anoniem:
Door The FOSS: Die parameters voor die placeholders moeten toch in een array worden meegegeven aan update()?
RTFM, die is online beschikbaar.

Dank je voor de ratificatie ter finesse majeure (maar hoezo is die online beschikbaar?)

Dus die parameters kunnen niet worden doorgegeven zoals hierboven? Dan is dat dus het probleem.
Pakt handje van "Waarom? Waarom?" vrager in de hoop dat deze wat leert...

1) Google: JdbcTemplate

2) Klik op "JdbcTemplate (Spring Framework 5.2.6.RELEASE API) https://docs.spring.io › org › jdbc › core" (bij mij het bovenste zoekresultaat)

3) Scroll naar de "update" functies met "args" parameters

4) Klik op "update" ZONDER array params, of klik meteen op de link die ik geef: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/core/JdbcTemplate.html#update-java.lang.String-java.lang.Object...-

Als je Googled naar "JdbcTemplate.update(" (inclusief aanhalingstekens) vind je tal van voorbeelden met losse (dus geen arrays) "vraagtekenparameters".

Jamaar, dan is de uitspraak '... SQL opdrachten onveilig zouden zijn.' dus gewoon niet waar en kan de sollicitant een juridische procedure starten wegens onterechte afwijzing!
10-05-2020, 09:49 door Erik van Straten
Door Anoniem:
Door Erik van Straten:
Door Anoniem: De code is onveilig omdat er injecties kunnen worden gedaan in de sql-string die je opbouwt.
Wat ik ervan begrijp, als leek, is dat jdbcTemplateObject.update( ) SQL injectie voorkomt mits je de parameters separaat doorgeeft, dus juist niet als onderdeel van de SQL opdracht. Ik heb er te weinig inzicht in of de TS dit in alle gevallen goed gedaan heeft, maar -met mijn gebrekkige kennis van Java en Spring- zie ik de fouten er op dat punt niet vanaf spatten.
Met string opbouw kun je altijd de latere escaping voorkomen/saboteren, mits je weet hoe het filter werkt.
Ah, wellicht komen we nu ergens. Graag links naar voorbeelden waarom het een risico vormt wat de TS doet (en al die andere gebruikers van Spring's JdbcTemplate).

Nogmaals, ik heb geen detailkennis op dit gebied, dus je zou zomaar gelijk kunnen hebben. Maar dan zul je dat wel moeten aantonen om ons (op z'n minst de TS en mij) daarvan te overtuigen; mogelijk loze kreten van een Anoniem slaan nog geen deuk in een pakje boter.
10-05-2020, 10:03 door Erik van Straten
Door The FOSS: Jamaar, dan is de uitspraak '... SQL opdrachten onveilig zouden zijn.' dus gewoon niet waar en kan de sollicitant een juridische procedure starten wegens onterechte afwijzing!
Dat jij (die er, net als ik, de ballen verstand van hebt, maar RTFM overslaat en willekeurig begint te prikken) je -na deze blunder- niet meer kunt voorstellen dat de TS terecht is afgewezen, helpt de TS voor geen meter.

Niet voor niets probeerde ik met mijn eerste bijdrage de scope te verruimen. Als het al gerelateerd is aan de programmeeropdracht dat de kandidaat is afgewezen, bestaat de kans dat de TS (waarschijnlijk onbewust) onvoldoende details heeft gegeven en ons op de verkeerde plaats laat zoeken naar iets wat er mogelijk niet is.
10-05-2020, 10:09 door [Account Verwijderd] - Bijgewerkt: 10-05-2020, 10:38
In de documentatie waar Erik aan linkt staat vrij duidelijk "Issue a single SQL update operation (such as an insert, update or delete statement) via a prepared statement, binding the given arguments." Als je doorklinkt kom je uit op https://docs.oracle.com/javase/8/docs/api/java/sql/PreparedStatement.html waar ook staat te lezen dat het gaat om
An object that represents a precompiled SQL statement.
Het gaat dus om precompiled SQL queries die gebruikt worden door een PreparedStatement. Daar zit dus niet nog een 'latere escaping' in die je kunt omzeilen, alle interpretatie heeft wat de database betreft namelijk al plaatsgevonden. Hoe dit werkt staat bijvoorbeeld uitgelegd op https://javabypatel.blogspot.com/2015/09/how-prepared-statement-in-java-prevents-sql-injection.html. Laat ik voor de duidelijkheid nog even een citaat uit de blogpost geven:
Due to one time compilation feature of PreparedStatement, it is free of SQL Injection attack.
De TS geeft al aan dat hij zelf niet begrijp wat er fout is, en terecht want SQL injecties worden hier wel gewoon voorkomen. Zoals ik in mijn bijdrage van 07:44 schreef vermoed ik dat men ook input validatie en/of error handling en/of (zoals Erik voorstelde) input sanitization had verwacht. Dan kan de discussie nu ophouden over SQL injecties wel of niet, dat is gewoon niet aan de orde hier.

EDIT: Citaat toegevoegd en link naar originele blogpost gegeven
10-05-2020, 10:37 door The FOSS - Bijgewerkt: 10-05-2020, 11:04
Door Erik van Straten:
Door The FOSS: Jamaar, dan is de uitspraak '... SQL opdrachten onveilig zouden zijn.' dus gewoon niet waar en kan de sollicitant een juridische procedure starten wegens onterechte afwijzing!
Dat jij (die er, net als ik, de ballen verstand van hebt, maar RTFM overslaat en willekeurig begint te prikken) je -na deze blunder- niet meer kunt voorstellen dat de TS terecht is afgewezen, helpt de TS voor geen meter.

Spreek voor jezelf (er de ballen verstand van hebben). En hoe kan je een ratificatie ter finesse majeure overslaan?

Door Erik van Straten: Niet voor niets probeerde ik met mijn eerste bijdrage de scope te verruimen. Als het al gerelateerd is aan de programmeeropdracht dat de kandidaat is afgewezen, bestaat de kans dat de TS (waarschijnlijk onbewust) onvoldoende details heeft gegeven en ons op de verkeerde plaats laat zoeken naar iets wat er mogelijk niet is.

Zou dát het zijn? Misschien heeft hij of zij het expres gedaan? Net zoiets als https://www.security.nl/posting/654925/Mijn+oude+moeder+haar+computer+overnemen maar dan anders.

Het onderstaande codefragment is denk ik de werkelijke reden voor de afwijzing:

public List<Klant> listKlants() {
String SQL = "select * from Klant";
List <Klant> Klants = jdbcTemplateObject.query(SQL, new KlantMapper());
return Klants;
}

(Zeg nou eerlijk, zou jij iemand aannemen die het meervoud van klant als klants spelt?)
10-05-2020, 10:52 door Anoniem
Door karma4: Let even op de voorbeelden: https://docs.spring.io/spring/docs/2.0.x/reference/jdbc.html
Je leert de taal maar hardcoded user id's en passwordt zitten er standaard in.
Die zitten niet standaard in de taal, die zitten in voorbeeldcode van een framework (niet de taal) die niet dient om het beheer van credentials voor databaseconnecties te illustreren maar om te laten zien hoe je credentials doorgeeft als je een connectie met een database maakt. Het is heel gangbaar om in voorbeeldcode waarden hard te coderen die in een echte toepassing niet hard gecodeerd worden. Dat is om het voorbeeld to-the-point te houden en de aandacht niet af te leiden met boilerplate die over iets anders gaat dan wat men aan het illustreren is.

Als dat ertoe leidt dat credentials hard in productiecode belanden dan heb je geen probleem met die voorbeelden maar met de aanwezige competentie in het projectteam, of met omstandigheden (haast, chaos) die mensen belemmeren in het toepassen van hun competentie. Dat los je niet op door naar die codevoorbeelden te wijzen alsof daar iets mis mee is, daarvoor moet je kritisch naar de organisatie kijken.
10-05-2020, 10:57 door The FOSS - Bijgewerkt: 10-05-2020, 10:58
...
10-05-2020, 10:59 door Anoniem
Door The FOSS: En hoe kan je een ratificatie ter finesse majeure overslaan?
Kennelijk moet het in je gezicht gewreven worden voor je stopt te doen alsof je het niet begrepen hebt. Goed dan:

Read The Fucking Manual. Die staat online.
10-05-2020, 11:13 door Anoniem
Code uit script:
public void delete(Integer id) {
String SQL = "delete from Klant where id = ?";

Voorbeeld SQL injectie. Stel voor:
id = "0; DROP TABLE klant;"
Dit zorgt ervoor dat de tabel gedropped wordt.

Bij goed database design zijn er voldoende permissie gestricties aanwezig dat dit niet lukt, maar een complexere injectie kan ook die mogelijk saboteren. Het is mogelijk om via queries het achterliggende schema te bevragen, en die informatie te gebruiken.
10-05-2020, 13:50 door Erik van Straten - Bijgewerkt: 10-05-2020, 13:59
Door Anoniem: Voorbeeld SQL injectie. Stel voor:
id = "0; DROP TABLE klant;"
Dit zorgt ervoor dat de tabel gedropped wordt.
Misschien dat niet elke lezer dit snapt, maar de TS hoogstwaarschijnlijk wel; deze exploit (type https://xkcd.com/327/) is m.i. niet van toepassing op de door de TS verstrekte code (in elk geval niet op deze plaats).

Immers, de relevante code is 1 regel langer en luidt:
public void delete(Integer id) {
String SQL = "delete from Klant where id = ?";
jdbcTemplateObject.update(SQL, id);
Aangezien 'id' van het type Integer is en, daarbovenop, als parameter (buiten het SQL commando) aan de SQL engine wordt doorgegeven, betekent dit m.i. geen enkel risico v.w.b. SQL injectie.
10-05-2020, 14:05 door Anoniem
Inderdaad lijkt een deel van de lezers het concept van prepared SQL statements (met ? als placeholder en doorgeven
van een lijst parameters aan de uitvoering van het statement) niet te snappen, en te denken dat de runtime dit intern
vervangt door de parameters op de plekken van die ? te zetten (zoals een %s in een sprintf zou doen) en dan vervolgens
het statement te parsen. Dat is dus niet zo, of in ieder geval dat zou niet zo moeten zijn.
(als die Java libraries dat wel zo oplossen smijt die dan maar weg!)
10-05-2020, 14:27 door Anoniem
Door Erik van Straten:
Door Anoniem: Voorbeeld SQL injectie. Stel voor:
id = "0; DROP TABLE klant;"
Dit zorgt ervoor dat de tabel gedropped wordt.
Misschien dat niet elke lezer dit snapt, maar de TS hoogstwaarschijnlijk wel; deze exploit (type https://xkcd.com/327/) is m.i. niet van toepassing op de door de TS verstrekte code (in elk geval niet op deze plaats).

Immers, de relevante code is 1 regel langer en luidt:
public void delete(Integer id) {
String SQL = "delete from Klant where id = ?";
jdbcTemplateObject.update(SQL, id);
Aangezien 'id' van het type Integer is en, daarbovenop, als parameter (buiten het SQL commando) aan de SQL engine wordt doorgegeven, betekent dit m.i. geen enkel risico v.w.b. SQL injectie.

id moeten nooit van type integer zijn, maar van type varchar met id's die worden gegenereerd door UUID key generator.
10-05-2020, 14:38 door Anoniem
Door Anoniem: Code uit script:
public void delete(Integer id) {
String SQL = "delete from Klant where id = ?";

Voorbeeld SQL injectie. Stel voor:
id = "0; DROP TABLE klant;"
Dit zorgt ervoor dat de tabel gedropped wordt.

Bij goed database design zijn er voldoende permissie gestricties aanwezig dat dit niet lukt, maar een complexere injectie kan ook die mogelijk saboteren. Het is mogelijk om via queries het achterliggende schema te bevragen, en die informatie te gebruiken.

knap hoe jij van een integer ineens een string dan maakt.
10-05-2020, 14:51 door [Account Verwijderd]
Door Anoniem:Voorbeeld SQL injectie. Stel voor:
id = "0; DROP TABLE klant;"
Dit zorgt ervoor dat de tabel gedropped wordt.
Dit in onzin, het gaat om een precompiled SQL waarbij de interpretatie al gedaan is. Er kán dus geen SQL injectie meer plaatsvinden in een van de parameters. En dat is nog los van het feit dat het gaat om integers i.p.v. een string.
10-05-2020, 15:06 door Anoniem
Gebruikt code tags voor code samples. Dit is de code geherformatteerd.

import java.util.List;
import javax.sql.DataSource;
import org.springframework.jdbc.core.JdbcTemplate;

public class KlantJDBCTemplate implements KlantDAO {
private DataSource dataSource;
private JdbcTemplate jdbcTemplateObject;

public void setDataSource(DataSource dataSource) {
this.dataSource = dataSource;
this.jdbcTemplateObject = new JdbcTemplate(dataSource);
}
public void create(String naam, Integer leeftijd) {
String SQL = "insert into Klant (naam, leeftijd) values (?, ?)";
jdbcTemplateObject.update(SQL, naam, leeftijd);
System.out.println("Created Record naam = " + naam + " leeftijd = " + leeftijd);
return;
}
public Klant getKlant(Integer id) {
String SQL = "select * from Klant where id = ?";
Klant Klant = jdbcTemplateObject.queryForObject(SQL,
new Object[] {
id
}, new KlantMapper());

return Klant;
}
public List < Klant > listKlants() {
String SQL = "select * from Klant";
List < Klant > Klants = jdbcTemplateObject.query(SQL, new KlantMapper());
return Klants;
}
public void delete(Integer id) {
String SQL = "delete from Klant where id = ?";
jdbcTemplateObject.update(SQL, id);
System.out.println("Deleted Record with ID = " + id);
return;
}
public void update(Integer id, Integer leeftijd) {
String SQL = "update Klant set leeftijd = ? where id = ?";
jdbcTemplateObject.update(SQL, leeftijd, id);
System.out.println("Updated Record with ID = " + id);
return;
}
}

Als het closed source betreft kun je het beste de tabel en fields niet raadbaar maken. Dat maakt het moeilijker voor de aanvaller als het lukt om code te injecteren. Foutmeldingen kunnen daar wel roet in het eten gooien.

Is dit een klein deel van de code? Als C programmeur (Java weet ik weinig van) zie ik geen main en diverse functies worden nergens aangeroepen. Complete code is nodig om te zien wat er gebeurt.
10-05-2020, 15:15 door karma4 - Bijgewerkt: 10-05-2020, 15:20
Door Anoniem: …. maar met de aanwezige competentie in het projectteam, of met omstandigheden (haast, chaos) die mensen belemmeren in het toepassen van hun competentie. Dat los je niet op door naar die codevoorbeelden te wijzen alsof daar iets mis mee is, daarvoor moet je kritisch naar de organisatie kijken.
Daar heb je gelijk in. Het zijn voorbeelden om de taal te leren niet om veilig te coderen. Als we de laatste zouden hebben dan zou het wel eens beter kunnen gaan met veilige code. Overigens heb ik wat te vaak meegemaakt dat dat soort voorbeelden omdat ze van een leverancier komen, hoe fout dan ook, als heilig verklaard worden. Het heten "best practices".

Het verbaast met dat het probleem die de intaker zo snel zag bij deze draad, of dat hij zocht naar een bepaalde wijze van denken, niet zo direct zien. Ach eigenlijk niet zo verbazend als je at zaken meegemaakt en gelezen hebt. Het is lastig onbekende zaken vooraf goed in te schatten. Ik zit me te vermaken met de EWD246 pag 20...
10-05-2020, 18:33 door Anoniem
Door Anoniem:
Door Anoniem: Code uit script:
public void delete(Integer id) {
String SQL = "delete from Klant where id = ?";

Voorbeeld SQL injectie. Stel voor:
id = "0; DROP TABLE klant;"
Dit zorgt ervoor dat de tabel gedropped wordt.

Bij goed database design zijn er voldoende permissie gestricties aanwezig dat dit niet lukt, maar een complexere injectie kan ook die mogelijk saboteren. Het is mogelijk om via queries het achterliggende schema te bevragen, en die informatie te gebruiken.

knap hoe jij van een integer ineens een string dan maakt.

Ah, dat had ik niet gezien, even niet opgelet. Maar normaliter gebruik je een varchar als id in databases; dit om voorspelling van bestaande id's te voorkomen.
10-05-2020, 21:01 door Anoniem
public void create(String naam, Integer leeftijd)
Waarom niet in de database een geboortejaar; zodoende kun je altijd de leeftijd bepalen.

public List<Klant> listKlants() {
String SQL = "select * from Klant";
Waarom niet een selectie die geordend is, en een deel selectie. Nu krijg je alle records, ipv bijvoorbeeld klanten 100-200.

public Klant getKlant(Integer id) {
Wat als het id niet bestaat omdat deze zojuist verwijderd is.

public void update(Integer id, Integer leeftijd)
Iemands geboortejaar is beter om te gebruiken. Ga je aan de klant vragen of hij elk jaar zijn leeftijd verhoogd?
10-05-2020, 21:21 door Anoniem
Als ik eerlijk ben vind je code top! Je gebruikt netjes de parameterized queries en de code is goed te lezen. Dus ik zou zeker eens vragen waarom ze het niet goed vonden. Ik zie geen SQL injectie mogelijkheden (want netjes parametrized queries). Dus ik zou zeggen, ga zo door! :)
11-05-2020, 07:42 door The FOSS - Bijgewerkt: 11-05-2020, 07:50
Door Anoniem:
public void create(String naam, Integer leeftijd)
Waarom niet in de database een geboortejaar; zodoende kun je altijd de leeftijd bepalen.

Ja, dat werkt geweldig! Vooral bij mensen die 31 december jarig zijn! Dan zit je er het hele jaar min één dag een jaar naast. Daar had je natuurlijk niet aan gedacht hè? Slimmerik...

Door Anoniem:
public List<Klant> listKlants() {
String SQL = "select * from Klant";
Waarom niet een selectie die geordend is, en een deel selectie [sic]. Nu krijg je alle records, ipv bijvoorbeeld klanten 100-200.

Nou en? Stond dat in de opdrachtbeschrijving dan?

Door Anoniem:
public Klant getKlant(Integer id) {
Wat als het id niet bestaat omdat deze [sic] zojuist verwijderd is.

Daar heb je transacties voor maar die vallen buiten de scope van dit voorbeeld. En jij noemt deze niet dus wilde waarschijnlijk met eerst opvragen en een if-statement gaan testen op id? Denk je echt dat dit beter werkt dan de gegeven code?

Door Anoniem:
public void update(Integer id, Integer leeftijd)
Iemands geboortejaar is beter om te gebruiken. Ga je aan de klant vragen of hij elk jaar zijn leeftijd verhoogd? [sic]

Dat kan je automatisch doen, op nieuwjaarsdag, maar is dus net zo zinloos als alleen het geboortejaar opslaan.

Nee, als ik zou moeten kiezen dan nam ik liever iemand aan die aan zichzelf twijfelt en hier om raad vraagt dan een schoolvoorbeeld van het dunning-krugereffect.
11-05-2020, 10:25 door Anoniem
Door Anoniem:
Ah, dat had ik niet gezien, even niet opgelet. Maar normaliter gebruik je een varchar als id in databases; dit om voorspelling van bestaande id's te voorkomen.
Ik zie nergens staan waar die database voor is en of dat wel een issue is.
Als dit een administratiesysteem is voor binnen een bedrijf dan speelt dat wellicht helemaal niet.
En ik denk ook dat je beveiliging beter op een andere laag kunt regelen dan via de keys van de database.
Maar goed, dan nog voldoet die kritiek niet aan "dat mijn SQL opdrachten onveilig zouden zijn" wat de vraagsteller te horen kreeg, je kunt dan hooguit argumenteren dat het database ontwerp onveilig is.
11-05-2020, 11:10 door Anoniem
Ik had eens meegemaakt dat ze bij een sollicitatie aangaven dat ik onvoldoende kennis had over een niche onderwerp waarvoor ik een 10 had gescoord op de universiteit. Soms verzinnen ze ook gewoon excuusjes om je af te wijzen.
11-05-2020, 14:12 door The FOSS
Door Anoniem:
Door The FOSS: En hoe kan je een ratificatie ter finesse majeure overslaan?
Kennelijk moet het in je gezicht gewreven worden voor je stopt te doen alsof je het niet begrepen hebt. Goed dan:

Read The Fucking Manual. Die staat online.

Maar dat is toch geen Nederlands? Waarom zou iemand dat schrijven op een Nederlandstalig forum? Volgens mij haal je wat dingen door elkaar.
11-05-2020, 14:39 door Anoniem
Lees phrack.org eens

Alle 69 phrack magazines ? Of heb je ook nog een tip omtrent welk phrack magazine, en welk artikel, voor de vraagsteller....
11-05-2020, 15:43 door Erik van Straten
Door The FOSS:
Door Anoniem:
Door The FOSS: En hoe kan je een ratificatie ter finesse majeure overslaan?
Kennelijk moet het in je gezicht gewreven worden voor je stopt te doen alsof je het niet begrepen hebt. Goed dan:

Read The Fucking Manual. Die staat online.

Maar dat is toch geen Nederlands? Waarom zou iemand dat schrijven op een Nederlandstalig forum? Volgens mij haal je wat dingen door elkaar.
Hoe pathetisch kun je zijn als troll.
11-05-2020, 16:03 door The FOSS - Bijgewerkt: 11-05-2020, 16:26
Door Erik van Straten:
Door The FOSS:
Door Anoniem:
Door The FOSS: En hoe kan je een ratificatie ter finesse majeure overslaan?
Kennelijk moet het in je gezicht gewreven worden voor je stopt te doen alsof je het niet begrepen hebt. Goed dan:

Read The Fucking Manual. Die staat online.

Maar dat is toch geen Nederlands? Waarom zou iemand dat schrijven op een Nederlandstalig forum? Volgens mij haal je wat dingen door elkaar.
Hoe pathetisch kun je zijn als troll.

Daar ga jij ook al! In het Nederlands schrijf je troll als trol. En ik ben geen trol. En je dat pathetisch is het verkeerde woord - https://taalhelden.org/bericht/pathetisch-en-pathetic
11-05-2020, 19:36 door Anoniem
Door Anoniem: Ik had eens meegemaakt dat ze bij een sollicitatie aangaven dat ik onvoldoende kennis had over een niche onderwerp waarvoor ik een 10 had gescoord op de universiteit. Soms verzinnen ze ook gewoon excuusjes om je af te wijzen.

Ik denk dat je hier een groot inzicht geeft. Zelf heb ik dit ook meegemaakt.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.