veiligheid

Hij probeert bijna altijd andermans account te "stelen", in te loggen in een account waar hij het wachtwoord niet van weet. Dat kan een account van z'n "vriend" zijn, maar ook die van de admin gebruiker.

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.

bedankt voor je snelle reactie.

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?

$_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. [php]mysql_real_escape_string[/php] 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. [php]htmlentities[/php] 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.

In aanvulling op het verhaal van Jelmer

http://www.phpfreakz.nl/downloadz/webprogrammers_hacking_huide.pdf leesvoer

Wow heel erg bedank jongens!

$sql = "SELECT id, FROM gebruikers WHERE naam='".$_POST['user']."'";
   $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 .... [php]mysql_real_escape_string[/php] ....

Als $_POST['user'] een id ofzo is, kan je al gaan checken of het een cijfertje is.

En anders kan je nog dit doen
<?php
mysql_real_escape_string($_POST['user'])
?>

$daa = mysql_real_escape_string($_GET['daa']);

Dat hoef je niet te doen, dat is zonde van je geheugen. Je kunt beter bij een query pas de gegevens filteren:

mysql_query("INSERT INTO blabla (veld1, veld2) VALUES ('".mysql_real_escape_string($_POST['daa'])."', 'en nog iets!')")

Bedankt,
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
<?php
mysql_real_escape_string($_POST['user'])
?>

Hoe moet je controleren als id een cijfer is?

[php]ctype_digit[/php] is de mooiste manier