phpBB.nl

Hallo mensen,

Een tijdje terug werd mijn website gehacked door middel van XSS (EN)
Ik had door middel van string replace bepaalde karakters 'verboden'/gefilterd echter bleek deze niet geheel water dicht te zijn

Nu heb ik een andere manier gezocht waarmee ik alle 'hack' mogelijkheden dmv $_POST en $_GET wil voorkomen, zonder de gebruiker bepaalde karakters te laten verbieden.

Ik gebruik deze PHP code
De str_replace zou in principe overbodig zijn maar dit is zoals ik hem heb gemaakt (functie)

Nu mijn vraag,
is er iemand die op wat voor manier dan ook dit nu nog zou kunnen hacken? (de PHP code, ga dr ff vanuit dat PHP 100% secure is en dus geen bugs bevat in dit opzicht)
ik heb hier ff een test pagina opgezet zodat jullie kunnen uit testen
http://www.supperbas.com/test.php

Bijvoorbaad dank,

-Bas aka supperbas

Je code is onvolledig, informatie die je invoert in een MySQL database moet je op z'n minst door mysql_real_escape_string() halen (vergeet htmlspecialchars() en str_replace()).

Om problemen met slashes te voorkomen moet je trouwens eerst kijken get_magic_quotes_gpc aanstaat in php.ini, en die dan ongedaan maken (magic quotes doen meer kwaad dan goed). Dit moet dus eigenlijk altijd boven je script:

get_magic_quotes_gpc staat uit in php.ini, die had ik idd al uit gezet

maar daar was je wss achtergekomen als je naar die test.php had gekeken.

en wat is het nut om get_magic_quotes_gpc te doen wanneer

' OR ''='

wordt

' OR ''='

dat is dan toch verspilde 'tijd' ? of zie ik nu iets over het hoofd?

Het kan geen kwaad om die code boven je script te zetten, mogelijk verhuis je ooit van server of worden de instellingen aangepast.

Je moet dus geen get_magic_quotes_gpc maar mysql_real_escape_string() gebruiken. Je ziet inderdaad iets over het hoofd, alleen quotes en slashes escapen is niet voldoende. Bijv. met multi-byte karakters kun je str_replace() en addslashes() etc. omzeilen. Lees deze artikelen maar eens:

http://shiflett.org/blog/2006/jan/addsl ... ape-string
http://dev.mysql.com/tech-resources/art ... ty-ch3.pdf

Ik heb de artikelen door gelezen en hier en daar nogwat gegoogled,

Maar van alle dingen die ik heb uit getest krijg bij mijn test pagina geen SQL injectie dr in gerammed, of een XSS attack

en met de GBK codes kom ik ook niet 'binnen' ook niet met chr(GBK)

maar dmv welke code zou je volgens jouw nu een hack kunnen uitvoeren op die test pagina? ik zal de link nog een keer geven LINK

bedankt,

-bas

Ik zou niet zo 1-2-3 controle over je server kunnen nemen hiermee (zover ik kan zien komt er geen SQL aan te pas?).

Ander voorbeeld: Als ik als gebruikersnaam admin en wachtwoord foo" OR "foo" = "foo kan invoeren log ik gewoon in onder de admin-account.

"SELECT * FROM `users` WHERE `username` = 'foo" OR "foo"'"

dit zou de output zijn
input < foo" OR "foo" = "foo > of <foo' OR 'foo' = 'foo > geeft bijde 0 resultaten bij mysql_num_rows();
echo mysql_num_rows(mysql_query("SELECT * FROM `tabel_users` WHERE `username` = '".$_POST['form']."'"));
-> 0 rows

maar wanneer alle special chars worden omgezet dan is het toch 'onmogelijk' om dmv SQL injection binnen te komen of ben ik nu gek?
want je kan de haakjes niet sluiten omdat " " wordt en ' '
en dit levert toch geen problemen op bij [php] mysql_query ? (het kan zijn dat ik nu iets gigantisch over 't hoofd zie)

of?

Zoals je in die artikels had kunnen lezen is het mogelijk om toch quotes en slashes in te voeren d.m.v. multi-byte karakters. Als ik een bepaald teken, zeg # (fictief voorbeeld) invoer dat niet escaped wordt, zet MySQL dit om naar bijv. 54%" en kan ik je query dus alsnog aanpassen. Daarom moet je altijd de escape-functie gebruiken die bij de database hoort.

In dit geval krijg je dan iets als dit:

Input: # OR TRUE = TRUE;
SQL: 54%" OR TRUE = TRUE;

okay wat dacht je hier van? (ik heb eerst special chars gedaan zodat je geen 'addslashes' krijgt, en zodat hij de 'string' die in de database gaat ook als laatste gecontroleerd heeft)

Dat ziet er al beter uit, maar ik zou niet de originele variabelen overschrijven. Er is geen functie om mysql_real_escape_string() om te keren (zoals addslashes()/stripslashes()).

Als je invoer van de gebruiker wilt weergeven heb je eigenlijk alleen htmlspecialchars() nodig, anders krijg je slashes op onverwachte plaatsen te zien. Als je informatie wilt opslaan heb je eigenlijk alleen mysql_real_escape_string() nodig (maar htmlspecialchars() kan geen kwaad).

Wat ik zelf doe is de gefilterde waarden in een nieuwe variabele plaatsen zodat ze allebei toegankelijk zijn.