MYSQL Where variabel

[wlang]

Ik ben bezig met een stuk aan het maken in PHP en MYSQL.

Nu wil ik een selectie uit de database halen met het volgende waarbij de
variabelen $Antwoord1 en $Antwoord2 leeg kunnen zijn en in de database
de kolom Antw1 t/m Antw5 ook (Null) kunnen zijn.
Wanneer deze leeg zijn wil ik alle resultaten zien, maar als deze variabelen
een waarde bevatten moeten alleen de regel geselecteerd worden waarbij de
waarde overeenkomt.
Hoe pak ik zoiets aan?
Ik ben al bezig geweest met "IFNUL" en met onderstaande voorbeeld,
maar deze geven niet het juiste resultaat.

PHP: filename

        $query_select = "Select
        a.Antw1, a.Antw2, a.Antw3, a.Antw4, a.Antw5, a.ModuleNr, a.Rev,
        m.ModuleIndex, m.Naam
        FROM module AS m
        INNER JOIN artiekel AS a ON a.Module = m.ModuleIndex
        WHERE m.Naam = '$ZoekModule' AND a.Antw1 = '$Antwoord1' 
        OR (a.Antw2 = '$Antwoord2' OR a.Antw2 is null)
        ";

[wlang]

PHP: filename

        $query_select = "Select
        a.Antw1, a.Antw2, a.Antw3, a.Antw4, a.Antw5, a.ModuleNr, a.Rev,
        m.ModuleIndex, m.Naam
        FROM module AS m
        INNER JOIN artiekel AS a ON a.Module = m.ModuleIndex
        WHERE m.Naam = '$ZoekModule' AND a.Antw1 = '$Antwoord1' 
        OR COALESCE(a.Antw2,'' ) LIKE '$Antwoord2'
        ";

Dacht dat ik hiermee het gevonden had.
Maar dat is dus niet het geval.
Wanneer ik nu Antwoord2 de waarde NULL geef zie ik de toond hij velden niet.

Dus voor de duidelijkheid:
wanneer Antwoord2 geen waarde heeft moet hij alles tonen van Antw2,
als er een waarde in Antwoord2 staat moet alleen die waarde getoond worden.

[ Voor 36% gewijzigd door wlang op 01-09-2017 09:51 . Reden: aanvullen en typo ]

[NMe]

Twee verschillende queries maken en die in PHP omvatten met een if-statement?

Overigens rammelt je datamodel zo te zien een beetje, kolommen met dezelfde naam en een oplopend cijfertje duiden er eigenlijk altijd op dat je een normalisatieslag hebt overgeslagen.

[Harrie_]

Wat @NMe zegt.
Verder kan ik je vraag niet helemaal volgen, kun je even duidelijker uitleggen wat de bedoeling is? Evt. een voorbeeld dataset geven en wat je terugverwacht ?

En probeer ook even je code fatsoenlijk neer te zetten dat is voor iedereen prettiger!

PHP:

$query_select = "
    SELECT
          a.Antw1
        , a.Antw2
        , a.Antw3
        , a.Antw4
        , a.Antw5
        , a.ModuleNr
        , a.Rev
        , m.ModuleIndex
        , m.Naam
    FROM module AS m
    INNER JOIN artiekel AS a ON a.Module = m.ModuleIndex
    WHERE 
        (m.Naam = '" . $ZoekModule . "' AND a.Antw1 = '" . $Antwoord1 . "')
        OR 
        (a.Antw2 = '" . $Antwoord2 . "' OR a.Antw2 IS NULL)
";

[Hydra]

Ik blijf het bizar vinden dat beginners ten eerste altijd uit lijken te komen op SQL injection vulnerable voorbeelden en er daarna ook niet op gewezen worden dat wat ze doen potentieel enorme gevaren heeft.

Dus @TS: http://php.net/manual/en/security.database.sql-injection.php

[Harrie_]

Hydra schreef op vrijdag 1 september 2017 @ 10:14:
Ik blijf het bizar vinden dat beginners ten eerste altijd uit lijken te komen op SQL injection vulnerable voorbeelden en er daarna ook niet op gewezen worden dat wat ze doen potentieel enorme gevaren heeft.

Dus @TS: http://php.net/manual/en/security.database.sql-injection.php

Er staat verder geen context bij, dus ik ga ervanuit dat hij $Antwoord1 vanuit de code hard zet en dat het geen user input is. Verder zien we alleen de query dus misschien heeft hij $Antwoord1 boven die query wel ergens ge-escaped.

[ Voor 9% gewijzigd door Harrie_ op 01-09-2017 10:19 ]

[NMe]

Gezien het gebrek aan normalisatie lijkt het me een veilige aanname van @Hydra en in elk geval een goede opmerking just in case.

[Hydra]

Harrie_ schreef op vrijdag 1 september 2017 @ 10:17:
Er staat verder geen context bij, dus ik ga ervanuit dat hij $antwoord1 vanuit de code hard zet en dat het geen user input is.

Nogal een aanname en is daarnaast geen excuus om geen parametrised queries te maken. Een fout is snel gemaakt. Er is vrijwel nooit enige reden om zelf die strings aan elkaar te plakken. *knip sneer*

[ Voor 5% gewijzigd door NMe op 01-09-2017 10:19 ]

[emnich]

Harrie_ schreef op vrijdag 1 september 2017 @ 10:17:
[...]
Er staat verder geen context bij, dus ik ga ervanuit dat hij $antwoord1 vanuit de code hard zet en dat het geen user input is.

Er kan van alles voor staan maar of dat zo is betwijfel ik toch een beetje. Daarbij is de tijd van handmatig queries aan elkaar plakken toch wel echt voorbij...

[Harrie_]

Bedankt voor het 'compliment' Hydra, ik hoop dat het niet sarcastisch was?

@NMe @Hydra @emnich

Jullie hebben verder allemaal gelijk, maar ik wordt er wel vrij moedeloos van dat dit elke keer weer terugkomt...

[NMe]

Harrie_ schreef op vrijdag 1 september 2017 @ 10:27:
Jullie hebben verder allemaal gelijk, maar ik wordt er wel vrij moedeloos van dat dit elke keer weer terugkomt...

Als niemand er iets van zegt blijft het inderdaad elke keer weer terugkomen.

[CurlyMo]

wlang schreef op vrijdag 1 september 2017 @ 09:34:
Wanneer ik nu Antwoord2 de waarde NULL geef zie ik de toond hij velden niet.

Er zijn twee opties. Eindeloze AND OR waarbij je kijkt of een waarde NULL is of niet en dan vergelijkt of een coalesce aan beide kanten.

SQL:

COALESCE(a.Antw1, '-') = COALESCE('$Antwoord1', '-');

1. Nu slaagt de conditie als beide antwoorden NULL zijn.

SQL:

COALESCE(a.Antw1, '+') = COALESCE('$Antwoord1', '-');

1. Nu faalt de conditie als beide antwoorden NULL zijn.

2. Als een van beide NULL is dan faalt de conditie sowieso.
3. Als beide niet NULL zijn en dezelfde waarde hebben dan slaagt de conditie anders niet.

SQL:

SELECT * FROM artiekel WHERE COALESCE(a.Antw1, '-') = COALESCE('$Antwoord1', '-');

Kijk ook goed naar de spelling van je tabelnamen.
Je PHP skills even daargelaten.

[Verwijderd]

-

[ Voor 100% gewijzigd door Verwijderd op 19-10-2019 14:57 . Reden: Leeg ivm privacy ]

[Verwijderd]

Waarom moeilijk doen in SQL als je toch al PHP voorradig hebt?

PHP:

$where = [ "naam='$zoekmodule'" ];
if ($variabele1) $where[] = "kolom1='$variabele1'";
if ($variabele2) $where[] = "kolom2='$variabele2'";
$query = "SELECT * FROM whatever WHERE ".implode(' AND ', $where);

Aangenomen, net als anderen, dat er geen risico meer is op SQL-injection...

[CurlyMo]

Verwijderd schreef op vrijdag 1 september 2017 @ 10:35:
Waarom moeilijk doen in SQL als je toch al PHP voorradig hebt?

Omdat het ook goed is om te weten hoe je dit in plain SQL zou kunnen oplossen

[wlang]

Bedankt voor de info allen, ik los het deze keer d.m.v. PHP.
Het werkt binnen een klein bedrijfsnetwerk.
De benoemde commentaar over o.a. indeling database neem ik mee voor de volgende keer als ik wat opzet.

[CurlyMo]

wlang schreef op vrijdag 1 september 2017 @ 11:23:
Het werkt binnen een klein bedrijfsnetwerk.
De benoemde commentaar over o.a. indeling database neem ik mee voor de volgende keer als ik wat opzet.

Helemaal als het binnen een bedrijf moet gaan draaien lijkt het me verstandig als je werk aan bepaalde basis zaken voldoet. Een beetje fatsoenlijk database model en wat basis PHP vaardigheden mogen dan best van je verlangt worden. Het bedrijf zal je in de toekomst dankbaar zijn als je werk nu een beetje degelijk is.

[Hydra]

Toch fijn dat er weer een SQL injection sensitive variant als 'beste' antwoord gemarkeerd wordt.

Harrie_ schreef op vrijdag 1 september 2017 @ 10:27:
Jullie hebben verder allemaal gelijk, maar ik wordt er wel vrij moedeloos van dat dit elke keer weer terugkomt...

Een van de grootste issues met PHP is niet zozeer de taal maar de community. Als keer op keer beginners niet heel vroeg bijgebracht wordt dat er bepaalde security eisen zijn die je aan een web applicatie stelt dan blijf je dus hebben dat die beginners gewoon kutsoftware online gaan zetten. Niet alleen voor zichzelf maar ook gewoon bij bedrijven waar ze, maar even een random voorbeeld, leasecontracten beheren.

SQL injection, password hashen met een sterk algo (dus niet MD5 of SHA-1) e.d. zijn gewoon harde eisen die iedere web dev moet stellen in een project. Geen enkele uitzondering. Je bent geen professionele developer als je dit soort dingen niet gewoon standaard al doet. En sorry dat ik dan lomp/allergisch reageer maar zolang je geen onderdeel van de oplossing bent, ben je IMHO een onderdeel van het probleem.

[ Voor 84% gewijzigd door Hydra op 01-09-2017 11:47 ]

[Harrie_]

Hydra schreef op vrijdag 1 september 2017 @ 11:43:
Toch fijn dat er weer een SQL injection sensitive variant als 'beste' antwoord gemarkeerd wordt.


[...]


Een van de grootste issues met PHP is niet zozeer de taal maar de community. Als keer op keer beginners niet heel vroeg bijgebracht wordt dat er bepaalde security eisen zijn die je aan een web applicatie stelt dan blijf je dus hebben dat die beginners gewoon kutsoftware online gaan zetten. Niet alleen voor zichzelf maar ook gewoon bij bedrijven waar ze, maar even een random voorbeeld, leasecontracten beheren.

SQL injection, password hashen met een sterk algo (dus niet MD5 of SHA-1) e.d. zijn gewoon harde eisen die iedere web dev moet stellen in een project. Geen enkele uitzondering. Je bent geen professionele developer als je dit soort dingen niet gewoon standaard al doet. En sorry dat ik dan lomp/allergisch reageer maar zolang je geen onderdeel van de oplossing bent, ben je IMHO een onderdeel van het probleem.

Klopt, maar de vraag is natuurlijk in hoeverre de verantwoordelijkheid hier ligt om daar maar telkens op te blijven wijzen. Ik ga er stiekem vanuit dat dit soort vragen vooral afkomstig zijn van hobbyisten die een website voor de lokale damclub aan het bouwen zijn. Heel hard, maar misschien moeten ze maar eens hun neus stoten dan want volgens mij hebben we het niet over websites/webapplicaties waar allerlei kritieke data achter hangt. Is dat wel het geval dan is het helemaal ridicuul dat iemand met die data bezig is en totaal niet weet wattie doet...

[Hydra]

Harrie_ schreef op vrijdag 1 september 2017 @ 11:54:
Klopt, maar de vraag is natuurlijk in hoeverre de verantwoordelijkheid hier ligt om daar maar telkens op te blijven wijzen.

Die verantwoordelijkheid ligt bij iedere developer. Ik ben redelijk actief op de beginners subs op Reddit en iedere keer als ik iemand zie met een SQL gerelateerde vraag die queries aan elkaar concatenate dan wijs ik ze daar op. Dat is m.i. de verantwoordelijkheid die je aangaat als je mensen gaat helpen; ze in de juiste richting wijzen. Als je die verantwoordelijk niet wil dragen dan moet je m.i. het gewoon helemaal laten.

[Verwijderd]

Hydra schreef op vrijdag 1 september 2017 @ 11:43:
Toch fijn dat er weer een SQL injection sensitive variant als 'beste' antwoord gemarkeerd wordt.

Hey - ik heb er niet voor niks "Aangenomen, net als anderen, dat er geen risico meer is op SQL-injection..." bijgezet.

[NMe]

Harrie_ schreef op vrijdag 1 september 2017 @ 11:54:
[...]


Klopt, maar de vraag is natuurlijk in hoeverre de verantwoordelijkheid hier ligt om daar maar telkens op te blijven wijzen. Ik ga er stiekem vanuit dat dit soort vragen vooral afkomstig zijn van hobbyisten die een website voor de lokale damclub aan het bouwen zijn. Heel hard, maar misschien moeten ze maar eens hun neus stoten dan want volgens mij hebben we het niet over websites/webapplicaties waar allerlei kritieke data achter hangt. Is dat wel het geval dan is het helemaal ridicuul dat iemand met die data bezig is en totaal niet weet wattie doet...

Wij op GoT gaan er redelijk prat op dat we de adviezen geven die iemand nodig heeft, en niet ophouden bij antwoord geven op de acute vraag. Niet alleen vanwege zijdelings opgemerkte fouten zoals tot twee keer toe in dit topic, maar ook om XY-problemen te voorkomen. Dat is onze bijdrage aan het beter maken van onze beroepsgroep. Gewoon lijdzaam toezien hoe iemand zonder het te weten een gat in zijn applicatie slaat ga je hier niet zien, nu niet en in de toekomst niet. Daar maak ik me persoonlijk hard voor.

[Hydra]

Verwijderd schreef op vrijdag 1 september 2017 @ 12:09:
Hey - ik heb er niet voor niks "Aangenomen, net als anderen, dat er geen risico meer is op SQL-injection..." bijgezet.

Ja, ging me erom dat de TS het weinig interesseert kennelijk. Neemt niet weg dat ook jij prima een versie kan geven die gewoon met PDO werkt.

[Verwijderd]

Als TS op de hoogte is (gebracht) van de gevaren van SQL injection, en hij doet er niks mee, dan is dat verder niet mijn probleem...

En zolang de waardes van de variabelen gesanitized zijn is er niks mis met een query samenstellen. Right?

[wlang]

De 'applicatie' wat ik aan het maken ben zal geen grote 'applicatie' worden.
Het is meer een kleine hulp-programma.
Aangezien wij als bedrijf geen IT-bedrijf zijn en ik als medewerker de enige ben welke
iets van programmeren afweet, ben ik dus met mn niet al te vele programmeer kennis begonnen met php.
Alles hoeft niet op hoge kwaliteit gemaakt te worden.
De gevaren van de SQL-injection zie ik wel in.
Bedankt voor de waarschuwingen.

[DutchCommando]

Verwijderd schreef op vrijdag 1 september 2017 @ 14:58:
En zolang de waardes van de variabelen gesanitized zijn is er niks mis met een query samenstellen. Right?

Ik weet niet wat de standaard is binnen de PHP wereld. Maar ik hoop dat dit het niet is... Het lijkt mij dat je altijd SQL parameters als mogelijk gevaarlijk moet behandelen. Je weet binnen je functie namelijk helemaal niet of je invoer variabelen gesanitized zijn; en je kan niet zeker zijn dat het in de toekomst zo zal blijven. Wat kost het om het goed te doen? Vrij weinig neem ik aan?

Ik zie dat je werkt als web developer voor het MKB. Ik vind dat klanten van je mogen verwachten dat je veilige software schrijft. Dat is professionaliteit. Doe je het niet terwijl je weet dat het fout kan gaan, dan ben je gewoon aansprakelijk voor de geleden schade en dat lijkt mij niet meer dan terecht.

[Verwijderd]

DutchCommando schreef op zondag 3 september 2017 @ 00:02:
Maar ik hoop dat dit het niet is... Het lijkt mij dat je altijd SQL parameters als mogelijk gevaarlijk moet behandelen.

Je mist het punt volledig. Dat is precies wat ik ook bedoel, alleen zeg ik dus dat, zeker gesteld hebbend dat dat geregeld is, het in principe geen probleem is om op deze manier een query samen te stellen.

Denk je nou echt dat ik het 14 jaar vol heb gehouden met "WHERE id=".$_GET['id'] - ga iemand anders beledigen...

[DutchCommando]

Verwijderd schreef op zondag 3 september 2017 @ 00:17:
[...]

Je mist het punt volledig. Dat is precies wat ik ook bedoel, alleen zeg ik dus dat, zeker gesteld hebbend dat dat geregeld is, het in principe geen probleem is om op deze manier een query samen te stellen.

Denk je nou echt dat ik het 14 jaar vol heb gehouden met "WHERE id=".$_GET['id'] - ga iemand anders beledigen...

Nee. Ik begrijp wat je schrijft in de post die ik aanhaal en mis je punt dan ook niet, maar ben het niet met je eens. Ik stel dat het altijd een probleem is en dat je nooit de aanname mag doen dat het 'goed geregeld is'.

Ieder voorbeeld dat het op een foute manier doet is er één te veel en dan maakt het niet uit of er een disclaimer onder staat of niet. Daarin ben ik het helemaal met @Hydra eens. Ik vond dit zo belangrijk dat ik na meer dan 3~4 jaar weer een forumpost doe en snap eigenlijk niet dat het een discussiepunt is.

[Verwijderd]

DutchCommando schreef op zondag 3 september 2017 @ 00:27:
Ik stel dat het altijd een probleem is en dat je nooit de aanname mag doen dat het 'goed geregeld is'.

Het is geen aanname - ik regel het zelf. Waar hebben we het over?

edit: ik weet niet - misschien ben ik wel heel erg onduidelijk.

Natuurlijk ben ik het met de hele wereld eens dat je externe data als extreem riskant moet beschouwen. En ik zeg ook dat als je eenmaal met absolute zekerheid voor hebt gezorgd dat $id de integer waarde 123 bevat het geen enkel bezwaar is om een query met "WHERE id=$id" samen te stellen.

Dus: waar heb je nou precies een probleem mee?

[ Voor 41% gewijzigd door Verwijderd op 03-09-2017 01:25 ]

[emnich]

Verwijderd schreef op zondag 3 september 2017 @ 01:14:
[...]

Het is geen aanname - ik regel het zelf. Waar hebben we het over?

edit: ik weet niet - misschien ben ik wel heel erg onduidelijk.

Natuurlijk ben ik het met de hele wereld eens dat je externe data als extreem riskant moet beschouwen. En ik zeg ook dat als je eenmaal met absolute zekerheid voor hebt gezorgd dat $id de integer waarde 123 bevat het geen enkel bezwaar is om een query met "WHERE id=$id" samen te stellen.

Dus: waar heb je nou precies een probleem mee?

Ik denk dat je nog steeds het punt mist.

Als je 100% zeker weet dat jij en alleen jij aan deze code werkt en nooit iemand anders én als jij die code goed kent, ook een jaar later én als je 100% zeker weet dat die waarde nooit een string zal/kan worden én als je 100% zeker weet dat die query nooit gebruikt zal worden voor andere doeleinden dan heb je gelijk en is er geen probleem.

Als je dat niet allemaal zeker weet dan is het wel een probleem omdat het onveiligheid in de hand werkt. Zo komen de veiligheidsissues er namelijk in.

Volgende keer gaat een stagiair werken met die code en er moet een extra parameter bij dus veranderd hij de code (en zal het niet helemaal opnieuw maken), gevolg:

code:

WHERE id=$id AND name='$name'

En echt, zo ontstaan heel veel issues. Niet omdat het in eerste instantie al fout gebouwd wordt maar omdat er later een aanpassing gedaan wordt waarbij niet is voorzien dat dit een mogelijk gevolg heeft.

[Verwijderd]

emnich schreef op zondag 3 september 2017 @ 08:11:
Volgende keer gaat een stagiair werken met die code en er moet een extra parameter bij dus veranderd hij de code...

Dus ik moet mijn dagelijkse manier van werken, die ik na alles uitgeprobeerd te hebben persoonlijk het prettigst vind, aanpassen omdat er heel misschien ooit een of andere knurft (die sowieso nog niet met zijn vingers aan PHP zou moeten komen) dingen aan kan gaan verprutsen?

Nee, sorry.

[Harrie_]

Het is niet normaal hoe die topics hier af en toe helemaal derailen. Hydra en NMe hierboven hadden terecht een punt n.a.v. mijn reactie en ik kan me wel vinden in het feit dat dat we bij dit soort code op z'n minst even SQL injectie en evt. andere veiligheidsrisico's aan kunnen halen.

Wat @Zaph verder voor zijn werk doet, en hoe hij dat doet, doet hier dus verder eigenlijk helemaal niet ter zake. Om dan zijn in zijn profiel te gaan lopen loeren om vervolgens zijn werk erbij te halen is heel erg triest @DutchCommando en heeft met deze discussie helemaal niets maar dan ook niets te maken...

[DutchCommando]

Harrie_ schreef op zondag 3 september 2017 @ 10:58:
Wat @Zaph verder voor zijn werk doet, en hoe hij dat doet, doet hier dus verder eigenlijk helemaal niet ter zake. Om dan zijn in zijn profiel te gaan lopen loeren om vervolgens zijn werk erbij te halen is heel erg triest @DutchCommando en heeft met deze discussie helemaal niets maar dan ook niets te maken...

Het doet terzake, omdat ik van een professional verwacht dat het goed zit. Bovendien is het onderdeel van het profiel dus geen geheim, want waarom staat het er anders?

@Verwijderd Is er in PHP geen eenduidige eenvoudige manier om parameterized queries uit te voeren? Het klinkt alsof dit veel extra werk is. Is het niet zo eenvoudig als onderstaande in C# .NET?

C#:

public decimal GetEmployeeSalary(string employeeName)
{
  string query = "SELECT salary FROM employee WHERE name = @name";

  using (var connection = new SqlConnection("..."))
  using (var command = new SqlCommand(query, connection))
  {
     command.Parameters.AddWithValue("@name", employeeName)
     command.ExecuteReader();
     // ...
  }
}

[Verwijderd]

DutchCommando schreef op zondag 3 september 2017 @ 11:28:
Het doet terzake, omdat ik van een professional verwacht dat het goed zit.

Wacht even - ik heb altijd gezegd dat je met user-input heel voorzichtig moet zijn, inclusief in dit draadje, en toch meen jij, omdat je daar overheen hebt gelezen, te moeten concluderen dat ik een soort amateur ben die zijn klanten in gevaar brengt.

[DutchCommando]

Verwijderd schreef op zondag 3 september 2017 @ 11:35:
[...]

Wacht even - ik heb altijd gezegd dat je met user-input heel voorzichtig moet zijn, inclusief in dit draadje, en toch meen jij, omdat je daar overheen hebt gelezen, te moeten concluderen dat ik een soort amateur ben die zijn klanten in gevaar brengt.

Je maakt het zelf zwaarder dan het is. Maar ik kan niet begrijpen dat parameterized queries niet de standaard is. Door parameterized queries te gebruiken hoef je vanuit het database security perspectief niet voorzichtig te zijn met user input. Dan zijn er uiteraard nog legio validaties die je moet uitvoeren. Maar het is toch prettig om met zekerheid te kunnen stellen dat er nooit en te nimmer SQL injection kan plaatsvinden? Wie wil dat nou niet?

[Verwijderd]

DutchCommando schreef op zondag 3 september 2017 @ 11:41:
Je maakt het zelf zwaarder dan het is.

Nee, dat doe ik niet. Jij suggereert op een openbaar forum dat ik niet professioneel ben.

Maar het is toch prettig om met zekerheid te kunnen stellen dat er nooit en te nimmer SQL injection kan plaatsvinden? Wie wil dat nou niet?

En als die stagiair van jou nou denkt "Jee, wat een gedoe, ik doe wel even snel mysql_query('UPDATE users SET blablabla WHERE id='.$_GET['id'])"? Dan zit jij daar met je nooit en te nimmer garantie.

Veiligheid is iets waar je altijd mee bezig moet zijn, en zolang je dat bewerkstelligt is de manier waarop je dat doet niet relevant. Als er namelijk wel wat tussendoor zou slippen betekent dat dat je niet alert genoeg bent, en dat is in dat geval het eigenlijke probleem.

[RagingPenguin]

DutchCommando schreef op zondag 3 september 2017 @ 11:28:
@Verwijderd Is er in PHP geen eenduidige eenvoudige manier om parameterized queries uit te voeren? Het klinkt alsof dit veel extra werk is. Is het niet zo eenvoudig als onderstaande in C# .NET?

C#:

public decimal GetEmployeeSalary(string employeeName)
{
  string query = "SELECT salary FROM employee WHERE name = @name";

  using (var connection = new SqlConnection("..."))
  using (var command = new SqlCommand(query, connection))
  {
     command.Parameters.AddWithValue("@name", employeeName)
     command.ExecuteReader();
     // ...
  }
}

Het is in PHP niet zo gek anders

Mysqli:

PHP:

$conn = new mysqli( ... );

$statement = $conn->prepare("SELECT salary FROM employee WHERE name = ?");
$statement ->bind_param("s", $name);
$statement->execute();

PDO:

PHP:

$conn = new PDO( ... );
$statement = $conn->prepare("SELECT salary FROM employee WHERE name = :name");
$statement->bindParam(":name", $name);
$statement->execute();

Maar op de een of andere manier staan prepared queries nog steeds bekend als rocket-science in het PHP wereldje....

[DutchCommando]

Verwijderd schreef op zondag 3 september 2017 @ 11:52:
[...]

Nee, dat doe ik niet. Jij suggereert op een openbaar forum dat ik niet professioneel ben.


[...]

En als die stagiair van jou nou denkt "Jee, wat een gedoe, ik doe wel even snel mysql_query('UPDATE users SET blablabla WHERE id='.$_GET['id'])"? Dan zit jij daar met je nooit en te nimmer garantie.

Veiligheid is iets waar je altijd mee bezig moet zijn, en zolang je dat bewerkstelligt is de manier waarop je dat doet niet relevant. Als er namelijk wel wat tussendoor zou slippen betekent dat dat je niet alert genoeg bent, en dat is in dat geval het eigenlijke probleem.

De manier is relevant. Parameterized queries is de beste manier. En ja, als jij dat anders ziet dan durf ik zeer zeker te stellen dat het niet te kennen geeft van professionaliteit. Pak de OWASP top 10 er maar bij.

De stagiair was overigens niet van mij. Maar ik onderken inderdaad het door jou genoemde risico. Daarom worden alle merges naar de master branch altijd voorafgegaan aan een verplichte code review. En alle medewerkers kennen de OWASP top 10 en de juiste wijze om deze problemen te vermijden.

Ik haal mijzelf even uit de anonimiteit. Wel zo eerlijk .

RagingPenguin schreef op zondag 3 september 2017 @ 12:01:
[...]


Het is in PHP niet zo gek anders

Mysqli:

PHP:

$conn = new mysqli( ... );

$statement = $conn->prepare("SELECT salary FROM employee WHERE name = ?");
$statement ->bind_param("s", $name);
$statement->execute();

PDO:

PHP:

$conn = new PDO( ... );
$statement = $conn->prepare("SELECT salary FROM employee WHERE name = :name");
$statement->bindParam(":name", $name);
$statement->execute();

Maar op de een of andere manier staan prepared queries nog steeds bekend als rocket-science in het PHP wereldje....

Goed om te zien dat het wel kan en ook helemaal niet moeilijk is!

[ Voor 20% gewijzigd door DutchCommando op 03-09-2017 12:06 ]

[emnich]

Verwijderd schreef op zondag 3 september 2017 @ 10:38:
[...]

Dus ik moet mijn dagelijkse manier van werken, die ik na alles uitgeprobeerd te hebben persoonlijk het prettigst vind, aanpassen omdat er heel misschien ooit een of andere knurft (die sowieso nog niet met zijn vingers aan PHP zou moeten komen) dingen aan kan gaan verprutsen?

Nee, sorry.

Nee, je hoeft helemaal niets aan te passen, blijf lekker zo werken als je zelf wilt. Als je voorzichtig bent en goed oplet kan je het inderdaad veilig doen.

Ik ben het er alleen pertinent mee oneens om te zeggen dat er helemaal niets mis mee is. Dat is er namelijk wel omdat code veranderd en dan beginnen de problemen.

[Verwijderd]

DutchCommando schreef op zondag 3 september 2017 @ 12:03:
De manier is relevant.

De OWASP top 10 zegt niks over de manier, alleen over het probleem. En daar zijn we het over eens.

En alle medewerkers kennen de OWASP top 10 en de juiste wijze om deze problemen te vermijden.

Misschien ligt ons wederzijds onbegrip daar wel in - met meerdere mensen van alles in dezelfde code doen versus in je eentje volledige controle en overzicht hebben.

[DutchCommando]

Maar ook in projecten die je in je eentje doet zijn parameterized queries de veiligste manier om te werken. Het punt met security is vaak dat het fout gaat als je niet de standaarden volgt of zelf een 'andere' manier van werken hebt. Dan kan je nog zo goed zijn in je vak... Vroeg of laat gaat het echt fout.

OWASP zegt wel iets over de manier:

How Do I Prevent Injection?
Preventing injection requires keeping untrusted data separate from commands and queries.
1. The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface.

[Verwijderd]

Precies: 'preferred'. Niet 'the only acceptable option anyone even remotely professional should use'.

Dat is mijn bezwaar tegen dit soort topics - het is altijd zo zwart/wit. Als je het niet braaf doet zoals iedereen het doet ben je automatisch een soort schuimbekkende idioot of zo.

[emnich]

Verwijderd schreef op zondag 3 september 2017 @ 12:40:
Precies: 'preferred'. Niet 'the only acceptable option anyone even remotely professional should use'.

Dat is mijn bezwaar tegen dit soort topics - het is altijd zo zwart/wit. Als je het niet braaf doet zoals iedereen het doet ben je automatisch een soort schuimbekkende idioot of zo.

Jij weet wellicht wat je aan het doen bent maar de mensen die dit soort topics openen (met respect voor TS) duidelijk niet. Daarom wordt er op zo'n manier op gereageerd.

[DutchCommando]

Verwijderd schreef op zondag 3 september 2017 @ 12:40:
Precies: 'preferred'. Niet 'the only acceptable option anyone even remotely professional should use'.

Dat is mijn bezwaar tegen dit soort topics - het is altijd zo zwart/wit. Als je het niet braaf doet zoals iedereen het doet ben je automatisch een soort schuimbekkende idioot of zo.

Ik moest lachen.

Het tweede punt is:

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter

En aangezien een parameterized API beschikbaar is in PHP... Waarom niet? Ik ben wel heel nieuwsgierig welke dingen je allemaal doet om het veilig te maken?

[Verwijderd]

emnich schreef op zondag 3 september 2017 @ 12:42:
Jij weet wellicht wat je aan het doen bent maar de mensen die dit soort topics openen (met respect voor TS) duidelijk niet. Daarom wordt er op zo'n manier op gereageerd.

Nee, er wordt puur op de persoon gespeeld op het moment.

DutchCommando schreef op zondag 3 september 2017 @ 12:50:
En aangezien een parameterized API beschikbaar is in PHP... Waarom niet?

Waarom wel? Het gaat om 2 criteria: de eerste is veiligheid (praktisch, dus niet theoretisch), en daarbinnen om het grootste gebruiksgemak voor mij als ontwikkelaar. Ik heb alle mogelijke methodes om databases te benaderen in de afgelopen dik 30 jaar wel gezien en gebruikt, en ik gebruik deze nu omdat ik dat het prettigst vind werken.

[Hydra]

Gewoon altijd parametrised queries gebruiken tenzij je voor specifieke queries hele goede redenen hebt het niet te doen. Er van uitgaan dat jij of de persoon na je geen fouten maakt is gewoon kortzichtig m.i.

Verwijderd schreef op zondag 3 september 2017 @ 13:07:
Nee, er wordt puur op de persoon gespeeld op het moment.

Als je evidente beginner gewoon een injection-safe voorstel had gedaan had je dit uberhaupt niet over je heen gehad. Je hebt het wel een beetje aan jezelf te danken door hoe je reageert. Je graaft je steeds dieper in in plaats van gewoon toe te geven dat je een beginner in principe altijd het goeie pad op moet duwen.

Je laatste opmerking over "gebruiksgemak" is precies waarom mensen over je reacties vallen: gebruiksgemak doet er niet toe. Als veilig werken tien keer zoveel moeite kost als niet veilig werken doe je alsnog dat eerste.

Dus tja; als je het er nog steeds niet mee eens bent zou ik dit topic verder lekker links laten liggen.

[CurlyMo]

Ben ik blij dat ik een SQL-only oplossing heb aangedragen

[Verwijderd]

Hydra schreef op zondag 3 september 2017 @ 14:04:
Je laatste opmerking over "gebruiksgemak" is precies waarom mensen over je reacties vallen: gebruiksgemak doet er niet toe.

Nee, da's een mooi voorbeeld van dat selectief lezen waar ik zo onderhand echt zat van ben - ik geef duidelijk aan dat veiligheid prio 1 is, en daarbinnen gebruiksgemak de 2e.

Maar je hebt gelijk: dit is verder zinloos, want ik doe het anders dan jullie en dus verkeerd. Mensen en hun meningen...