Website in opbouw

Status
Niet open voor verdere reacties.
pieter53 zei:
Ondertussen langzaam aan maar begonnen met de opbouw, maar veel kennis blijkt ver weggezakt te zijn,
dus het gaat maar langzaam. Narigheid via SQL injecties tracht ik te voorkomen met
Code: 
  $invoer = trim($invoer);
  $invoer = stripslashes($invoer);
  $invoer = htmlspecialchars($invoer);
hopelijk is dat afdoende.
Klik om te vergroten...

Nee, dat is juist niet de bedoeling.
Daarvoor heb je de geweldige mysqli_real_escape_string() functie die al enkele decennia erin zit.
En voor de rest moet je htmlspecialchars nooit in een query gebruiken: Je wilt immers je data niet om zeep helpen. Je kan prima achteraf je data filteren en trimmen.

Ik neem aan dat je wel MySQLi of PDO gebruikt? (Met nadruk op de i bij MySQLi)
 
Laatst bewerkt:
Aan mysqli_real_escape_string() ben ik nog niet toe.
Ik ben nog niet verder dan het invulformulier lezen en het opzetten van de DB.
 
pieter53 zei:
Aan mysqli_real_escape_string() ben ik nog niet toe.
Ik ben nog niet verder dan het invulformulier lezen en het opzetten van de DB.
Klik om te vergroten...

Ik denk dat je er wel snel aan toe bent. Zodra je door de gebruiker gespecificeerde waardes in je query wilt verweken, zoals uit $_POST, $_GET, $_COOKIE, $_SESSION (twijfelgavel, maar better safe than sorry) en $_ENV, dan moet je deze waardes op de juiste manier 'escapen' met de genoemde functie. Het ligt er ook aan op welke manier je MySQLi gebruikt: Is dat met functies (open- en sluithaakjes. zoals dit mysqli_query(....) ) of met objecten (pijlen, zoals dit $mysql->query(...) )?

Als je geen escaping toepast, of enkel de single-quotes ( ' ) bij WHERE voorwaardes vergeet, is het eenvoudig mogelijk door jan en alleman om je query aan te passen, met schadelijke gevolgen van dien.
 
Bedankt voor de informatie:
maar wat doet mysqli_real_escape_string precies?
Worden er tekens weggelaten of gecodeerd of wordt er controleerd op verdachte combinaties van tekens?
 
pieter53 zei:
Bedankt voor de informatie:
maar wat doet mysqli_real_escape_string precies?
Worden er tekens weggelaten of gecodeerd of wordt er controleerd op verdachte combinaties van tekens?
Klik om te vergroten...

Dit:
Escapes special characters in a string for use in an SQL statement, taking into account the current charset of the connection
Klik om te vergroten...
Er wordt ge'escaped zodat ze schadelijke tekens niet schadelijk zijn. Een soort addslashes(), die je vroeger (jaren 2000) gebruikte, maar dan slimmer.
Lees maar hier: https://stackoverflow.com/questions...tween-mysql-real-escape-string-and-addslashes (oud artikel, maar tegenwoordig gaat het om de mysqli-variant)
Test maar eens uit.
 
Laatst bewerkt:
Mocht je wat code geschreven hebben, en deze wil laten reviewen:
Prima :)
 
htmlspecialchars werkt op slechts 5 html karakters, niet op alle html entities.
Het zijn de 5 karakters waarmee geïnjecteerd kan worden, namelijk & ' " < >
Het is iets om in te duiken omdat een query als php string naar MySql gaat.

Aanvulling. je hebt meerdere filters nodig tegen injection.
Het onderstaande voorbeeld kan je via google makkelijk terugvinden.

Stel, dit is je query
Code: 
SELECT * from user WHERE (name='$login' OR email='$login') AND password='$password'

dit wordt ingevuld

login   :   ) OR 1=1 /*\
password:   */--

Het resultaat van de query
Code: 
SELECT * from user WHERE (name=') OR 1=1 /*\' OR email=') OR 1=1 /*\') AND password='*/--'

dit is hetzelfde als

SELECT * from user WHERE (name=') OR 1=1 /*\' OR email=') OR 1=1

Dus AND password='$password' is veranderd in OR 1=1 (password doet er niet meer toe)

Eén van mijn beveiligingen hiertegen (en ook tegen spam) is dat in geen enkel veld een linkje mag worden gezet, er wordt dus gecontroleerd op de \ en de / in de validatie.
 
Laatst bewerkt:
@Bron

Jij hebt het over meerdere filters tegen SQL-injection. Welke gebruik jij dan?
mysqli_real_escape_string in combinatie met jet juist gebruik van single-quotes om de WHERE-clausule lijkt mij toch afdoende?

htmlspecialchars() hoort sowieso al niet in een query, is mij aangeleerd.
 
Code: 
RewriteCond %{QUERY_STRING} http\: [OR]
RewriteCond %{QUERY_STRING} https\: [OR]
RewriteCond %{QUERY_STRING} \[ [OR]
RewriteCond %{QUERY_STRING} \] [OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} UNION [OR]
RewriteCond %{QUERY_STRING} // [OR]
RewriteCond %{QUERY_STRING} proc\/self\/environ [OR]
RewriteCond %{QUERY_STRING} \*
RewriteRule ^.*$ - [F,L]

Dit scheelt al een hoop ellende aan de voorkant voordat je gaat remappen met index.php?page=$1 ofzo.

Aanvulling na een google
mysqli_real_escape_string is veilig tegen SQL injection.
htmlspecialchars is meer veilig tegen cross-site scripting (XSS).
 
Laatst bewerkt:
Dat is niet zozeer (enkel) tegen SQL-injection, maar ik heb het idee dat je hiermee mod_security dunnetjes nadoet. :) (irritante extentie overigens)
Als je gaat remappen dan moet je inderdaad goed filteren. Als je dit gebruikt met een include naar een hardcoded .php-bestand, dan zou het geen kwaad kunnen.

Ik geloof dat CloudFlare dit standaard ook al doet.
 
Leerzame discussie.

In mijn geval(len) kan men, voor zover ik kan overzien, weinig kwaad als men in de database binnendringt.
Ik geloof niet dat er gevoelige informatie in opgeslagen is en als men de database vernietigt, is er nog geen ramp geschied.
Maar ik zal toch voor enige veiligheid zorgen.
 
Uiteraard, een voordeur heeft immers ook een slot ;-)
 
Als je gaat remappen dan moet je inderdaad goed filteren. Als je dit gebruikt met een include naar een hardcoded .php-bestand, dan zou het geen kwaad kunnen.
Klik om te vergroten...
Ik gebruik geen hard-coded php bestanden :) Alle config & data met mysqli en frontend/backend met php classes. Wel een cache directory waarin statische delen als bestanden klaar staan voor betere laadtijden.

Het stukje code wat ik gaf is slechts een deel van mijn .htaccess. Een .htaccess is inderdaad geen 123'tje maar er is veel over te lezen. Ook bij Wordpress is extra beveiliging nodig omdat WP in de htaccess eindigt met RewriteRule . /index.php [L] en in WP de $_SERVER['REQUEST_URI'] wordt uitgelezen. Dan is het handig dat ellende in htaccess al wordt afgevangen.
 
Ik bedoel de .php extentie hardcoded in je include/require, zodat je het inladen van andere bestanden kan voorkomen, zoals /proc enzo.
 
Alle templates, data en configs staan in de database (geen includes/require voor nodig).
Extensie van statische cache bestanden is .cms :)

Maar we dwalen af van de vraag van TS
 
Laatst bewerkt:
Maar even weer terug naar mijn ontwerp.
Ik geloof dat mijn database er ongeveer zo uit moet gaan zien.

schema vraagbaak.jpg

Op basis van 3 keuzes (filters) en een trefwoord wordt er Tekstbestand geselecteerd.
Via de tabel koppel-tb-naam worden auteurs met de bijbehorende tekstbestanden gekoppeld.

anaamc is een voor het alphabetiseren afgeleide van anaam wat natuurlijk voor achternaam staat
 
Laatst bewerkt:
Ik zie genummerde velden. Hier moet je nooit aan beginnen. Als je die uitbreidt, dan moet je dus in de lengte gaan werken, en dat betekent dat je jouw applicatie moet aanpassen. Alles wat genummerd is, is een eigen entiteit die op zichzelf staat: product, lid, evenement etc, en die verdienen een eigen tabel.
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan