Paswoord en Gebruikersgegevens in Php
Brengt dit veiligheidsrisico's mee ?
Gewijzigd op 02/03/2017 19:41:35 door Luc V
Je kan beter een API maken waarmee je via het aanroepen van de URL diverse acties kan uitvoeren, en data kan sanitizen en valideren.
www.site.nl/api.php?action=profile&id=1 om bijv. het profiel van gebruikers-ID 1 op te halen.
www.site.nl/api.php?action=login om bijv. een POST-request te doen, als iemand van uit de app op zijn profiel wilt inloggen.
Ja, en een goede tip: Gebruik POST voor inloggen en gebruik een SSL-certificaat. Dat laatste is zo duur niet meer, het kan zelfs gratis met Let's Encrypt.
Gewijzigd op 02/03/2017 19:53:44 door - Ariën -
Voor de toepassing zoals ik deze nu gemaakt heb heb ik mij gebaseerd op http://easyway2in.blogspot.be/2015/07/android-mysql-database-connect.html
Hier worden de inloggegevens dus wel in een php bestand geplaatst.
Verder kan het uiteraard geen kwaad als je de inlog-gegevens voor je database in je PHP-script opslaat, want anderen kunnen daar toch niet zomaar bij. Als je voor maximale veiligheid wilt gaan, dan zou ik het buiten je webroot plaatsen. Mocht je ooit door een configuratie-fout alle PHP-bestanden als plain-text doorsturen, dan zal niemand ooit bij deze inloggegevens kunnen.
Een andere goede tip is om SSL te gebruiken, en dus alle requests via een https URL te laten verlopen. Een certificaat kost tegenwoordig niks meer met het makkelijke gebruik van Let's Encrypt.
Gewijzigd op 08/03/2017 13:57:07 door - Ariën -
- Ariën - op 08/03/2017 13:51:39:
Het escapen in SQL draait voornamelijk om de ' en niet om de backslash. Deze backslash heeft ook geen relevantie in queries.
Maar als je deze ongestraft kunt combineren (een backslash gecombineerd met een single quote) dan is dit een potentieel gevaar omdat je hiermee "uit de quotes kunt breken". Ik zou zelfs zeggen: een backslash kan zeer gevaarlijk zijn want hiermee kun je de speciale betekenis van bepaalde (syntactisch belangrijke) karakters wegnemen. Een goed gebruik hiervan is handig natuurlijk, maar een verkeerd gebruik is funest.
Ik denk dat je niet zozeer in termen van specifieke karakters moet denken maar meer aan escaping in het algemeen. Daarbij is het ook handig als je
Abstract gezien bestaat elke query uit SQL-code en mogelijk extra invulvakjes: DATA die uit een externe bron wordt aangeleverd. Het is enerzijds zaak dat deze DATA gefilterd wordt: indien de DATA niet van het goede formaat is kun je niet verwachten dat de query (zinnige) resultaten oplevert. Anderzijds is het zaak dat deze DATA niet als SQL geïnterpreteerd kan worden omdat je daarmee de werking van de query kunt manipuleren. Dit is in feite wat SQL-injectie is: DATA die als SQL-code geïnterpreteerd wordt waarmee de werking van de query wordt gemanipuleerd.
ALLE DATA-delen dienen daartoe ge-escaped te worden met de de daarvoor bestemde escaping-functies. Voor MySQLi is dit bijvoorbeeld de escape_string() methode. Gebruik voor de MySQL-context dus géén functies als addslashes() (als je hier aan zat te denken) of wat dan ook, of, omdat je het beter denkt te weten, zelf gerolde functies, addslashes() is simpelweg niet bedoeld voor het escapen van DATA in SQL-code.
Daarnaast is het zaak dat je escape_string() gebruikt in combinatie met (enkele) quotes. Het een is namelijk niet veilig zonder het ander. Beschouw het volgende stukje code, dat in een DATA-deel gezet zou kunnen worden:
Code (php)
1
OR 1=1
Als je hier escape_string() overheen haalt escaped deze NIETS, omdat er in dit stukje code niets te escapen valt. escape_string() is geen wondermiddel.
En als je meer een voorstander bent van prepared statements: gebruik PDO.
Welke techniek je ook gebruikt voor het beveiligen van queries: een verkeerd gebruik kan nog steeds fatale gevolgen hebben dus zorg dat je weet van de hoed en de rand.