In dit artikel staan veel hack methodes: http://h1.ripwa..._guide.pdf

Let wel op dat dit een oud artikel is (uit 2004), dus de methode om het te voorkomen kunnen vele malen beter.

Oef ty, had gehoopt dat het er minder zouden zijn xD

Ik ben geen specialist, maar ik dacht dat PDO ook al wat ingebouwde bescherming tegen SQL Injections had. Aangezien je toch met OOP gaat werken is PDO meteen ook het handigste denk ik om alle database-stuff mee te doen.

EDIT: sorry, verkeerd gelezen, dacht dat je wilde weten HOE 

@Dlol, PDO heeft inderdaad bij het gebruik van preparend statements ingebouwde bescherming tegen SQL injection. Ook heeft het zijn eigen real_escape_string() methode met de naam quote().

Wikipedia.org: Session fixation en Wikipedia.org: Cross-site Request Forgery worden ook vaak gebruikt. Wat je ook niet mag vergeten is de backend van je webapplicatie. Houdt je database en webserver software altijd up-to-date. Mocht je je verder willen verdiepen in dit onderwerp is het boek Hacking Exposed: Web Applications een aanrader. (De 3e editie welteverstaan, deze is vrij recent(oktober 2010)) http://www.webhackingexposed.com/

Hmm ok, ik heb al stuk of 5 beveiligingen geimplementeerd, maar kan altijd wel beter.

momenteel heb ik:
- Sql Injection
- XSS
- Kijken op waardes (int)
- Get Functie beveiligd
- max aantal inlog pogingen
- delay tussen inlog pogingen
- 10min ban bij meer dan 5 pogingen
- ini_sets goed gedaan

Waar ook je ook nog aandacht kan aan schenken bij de beveiliging van de authenticatie van je webapp is username enumeration: https://www.owa...umeration_(OWASP-AT-002)
Zeker als je een "wachtwoord vergeten" functie hebt mag je die zeker ook niet vergeten te beveiligen hiertegen.

Geef bij fouten ook nooit teveel informatie. Als de gebruikersnaam fout is zeg dan niet 'gebruikersnaam is fout' maar 'gebruikersnaam of wachtwoord is fout', hetzelfde voor als het wachtwoord fout is. Hierdoor kan de spammer er minder snel achter komen welke fout is en welke goed.

@Waldio
Mogelijk een beveiligings idee, maar is het niet dat dit naarmate de client kan gaan irriteren?

@NTS64
Ik zal deze Pdf even bekijken.

Naast de hierboven bestaande technieken en aandachtspunten, kun je de stelregel "filter input, escape output" ter harte nemen. Deze zal je hoogstwaarschijnlijk nog vaak tegenkomen.

Daarnaast kunnen alle toegepaste technieken je website of -applicatie nog zo veilig maken, de gebruiker is daardoor nog niet geheel onkwetsbaar geworden. Stel bijvoorbeeld dat een gebruiker op een netwerk zit waar nog alles gebroadcast wordt, mocht een wachtwoord dan dus onversleuteld verstuurd worden kan deze nog steeds opgevangen worden. Je zou met JavaScript dit soort gegevens kunnen hashen/encrypten voordat deze de deur uitgaan, of zelfs overwegen om alles via HTTPS te laten verlopen. Zo zou je nog een aantal zaken kunnen verzinnen die helemaal buiten (bovenstaande) standaard rijtjes vallen. Niets kan een applicatie trouwens beveiligen tegen slordig gebruik, je zou deze wel robuuster kunnen maken om op die manier eventuele schade zoveel mogelijk te beperken.

Deze site is waarschijnlijk wel interessant: PHP Security Guide (engels)