[Alg] Veilig (web)programmeren

[Dr HenDre]

beste sm'ers ()

ik zit momenteel een beetje met een vraag waar ik niks over kan vinden. Hoe krijg je het voor elkaar dat je scripts/programma's zo veilig mogelijk zijn? Voor het gemak richt ik me op php, om dingen als buffer overflows effe buiten te houden, maar als iemand zich geroepen voelt om t ook daarover te hebben, prima.
Wat ik doe op mn php scripts om ze veilig te maken is alle invoer door htmlentities halen met ENT_QUOTES. En ervoor zorgen om in sql query's op te bouwen in de vorm:

PHP-code:

$sql = "SELECT * FROM ".$table_input_by_user." WHERE id = '".$id."'"; 


Toch komen in systemen als phpBB geregeld problemen mbt sql-injections en cross site scripting. Nu is mijn vraag, komt dit omdat dit soort systemen zo groot en complex zijn dat de proggers gewon over het hoofd zien dat er bepaalde dingen niet gecontroleerd worden of zijn er nog extra stappen die je moet ondernemen om je site veilig te krijgen.

Ik weet het niet schat.

[Gimme more beer]

Het gaat niet alleen om de grootheid en complexheid van een site, maar vaak vooral om het feit dat de programmeur niet goed op de hoogte is van de mogelijkheden die hackers hebben of het feit dat de sites waar het kan vaak erg oud zijn.

Ik gebruik in PHP altijd bijvoorbeeld addslashes() om PHP- en SQL-injectie tegen te gaan, maar er zijn genoeg andere manieren waarop een site te hacken is. Sommige sites zijn simpelweg slecht gebouwd en hebben hun security leaks vooral in de slordigheid zitten, maar je kunt natuurlijk ook andere hacktechnieken toepassen dan puur en alleen het hacken dmv. de website. Je kunt ook bijvoorbeeld een server gaan hacken, die moet ook zo secure mogelijk zijn, anders heb je niets aan je maatregelen op de website.

Ik ben bijvoorbeeld ook genoeg sites tegengekomen waar de passwords in een MD5 hash open en bloot in een losse folder staan. Als je er dan achter komt welke folder dat is, kun je de wachtwoorden heel gemakkelijk kraken.

Maar ook heb je soms sites met bepaalde "features" waarmee je een PHP script kunt showen in je browser. Soms houdt een programmeur bij 2 verschillende dingen geen rekening met het ander en dan gaat hij nog wel eens de mist in.

[Dr HenDre]

Gimme more beer schreef op 10-04-2005 @ 17:37 :
Het gaat niet alleen om de grootheid en complexheid van een site, maar vaak vooral om het feit dat de programmeur niet goed op de hoogte is van de mogelijkheden die hackers hebben of het feit dat de sites waar het kan vaak erg oud zijn.

Ik gebruik in PHP altijd bijvoorbeeld addslashes() om PHP- en SQL-injectie tegen te gaan, maar er zijn genoeg andere manieren waarop een site te hacken is. Sommige sites zijn simpelweg slecht gebouwd en hebben hun security leaks vooral in de slordigheid zitten, maar je kunt natuurlijk ook andere hacktechnieken toepassen dan puur en alleen het hacken dmv. de website. Je kunt ook bijvoorbeeld een server gaan hacken, die moet ook zo secure mogelijk zijn, anders heb je niets aan je maatregelen op de website.

daar ben ik t wel met je eens, maar zoiets komt veel minder vaak voor dan gebrekkige code. Als je de server wil inkomen moet dat of via de ftp server ofzo, en t komt maar zelden voor dat een ftp zo slecht is dat je binnen kan komen.

Gimme more beer schreef op 10-04-2005 @ 17:37 :

Ik ben bijvoorbeeld ook genoeg sites tegengekomen waar de passwords in een MD5 hash open en bloot in een losse folder staan. Als je er dan achter komt welke folder dat is, kun je de wachtwoorden heel gemakkelijk kraken.

Maar ook heb je soms sites met bepaalde "features" waarmee je een PHP script kunt showen in je browser. Soms houdt een programmeur bij 2 verschillende dingen geen rekening met het ander en dan gaat hij nog wel eens de mist in.

Hmm, ok dat zijn gewoon domme fouten van de gebruikers, maar het is dus in feite genoeg om input te filteren op <'s >'s single/en dubble quotes? En bij exec's ook op ;'s?

Toch vertrouw ik t niet, ik heb t gevoel dat er meer is, ik weiger te geloven dat je met simpele input filters alles kan voorkomen. Dat kan iedere naab wel, en toch worden zelfs banken gehax0rd

[Gimme more beer]

Dr HenDre schreef op 10-04-2005 @ 17:53 :
daar ben ik t wel met je eens, maar zoiets komt veel minder vaak voor dan gebrekkige code. Als je de server wil inkomen moet dat of via de ftp server ofzo, en t komt maar zelden voor dat een ftp zo slecht is dat je binnen kan komen.

Software beveiligt zich niet zelf, dat moet de gebruiker doen. Als hij een of andere applicatie gaat draaien die niet secure is, brengt hij zichzelf in de problemen. Maar ook gewoon het OS moet secure draaien. Daar moet de gebruiker zelf voor zorgen.

Hmm, ok dat zijn gewoon domme fouten van de gebruikers, maar het is dus in feite genoeg om input te filteren op <'s >'s single/en dubble quotes? En bij exec's ook op ;'s?

Toch vertrouw ik t niet, ik heb t gevoel dat er meer is, ik weiger te geloven dat je met simpele input filters alles kan voorkomen. Dat kan iedere naab wel, en toch worden zelfs banken gehax0rd

Banken worden meestal niet via de website gehackt, dat gaat echt via doorgespeelde SSH accountjes en gewoon server hacken. Je probeert in een netwerk in te breken en als je dat via de website kan, ben je echt dom bezig geweest als programmeur. Als je elke vorm van user input filtert en er rekening mee houdt dat bijvoorbeeld een bestandje dat content print niet de content van je php scripts kan printen om maar een voorbeeldje te noemen, wordt hij niet meer gehackt door onvolkomenheden in je eigen code. Hooguit door php security leaks, maar die zijn er (vrijwel) niet.

[Martin]

Kijk ook eens in dit topic:

http://forum.scholieren.com/showthre...ght=php+veilig

[dafelix]

altijd de userinput controleren

idd bij SQL altijd de dingen escapen, zie eventueel ook de manual (tip: geef ook de resource link_identifier mee, want sommige DB's hebben andere charset, waardoor de functie nog geen zin zou kunnen hebben)

nooit een functie zo gebruiken:

PHP-code:

include($_GET['includefile']); 


maar zo:

PHP-code:

if ($_GET['includefile'] == "index") {
  include("index");
}
(...) 


Of er natuurlijk een controle functie gebruiken (input bevat geen "." (punt) of "/" (slash))

En dit is ook leuk:

PHP-code:

$result = mysql_insert("INSERT INTO bedacht ('body') VALUES ('".mysql_real_escape($_GET['body')."');"; 


PHP-code:

echo mysql_result("SELECT body FROM bedacht"); 


Dit lijkt veilig, maar wat nou als iemand "<script language='javascript'>" etc invoert? Dan kun je nog heele leuke trucjes mee uithalen

Wees creatief met je inputvelden, kijk eens wat je zou kunnen uitvreten, en daarna bouw je controle moment in, want zolang je de userinput op alle mogenlijke manieren checkt+beveiligd, is het grootste probleem opgelost!

link naar goede documentatie hierover

[Dr HenDre]

hmm, en hoe zit t dan met dit soort "truukjes"

Let's use some trick for bypassing any eventual gpc_magick_quotes setted to On (did you hackproof
php,isnt it?)  by using the 0xXX hex to text MySQL feature:
mysql> select HEX('<script>alert(“SiXSS”);</script>');
+------------------------------------------------------------------+
| HEX('<script>alert("SiXSS");</script>')
|
+------------------------------------------------------------------+
| 3C7363726970743E616C6572742822536958535322293B3C2F7363726970743E |
+------------------------------------------------------------------+
1 row in set (0.00 sec)
and let's put it into HTTP Request:
http://www.mybank.com?id=1+union+sel...3B3C2F73637269
70743E

is dit gewoon onzin, of werken dit soort truukjes, ik heb t namelijk zelf niet werkend gekregen

@dafelix daar is mijn topic een beetje op gebasserd, op de link die je gaf

[Manuzhai]

Als je input weer in HTML gaat weergeven kan het ook geen kwaad om bijvoorbeeld htmlspecialchars() te gebruiken zodat niet alle HTML klakkeloos wordt weergegeven.

[Enlightenment]

1) zoals manuz zegt, alles wat op het scherm komt uit de database loods ik bijna altijd door een htmlentities() filter, deze zal alle codes HTML-safe maken maar ook karakters als & omzetten naar & amp; zodat de code charactermap-compliant wordt zodat je (X)HTML als correct gevalideerd wordt.

2) als je een integer variabele in een query wilt opnemen, gebruik van type casting:

PHP-code:

$user = sql_mono('SELECT * FROM `users` WHERE `id` = '.(int)$userid); 


(wat je hier doet is van $userid een integer maken, dus deze zal nooit een ' of " kunnen bevatten. 5'9A9 wordt dus 599 en AA() wordt 0. Veilig en makkelijk.

3) gebruik geen magic_quotes_gpc of als je project op meerdere servers moet kunnen draaien, gebruik een functie zoals safegpc:

PHP-code:

 $messages = sql_poly('SELECT * FROM `messages` WHERE `user` = '.(int)$userid.' AND `dataindex` = '.safegpc($_POST['index']); 


Mijn sagegpc() functie ziet er zo uit:

PHP-code:

function safegpc($string)
{
 if (get_magic_quotes_gpc() == 0)
  return mysql_escape_string($string);
 else
  return $string;
} 


Bij de functie safegpc moet je deze dus gebruiken bij variabelen die van je GPC ($_GET, $_POST, $_COOKIE) komen. De functie controleert dan zelf of gebruik van mysql_escape_string() nodig is, afhankelijk van of magic_quotes_gpc aan of uit staat.

Geinig, toch?