veiligheid
(graag in nl, engels kan ook)
Als jullie site een aanval word gedaan,
wat doet/probeert die negative hacker dan?
En hoe kan hij dat vooral doen?
- SQL injection
- Cross-site request forgery (CSRF)
- Cross-site scripting (XSS)
- en natuurlijk eigen PHP code uploaden via upload-formuliertjes. Dat formuliertje hoeft niet eens op je eigen site te staan, het kan ook zijn dat een andere site die op dezelfde server gehost wordt een lek heeft. Wanneer jouw site dan ergens een "lek" include statement heeft, een include statement waarin een variabele van buitenaf wordt gebruikt in het pad naar het PHP bestand, ben je ook niet veilig.
Volgens mij staan over al deze bekendere technieken wel tutorials op deze site.
Ik zal eens kijken.
Kan iemand me uitleggen hoe je gebruik maak van https://.
En hoe je het maakt?
Ik wil dit in de toekomst gebruiken voor betalingen
---oplossingen---
sql injecion =
$daa = mysql_real_escape_string($_GET['daa']);
cross-site request=
default wachtwoord wijziggen (weet begod niet wat het is)
de andere 2 kan ik geen oplosing bedenken.
maar ik weet wel dat
site.nl/homepage.php?voornaam = "carlo"
onveilig is, is GET dan ook onveilig?
Gewijzigd op 01/01/1970 01:00:00 door carlo boy
mysql_real_escape_string is een goeie oplossing om in ieder geval alle waarden alvast op de juiste manier van quotes te voorzien. Je kan nog een stapje verder gaan, en prepared statements gebruiken. Dan stuur je namelijk de SQL code en de waarden die je wilt invullen apart naar de database, en kan een waarde dus niet de opbouw van je SQL code omgooien. Moet je jezelf wel aanleren om geen variabelen bij het maken van de SQL code te gebruiken, en zorvuldig je waarden via placeholders in je SQL te verwerken.
XSS kan je deels tegengaan door het in ieder geval onmogelijk te maken dat mensen HTML kunnen posten op je website. htmlentities helpt je daarmee al een eindje op weg.
CSRF is eigenlijk dat de kwaadwillende de gebruiker als het ware op een knopje op jouw website drukt waardoor de actie die de kwaadwillende voor ogen had gebeurt. Bijvoorbeeld de link http://example.com/index.php?del=24 verwijdert gebruiker 24 wanneer de admin is ingelogd. Nu ben ik de admin, en ik ben ingelogd. Nu plaatst iemand op een andere site <img src="http://example.com/index.php?del=24"> en mijn browser zal die URL opvragen, waarmee de actie dus wordt uitgevoerd. Dat kan omdat ik al was ingelogd op de website. Dit kan je al deels tegen gaan door alleen niets wijzigende acties via GET te laten lopen. Alles wat wat aanpast of verwijderd via POST laten gaan. Mocht er alsnog misbruik worden gemaakt van je website op deze manier (dat kan, maar al een stuk minder effectief) dan kan je nog ieder formulier een unieke random code meegeven, en controleren of die unieke random code ook werkelijk in een formulier is gezet. Maar dat is voor later.
Upload-formuliertjes moet je gewoon heel erg voorzichtig mee omgaan. Controleer op de naam en als het kan op de inhoud van het bestand. Beiden zijn echter niet uitsluitend, dus het is ook een goed idee om ervoor te zorgen dat het niet mogelijk is het bestand vanuit de browser te kunnen benaderen: plaats de geuploade bestanden buiten de web-root.
include-statements moet je eigenlijk zo min mogelijk op basis van variabelen doen. Komt er wel een variabele in voor, zorg er dan voor dat je een whitelist hebt met alle waarden die de variabele mag hebben, en controleer of de waarde in de whitelist zit. Dit lek komt echt heel veel voor, en is, zeker in combinatie met een kapot upload formulier, maar ook alleen al erg erg gevaarlijk. Mensen kunnen dan namelijk PHP code op jouw server uitvoeren, en dus alles met je server doen wat vanuit PHP mogelijk is.
$_GET, $_POST, veel uit $_SERVER & $_ENV, en eigenlijk ook $_SESSION komen van buiten je applicatie. Dat betekent dat je geen controle had over hoe de data erin is terecht gekomen, en je er dus eigenlijk vanuit mag gaan dat die data klopt of überhaupt veilig is. XSS kan je deels tegengaan door het in ieder geval onmogelijk te maken dat mensen HTML kunnen posten op je website. htmlentities helpt je daarmee al een eindje op weg.
CSRF is eigenlijk dat de kwaadwillende de gebruiker als het ware op een knopje op jouw website drukt waardoor de actie die de kwaadwillende voor ogen had gebeurt. Bijvoorbeeld de link http://example.com/index.php?del=24 verwijdert gebruiker 24 wanneer de admin is ingelogd. Nu ben ik de admin, en ik ben ingelogd. Nu plaatst iemand op een andere site <img src="http://example.com/index.php?del=24"> en mijn browser zal die URL opvragen, waarmee de actie dus wordt uitgevoerd. Dat kan omdat ik al was ingelogd op de website. Dit kan je al deels tegen gaan door alleen niets wijzigende acties via GET te laten lopen. Alles wat wat aanpast of verwijderd via POST laten gaan. Mocht er alsnog misbruik worden gemaakt van je website op deze manier (dat kan, maar al een stuk minder effectief) dan kan je nog ieder formulier een unieke random code meegeven, en controleren of die unieke random code ook werkelijk in een formulier is gezet. Maar dat is voor later.
Upload-formuliertjes moet je gewoon heel erg voorzichtig mee omgaan. Controleer op de naam en als het kan op de inhoud van het bestand. Beiden zijn echter niet uitsluitend, dus het is ook een goed idee om ervoor te zorgen dat het niet mogelijk is het bestand vanuit de browser te kunnen benaderen: plaats de geuploade bestanden buiten de web-root.
include-statements moet je eigenlijk zo min mogelijk op basis van variabelen doen. Komt er wel een variabele in voor, zorg er dan voor dat je een whitelist hebt met alle waarden die de variabele mag hebben, en controleer of de waarde in de whitelist zit. Dit lek komt echt heel veel voor, en is, zeker in combinatie met een kapot upload formulier, maar ook alleen al erg erg gevaarlijk. Mensen kunnen dan namelijk PHP code op jouw server uitvoeren, en dus alles met je server doen wat vanuit PHP mogelijk is.
Code (php)
1
2
3
2
3
$sql = "SELECT id, FROM gebruikers WHERE naam='".$_POST['user']."'";
$query = mysql_query($sql);
$tellen = mysql_num_rows($query);
$query = mysql_query($sql);
$tellen = mysql_num_rows($query);
Dit heb ik van het inlog script wat ik gekopieerd heb.
En dit is dus harstikke gevaarlijk.
Helaas weet ik niet hoe ik dit moet gaan oplossen.
Ik moet toch de waarden $_POST gebruiken :'(.
Als ik een oplossing heb gevonden zal ik het posten
Jelmer schreef op 15.03.2009 20:18:
$_GET, $_POST, veel uit $_SERVER & $_ENV, en eigenlijk ook $_SESSION .... mysql_real_escape_string ....
Dat hoef je niet te doen, dat is zonde van je geheugen. Je kunt beter bij een query pas de gegevens filteren:
Code (php)
1
mysql_query("INSERT INTO blabla (veld1, veld2) VALUES ('".mysql_real_escape_string($_POST['daa'])."', 'en nog iets!')")
Gewijzigd op 01/01/1970 01:00:00 door Roel -
Ik zie nu echt fouten in m'n scrips.
Arian schreef op 15.03.2009 21:51:
Als $_POST['user'] een id ofzo is, kan je al gaan checken of het een cijfertje is.
En anders kan je nog dit doen
En anders kan je nog dit doen
Hoe moet je controleren als id een cijfer is?
ctype_digit is de mooiste manier
Je kunt hem ook gewoon casten. Als het dan geen valid int is dan wordt dat standaard toch 0.
Zijn dit de enigge bugs?
Code (php)
1
2
3
2
3
<?php
$query = "SELECT * FROM tabel WHERE id = ".(int)$_SESSION['user_id']." OR naam = '".mysql_real_escape_string($_POST['naam'])."'";
?>
$query = "SELECT * FROM tabel WHERE id = ".(int)$_SESSION['user_id']." OR naam = '".mysql_real_escape_string($_POST['naam'])."'";
?>
Even een klein aanvullend voorbeeld.
Ik moet zeggen.
Ik heb veel geleerd op dit forum.
Ik heb op forum's geweest waar ik als gozer werd uitgescholden.
Hier geven ze tips waar je op moet letten.
Code (php)
Ik werd met deze fouten uitgelaggen.
Bedankt jongens
ps. zoek de fouten :p