Ivanti waarschuwt voor ernstig lek waarmee hackers EPM-machines kunnen overnemen

Ivanti waarschuwt gebruikers van zijn Endpoint Management-dienst voor een ernstige kwetsbaarheid waarmee het mogelijk was om op afstand een machine over te nemen zonder authenticatie. Inmiddels is er een patch uit voor de bug.

Ivanti trackt de bug als CVE-2023-39336. Die krijgt een CVSS-score van 9,6. Het bedrijf zegt in een blogpost dat het geen aanwijzingen heeft dat klanten door de bug zijn getroffen, maar raadt klanten wel aan hun software bij te werken. Een patch voor de bug is meegestuurd in Ivanti EPM 2022 Service Update 5.

Voor een succesvolle aanval moet een aanvaller eerst toegang hebben tot een intern netwerk. Zodra die toegang er is, kan de aanvaller via een niet verder beschreven SQL-injectie nieuwe SQL-query's uitvoeren. Zo is het bijvoorbeeld mogelijk om data van een server uit te filteren.

Met die commando's zou het ook mogelijk zijn om apparaten waar Ivanti's Endpoint Manager-software op draaide, over te nemen. Als de coreserver SQL had ingeschakeld, kon een aanvaller ook die server overnemen. Volgens Ivanti was het mogelijk die acties uit te voeren zonder dat er verdere gebruikersauthenticatie nodig was.

Het is de tweede keer in relatief korte tijd dat Ivanti in het nieuws komt vanwege een ernstige kwetsbaarheid. Dat gebeurde ook in juli vorig jaar. Toen bleek dat systemen van de Noorse overheid waren gehackt door middel van een zeroday in Ivanti's mobiele EPM. Ook daarbij was het mogelijk om een aanval zonder authenticatie uit te voeren.

Door Tijs Hofmans

Nieuwscoördinator

05-01-2024 • 14:58

52

Submitter: HKLM_

Reacties (52)

52
52
20
1
0
27
Wijzig sortering
Persoonlijk heb ik nu moeite om die CVSS scores nog serieus te namen, na het drama rond curl link. Hierbij worden leveranciers/maintainers vaak negatief door de security community in de media weggezet. Nu begrijp ik dat Ivanti dat wil verkomen dat ze negatieve pers krijgen. Maar ik vind 9.6 nogal hoog voor exploit waarbij eerst toegang tot interne netwerk nodig is. Ik kan meerdere dingen bedenken waarbij als ik toegang tot het interne netwerk meer gevolgen heeft, dan een management tool voor client devices.
Toegang tot een intern netwerk kan zo eenvoudig zijn als het plaatsen van een Raspberry Pi die een reverse tunnel opzet naar de aanvaller of gewoon een wifi SSID waar ingebroken wordt. Om nog maar te zwijgen over eigen medewerkers (zonder beheersrechten) die eventueel kwaad willen. Dat een product als deze (en vergis je niet over wat je allemaal voor kwaad kan aanrichten met "een management tool voor client devices") vervolgens voor een basale aanval als een SQL-injectie kwetsbaar is, is niet te verkopen. Als je beheer hebt over alle devices van een organisatie, dan is het uitschakelen van anti-virus en het vervolgens uitrollen van een backdoor natuurlijk kinderwerk.
De meeste ( ik ken geen organisaties die het volledige via een EPM regelen ) anti-virus hebben hun eigen management software. Ik kan je garanderen dat een van de manier waarop een backdoor direct word opgemerkt is het op (grote) schaal uitzetten van de anti-virus. Elke uitschakeling van de anti-virus wordt bij ons serieus onderzocht.
als je de tool die al je devices in bots kan laten veranderen kan hacken is dat natuurlijk een groot probleem.. een server hacken geeft je alleen toegang tot de services die daar op draaien.. maar EPM hacken potentieel tot alle devices op je netwerk, inclusief die servers.. dus ik snap die hoge score wel..
Toegang tot een netwerk is wel wat, maar niet veel. Een zwakke wifi, een niet afgesloten patchpunt, een geïnfecteerde client... allemaal genoeg om 'toegang tot het interne netwerk' te hebben.
Dan an je wel zeggen: beveilig de wifi, sluit het patchpunt af, beveilig je clients,... maar security doen we in laagjes. Dus ALS dat laagje sneuvelt, willen we andere security controls, zoals, bijvoorbeeld, veilige (gepatchte) software.
In die zin is dit een bijzonder belangrijke kwetsbaarheid!
Uitgangspunt voor een goed securitybeleid is dat de aanvaller al binnen is. In die zin is een hoge score zo gek nog niet.
Zero trust is populair en wellicht ook waar je zo veel mogelijk naartoe moet.
Maar dingen die je vanaf internet kan uitbuiten of waarvoor je eerst wel echt voorbij de perimeter firewall moet zijn dat heeft evengoed nog echt wel een radicaal andere aanvalsoppervlakte en ik ben ook wel van mening dat die scores dat adequaat moeten reflecteren anders gaan mensen die scores gewoon niet meer serieus nemen.

Boy who cried wolf.

[Reactie gewijzigd door Polderviking op 23 juli 2024 19:49]

Hoe relevant is een perimeter firewall in tijden van thuis werken? Elk device heeft in-principe wel een firewall, maar of je daarop moet vertrouwen ....
Deze moet je me even uitleggen ben ik bang, want het is me niet duidelijk waar je naartoe wil hiermee.
Dat ligt vaak aan implementatie. Bij veel fabrikanten zijn CVE's geweest met score van 9-10 afgelopen jaren, VMWare, f5, Citrix, Fortinet etc maar ging allemaal om de management interface. De management interface hoort niet aan het internet te hangen. Die hoort in afgeschermd vlan zodat alleen beheer via beheersystemen erbij kan. Maar dat onderscheid is niet te maken in de CVE score daar gaan ze uit van worst case.
En die worst case komt echt heel vaak voor.
Kan iemand mij vertellen wat EPM is?
Ja, als je de eerste zin van het artikel had gelezen had je gezien dat het om machines ging die gebruik maken van EndPointManagement van Ivanti.
Daar raakte ik ook niet veel wijzer uit. Ik kom hier ook graag om bij te leren. Een zinnetje bijkomende uitleg is handig. Dankzij een goed antwoord weet ik genoeg en heb ik weer iets bijgeleerd.
Epm is een systeem om in een grote organisatie al je computers centraal te beheren.

[Reactie gewijzigd door Pindakaasman op 23 juli 2024 19:49]

Een endpoint is het fysieke apparaat waarop een gebruiker verbindt met diensten/services.
Een laptop, thin client, smartphone is dus een endpoint als de gebruiker met bijvoorbeeld webmail of video conference verbinding heeft.
Bor Coördinator Frontpage Admins / FP Powermod @laserfreak5 januari 2024 15:03
Je zou dit kunnen bekijken: https://www.ivanti.com/products/endpoint-manager

One place to manage user profiles and all client devices – from Windows to macOS, Linux to Chrome OS, and beyond to IoT. With Day Zero support, have peace of mind knowing your device can be managed without any loss of management functionality or downtime.

[Reactie gewijzigd door Bor op 23 juli 2024 19:49]

Vertellen: EPM == End Point Manager
Uitleggen: Zie de computer die je nu gebruikt als een endpoint. Als die zakelijk aan jou is verstrekt, dan zou het zomaar kunnen dat die organisatie enige controle uitoefend op de configuratie van die computer. De Ivanti EPM is een stuk software dat daarvoor gebruikt kan worden. En dat gaat dan zo ver dat jij zelf mogelijk ongeveer niets meer kan en mag configureren, alleen maar gebruiken wat er op staat.
Endpoint Management ;)
Gemakt dient de mens, maar ik vind dit soort centrale management tools an sich een groot risico in een zeer interessante attack vector. De impact in geval van een incident kan dan ook enorm zijn als er een kwetsbaarheid in deze tool misbruikt wordt.
zowel een attach vector als een methode om je attach surface te verkleinen.. namelijk door alle endpoint op tijd te updaten..

Maar ja, als je EPM systeem zelf gehackt word dat heb je een probleem..
Je kan natuurlijk ook gewoon de ingebouwde MDM functionaliteit van Windows gebruiken. Hoef je geen extra gaten in je beveiliging te prikken en kan je ook je 'vloot' up to date houden.
De MDM functie van Windows doet niet aan patchen. Hooguit het instellen van Windows Update, maar dan update je alleen het OS.

Daarnaast moet je om die MDM te gebruiken eerst een pakket hebben als Epm, Intune, etc.
qua beheerbaarheid is dat minder makkelijk..
Maar als je MS functionaliteit will gebruiken zijn Intune en SCCM wel een optie natuurlijk https://www.ninjaone.com/...sccm-comparison-microsoft
Die MDM-functionaliteit creëert natuurlijk dezelfde "gaten" als een third party oplossing, uiteindelijk heb je ergens een beheer platform die ook gewoon vulnerable kan zijn.
Ik heb meer vertrouwen in functionaliteit die door de bouwer van het OS is toegevoegd dan dat derden hier nog een extra opening voor proberen te bouwen.
Bovendien minimaliseer je daarmee het aantal mogelijkheden om de configuratie over te nemen...
Ja kijk naar het hele Kaseya-debacle, of SolarWinds....
De imapct van het risico hiervan is inderdaad groot maar over het algemeen is de kans dat het risico optreedt veel kleiner dan als je zaken niet centraal managet.
Ivanti is toch die software die ervoor zorgt dat je na aanzetten van je computer nog even op je gemak naar de koffieautomaat kan, het weekend kunt bespreken met je collega, je lunchbestelling kunt doorgeven aan de kantinejuffrouw, nog een tweede bakkie kan halen en dan issie bijna klaar met opstarten als je terug achter je bureau zit?
Klopt, het is dan ook al 3 jaar niet doorontwikkelt nadat het product Workspace Control gekocht is door Ivanti. Ze geven dan ook zelf aan dat ze het niet meer zullen doorontwikkelen. Dat doet de performance ook geen goed. Ook is inrichting van het pakket, eigenlijk zoals bij alles, een grote factor. Het helaas zal een stille doorsterven.

Echter, het was wel erg handig in de tijd dat het nog door ontwikkelt werd om je Citrix omgeving gemakkelijk te beheren en veilig te maken. Jammer dat het niet meer wordt doorontwikkelt.
?? Ivanti Endpoint manager wordt nog steeds ontwikkeld alleen is men de focus aan het verleggen op Neurons hun cloud hosted management platform.
Klopt, evilution had het echter over de Workspace Control software en daar reageerde ik op.

Het klopt ook dat dit volledig los staat van het artikel maar ik vond het toch grappig om even te reageren, Ex uses, het is offtopic. :-)
Je bedoelt die beheerder die geen idee heeft hoe de software schedules te optimaliseren zodat het geen invloed heeft op het opstarten van je computer.
SQL injection, dat is wel behoorlijk jaren’90… 8)7
Staat ook nog steeds in de owasp top 10.
Vingers omhoog van iedereen in deze community die op <vul zelf maar iets heftigs in> durft te garanderen dat bij alles waar hij/zij mee bezig is immuun is voor SQL injection....
Je ziet het ook bij dingen als publieke datalekken en ransomware aanvallen.

Je kan je klok gelijk zetten op mensen die komen verklaren dat de beveiliging van een omgeving die ze nog nooit van dichtbij hebben gezien niet klopt en dat het bedrijf de grond in beboet moet worden. Of er bij het bedrijf zelfs mensen persoonlijk aansprakelijk gesteld moeten worden.

Iets over een wal en stuurlui.

[Reactie gewijzigd door Polderviking op 23 juli 2024 19:49]

Of er bij het bedrijf zelfs mensen persoonlijk aansprakelijk gesteld moeten worden.
Een "programmeur" die anno 2024 nog code schrijft die gevoelig is voor SQL injection, die hoort bij geen enkele organisatie te werken. Deze hoort in de schoolbanken te zitten. Zo'n "programmeur" is een gevaar voor de organisatie!

Gebruik van prepared statements of zelfs een ORM, hoe moeilijk kan het zijn?
Het gaat er meer om dat iedereen fouten kan maken en dat niet opeens minder waar is omdat je met computers werkt. En je sowieso niet op afstand kan zien hoe de fout tot stand is gekomen.

Een financiële administrateur die een keer geld de verkeerde kant op stuurt noem je toch ook niet gelijk incompetent.

Menselijkheid is compleet weg als het aankomt op fouten maken in de ICT sector.
Het gaat er meer om dat iedereen fouten kan maken en dat niet opeens minder waar is omdat je met computers werkt.
Ik ben de afgelopen 20 jaar nog niet tegengekomen dat dit een fout was. In alle gevallen wat het the-way-of-working, hoe men SQL gebruikte. Men wist niet beter, had in veel gevallen zelfs nog nooit van SQL injection gehoord of wist hoe het werkte. En dat is waarom ik verwijs naar de schoolbanken.

Je kunt mij een graafmachine laten besturen, dat kan best wel een tijdje goed gaan, maar het is wachten op ongelukken. Is dat dan een fout of is het gewoon dat ik niet gekwalificeerd ben?
Och, in de jaren 90 werd een medewerker van de administratie vaak admin gemaakt van het, toen populaire, Novell Netware netwerk. Meerdere keren meegemaakt. Even een korte training en hup, je bent netwerkbeheerder. Dit was uiteraard bij de kleinere mkb bedrijven, maar het gebeurde wel veel.

Dit zag je ook met website ontwikkeling. Degene die het leuk vond verdiepte zich in html en maakte de 'corporate website'. Die mensen hebben nooit formeel training gehad, maar lopen tegenwoordig wel rond in de professionele ICT business.

Het zal je overigens tegenvallen wat een mkb'tje betaalt voor een HBO'er met veel ervaring die tot de strot volzit met extra trainingen.

Als je het hebt over de financieele of energiesector, ja dan mag je verwachten dat een SQLi niet voorkomt door goede programmeurs (alhoewel die ook een maandagochtend hebben) en testen (unit, regressie, security etc) in een volwaardige OTAP omgeving.

Maar het merendeel van de bedrijven in NL hebben simpelweg het geld er niet voor en is het ook niet hun core business.

Edit: in een comment hierboven vermelde ik al dat SQLi nog steeds in de OWASP top 10 staat. Het is dus eerder regel dan uitzondering helaas.

[Reactie gewijzigd door j-phone op 23 juli 2024 19:49]

Is herkenbaar!

Maar we zouden dus ook kunnen stellen dat mensen persoonlijk verantwoordelijk kunnen worden gehouden voor dit soort lekkages. Mensen met opleiding zullen deze fouten niet snel maken en kunnen ook aantonen dat het een eenmalige fout is. Mensen zonder opleiding zullen dat niet/minder kunnen aantonen en gaan dan voor de bijl. Uiteraard is dan zowel de inhurende manager als de leidinggevende ook aansprakelijk, zij huren deze persoon in en controleren zijn/haar werk.

Een een bedrijfje waar de software uitsluitend intern wordt gebruikt, is het risico dan te overzien. Ga je echter de software (als dienst) verkopen, verandert het risicoprofiel.

Ik ken overigens MKB bedrijven met enorme data sets van een groot deel van de samenleving. Denk in Nederland aan telco's die hun data delen met marketingbedrijven die voor hen klanten benaderen. Zo'n MKB-er is een high risk, ook wanneer de software alleen (kuch) intern wordt gebruikt.
Helaas geldt dit niet alleen voor het MKB. Kennis van security in een development organisatie is zeer specialistisch werk. Een extra probleem is dat security geld kost en zeer zichtbaar is op de korte termijn, en de baten je hopelijk nooit zult zien.
Het probleem is, denk ik, dat developers zich niet verantwoordelijk voelen voor security. Het zit gewoon niet in de aard of focus. En kennis van security is inderdaad / wordt inderdaad een specialisme.

Kosten / baten zijn tegenwoordig wel bekend middels de vele geslaagde ransomware aanvallen. Via een risicoanalyse kan een directie besluiten dat doorgaan op de oude weg prima is. 'Dat overkomt ons toch nooit, wie zou ons willen hacken' is een gedachte die helaas nog steeds de boventoon voert.

Het is eigenlijk triest dat er weer extra kosten moeten worden gemaakt om je bedrijf draaiende te houden als je afhankelijk bent van ICT. En het tegenhouden van bad actors is moeilijk, tijdrovend, specialistich en duur.
Is herkenbaar!

Maar we zouden dus ook kunnen stellen dat mensen persoonlijk verantwoordelijk kunnen worden gehouden voor dit soort lekkages. Mensen met opleiding zullen deze fouten niet snel maken en kunnen ook aantonen dat het een eenmalige fout is. Mensen zonder opleiding zullen dat niet/minder kunnen aantonen en gaan dan voor de bijl. Uiteraard is dan zowel de inhurende manager als de leidinggevende ook aansprakelijk, zij huren deze persoon in en controleren zijn/haar werk.
Nee, dat gaat niet lukken. Je kan mensen niet persoonlijk verantwoordelijk houden voor iets dat een vergissing kan zijn. Je krijgt dan namelijk gedrag dat die mensen willen dat alles getest wordt, en als de test zegt dat het goed is dan is ineens de tester degene die verantwoordlijk is. Met een beetje doordenken gaat de ketting dan door naar de aandeelhouders en die zijn, uiteraard, nooit verantwoordelijk. Die willen namelijk alleen geld zien, tegen de minst mogelijke inspanning en investering.

Mensen met een opleiding kunnen ook niet aantonen dat een fout 'niet meer voor gaat komen', evenmin als de beter amateur dat kan. Opleiding zegt niets over prestaties in de toekomst. Persoonlijk heb ik ICT afgestudeerden voorbij zien komen met een enorme passie en know how. Ik heb ook mensen gezien die alleen maar afgestudeerd waren, maar niet snapten waar de materie nu over gaat. Met die mensen is het overigens lastig communiceren over security omdat het product wat ze programmeren prima voldoet aan de wensen. Security ligt buiten de scope.
Een een bedrijfje waar de software uitsluitend intern wordt gebruikt, is het risico dan te overzien. Ga je echter de software (als dienst) verkopen, verandert het risicoprofiel.
Daar ben ik het helemaal mee eens.
Ik ken overigens MKB bedrijven met enorme data sets van een groot deel van de samenleving. Denk in Nederland aan telco's die hun data delen met marketingbedrijven die voor hen klanten benaderen. Zo'n MKB-er is een high risk, ook wanneer de software alleen (kuch) intern wordt gebruikt.
Uit nieuwsgierigheid, zijn dit ISO gecertificeerde bedrijven met eigen red teams of een purple team? Zit hier een SOC? Wat is het niveau van de programmeurs?
Nee, dat gaat niet lukken. Je kan mensen niet persoonlijk verantwoordelijk houden voor iets dat een vergissing kan zijn.
Dat ben ik met je eens, iedereen maakt fouten.

Maar wanneer jij in jouw applicatie SQL gebruikt en nooit gebruik maakt van een ORM, prepared statements of server-side binding, dan is er imho géén sprake van een fout. Dan ben je gewoon niet gekwalificeerd en ongeschikt voor het werk. Hetzelfde als wanneer je mij met die graafmachine aan het werk zet, dat is vragen om ongelukken.
Je krijgt dan namelijk gedrag dat die mensen willen dat alles getest wordt, en als de test zegt dat het goed is dan is ineens de tester degene die verantwoordlijk is.
Álles testen is onmogelijk en zal toch al niemand doen. Gebrek aan kennis kom je al tegen wanneer je een code review doet, meestal heb je binnen een half uur al wel een idee van het niveau.
Met een beetje doordenken gaat de ketting dan door naar de aandeelhouders en die zijn, uiteraard, nooit verantwoordelijk. Die willen namelijk alleen geld zien, tegen de minst mogelijke inspanning en investering.
Maar ook tegen de laagste mogelijke risico's. Vandaag grote inkomsten maar morgen een bedrijf die is omgevallen vanwege een hack, levert de aandeelhouder vooral een verlies op. En dat willen ze juist vermijden.
Mensen met een opleiding kunnen ook niet aantonen dat een fout 'niet meer voor gaat komen'
Fouten heb ik geen enkel probleem mee, maar met onkunde wel. Veilig werken is gedrag, zelfde als wanneer je in de auto gaat zitten en direct de gordel omdoet. Ook met die gordel om kun je ongelukken krijgen, maar de impact zal minder zijn.
Security ligt buiten de scope.
Wanneer wij komen ligt er meestal al iemand met z'n kop op het hakblok... 8-)
Uit nieuwsgierigheid, zijn dit ISO gecertificeerde bedrijven met eigen red teams of een purple team? Zit hier een SOC? Wat is het niveau van de programmeurs?
;( Dit soort MKB-ers zijn vaak een 50 tot 100 medewerkers groot, met als het meezit géén eigen programmeurs. In het verleden hadden ze dat wel, meestal van dramatisch slecht niveau. De klanten waar ik het hier over heb, hebben allemaal afscheid genomen van hun in eigen huis ontwikkelde toepassingen. Dat ze nooit het nieuws hebben gehaald met zeer pijnlijke data lekken, mag een klein wonder heten. Anno 2024 zouden ze hier niet meer mee weg komen, ze liggen constant onder aanval van met name Rusland.
Maar wanneer jij in jouw applicatie SQL gebruikt en nooit gebruik maakt van een ORM, prepared statements of server-side binding, dan is er imho géén sprake van een fout. Dan ben je gewoon niet gekwalificeerd en ongeschikt voor het werk. Hetzelfde als wanneer je mij met die graafmachine aan het werk zet, dat is vragen om ongelukken.
Pay peanuts, get monkeys. Het bedrijfsleven is zelf ook verantwoordelijk voor het niveau van het personeel. Je voorbeeld met de graafmachine, of met auto's, gaat mank. Mensen snappen dat graafmachine's en auto's dodelijk kunnen zijn. Dat snappen ze niet van ICT systemen waar iets mee aan de hand is.
Álles testen is onmogelijk en zal toch al niemand doen. Gebrek aan kennis kom je al tegen wanneer je een code review doet, meestal heb je binnen een half uur al wel een idee van het niveau.
Peer reviews op code is vaak lastig ivm tijd, personeel en (juist) het niveau wat jij benoemd. Niet iedereen kan de code van de ander op een juiste manier beoordelen, of durft te zeggen dat de senior (je weet wel, dat persoon waar ik het in het vorige voorbeeld over had) toch niet zo goed is als dat de organisatie denkt dat hij is. En geloof me, dat komt vaker voor dan je denkt.
Maar ook tegen de laagste mogelijke risico's. Vandaag grote inkomsten maar morgen een bedrijf die is omgevallen vanwege een hack, levert de aandeelhouder vooral een verlies op. En dat willen ze juist vermijden.
Waarom blijven investeringen dan vaak achter op, vooral, ICT gebied? Het is lastig, duur en moeilijk te beoordelen voor een 'niet nerd'.
Fouten heb ik geen enkel probleem mee, maar met onkunde wel. Veilig werken is gedrag, zelfde als wanneer je in de auto gaat zitten en direct de gordel omdoet. Ook met die gordel om kun je ongelukken krijgen, maar de impact zal minder zijn.
Onkunde is wat je krijgt als je niet wilt, of kunt, betalen voor kunde. Opleiden / trainen / awareness kweken kost allemaal geld.

Overigens is de pool van onkundige mensen (veel) groter dan de pool van kundige. Dit is sowieso een bedreiging voor bedrijfsvoering. Als je moet kiezen tussen het hebben van geen personeel, of personeel die een beetje op de hoogte is...
Wanneer wij komen ligt er meestal al iemand met z'n kop op het hakblok...
Is dit in het kader van IB&P, crimineel personeel, of zit je bij een (duur) consultancie bureau die de boel moet 'redden' en 'reorganiseren'. Ik kan niet goed inschatten in welke rol je zit. Ik zie wel dat dit bij high end bedrijven is waar geld tegen de plinten aan klotst.
Dit soort MKB-ers zijn vaak een 50 tot 100 medewerkers groot, met als het meezit géén eigen programmeurs. In het verleden hadden ze dat wel, meestal van dramatisch slecht niveau. De klanten waar ik het hier over heb, hebben allemaal afscheid genomen van hun in eigen huis ontwikkelde toepassingen. Dat ze nooit het nieuws hebben gehaald met zeer pijnlijke data lekken, mag een klein wonder heten. Anno 2024 zouden ze hier niet meer mee weg komen, ze liggen constant onder aanval van met name Rusland.
Konden we daar maar iets tegen doen met de kennis die we hebben tegen een laag tarief ;)
Op het moment dat je mensen persoonlijk aansprakelijk gaat houden voor fouten gaat niemand dat werk meer doen.

Bovendien levert afgestudeerd personeel echt niet persé beter werk af. Die kunnen zeker geen extra garanties afleggen.
Op het moment dat je mensen persoonlijk aansprakelijk gaat houden voor fouten gaat niemand dat werk meer doen.
Ik heb het al meerdere keren gezegd, maar dit is geen fout! Wanneer iemand dagelijks code schrijft en dagelijks prepared statements e.d. vermijdt, dan is het een way-of-working. Wanneer iemand alleen maar onveilig werkt, is het geen fout. Dan ben je gewoon niet gekwalificeerd voor het werk en hoor je dat werk ook niet te doen. En wanneer het toch doet, hoor je ook voor de (financiële) gevolgen op te draaien.

Fouten maken is menselijk, werk doen wat je niet kunt, is gewoon onverantwoordelijk.
Klein voorbeeldje van klassiek fout programmeer/prutswerk (PHP in dit voorbeeld)
$username = $_POST['username']; // indicatie dat het fout zal gaan...

$sql = "SELECT * FROM users WHERE username = '$username';"; // zó fout...
$result = pg_query($dbconn, $sql);
En een veilige manier:
$sql = "SELECT * FROM users WHERE username = $1;"; // placeholder
$result = pg_query_params($dbconn, $sql, array($_POST['username'])); // array met input
Dit is dan PHP, maar met álle andere programmeertalen of scripts kun je precies hetzelfde doen.

Het foute voorbeeld is geen fout, het is een bewijs van onkunde. En daar wil je mensen aansprakelijk voor stellen.
Is er in de programma code sprake van dynamic SQL? Zo ja, grote kans op SQL injection.

Door de logfiles van jouw database te analyseren, kun je al achterhalen waar mogelijk sprake is van dynamic SQL. Broncode kun je uiteraard ook geautomatiseerd laten analyseren.
Ben ik de enige die EMP las? :X

Op dit item kan niet meer gereageerd worden.