Een anti MySQL beveiliging? Dus geen MySQL beveiliging, maar een anti beveiliging? Voor ze ver ik weet heeft htaccess niks te maken met MySQL of andersom.

Ik ken hier niks van, maar heb wel gevonden op internet dat dit mogelijk is.
Kijk anders hier eens naar:
https://secure.rivalhost.com/knowledgebase/…ther-hacks.html

Je kan htaccess zo instellen in combinatie met mod security om bepaalde veel voorkomende hacker commando's af te blokken.

Bv: niet toestaan dat een url met ?p=ietsheel_heel_heel_lang
of
?p=' OR 1=1
kan worden geladen.

Maar is geen 100% waterdichte beveiliging.
Htaccess is enkel een additionele laag.

In dit geval ga ik het topic toch niet sluiten, aangezien beveiliging belangrijk is en er mogelijk nog andere goede oplossingen komen.

Zoals K.Rens al zei is het vooral een extrz laag beveiliging, met als focus de GET parameters. Echter moet je ook nog rekening houden met je POST parameters.

Als SQL-injection preventie je intresseerd, kijk je best eens naar de OWASP website (SQL Injection Prevention Cheat Sheet - OWASP)

Nee, je kunt hooguit wat muren opwerpen, maar het is een slecht idee. Als je software schrijft, dan moet je erop vertrouwen dat je software waterdicht is, en niet dat de middleware die ervoor staat allerlei gekke trucjes uit haalt om je software uit de wind te houden.

Mijn advies zal dan ook zijn: Leer wat de mogelijke security issues zijn in je software. Leer op deze manier de software hiertegen te beveiligen, maar leer vooral ook te testen of de software veilig is. Met andere woorden: Hack je eigen software.

Er is niemand die meer verstand van jouw software heeft dan jij zelf. Dus als je genoeg kennis in huis hebt of haalt, waarom zou dan iemand een lek vinden in je software?

Het idee is natuurlijk aardig, maar ik denk niet dat .htaccess de plaats is waar je dit soort zaken moet oplossen.

Daarnaast is het voorbeeld .htaccess-bestand die in de link van matistop333 beschreven staat... één grote blacklist.

Het probleem van beveiligingen met blacklists is (ten minste :)) tweeledig:
- de gevallen die niet in de blacklist staan... worden doorgelaten, dus vergeet je een geval, dan ben je de sjaak
- het kan "false positives" opleveren, oftewel, een URL aanroep kan ten onrechte gemarkeerd worden als zijnde een "hackpoging"

Een "whitelist" is altijd beter: beschrijf enkel die gevallen die zijn toegestaan. En niet alle gevallen die niet zijn toegestaan (om eerder genoemde redenen).

Verder moet er altijd een zekere alertheid zijn bij het schrijven van code en queries, het lijkt mij onverstandig om er vanuit te gaan dat (in dit geval) .htaccess alle gevaarlijke gevallen eruitvist (te meer omdat het een blacklist betreft).

Als je PHP gebruikt om met een MySQL-database te communiceren zou je met MySQLi kunnen werken of met PDO.

Daarnaast zou je je invoer moeten filteren / valideren, en je uitvoer moeten escapen. Als je deze stelregel altijd in je achterhoofd houdt (filter input, escape output) dan kom je al een heel eind.

Je moet het zo zien: een query is meestal opgebouwd uit vaste stukken SQL en variabele stukken DATA (user input, die je nooit moet vertrouwen).

Iemand kan SQL injecteren als het variabele DATA-deel geinterpreteerd kan worden als SQL, je kunt in dat geval namelijk de werking van een query aanpassen.

Dit kun je enerzijds tegengaan door je input te filteren. Als je in $_GET['id'] een auto-increment id verwacht (EDIT: waarmee je een query bouwt) - controleer hier dan op! Als $_GET['id'] geen positief geheel getal bevat
hoef (en zou je) de query niet eens uit (moeten) voeren.

Daarnaast zou je je DATA in je query moeten ontdoen van haar speciale betekenis binnen SQL. Dit kan in MySQLi via de real_escape_string() functie en in PDO gebruik je prepared statements.

filter input, escape output beperkt zich trouwens niet tot MySQL alleen, maar is ook van toepassing op HTML (en zaken die je via PHP afdrukt in een HTML-document).

Citaat

Er is niemand die meer verstand van jouw software heeft dan jij zelf. Dus als je genoeg kennis in huis hebt of haalt, waarom zou dan iemand een lek vinden in je software?

Omdat je vaak vastgeroest bent in je eigen denkpatroon, is het juist verstandiger om iemand anders je software te laten testen. Een buitenstaander verzint mogelijk sneller dingen waar je nooit aan hebt gedacht. Ik neem ook aan dat je dit moment wilt voor zijn :).