Geschreven door : Hielke P
Cross Site Scripting ( XSS )
Wat houd deze fout in :
Bijvoorbeeld als een zoek functie het opgegeven woord terug geeft in de zin van:
Geen resultaten voor: omygod
echo "Geen resultaten voor:". $zoekwoord;
In dit voorbeeld heeft de gebruiker ''omygod'' als zoek term ingevuld en de php script
laat de ingevoerde resultaat rechtstreeks op de pagina zien zonder dat deze wordt
gecontrolleerd. Dus met andere woorden: alles wat je invult bij de zoek functie zal
tijdelijk op de pagina worden verwerkt. Dus ook HTML / Javascript.
Vul je nu in de zoek functie het volgende in:
<script>alert('foutje')</script>
En je drukt vervolgens op zoek zul je zien dat er een een popup schermpje verschijnt
met de tekst 'foutje' en als je de broncode van de pagina bekijkt zie je dat het script
tijdelijk in de website is verwerkt omdat het PHP script de zoek resultaat in de
pagina verwerkt zonder die eerst te controlleren. En ook zul je zien dat de script in de URL is terug te vinden.
Hoe misbruiken hackers deze bug ?
Hackers passen de URL van de website aan zodat ze zelf dingen kunnen invoegen op
de website. De website wordt niet echt veranderd maar als je de aangepaste URL opent
dan wel. Dus in de eerste instantie lijkt het alsof deze bug niet kwaad kan maar kort een
scenario van wat er kan gebeuren hieronder uitgelegd.
De hacker vind de bug
De hacker heeft op koopspullenonline.nl een XSS bug in de zoek functie gevonden. Deze website bevat naast de zoek functie ook een inlog systeem & natuurlijk een formulier waar
je je gegevens en creditcard informatie moet invullen als je tot aankoop wilt overgaan.
mogelijkheid 1:
De hacker past de URL van de website op dusdanige manier aan zodat er een script wordt
toegevoegd aan de website. Deze script veranderd de 'action=' van het inlog systeem dus
zodra een gebruiker op de 'inlog' knop drukt worden de login details verzonden naar de hacker en wordt de gebruiker netjes ingelogd zodat er niemand argwaan krijgt.
Vervolgens doet de hacker zich voor als een klant en verstuurd naar de website eigenaar een emailtje dat hij problemen heeft met inloggen en rare dingen krijgt bij het inloggen
en vervolgens staat er een hyperlink in het emailtje.Die hyperlink bevat de aangepaste URL en zodra de website eigenaar inlogt zullen zijn login details per email worden verstuurd naar de hacker.En de rest kun je zelf invullen. Natuurlijk is dit al de omslachtige manier en zou de hacker ook simpel weg een stukje javascript kunnen toevoegen die de cookie van de admin verstuurd naar zijn email adres en vervolgens zijn eigen cookie aanpast met de gestolen phpsessie van de admin en zijn browser refreshen en de hacker is vervolgens ingelogd als de admin. Indien deze "wachtwoord onthouden" heeft aangevinkt.
mogelijkheid 2:
De hacker bemachtigd door een andere bug of gewoon via de website een lijst met klanten. Vervolgens maakt de hacker een formulier waarbij je je creditcard gegevens moet invullen en wachtwoord gegevens en nog wat andere gegevens. Doormiddel van de bug in de zoek functie (xss) kan hij deze formulier op de orginele website plaatsen. Omdat de zoek functie alle code toevoegd aan de HTML kan hij dus ook de hele pagina opnieuw inrichten in dit geval is dat dus een formulier met invul velden.
Vervolgens spoofed de hacker de afzenders email adres. Wat inhoud dat hij zelf de afzender kan bepalen. In dit geval vult de hacker de email adres van de website in zodat het net lijkt alsof de website beheerder de email heeft verstuurd. Vervolgens maakt de hacker een echt uitziende email waarin staat dat er problemen zijn geweest met het systeem en er gegevens zijn verloren gegaan. En of de klanten de volgende gegevens kunnen bevestigen omdat ze anders mogelijke bestellingen niet binnen krijgen. Met wederom de aangepaste link achter een hyperlink. En vervolgens verstuurd de hacker de email naar alle klanten.
vervolgens:
Ziet de klant in zijn inbox een email die afkomstig is van de website beheerder. Dus het vertrouwen is er al. De email ziet er vervolgens orgineel/echt uit en het verhaal wat erbij staat is overtuigend en wekt geen enkele argwaan. Vervolgens opent de klant de link en ziet gewoon dat de 'echte' website wordt geopend. Dus waarom zou hij denken dat hij gehackt wordt als de website naam ook nog eens klopt. ?
Klant vult netjes zijn gegevens in en wordt doorgestuurd naar een bedank pagina. De hacker krijgt alle creditcard gegevens binnen en verkoopt die of misbruikt die om vele aankopen online op het internet te doen.
Mogelijkheid 3:
De hacker vind een XSS bug op een forum/website die een inlog systeem heeft. De XSS zit hem in de BBcode. Bepaalde tags zoals [img] worden niet gecontrolleerd. De hacker plaats vervolgens een stukje javascript hiertussen die de cookie steelt en verstuurd naar de email adres van de hacker. De hacker plaats een bericht op de website en krijgt vervolgens van iedereen de cookie's per email gestuurd die de pagina bekijkt waar hij een bericht heeft geplaatst. En heeft zo vrij snel zo'n beetje elke gebruiker op de website gehackt.Gevaarlijke aan dit is dat de code niet tijdelijk in de website zit verwerkt doormiddel van een aangepaste URL maar de code echt in de site zit verwerkt. Dit is verder vaak ook mogelijk bij gastenboeken en zelfs bij velden waar je je naam in moet vullen,
Oplossing:
Er is hier een hele simpele oplossing voor en dat is simpel weg een php functie gebruiken.
Voordat het zoek resultaat wordt getoond op de website haal je hem door htmlentities heen.
$zoekwoord = htmlentities($zoekwoord);
Nu wordt de zoekstring omgezet naar speciale html code's en zal hij dus niet meer worden
uitgevoerd en is daarmee de bug verholpen.En niet alleen zoekresultaten maar gewoon alle userinput die op de website gaat getoond moet hierdoor heen worden gehaald.
Let op !
Vaak wordt ten onrechte gedacht dat als de php functie 'magic quotes' aanstaat XSS ook niet meer mogelijk is omdat deze er dan zo uit ziet.
<script>alert(/'foutje/')</script>
Maar hier is simpel om heen te gaan door de inhoud van alert om te zetten in charcode. De xss ziet er dan als volgt uit.
En omdat er geen gebruik meer wordt gemaakt van quotes zal magic quotes dit dus niet tegenhouden.
eind woord:
Hoe ernstig deze bug is hangt van de mogelijkheden van de website zelf af. Maar verder zijn de mogelijkheden zo groot als de creativiteit van de hacker. Vooral phishers(oplichters) zijn bijzonder vindingrijk in het oplichten van mensen op deze manier. En naast mijn voorbeelden zou je zelfs iemand zijn browser kunnen overnemen doormiddel van een XSS shell. Veel mensen verkijken hun op deze bug en dat is ook de rede dat bepaalde browsers automatisch deze bug blokkeren.
Remote File Include bug ( RFI )
Wat houd deze bug in:
Dit houd in dat een variabelen die in de URL staan of door de gebruiker zijn ingevuld ongecontrolleerd worden gebruikt in een include functie.Wat dus inhoud dat een
gebruiker zijn eigen php code in de website kan verwerken.
Voorbeeld van zo'n code is :
$pagina = $_GET['pagina']; // pakt de variabelen
include($pagina . '.php'); // include variabelen + .php
de link ziet er volgens bijvoorbeeld zo uit:
www.websitenaam.nl/index.php?pagina=contact
De functie include variabelen pagina wat in dit geval dus de waarde "contact" heeft en het script zet er vervolgens .php achter en het dus contact.php wordt. Alleen nu kan de include functie van php ook bestanden van buiten af(remote) includen. Dus is het mogelijk om een php bestand van een andere website/server via de include(pagina) toe te voegen aan de website.En juist dit vinden hackers intressant.
Door een vraagteken op het einde van de URL wordt hetgene wat de script nog meer toevoegd simpel weg als paramater ingesteld en dus genegeerd. Hiervoor kan de null byte exploit ook worden gebruikt ( %00 ) waardoor het script simpelweg gewoon de rest van de code negeert.Kortom : de hacker kan elke willekeurige php code op de website uitvoeren.
Hoe misbruiken hackers deze bug
Omdat je alle willekeurige PHP code kunt uitvoeren is het niet moeilijk om te verzinnen hoe hackers deze bug kunnen misbruiken. Maar vaak wordt dit gedaan met PHPshell's. Dit is een php script die kort gezegd controle geeft over ALLES ftp/server. De hacker ziet alle bestanden netjes weergeven in een lijst en heeft onder meer de optie's om bestanden te verwijderen, te veranderen, up te loaden etc... Verder maken PHPshells het vaak ook mogelijk om exploits uit te voeren waardoor de hacker de complete server kan overnemen. PHPshells zoals c99 en r57 maken het kinderspel om een website over te nemen die deze bug bevat.
Mogelijkheden:
1. Je website wordt gebruikt om andere websites doormiddel van DDoS plat te leggen
2. Je website wordt gebruikt om spam te versturen
3. Alles wordt verwijderd en de website laat een pagina zien met de tekst "Hacked By:"
4. De hacker voegt een stuk script aan je website toe dat elke bezoeker van je website infecteert met een virus en zo onderdeel wordt van een botnet ( netwerk van gehackte computers)
5. De hacker steelt vertrouwelijke gegevens
6. De hacker misbruikt je server om illegale dataverkeer doorheen te laten stromen
etc..... de optie's zijn echt eindeloos
Oplossing:
Het veiligst is aan te geven welke woorden ge include mogen worden in een array.Op deze manier is er geen ruimte voor andere woorden.
-------------------------------------------------------------------------------------------
--------------------------------
$pagina = $_GET['pagina'];
$paginas = array('contact','index','producten'); // namen van de paginas
if(in_array($pagina, $paginas)) // controlleerd of pagina 1 van de namen bevat
{
include("$pagina . '.php'); // zo ja include
}
else
{ $pagina = "index.php"; include($pagina); } // en anders include gewoon index.php
Local File Include bug ( LFI )
Wat houd deze bug in ?
Eigenlijks gaat het hier om dezelfde fout geprogrammeerde code als met RFI. Met het verschil dat de makers van deze script dachten slim te zijn door in de php.inni bestand bepaalde instellingen uit te zetten zodat RFI onmogelijk wordt. Of gewoon door simpel weg door "http://" & "www" te vervangen in $pagina zodat de RFI niet succesvol meer kan worden uitgevoerd.
php.inni instellingen:
1.Set allow_url_fopen to OFF
2.Set allow_url_include to OFF
De script
-------------------------------------------------------------------------------------------
-------------------
$pagina = $_GET['pagina']; // pakt de variabelen
$pagina = strtolower($pagina); // zet $pagina om in kleine letters
$pagina = str_replace("***","http:",$pagina); // vervangt http: voor ***
$pagina = str_replace("***","www.",$pagina); // vervangt www. voor ***
include($pagina . '.php'); // include variabelen + .php
-------------------------------------------------------------------------------------------
-----------------
In de eerste instantie lijkt dit veilig. De inhoud van $pagina wordt eerst omgezet in kleine letters zodat er niet kan worden gespeelt met hoofd/kleine letters combinatie's. Vervolgens worden http en www vervongen voor *** en pas daarna word het geheel ge include. Of de instellingen zijn zo gezet dan RFI gewoon weg niet meer mogelijk is. Inderdaad veilig voor een RFI attack maar niet veilig voor Local File Include bug.
Local File Include(LFI) V.S Remote File Include(RFI)
Let op de namen. De hacker kan inderdaad niet meer een script van buiten af aanroepen (remote) maar kan nog wel bestanden op de website zelf aanroepen (Local). Wederom zijn hier veel dingen mee mogelijk. En is het speelkwartier voor de hacker geopend.
Hoe misbruiken hackers deze bug
Mogelijkheid 1: Wachtwoord Bestand:
Doordat de $pagina variabele met alleen controle op ''www'' en "http:" wordt doorgegeven aan de include is het dus gewoon nog mogelijk bestanden die op de website zelf bevinden te includen.Wat dus inhoud dat de hacker ook bij het wachtwoord bestand kan komen doormiddel van het volgende bij pagina in te vullen.
Doordat de hacker %00(null byte) toevoegt aan de url op het eind zal het script wederom ".php" negeren en het bestand openen, doet hij dit niet zal de pagina "etc/password.php" openen en dat bestand bestaat niet.In het passwd bestand staan (je raad het al) login details. Door "../" gaat de hacker steeds een map omlaag totdat hij het bestand vind en door de include functie kan hij de inhoud lezen omdat hij de rechten van de pagina heeft die de LFI bug bevat. De locatie van dit bestand kan per website verschillen maar hackers hebben hier tools voor die dit zoekwerk automatisch doen.
In het passwd bestand treft de hacker het wachtwoord in encryptie aan.
Doormiddel van het programma "John the ripper" cracked de hacker het wachtwoord.
Mogelijkheid 2: Apache log
Er zijn andere mogelijkheden om een website over te nemen met LFI. De apache log registreert alles wat er gebeurd op de website dus die gaat de hacker zoeken zodat hij daar php code kan invoegen. Het zoeken gebeurd via een automatische hacktool of door de locatie's via google op te zoeken. Ons voorbeeld:
de hacker wil een command prompt op de server draaien,
<? passthru(\$_GET[cmd]) ?>.
De hacker ziet dat de ''niet gevonden'' pagina's hier worden opgeslagen. Maar als hij achter pagina de php code plaatst zal het automatisch encoded verwerkt worden in de acceslog en dus niet werken dus gebruikt de hacker daar een PERL script voor die de POST request rechtstreeks uitvoert op de website en op deze manier wordt de php niet encoded en komt die rechtstreeks in de acceslog terrecht.Vervolgens gaat de hacker weer naar de acces log en een commannd prompt verschijnt en hij heeft wederom controle over de website.Omdat de include functie in index.php zoekt naar php code zal hij de phpcode in acceslog automatisch uitvoeren. Handig :D
Mogelijkheid 3: Avatar/img upload
Meeste forums en sommige websites hebben een avatar upload stuk. De hacker opent vervolgens een plaatje en voegt hier met een programma of via hex editor een stuk php code aantoe bijvoorbeeld: een phpshell(zie remote file include) vervolgens slaat hij het plaatje op en upload hij die zonder problemen naar de website. Vervolgens zorgt hij voor een error op de pagina door iets met opzet verkeerd te doen. De hacker krijgt hetvolgende te zien.
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /index/httpd/public_html/includes/view.php on line 80
Nu hij deze informatie bezit over de pagina. Doet hij rechte muisklik op het plaatje en ziet de path wat in dit voorbeeld : ''avatars/evilfoto.jpg'' is. De hacker opent nu de link.
Doordat index.php automatisch evilfoto.jpg include zal vervolgens de php code die verwerkt zit in het plaatje te zien zijn. In dit geval dus een PHPshell en daarmee heeft de hacker wederom controle over de hele website.
Oplossing:
De oplossing zoals die bij RFI staat beschreven zou alleen ook al voldoende moeten zijn. Je kunt natuurlijk ook alle slashes nog filteren als extra beveiliging. En wat ook geen overbodige luxe is, is de avatar plaatjes via een php script te laten laden zodat de het php bestand de path van het plaatje verbergt.
Upload bugs
Wat houden deze bugs in ?
Veel websites bieden de mogelijkheid om plaatjes te uploaden. Hier zitten natuurlijk checks in gebouwd die controlleren of je wel een plaatje upload. En laat php nou net een aantal bugs hebben met betrekking tot het uploaden van bestanden, waardoor een hacker een phpshell kan uploaden op de website en volledige controle heeft over de website. Exploits zoals de nullbyte worden veelvuldig gebruikt door beginnende hackers (scriptkiddy's) omdat deze simpel zijn maar wel de mogelijkheid geven om volledige controle over een website te krijgen.Ze zoeken vaak zelfs google af en testen willekeurig gewoon elke website met fotoupload die ze tegenkomen.En deze scriptkiddy's zullen je website niet misbruiken of gegevens stelen maar ze verwijderen de gehele website en het enigste wat je dan nog kunt lezen op je website is : Hacked By.
Poison Null Byte: (nullbyte exploit).
PHP breekt vaak een string af zodra hij NULL vind wat dus beter bekend staat als de nullbyte. PHP leest de nullbyte als /0 maar om iets te exploiten of in urls gebruik je hem als %00.Bijvoorbeeld ga maar eens naar de volgende url:
http://www.google.nl/search?hl=nl&q=lachen%dit
En je zult zien dat 'dit' op het eind wordt weg gelaten en en er alleen 'lachen' staat in het zoekveld. Wat dus inhoud dat het script hetgene achter %00 niet meer leest. En hier maken hackers in de naam van bestanden misbruik van. Ze slaan een phpshell op als "c99.php%00.jpg" en uploaden deze vervolgens via de foto upload.
PHP upload nu c99.php omdat het ophoud met lezen na de %00 byte en dus .jpg gewoon weg niet leest.
Maar de server ziet alleen .jpg exentensie en denkt dus dat het om een plaatje gaat en staat het uploaden ervan gewoon toe. En heeft de hacker zo op een vrij simpele manier een PHPshell op je website geplaatst.En neemt de controle over.
Upload VS HTTP post requests
Bij een foto upload zit bijna altijd een HTML formuliertje waarmee je de plaatjes kunt uploaden.Deze formulier verstuurd de foto's doormiddel van een HTTP post request aan de server door. Deze requests bevatten een deel van de informatie over het bestand. En als de hacker nu zelf via een PERL script deze http post requests verzend kan hij zelf die informatie invullen die anders door de html wordt verstuurd. En een hacker die zelf gegevens kan invullen dat werkt niet zovaak gunstig.
de script(PHP):
-------------------------------------------------------------------------------------------
--------------------------------
if($_FILES['userfile']['type'] != "image/gif") { // controlleert of het een gif bestand is
echo "Sorry, we accepteren alleen gif bestanden";
exit;
}
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {
echo "Bestand is geupload.\n";
} else {
echo "Dit bestands type is niet toegestaan.\n";
}
Probeert de hacker nu een een php bestand up te loaden weergeeft het script netjes dat het hier niet om een plaatje gaat.
Hoe misbruiken hackers deze bug ?
Door via een perl script zelf de post request headers te bepalen waarmee de hacker macht krijgt over de informatie die de server ontvangt. Dit is dus ook de informatie over het bestand zelf
een perl script om HTTP post requests te versturen ziet er zo uit:
-------------------------------------------------------------------------------------------
--------------------
#!/usr/bin/perl
use LWP;
use HTTP::Request::Common;
$ua = $ua = LWP::UserAgent->new; # de useragent is een HTTP client
$res = $ua->request(POST 'http://onveiligewebsite.nl/upload.php', # POST request
Content_Type => 'form-data', # de content type is
],
);
print $res->as_string(); # weergeeft de reponse van de website
-------------------------------------------------------------------------------------------
--------------------------------
Dit script upload het plaatje "plaatje.gif" naar het php bestand "upload.php". En weergeeft vervolgens het bericht : Bestand is geupload . Zou je nu bij userfile "shell.php" invullen dan krijg je te zien dat het bestands type niet is toegestaan. Omdat de content type niet langer meer GIF is. Maar omdat de hacker zelf de HTTP post request verstuurd kan hij natuurlijk zelf ook instellen welk content type het bestand heeft. Dit doet hij door het volgende te veranderen.
Deze regel : userfile => ["plaatje.gif"],
wordt veranderd in : userfile => ["shell.php", "shell.php","Content-Type" => "image/gif"],
Doordat de hacker aangeeft dat het bestand content type image/gif heeft zal het php bestand netjes de phpshell uploaden en zo de hacker controle over de website geven,
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {
echo "Het bestand is geupload.\n";
} else {
echo "Dit bestands type is niet toegestaan.\n";
}
Inplaats van te vertrouwen op de content type van het bestand, controlleert dit script daadwerkelijk het bestand zelf op de content type. De functie verantwoordelijk hiervoor is getimagesize. Als de hacker nu probeert het content type in te stellen zal het script netjes "dit bestands type is niet toegestaan" weergeven en wordt het bestand niet geupload omdat het script ook de daadwerkelijke het bestand controlleert op zijn content type en of het een geldig foto bestand is. Je zou zeggen nu is het veilig...maar dat is niet zo :). Het is mogelijk een php code toe te voegen aan de comments van een plaatje met programma's die dat ondersteunen zoals GIMP. De hacker voegt nu de phpshell toe aan de comments van het plaatje. En nu veranderd hij het volgende aan zijn PERL script.
Deze regel : userfile => ["shell.php", "shell.php","Content-Type" => "image/gif"],
Veranderd in : userfile => ["shell.gif", "shell.php","Content-Type" => "image/gif"],
De eerste paramter van userfile is het bestand, met de tweede parameter wordt aangegeven wat de naam wordt en hier stelt de hacker shell.php in. Nu zal doordat de hacker de http request heeft aangepast de uploadscript netjes shell.gif als shell.php opslaan.En door de php code in de comments te zetten gaat het om een geldig plaatje waarmee de hacker voorbij de MIME check komt. Opent de hacker nu het php bestand ziet de hacker eerst wat onduidelijk tekens gevolgd door de PHPshell en heeft hij wederom volledige controle. Dit omdat PHP simpel weg de php code vind in de comments van het plaatje en die vervolgens uitvoert.
Oplossing.
Laat voordat de rest van het inlog script verder gaat eerst controlleren op php extencie's op deze manier wordt elke poging om een php bestand te uploaden geblokkeerd.
En om het geheel nog veiliger te maken verander je de naam van elke geuploade bestand en sla je de foto's buiten de webroot op en de locatie van de foto sla je op in je database. Vervolgens laat je een php bestand de foto weergeven. Voorbeeld staat hieronder.
SQL Injection
En als laatste en samen met XSS de meeste voorkomende bug in websites. SQL injection.Bij deze bug word een variabelen niet goed gecontrolleerd en rechtstreeks in de sql statement verwerkt. Met andere woorden een hacker kan SQL commands invoegen die worden uitgevoerd. Dat is als een kerstkadootje voor een hacker en maakt zijn hele dag gelijk goed.
De script pakt de ID nummer uit de URL weg doormiddel van de get. En vervolgens haalt het script alle gegevens op die overeenkomen met de id nummer.
de hacker gaat vervolgens zelf de waarde aangeven van ID in de url balk.En gaat ervan uit dat de admin/beheerder acount nummer 1 heeft(id 1). Dus gaat hij een SQL command invoegen waardoor hij de wachtwoord gegevens van de beheerder steelt. Hierbij gebruikt hij de sql command UNION hiermee scheid je sql commands waardoor je meerdere sql commands kunt uitvoeren.
de url wordt nu :
members.php?id={99999999 UNION SELECT gebruiker,wachtwoord,id FROM users WHERE id = 1;-- }
de sql is nu
SELECT naam, avatar, signature,email FROM members WHERE id = 666666
UNION
SELECT gebruiker, wachtwoord, id FROM gebruikers WHERE id = 1
in de tweede SQL vraagt de hacker de ''gebruiker'''+ ''wachtwoord" op van ID 1. wat doorgaans dus het acount is van de beheerder en met het streepje - negeert de hacker de rest van de sql die mogelijk aanwezig is.Dus de hacker heeft vervolgens de login details. In praktijk zal de hacker veel testen,testen,testen om erachter te komen welke tabels en columns hij moet opvragen maar vaak gaat dit ook automatisch door scripts. De hacker zal vervolgens een script maken die automatisch je hele database aan login gegevens leeg trekt.Vervolgens voegt hij die lijst toe aan een programma die hun wachtwoord die ze gebruiken op de website controlleert op hun email adres.Dus in minder dan een paar uur is niet alleen de website gehackt maar ook veel email adressen van gebruikers van de website.En om het af te maken verkoopt de hacker ook nog eens alle email adressen aan een spamboer en alle andere gegevens die geld waard zijn.
oplossing:
mysql_real_escape_string. Haal alle variabelen die door de gebruiker kunnen worden ingevuld of via de url aanpasbaar zijn door deze string heen.Voordat je hem gebruikt in een query.
En bij id nummers kun je de php functie is_numeric gebruiken om te controlleren of het daadwerkelijk om een getal gaat.
if(is_numeric($id)
{
code hier
}
Een andere erg handige optie is het aanzetten van "magic quotes". Dit voorkomt SQL injection automatisch.Maar maar vertrouw hier nooit blind hieronder een voorbeeld :
-------------------------------------------------------------------------------------------
-
function checkmagicquotes()
{
if(get_magic_quotes_gpc()) // checkt of magic quotes aanstaat
{
return true;
} else { return false; }
}
if(checkmagicquotes() == false) // Als magic quotes uitstaat dan
{
$titel = mysql_real_escape_string($_POST[''titel'']); // escape titel
}
nu controlleert de functie "checkmagicquotes" eerst of magicquotes aanstaat is dit het geval dan geeft functie : true terug. Is de functie false dan zal doormiddel van de IF statement de waarde door mysql_real_escape_string worden gehaald.
Rechten
Zorg gewoon niet dat de gebruiker teveel rechten heeft. Zo beperk je de schade die een hacker kan aanrichten in t geval van een sql injection.