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?
function make_safe($var) {
global $con;
$var = htmlspecialchars(strip_tags(trim($var)));
$var = mysqli_real_escape_string($con, $var);
$var = addcslashes($var, '%_');
return $var;}
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.
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.
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.
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.
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.
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?
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.
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?
