SQL injection kan ook gewoon in java. De programmeertaal maakt niet zoveel uit. Aks gebruikers input niet wordt gefilterd en het dus mogelijk is om een SQL commando uit te voeren is de website/programma vatbaar voor een sql injection.

Zelf kan ik je niet echt helpen ik ken geen java alleen een beetje php. Maar heb even stel dit voor je op google gevonden: https://www.owasp.org/index.php/Preventing_SQL_Injection_in_Java

Met java kan ik je niet helpen. Maar zoals in php geld controleer de input. Je verwacht nummer bij gebruikersnaam dus weiger alles wat geen nummer is. Als wachtwoord kan je bijvoorbeeld alleen cijfers en letters toestaan. Op deze manier is bij me weten sql injection niet meer mogelijk. Omdat bijvoorbeeld admin' OR '1'='1 meer mogelijk is.

Voor de rest moeten echt andere je helpen.

Een programmeer taal met een fatsoenlijke "prepared statement" interface naar SQL biedt geen mogelijkheid voor SQL injection.
SQL injection heb je alleen bij rotzooi zoals de mysql_ functies in PHP waarbij de SQL queries worden opgebouwd door stukjes SQL statement en user input aan elkaar te plakken tot een SQL statement.
Dat is niet meer van deze tijd, maar keer op keer halen mensen weer oude PHP boeken op de rommelmarkt en beginnen weer vrolijk een nieuw project op basis van die interface.
In Java ga je dit natuurlijk niet doen...

maakt je site uberhaupt gebruik van mysql? zo ja, dan is het mogelijk om sql injectie(s) uittevoeren.
je moet je scripts behoorlijk testen en controleren, er zijn tal van tools die kunnen testen of jou site kwetsbaar is of niet. bijvoorbeeld acunetix, of ironwasp google het maar.. houdt er wel bijvoorbaat rekening mee wanneer je een scanner gebruikt je kans hebt op false/positives.

verder mocht je je eigen inzicht niet vertrouwen, kun je altijd terug vallen op verschillende script firewalls enof server level firewall bijvoorbeeld http://configserver.com/cp/csf.html

mvg

Waarschuwing: mijn reactie is vrij LAAANG en technisch van aard, met allerlei termen die sommige mensen wel, en anderen niet kennen. Excuus. Ik kan niet ruiken wat je allemaal wel en niet weet. Vraag maar rustig. En voel je vooral niet dom als je iets niet snapt :)

Alleen als je een MySQL database gebruikt (om bijv. je gebruikersnamen en wachtwoorden op te slaan) ben je evt. gevoelig voor MySQL-injection. Dit is onafhankelijk van de taal die je gebruikt (in jouw geval Java). Er zijn ook andere database-systemen dan MySQL (o.a. Oracle, Postgres, Sybase, Firebird) met ook elk hun eigen zwaktes, maar aangezien MySQL een van de meest gebruikte DBMS'en op het web is, hoor je daar het vaakst over.

Er zijn meerdere test tools/suites om te kijken of je website bestand is tegen (veelgebruikte) MySQL-injectie aanvallen. Helaas vereisen die tools vaak wel behoorlijk wat technische kennis en vaardigheden. Als je site echt heel erg gevoelige informatie bevat kan het nuttig zijn iemand in te huren (of lief aankijken) die je site kan penetration-testen en de eventuele kwetsbaarheden kan verhelpen.

Ja dat kan. Om te beginnen kan (over het algemeen) iedereen die gebruik maakt van het netwerk waar je op zit met de juiste tools en vaardigheden die gegevens afluisteren en mogelijk misbruiken. Google maar naar het woord "wireshark" en/of "ettercap". Ik ga je helaas niet uitleggen hoe dat werkt, dat gaat me wat ver :)

------------------------------------------------------------------------------------------------------------------

Ik heb zo goed als geen ervaring met Java, dus ik weet niet in hoeverre Java je standaard beschermt tegen dit soort aanvallen.

Een aantal van mijn persoonlijke adviezen zijn in elk geval:

*) Gebruik altijd HTTPS (SSL/TLS) voor je gehele website, dus niet alleen voor de login procedure, maar voor elke byte die over wordt gestuurd. Als je het geld ervoor (over) hebt kun je ook een SSL/TLS-certificaat kopen bij een betrouwbare partij (CA) die ervoor zorgt dat gebruikers/klanten makkelijker zeker kunnen zijn dat de HTTPS-verbinding niet is gecompromitteerd, i.a.w. dat ze met jouw site communiceren, en zonder afluisteraars ertussen. Maarja, dat is vaak niet goedkoop en wordt vooral gebruikt door banken en overheden.

*) Versleutel/hash voordat je het wachtwoord verstuurt in je login-formulier het wachtwoord, bij voorkeur met een CPU-intensieve methode als bcrypt zodat aanvallers veel meer rekenkracht nodig hebben om de boel te kraken. Er zijn JavaScript libraries die je hiervoor kunt gebruiken. Op deze manier blijft je wachtwoord redelijk veilig, ook als je HTTPS-verbinding is gecompromitteerd, wat vooral op publieke/untrusted netwerken nogal eens voorkomt (vliegveld, McDonalds, camping wifi, hotels, pompstations noem maar op).

*) Als je wachtwoorden encrypted/hashed opslaat in een database (al dan niet MySQL), salt ze. Ik kan niet in een paar woorden uitleggen waarom en hoe en wat, dus dat zul je moeten Googlen als je nog niet weet wat dat is.

*) Houd er rekening mee dat hoe veilig jij je gegevens en programmeercode ook behandelt, jij geen invloed hebt op een eventuele hack van de server waar alles is gehost (zelfs je eigen server zou kunnen worden gehacked, je weet maar nooit). In een database bankrekeningnummers met bijbehorende pincodes opslaan is dus wat dat betreft vragen om problemen (en rechtzaken, hehe).

*) Pas (mits praktisch haalbaar) IP-restrictie toe, oftewel dat slechts bekende hosts verbinding mogen maken met de website. Dit is niet praktisch als de website voortdurend vanaf verschillende plekken (IP's) beschikbaar moet zijn.

*) Als je een database gebruikt (zoals MySQL), zorg ervoor dat die niet direct van buitenaf benaderbaar is. Vaak draait de database op dezelfde machine als de website en is directe toegang van buitenaf onnodig en potentieel desastreus. Bij veel externe hosters is dit al standaard voor je afgeschermd, maar even controleren kan natuurlijk geen kwaad (meten is weten).

*) Als je een database gebruikt, zorg er dan voor dat je website slechts de rechten krijgt die het nodig heeft en gebruik die login niet voor andere sites (dus per site een eigen db-login). Ik zie regelmatig websites die met root login de database gebruiken. Dat is oliedom. Mocht een aanvaller dan 1 gedeelte van je database compromitteren, dan kan hij ook direct OVERAL bij. Dit laatste is vooral van toepassing als je je database voor verscheidene sites gebruikt die dus allemaal dezelfde login gebruiken.

*) Controleer (en sanitize, escape, hoe je het ook noemt) automatisch elke vorm van invoer van de gebruiker, vooral als die invoer wordt gebruikt om database-queries mee te vormen. Hier gaat het vaak fout bij SQL-injectie. Een veelgebruikt voorbeeld: tekens als ; (puntkomma) kunnen een SQL-query termineren, zodat een aanvaller erachter nieuwe queries kan uitvoeren, zoals bijv. het opvragen van de tabel met inloggegevens. Dat is 1 van de vele (en zeer veel gebruikte) voorbeelden.

Maar nu wordt het verhaal iets te technisch denk ik (en lang).

Als je goed Engels kunt lezen kan ik je absoluut deze site aanraden: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
Echt de moeite waard als je wil leren hoe je veilige websites maakt. Verder kun je Googlen naar "preventing MySQL injection" (link: https://www.google.com/search?q=preventing+sql+injection )

Maarja nogmaals, dat is allemaal in het Engels en dat is niet altijd even simpel te begrijpen, alleen is er in het Nederlands helaas niet zo verschrikkelijk veel over te vinden ;)


Succes ermee in elk geval!
Groetjes

ernie

@Ernie;

Dank voor je heldere manier van uitlegen.
Zo zouden dat meer mensen moeten doen.


+1 voor je.

[quoteEr zijn JavaScript libraries die je hiervoor kunt gebruiken.[/quote]Gaan we weer: JAVASCRIPT !== JAVA!!! Verder prima uitgelegd.

JavaScript en Java zijn niet het zelfde.

Java ondersteund BCrypt al standaard.
http://stackoverflow.com/questions/277044/do-i-need-to-store-the-salt-with-bcrypt
http://www.mindrot.org/files/jBCrypt/jBCrypt-0.2-doc/
http://sziebert.net/posts/using-bcrypt-with-spring-security/

@Anoniem 21.27
Jammer dat je anonem reageert. Ik krijg je bericht nu pas om 9.51 uur binnen.
Maar je opmerking valt me op;

"Een programmeer taal met een fatsoenlijke "prepared statement""

Noem voor mijn beeldvorming een programmeer taal met een fatsoenlijke "prepared statement"?
En beschrijf wat uitgebreider waar het daarin om gaat en hoe dat gerealiseerd wordt?

Ik gebruik dit zelf nog wel eens in Perl (DBI module) maar ik begrijp dat het ook in PHP kan (mysqli_xxx).
Het essentiele punt is dit: je bakt de SQL query niet dynamisch aan elkaar uit losse stringvariabelen, dus niet:

$query = "SELECT user from users WHERE username = '".$username."'";
mysql_query($query,$db);

In plaats daarvan gebruik je zo iets:

$sth = $dbh->prepare("SELECT user from users WHERE username = ?");
$rc = $sth->execute($username);

De parameter van execute wordt in het SQL statement ingevoerd op de plaats van de ?.
Maar niet door die erin te plakken, de SQL engine weet echt waar die mee bezig is en gaat geen rare
dingen doen als $username bijvoorbeeld "'; drop table users; '" is ofzo.
Dan gaat ie gewoon de user met die naam matchen, geen drop table doen.

Het is ook nog eens efficienter want de prepare kun je buiten een loop houden en in een loop meerdere
keren aanroepen met verschillende parameters. Het SQL statement hoeft dan maar 1 keer geparsed te worden.

Dan heb je me denk ik verkeerd begrepen. Ik zei:
Mijn bedoeling is om client-side (in de browser dus) m.b.v. JavaScript de bcrypt versleuteling uit te voeren ( met bijv: https://code.google.com/p/javascript-bcrypt/ ), zodat je niet voor zoiets triviaals 'untrusted' Java code in je browser moet draaien.

Het zou toch van de zotte zijn om van een website-bezoeker te vereisen dat hij/zij een Java Runtime Environment heeft geïnstalleerd en in de browser ingeschakeld (hallo, 0-days), puur en alleen voor de inlogprocedure van 1 site ;P

P.S. Ik heb niks tegen Java an sich, het is alleen die "sandbox" waarin ik de hoop definitief heb opgegeven. Maar volgens mij ben ik daarin niet de enige...

Wat mij nou nog steeds niet duidelijk is, is of de website iets van een RDBMS er achter heeft, al dan niet MySQL of sqlite of zo? De nogal beperkte omschrijving van de topicstarter maakt dat niet duidelijk helaas.

@Gisteren,10:55 doorAnoniem..
Dank voor je uitleg.

Klopt, is dé oplossing tegen SQL injection.

Totale onzin! SQL injection is een fout van de programmeur, niet van de taal. Het probleem van de mysql_-functies in PHP is dat deze zijn ontwikkeld in de periode dat MySQL helemaal géén ondersteuning had voor prepared statements. Het is een fout van MySQL, dat is gewoon een zeer beperkte database en daar heb je met iedere programmeertaal last van. Ook met Java zou je in die periode géén prepared statements op MySQL hebben kunnen uitvoeren, die optie bestond helemaal niet in MySQL. MySQL was (en is nog steeds) sterk af te raden wanneer je een veilige omgeving nodig hebt.

Ook in Java (en iedere andere programmeertaal) kun je een string gaan samenstellen die je later als een stuk SQL gaat uitvoeren. Is natuurlijk een blunder van heb ik jouw daar, maar heeft niks met de programmeertaal te maken. Het grootste veiligheidsprobleem zit achter het toetsenbord en dat geldt voor zowel de programmeur als de gebruiker.

"Mijn bedoeling is om client-side (in de browser dus) m.b.v. JavaScript de bcrypt versleuteling uit te voeren"
FACEPALM....

bcrypt vereist een salt en digit cost, als je een sleutel wilt maken voor vergelijken moet je die twee waardes hebben.
Je salt vrijgeven maakt bruteforcen nu wel erg makkelijk!! Helemaal als de gebruiker zo vrij is geweest om een makkelijk wachtwoord te gebruiken.

Dit is de reden waarom je bij een SQL INJECTIE MET DATA LEAKAGE, ALTIJD DE WACHTWOORDEN MOET VERANDEREN! Zelfs een beveiligde verbinding gaat je hier niet tegen beschermen.

Als iemand inlogt voert hij zijn gebruikersnaam in (makkelijk te raden) of e-mailadres (nog makkelijker), en daarna stuurt de server de salt terug en gebruiker (hacker) krijgt de salt en kan vervolgens leuk ze gang gaan. Het mooie effect dat bcrypt heeft op de snelheid word te niet gedaan omdat er 1 op 1 word vergeleken en de hacker niet veel moeite meer hoeft te doen omdat hij de salt immers al heeft.

Er zijn veel betere methode als rate limiting die een grote hoeveelheid data kunnen stoppen.
Dit is echt goed bedacht, maar maakt het probleem alleen maar erger.

Zolang een aanvaller de http(s) stream kan lezen, zal hij altijd de salt kunnen zien, daar doe je niets aan. Een salt heeft puur als functie dat de gebruikte hashes/tokens voortdurend verschillen, zodat o.a. grootschalige/makkelijke hacks moeilijker worden (bijv. dmv rainbow tables).