Het gaat er om dat er invoer (dus data van buitenaf) op d'een of d'andere manier in een sql query terecht kan komen, op zo'n manier dat'ie niet als data maar als onderdeel van (het instructiegedeelte van) de query gezien wordt.

Hoe, dat is om het even. Net zoals dat het om het even is hoe een phpscript bij de phpinterpreter terecht komt. Of er nu ergens .php of .joechei of helemaal niets van dat alles in de url staat, maakt niet uit. Zodra het opvragen van een url tot gevolg heeft dat er phpcode uitgevoerd wordt, moet je die code inspecteren op eventuele lekken. Vraag je dus bij elke stap af of en zo ja hoe er een mogelijkheid is dat "een aanvaller" de boel zo kan manipuleren dat er gebeurt wat hij wil. En dat kan in een heel klein hoekje zitten.

Het is toch jouw website? Dan weet je toch hoe die er "aan de achterkant" uitziet?

Het "hebben van een website" betekent tegenwoordig niet meer dat je ook weet hoe die van
binnen werkt, hoor.
Mensen downloaden en-masse kant en klare "cms" systemen en bijbehorende plugins en
templates en plakken dat allemaal in elkaar tot een website, zonder verder te weten hoe zo
iets werkt. Daarom is het voor inbrekers ook zo makkelijk om gaten te vinden, want ze
weten waar ze per gebruikt pakket moeten zoeken. Als het custom made code was dan was
dat niet zo simpel.

Ik snap best dat iemand die eens wil kijken hoe dat eventueel kwetsbaar zou zijn niet weet
waar te beginnen. Als ik zelf zo iets had zou ik dat ook niet weten, het is meestal allemaal
veel groter en ingewikkelder dan minimaal nodig, en daardoor erg veel werk om te onderzoeken.

Nouja, je hebt al gehoort van kant-en-klare website pakketten. dat scheelt een hoop want het is namelijk ook zo dat er gewoon vulnerability scanners. zowel in het donkere hoekje van het internet, als de normale kant van internet.
een voorbeeld hiervan is; acutnetix (google het maar)

verder, "custom-made" source-codes zijn ook niet moeilijk hoor, het draait allemaal om het zelfde.
als beginneling in dit soort dingen kan ik me eigenlijk wel voorstellen dat zij niet weten waar te beginnen, en dat is maar goed ook anders waren er veel meer skimmers/hackers bijvoorbeeld ;)
zolang jij goede kennis hebt van web programming o.a php dan kan je je zelf vaak wel redden met het inbreken op een php based site.

maar wat mij niet echt duidelijk is waar loop je vast?
p.s.
ik ga niet op verzoek via dit forum een pentest uitvoeren, omdat ik niet hard kan maken dat jij de echte site eigenaar bent.

daarom is het belangrijk om eerst de omgeving te verkennen, stel je zelf daarbij bepaalde vragen:

- word er apache gedraait of iets anders?
- welke applicaties draaien op welke poorten
- welke OS versie heeft de server
- welke php versie, en welke sql db etc.
- wat voor cms gebruiken ze,
- run eens een scan met acunetix, wat voor vulns geeft deze aan? en zijn dit false/positivies?
- zijn bepaalde codes wel juist sanitized?

op basis van deze informatie kun je bijvoorbeeld exploits aanelkaar koppelen om een hogerdoel te bereiken (root access bijv) of xss een java keylogger laten runnen.

denk als je tegenstander, als je weet hoe je erin komt weetje ook hoe of waar je iets moet patchen of fixen.

p.s. ik denk niet dat het verstandig is mensen te vragen om een pentest uit te voeren, omdat niemand hard kan maken dat jij de echte site owner bent die je zegt dat je bent. mocht dit niet zo zijn, en de site word gehackt d.m.v. aanwijzingen van hier, zijn wij strafbaar.

Maarja, je een beetje op weg helpen om je site te leren kennen en beveiligen kan nooit geen kwaad.


ik zou je aanraden om je zelf een account te geven met alleen rechten zoals members die hebben op bijvoorbeeld jouw forum of site. probeer je zelf dan neer te zetten in de rol van een kwaadwillende gebruiker.

Succes!

Bedankt voor de reacties

Het is juist de bedoeling dat ik het zelf doe. Omdat ik hier meer vanaf wil weten.
Als iemand nog een goede handleiding heeft hoort ik het graag.

http://websec.ca/kb/sql_injection
Daar staat redelijk wat informatie in :)

is er ook software om de bestanden (.php) op website te zoeken? Op mijn website staat alleen /overige/archief/ .
Ik zie nooit een .php bestand verschijnen. ik vraag me dan ook af hoe een "hacker"dit doet.

Gewoon je parameters testen, dus iets als view/page/id/12 <- de 12 zou een mogelijke SQL Injection plek kunnen zijn.

zet een ' achter die 12 en kijk eens naar je resultaat.

Veel gebeurt tegenwoordig ook op de achtergrond (AJAX)
Tamper data(firefox plugin) is erg makelijk om deze requests af te vangen en aan te kunnen passen alvorens deze worden verstuurd

Greetingz,
Jacco