Inderdaad, je zit op de goede weg. Je gebruikt ' om in SQL uit een string te breken. Vervolgens kun je in SQL de query aanpassen, maar op het einde krijg je dan toch de ' die het normale einde van de invoer-string aangeeft. het # zorgt ervoor dat alles na het hekje als comment wordt gezien. Hiermee voorkom je dat de query kapot gaat op de ' aan het einde van de string.
dus normaal
SELECT username, password FROM users WHERE username = 'admin'
en met injection
SELECT username, password FROM users WHERE username = ' ' OR 1=1 #'

Volgens mij klopt het vetgemaakte stukje niet. Zou volgens mij zonder quotes moeten.

See: https://stackoverflow.com/questions/52134712/sql-injection-what-is-the-difference-between-or-1-1-and-or-1-1

Je vraag doet vermoeden dat je je afvraagt hoe SQL-injectie werkt zonder dat je onder de knie hebt hoe SQL eigenlijk werkt.

Mijn advies is daarom om te beginnen basale SQL-kennis op te doen, zodat je weet hoe je een tabel definiert, er records aan toevoegt en hoe je basale queries doet, en dat allemaal via SQL-statements weet te doen. Doe dus kennis op over de syntax van SQL en wat voor effecten de verschillende statements hebben. Verdiep je dan ook in hoe in SQL-statements commentaar kan worden opgenomen. Als je daar een begin van onder de knie hebt denk ik dat vanzelf duidelijk wordt hoe SQL-injectie eigenlijk werkt en wat die tekens doen. Als je het overslaat kunnen mensen proberen je het uit te leggen, maar mis je de basis om die uitleg te begrijpen.

Het #-teken doet vermoeden dat je vraag over het SQL-dialect van MySQL gaat, omdat # daar gebruikt wordt om de rest van de regel als commentaar te zien (in standaard-SQL gebeurt dat niet met # maar met --). MySQL is gratis en heeft een commandline-interface waarin je kan oefenen met SQL-statements om tabellen te creëren, er gegevens aan toe te voegen en er queries op los te laten.

Extreem simpel te gebruiken is het (ook gratis) SQLite3, niet bedoeld als centraal systeem dat door vele programma's wordt gebruikt maar om in programma's in te bedden. Firefox gebruikt het bijvoorbeeld om browsegeschiedenis, wachtwoorden en nog veel meer in bij te houden. Dat kan je gebruiken zonder enige setup, een database is een enkel bestand op een plek waar het jou uitkomt, of kan zelfs alleen in geheugen bestaan (wat dan natuurlijk niet bewaard wordt). Ook SQLite3 heeft een commandline-interface.

Als je kan programmeren kan je dit vanuit programma's doen, en kom je al wat realistischer naspelen wat er met SQL-injectie gebeurt én hoe je dat kan voorkomen. SQLite3-ondersteuning zit in de standaardbibliotheek van Python, je hoeft niets extra te installeren of te configureren om het te kunnen gebruiken.

Doe dat soort dingen. Ergens mee spelen, en zo zelf een beetje op onderzoek uitgaan, is enorm behulpzaam bij het leren begrijpen van dingen. Ik vermoed dat je de vraag die je stelt nooit had hoeven te stellen als je er zelf mee had gespeeld.

Zo kun je ook vanuit de DOm code speuren naar DOM-XSS kwetsbaarheden, als bijvoorbeeld deze:
en dit dan gaan uitpuzzelen naar diverse soort sources en sinks (hier een HTML Element Sink voorbeeld)

luntrus

Dank voor de reacties. Ik ben hier erg mee geholpen.

Interessant met beperkte middelen te vinden in de developer console (shift ctrl I):

#sockpuppet

Jullie (of je?) hebben het over een volkomen ander onderwerp dan de vraagsteller. Je kan ook een eigen topic starten voor het onderwerp waarover je het wilt hebben.

@ de gewaardeerde anoniem van 18:29,

Ik begrijp dat volkomen en terecht ook dat je die wrevel uit en ik zal ook wel eens een topic starten over m.n. DOM-XSS.
Ik wilde hier alleen maar aangeven hoe of men binnen de developer console met behulp van bepaalde extensies
veel info boven water kan krijgen.

De makke is op het moment, dat Google bepaalde user scripts en extensies weert.
Ook veel online scanners bijvoorbeeld, zoals die van geeksta voor DOM-XSS bijvoorbeeld, zijn gediscontinueerd,
vanwege kosten voor server onderhoud en om andere redenen. Men doet het meestal ook niet voor de kat z'n viool.

Binnen een browser kun je geen potentieel kwaadaardige sites benaderen.
Dt moet op een stand-alone machine zonder Internet-connectie.
Of bijvoorbeeld in een VM browser als bijvoorbeeld Malzilla van Bobby.

Het ging mij dus om algemene procedures en dat niet direct gerelateerd aan een bepaalde kwetsbaarheid als SQL etc.

Maar nogmaals gezegd vrije info garing ook voor de error-hunter wordt steeds schraler verkrijgbaar.
Men sluit ons op in info en geprefereerde info bubbels.
We dienen wellicht met z'n allen te "verdommelijken" van Big IT en consorten.
Geen belang bij slimmerikjes? Too smart for your shoes and bad for business by the few and wealthy?

luntrus

Tip voor html ontwikkelaars: Als je alle variabelen die in een SQL statement eerst door een filter-routine haalt waarbij je alle ongewenste karakters vervangt door een procent-teken dan beschermt dat effectief goed tegen SQL injectie, bovendien heeft het dan vrrijwel geen impact op variabelen die iets in een database opzoeken (% is namelijk de SQL wildcard).
Neem in ieder geval de quootjes (enkel, dubbel) en de hash (#) in je filteer van ongewenste tekens mee. Ook een dubbel min-teken zou ik wegfilteren.

Tip voor jou: daar zijn geparameteriseerde queries voor.

Zou inderdaad prepared/parameterized statements hiervoor gebruiken.

Daarnaast klopt dat het weinig effect op de resultaten van een query heeft ook niet. Als je WHERE clausule er namelijk bijvoorbeeld zo uitziet:

WHERE username = '%Anoniem%'

Dan krijg je gewoon enkel de records terug waarin het veld username "%Anoniem%" bevat. Het procent teken wordt gewoon letterlijk opgevat, pas als je het sleutelwoord like gebruikt (dus WHERE username like '%Anoniem%') kun je een patroon met Wildcards opgeven. Maar om nou al je queries naar patronen te laten zoeken, terwijl je vaak gewoon een exacte match wil, puur omdat je niet aan de prepared statements wil...