Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
SQL injection
Beste forum leden.
Ik heb al enige tijd een eigen website. Echter besteed ik pas recent aandacht aan de beveiliging ervan.
Nu heb ik al enige tutorials voor SQL en XSS injections door genomen.
Alleen is het probleem dat ik het begin niet haal. In mij browser balk kom ik nooit op een .php pagina uit. enkel op deze pagina's( voorbeeld) /2012/09/06/about/ en alleen maar van dat soort link. Hoe moet ik nu verder? Hoe kan ik een .php pagina opsporen?
Ik besteed nu alleen aandacht aan SQL en XSS injection maar waar moet ik nog meer opletten?
groeten
Brebent
Ik heb al enige tijd een eigen website. Echter besteed ik pas recent aandacht aan de beveiliging ervan.
Nu heb ik al enige tutorials voor SQL en XSS injections door genomen.
Alleen is het probleem dat ik het begin niet haal. In mij browser balk kom ik nooit op een .php pagina uit. enkel op deze pagina's( voorbeeld) /2012/09/06/about/ en alleen maar van dat soort link. Hoe moet ik nu verder? Hoe kan ik een .php pagina opsporen?
Ik besteed nu alleen aandacht aan SQL en XSS injection maar waar moet ik nog meer opletten?
groeten
Brebent
Reacties (9)
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?
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 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.
24-09-2012, 17:02 door
Security Scene Team
Ik snap best dat iemand die eens wil kijken hoe dat eventueel kwetsbaar zou zijn niet weet
waar te beginnen.
waar te beginnen.
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.
24-09-2012, 17:24 door
Security Scene Team
Door Anoniem:
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.
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.
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!
25-09-2012, 10:25 door
Brebent
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.
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.
25-09-2012, 10:28 door
regenpijp
Door Brebent: 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.
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.
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.
zet een ' achter die 12 en kijk eens naar je resultaat.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?