SQL Injection voorkomen

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Oracle ontwikkelaar met PL/SQL en APEX in de regio

Bedrijfsomschrijving Het havengebied rondom Rotterdam biedt veel uitdagende projecten binnen o.a. container mangement, douane en warehousing. Deze organisatie biedt juist op dergelijke segmenten ICT-oplossingen van grote kwaliteit. Deze organisatie kenmerkt zich als een fullservice softwarehuis dat verantwoordelijk is voor zowel het bepalen van de informatie behoeftes bij klanten, inhouse software ontwikkeling en de implementatie van deze software. Dit doen ze inmiddels al een zeer geruime tijd voor voornamelijk klanten binnen de logistieke sector. Binnen de logistieke sector hebben ze inmiddels een imposant klantenbestand opgebouwd wat optimaal bediend wordt. Denk hierbij aan bijvoorbeeld grote vervoers/transportmaatschappijen. De organisatie is zeer goed bereikbaar

Bekijk vacature »

G Jansma

G Jansma

16/09/2016 16:45:08
Quote Anchor link
Hallo,

Ik had een vraag over het voorkomen van SQL injection. Ik had een functie gemaakt van wat ik er zoal over heb gevonden, maar ik vroeg me af of onderstaande code volstaat? Of zijn er nog dingen die ik zou moeten toevoegen? Hoe hebben jullie je hier tegen beveiligd? En überhaupt wel eens gehoord, of gehad, dat er op deze manier werd ingebroken?

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
function make_safe($var) {
global $con;
$var = htmlspecialchars(strip_tags(trim($var)));
$var = mysqli_real_escape_string($con, $var);
$var = addcslashes($var, '%_');
return $var;}


Groet
 
PHP hulp

PHP hulp

17/01/2022 17:42:17
 
- Ariën -
Beheerder

- Ariën -

16/09/2016 17:29:26
Quote Anchor link
Het gebruik van mysqli_real_escape_string() op de $_POST, $_GET, $_COOKIE, $_SESSION en $_ENV variabelen is al voldoende. Het gebruik van htmlspecialchars() is alleen praktisch bij het uitlezen van de data. Je wilt deze in bijna geen enkel geval gebruiken bij het INSERT'en of UPDATE van data in een query.
 
Michael -

Michael -

16/09/2016 18:33:34
Quote Anchor link
Het lijkt me onnodig hier een functie voor te maken.
Op alle gebruikers input wat je in je database INSERT of UPDATE kun je *real_escape_string gebruiken. Dit is voldoende, maar om te voorkomen dat bijv. code wordt uitgevoerd die je ophaalt met SELECT kun je htmlspecialchars gebruiken.
Je kunt i.p.v. MySQLi ook PDO gebruiken en met bindings werken. Zie voorbeelden hier
Prepared statements in PDO zorgen dan dat je data op een veilige manier worden geüpdatet of toegevoegd.
 
Ben van Velzen

Ben van Velzen

16/09/2016 21:09:42
Quote Anchor link
Zoals aangegeven is escaping zelf al voldoende. Je moet je data veilig maken, niet verminken. htmlspecialchars, trim en strip_tags vernielen je data op een manier die je later onmogelijk kunt herstellen, dus gebruik je ze bij weergave wanneer nodig.
 
G Jansma

G Jansma

16/09/2016 21:53:16
Quote Anchor link
Misschien had ik dat er bij moeten vermelden, maar de website waar ik aan werk is een databasewebsite waarbij eigenlijk alleen SELECT wordt gebruikt. Er gaat (voorlopig) geen input van gebruikers de database in door middel van INSERT of UPDATE. Maar met behulp van GET worden dus wel veel verzoeken gedaan. Die verwerk ik dan weer in een SQL-query of in zoekvelden. Ik dacht dat htmlspecialchars en strip_tags dan ook wel handig was, ook met XSS? Het is dus niet zo dat ik data vermink of wijzig dat bewaard moet worden, alleen probeer te beschermen tegen invoer in de GET.

Omdat ik per pagina vaak meerdere GET ophaal leek het me praktischer om ze in een functie te stoppen, dan om elke keer de hele riedel te herhalen.
Gewijzigd op 16/09/2016 21:54:20 door G Jansma
 
Ben van Velzen

Ben van Velzen

16/09/2016 22:35:43
Quote Anchor link
Nee, dat is ook daar niet handig, want je gebruikt htmlspecialchars e.d om de data UIT je database weer te geven, niet tijdens het selecteren, inserten of updaten.
 
G Jansma

G Jansma

16/09/2016 22:51:26
Quote Anchor link
Ik kan niet helemaal volgen wat je bedoelt. Als een gebruiker in een zoekveld iets intypt en verstuurt, dan haalt hij die vervolgens op uit de GET. Die variabel wordt dan vervolgens door de functie gehaald. Die wordt daarna dus in de query gezet, of in het zoekveld waar het is ingetypt. Om XSS-injection tegen te gaan wordt htmlspecialchars genoemd in onderstaande tutorial, dat is dan toch niet helemaal zinloos?

https://www.phphulp.nl/php/tutorial/overig/beginnersfouten-tegengaan/763/xssinjection/2042/
 
- Ariën -
Beheerder

- Ariën -

16/09/2016 22:58:58
Quote Anchor link
Bij de uitvoer van de data heeft htmlspecialchars() pas zin tegen XSS-protectie. En dat gebeurt ook in de tutorial.
 
Ben van Velzen

Ben van Velzen

16/09/2016 23:02:36
Quote Anchor link
Precies. Dat gebeurt bij de weergave van de data, niet in de query zelf. Daar is het zinloos, en kan tot foutieve resultaten leiden.
 
Ivo P

Ivo P

16/09/2016 23:10:03
Quote Anchor link
htmlspecialchars verandert bijvoorbeeld een & in je tekst in &

Stel je zoekt naar C&A

Dan plaats jij dus in de query:


SELECT * FROM tabel WHERE naam = 'C&A'

in je database staat echter C&A
dus jij vindt niets.


htmlspecialchars() is een functie die je eigenlijk alleen bij echo gebruikt.

---
en om de slimmerik voor te zijn die dan in de database C&A wil opslaan: wat nu als je die naam niet op een webpagina wil weergeven, maar wilt gebruiken om een excelsheet te vullen? dan heb je alleen maar last van die escapete data.
 
G Jansma

G Jansma

16/09/2016 23:24:36
Quote Anchor link
Oké, dat is verhelderend. Maar het enige waar je op mijn site kan op zoeken is op personen, dus daarin is het niet nodig om vreemde tekens of html ofzo te gebruiken. Het enige dat daarin eens voorkomt is een - of een O'Connor ofzo. Op zich is het dus niet zozeer schadelijk, maar ik begrijp dat het niet nodig is. De mysqli_real_escape_string volstaat dus in deze?

Maar als iemand zoals in de tutorial zoekt op 'Kees"/>', en ik wil dat vervolgens echoën in het zoekvak, dan is het wel aan te raden om de htmlspecialchars te gebruiken toch?
 
Ben van Velzen

Ben van Velzen

16/09/2016 23:33:32
Quote Anchor link
Sowieso, maar daar is het ook voor bedoeld: bij weergave.
>> Op zich is het dus niet zozeer schadelijk, maar ik begrijp dat het niet nodig is. De mysqli_real_escape_string volstaat dus in deze?

In dit specifieke geval is het niet zozeer schadelijk, maar er komt een moment/een project waar je zinloze "truc" wel tot problemen leidt, en dan heb je in het ergste geval reparaties uit te voeren aan je data. Baat het niet dan schaadt het niet gaat hier niet echt op, belangrijker is consistentie.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.