Hoofdcategorieën

Lek in opensourcemodule voor iDeal-betaling blootgelegd

Door Dimitri Reijerman, vrijdag 10 augustus 2007 15:47
Bron: Oscommerce, views: 25.971

De e-commerce-helpdesk van iDeal waarschuwt webwinkels die gebruikmaken van het oscommerce-platform voor een lek in de iDeal-betaalmodule. Mogelijk lopen ook betaalmodules in andere webwinkelsoftware het risico op misbruik.

iDeal oscommerce logo'sDe helpdesk van iDeal heeft zijn klanten per e-mail op de hoogte gebracht van het probleem. Door het geconstateerde lek kan een consument tijdens het orderproces op een oscommerce-webwinkel het te betalen bedrag manipuleren. De fraude is mogelijk door een fout in de opensourcemodule 'idealm', een module die door anderen is geschreven; het iDeal-platform zelf is onaangetast.

Voorafgaand aan een iDeal-transactie krijgt een klant die elektronisch wil betalen een nieuw venster te zien waarin het af te rekenen bedrag wordt getoond, en om bevestiging wordt gevraagd. Een onbekende is er in geslaagd om een parameter waarmee dit venster wordt aangeroepen, aan te passen. Dezelfde parameter wordt ook gebruikt om na de bevestiging de iDeal-transactie richting de bank door te geven. Het webwinkelplatform controleert niet of het gemanipuleerde bedrag gelijk is aan het in de orderdatabase opgeslagen bedrag.

De helpdesk van iDeal spreekt van een ernstig lek in de idealm-betaalmodule, omdat de parameters die gebruikt worden bij het aanroepen van het iDeal-bevestigingsscherm voor de eindgebruiker niet zichtbaar mogen zijn. Om misbruik van het lek te voorkomen wordt aangeraden om de betaalmodule te controleren en zo nodig aan te passen of te vervangen. Ook zouden winkeliers moeten controleren of het betaalde bedrag overeenkomt met de orderdatabase, voordat tot levering wordt overgegaan. Bij eventuele fraude wordt aangeraden om aangifte te doen bij justitie. Op de website van oscommerce staat een mogelijke oplossing voor het probleem met de iDeal-module.

Volgende 16:20
Vorige 15:25

Reacties

«  1  2  3  »


jij bent ook geen klant van iDeal. De banken en webwinkels zijn dat.

( of je moet zelf al een webwinkel draaien / IT vent bij een bank zijn, natuurlijk )

Gebruik jij iDeal op je website dan?

Het gaat hier om een fout in een 3rd-part module die door online winkels in combinatie met iDeal gebruikt kan worden. Klanten van de winkels kunnen door een fout in die module fraude plegen.

Heb jij een webwinkel dan die gebruikt maakt van iDEAL? Dan pas ben je klant van iDEAL dunkt me.

Ben jij dan ook klant bij iDeal? (als in dat je een bedrijf/webshop hebt die betalingen maakt via iDeal)??

Dit is net als die 0 euro artikelen die soms voorkomen in webshops, je moet altijd blijven controleren of alles klopt.
Het is wel een lek, maar als je die uitbuit weten ze hier gelukkig meteen wie schuldig is vanwege de rekening nummer. Daarom niet echt een aantrekkelijk manier om het uit te buiten.

Het lijkt mij daarom ook sterk dat webwinkels hier in trappen. Tis toch niet meer dan logisch dat je eerst de betaling controlleerd voordat er tot verzending overgegaan word. Ze moeten het immers toch al controlleren met vooruit betalingen.

het handige aan iDeal tegenover gewone bankoverschrijving was juist dat alles automatisch/sneller kon.
de webshop krijgt meteen te zien of er betaald is in hun systeem.
en dan kijken ze aan het eind van de maand eens of ze genoeg geld op de rekening hebben staan, of dat ze wat missen.
missen ze iets dan gaan ze er vast wel achteraan ja, maar ze zullen echt niet iedere order weer handmatig controleren alvorens het af te ronden.

Bij iDeal krijg je over het algemeen, buiten de client om, een bevestiging van betaling binnen zeer korte termijn op een geheime URL met geheime code op je website. Dit was iig het geval toen ik een webshop moest programmeren met Buckaroo (iDeal, machtiging en CC betalingsprovider). Daarnaast is er bij dit soort systemen een online omgeving waarin je betalingen kunt bekijken. Je hoeft niet tot het eind van de maand te wachten om te weten of je belazerd bent, er zijn genoeg methodes om erachter te komen of je klant het bedrag veranderd heeft.

ja, ik kan ook al mijn overschrijvingen zo in zien, maar het feit is dat dit bij de meeste webshops geen continue proces is. ze controleren gewoon eens om de zoveel $tijdseenheid of de boekhouding overeenkomt met de bankrekening.

dat is niet standaard hoor.
Bij ons hebben we één prijs en één product.

De bestelmodule zet het bedrag vast aan de hand van het aantal en geeft dat zo door aan ideal en paypal. Bij de terugmelding van betaling staat in de webshop alles op "betaald" en rolt met een druk op de knop een adressticker en paklijstje eruit.

Op zn vroegst zouden we dit zien als het bankafschrift binnenkomt.



Dan is de vraag of jouw bevestigingspagina ook beveiligingslekken heeft, zoals een URL .../ideal?bedrag=18,35, of een <input type="hidden" name="bedrag" value="18,35" />

Vast niet. Je moet zorgen dat deze gegevens nooit door de gebruiker kunnen worden aangepast, dus intern in de code afhandelen aan de hand van de in de database/sessie opgeslagen artikelen, en niet een response die je terug krijgt van een bevestigingspagina.

Ik ben helemaal voor Open Source, maar hier heb je toch weer een goed voorbeeld van een niet zorgvuldige of misschien zelfs onbekwame ontwikkelaar. En sowieso een falend testbeleid bij de osCommerce organisatie.

ideal geeft een transactie id terug aan de bevestigingspagina waarmee je verplicht de transactie status bij de ideal server moet opvragen. Lijkt me sterk dat iemand op die locatie nog kan frauderen.

Ze gebruiken in de code:

[code]
$iamount = $_POST['idealm_amount'];
[/code]

Maar dit lijkt me per definitie problemen opleveren, omdat er geen enkele validatie op de user input word uitgevoerd. Imho is dit dus gewoon een heel slordige fout.

Mja, valt wel mee. De bank stuurt namelijk op de achtergrond een verzoek naar een speciale pagina van de winkelier met als POST-variabele het ordernummer. De winkelier moet vervolgens in een XML bestand het bedrag geven.

Je kunt dus wel het bedrag aanpassen, maar normaliter wordt dit bedrag gecontroleerd (buiten de klant om). Het probleem is dat deze controle achterwege is gelaten!

Het probleem is alleen dat deze controle niet door de banken verplicht wordt gesteld. Lijkt me toch ook een slechte zaak van de banken zelf!

Maar voor mij geeft het feit dat er geen validatie op de code word uitgevoerd al aan, dat de code niet netjes is van deze module.

Je zou namelijk ook in de $_POST een stuk code mee kunnen geven waardoor de pagina anders gaat reageren (javscript) of er anders uit laten zien (html/css).

Mijn inziens zou er iig op deze $_POST de volgden iig de volgende 2 controles uitgevoerd moeten worden.
1. Is $_POST numriek
2. Aantal karrakters van $_POST

Ik weet dat je met deze 2 controles niet de genoemde security leak kunt voorkomen, maar het zou wel de minimale controle moeten zijn voor de $_POST variabele.

Vervolgens zou (zoals de IDEAL ook suggereert) bij de werkelijke transactie het totaal bedrag uit de database moeten worden gehaald, en niet uit een variabele welke gewoon door gewoon een gebruiker kan worden gewijzigd |:(

Van die $_POST variabele wordt nergens gekeken of de waarde overeenkomt met de prijs, maar je gaat er nu - wellicht onterecht - vanuit dat $_POST verderop, of bij output, ook niet wordt gecontrolleerd of beveiligd op syntax.

Die POST waarde hoeft niet gevalideerd te worden. Die zou niet eens mogen bestaan. Aan de hand van de artikelen in het winkelmandje moet in de PHP code de totale prijs berekend worden, nooit door een POST vanaf een bestel- of bevestigingspagina.

Het gaat om een koppeling met het externe iDeal systeem. De webshop berekent de prijs, naar ik mag aannemen via de winkelmand, en stuurt dit vervolgens via een post richting de iDeal site. De iDeal service kan niet query'en in je database en al helemaal niet in je winkelmand.

Hoezo een slechte zaak van de banken? Winkeliers die zelf geen maatregelen nemen om zichzelf goed te beschermen en daar nadelen van ondervinden zonder dat dat aan iDeal zelf ligt is geen verantwoordelijkheid van banken. Banken stellen overigens al dat zakelijke gebruikers voor het aanbieden van de betaaldienst zelf zorg moeten dragen voor een goede implementatie.

Ze gebruiken in de code:

[code]
$iamount = $_POST['idealm_amount'];
[/code]

Maar dit lijkt me per definitie problemen opleveren, omdat er geen enkele validatie op de user input word uitgevoerd. Imho is dit dus gewoon een heel slordige fout.
Hoe kan je dat zeggen dat $_POST per definitie onveilig is?
Wie weet gebruiken ze deze code, niks onveiligs meer aan hoor en je kan overal $_POST gebruiken.

foreach($_POST as $key=>$value) {
$_POST[$key] = validatiefunctie($value);
}

Maar validatiefuntie() gebruiken ze dus niet,

Mij lijkt het logischer als er:
$iamount = validatiefunctie($_POST['idealm_amount']);

Zou worden gebruikt,

Het heeft gewoon totaal geen waarde of nut, om van een global $_POST['idealm_amount'], een variabel $iamount te maken als geen bewerking op word uitgevoert op $_POST['idealm_amount']. Ik vind het dus eigenlijk ook gewoon hele lose code. Er gebeurt niks.


[Reactie gewijzigd door Bedge_85]


Dus dit is meer schadelijk voor de winkels? Dus een 'winkelier' zou de waardes kunnen veranderen in hun voordeel? als ik het goed begrijp?

Yap goed gezien, ik koop een plasma voor 3000 euro, verander het bedrag naar een willekeurig bedrag (of 0) en vervolgs druk ik op accepteren en heb de betaling volledig gedaan volgens ideal, wat dus ook "volledig" wordt ingevuld op de website.

Ofwel je kan producten kopen voor een "eigen" ingevulde prijs simpel gezegt ;)

"Helaas" zal een winkelier altijd zijn bank gegeven controleren met het order bedrag.

Die bankgegevens zie je pas een dag later. Dan is het hele voordeel van IDeal naar de haaien. IDeal is bedoeld als Direct en Gegarandeerd betaalsysteem, waarbij de winkelier er op moet KUNNEN vertrouwen dat als een artikel als betaald staat dat het geld MORGEN op zijn rekening staat.

Dit bespaard dus 1 dag levertijd, iets waar de klanten hard om vragen.

Dit bespaard dus 1 dag levertijd, iets waar de klanten hard om vragen.
Bij de goede webwinkels kan je nog steeds onder rembours bestellen, wat resulteert in dezelfde levertijd. Sommige winkels buiten dit echt uit om er extra geld uit te slaan, bij andere winkels valt de remboursprijs hartstikke mee.

Doet me denken aan de supermarkt truuk, waarbij je een stickertje van een goedkope luidspreker set plakt overdie van een duur hifi systeem (met DAB :p).
Winkelier zal niet doorhebben dat het om een ander product gaat.

Maar ik ben veel te eerlijk om zo iets uit te proberen..

Maar het werkt vaak wel ;)
Meer in supermarkten, heb je vaak van die "afprijs" stickers voor dingen die bijna over datum zijn.

Is inderdaad het zelfde principe. Een vriend van mij ging als kind stickers van NES games aftrekken om ze dan op een SNES spel te plakken en dan af te rekenen bij de meest onnozel-uitziende cassiere. Gelukkig is een volledig geautomatiseerd systeem wat minder makkelijk te foppen.

Alleen als het je wel lukt om zo'n volledig geautomatiseerd systeem te foppen zullen ze er niet zo heel snel achter komen in de meeste gevallen.

Nee, de klant kan het bedrag naar beneden schroeven, naar eigen believen. Normaal kan je dat niet aanpassen, maar door de aangepaste parameter is dat dus wel mogelijk.
Als de winkelier het zou doen, dan accepeteer je het gewoonweg niet, toch?

We hadden inderdaad al een mailtje vandaag dat het fout ging. Wat me op viel is dat er meermaals heel expliciet werd gemeld dat het niet aan iDeal, maar aan de module van OsCommerce

Logisch toch. Ze willen (terecht) niet dat het op hen afstraalt.

Lijkt me niet meer dan logisch dat zo'n kritiek stukje informatie goed doorgegeven wordt. Niet alleen omdat de webwinkels hier zelf de dupe van kunnen worden (en dat het dus niet een 'scamlek' of zo is die de klant benadeelt), maar ook omdat zij zelf actie moeten ondernemen, en niet op een update-mailtje van iDeal gaan zitten wachten (want daar ligt het probleem niet).

Ja uiteraard, maar het werd wel _heel_ vaak _heel_ expliciet gezegd.

Het is inderdaad een risico voor de winkelier, dat er een verkeerd bedrag wordt afgeschreven. Het gaat erom dat de waarde die van je rekening wordt afgeschreven, wordt bepaald door een variabele die vanuit de gebruiker (dus de bezoeker van de shop) wordt doorgestuurd. En die later blijkbaar niet meer wordt gecheckt. Wat natuurlijk een enorm stomme fout is. Wat je hoort te doen, is de parameters van de bestelling in je database op te slaan, dan de iDeal betaling uit te voeren en vervolgens te checken of er ook echt is gebeurd wat je had gevraagd. Wat hier dus niet gebeurde.

Dit is dus de reden waarom ik geen sites maak op basis van dit soort opensource producten. Je kunt onmogelijk richting je opdrachtgever verklaren dat iets veilig is, als je niet weet wat er eigenlijk gebeurt!

Aanvulling:
"Als je niet weet wat er eigenlijk gebeurt" slaat niet op de vraag of je het KUNT controleren. Dat kan natuurlijk juist wel bij open-source software, de naam zegt het al. Het gaat mij erom dat het in de praktijk niet nuttig is; als je een open-source component compleet moet gaan nachecken of het wel veilig is geschreven, wat is dan nog de meerwaarde. Schrijf het dan zelf denk ik dan. En dat doe ik dan dus ook.

[Reactie gewijzigd door mddd]


Het lijkt mij dat jouw reactie niet echt ergens op slaat. Het feit dat het opensource is betekent niet automatisch dat het onveilig is, andersom betekent closed-source ook niet automatisch dat het veilig is.

Bij een opensource applicatie kan je tenminste de code er nog eens op naslaan om te zien wat er gebeurd, bij closed source is dat toch wat lastiger lijkt mij.

Feit is dat het gewoon een slordige fout is, en dat heeft m.i. niks te maken met open/closed source.

Ik vind zijn reaktie juist erg zinnig: hij ontkent niet dat je met OS alles ziet hij zegt dat waneer je effectief alles in de OS code moet nagaan je het zowel zelf kan schrijven, en daar heeft hij volgens mij een goed punt, want als je het zelf schrijft is het 100% hetgeen jij wil en niet wat een gemeenschap gedacht heeft dat een grote groep zou willen...

Het slimste is om gewoon een artikelnummer als referentie te gebruiken. Wanneer een betaling wordt gedaan neem je pas de prijs op. Eventueel kun je nog wat spelen met versleutelde tijden/prijswijzigingen.

Als de gebruiker nu een artikelnummer veranderd hij zichzelf het hardste mee, omdat hij iets totaal anders afrekend.

uhm.. Met open source heb je toch juist WEL de mogelijkheid om te zien wat er eigenlijk gebeurd.
Enige andere optie om het zeker te weten is door het zelf uit te programmeren (aangenomen dat je de compiler vertrouwd).

Wanneer je het voor jezelf zeker wilt weten zou ik eerder de bestaande code reviewen dan zelf iets te maken. Andersmans fouten zie je vaak eerder dan je eigen.

Ik ben ook geneigd zelf iets te maken als ik dit geprogrammeerde stukje onkunde zie. Bugs zullen er altijd zijn, maar om het totaalbedrag via de gebruiker te laten lopen is toch wel echt reden om deze "programmeur" het project uit te schoppen.

(en PHP code wordt niet gecompileerd)

Ofdat closed sourcesoftware veiliger is joh?
Als je dit op je website hebt geïmplanteerd of op een website van je opdrachtgever dan had je al in de source kunnen zien dat er een mogelijk beveiligingsprobleem is. Hier kan je dan naar handelen door of de fout op te lossen en de patch zelf door te voeren en natuurlijk naar de ontwikkelaars te sturen.

Jouw redernatie is dan ook bull-shit! Bij open source kan je dus in de source kijken wat er al gebeurd. Bij closed sourcesoftware moet je maar op de blauwe ogen van de softwarebouwer(s) vertrouwen. Mogelijk dat daar wel een verborgen 'backdoor' in zit die allerlei vertrouwelijke gegevens doorsluist... Maar dat weet je niet en kan je niet weten. Per definitie is dat dus altijd onveilig! Want je weet niet wat de software allemaal doet! :P

Zie ook mijn antwoord verderop. Ik pleit niet ervoor om een closed-source module in te kopen in plaats van een open-source module. Ik signaleer enkel, dat in de praktijk ontwikkelaars niet de complete code van elk onderdeel willen gaan nalopen, dat is ook haast niet te doen zo complex als veel frameworks zijn. Je moet er dus uiteindelijk op vertrouwen dat het open-source element zo veilig is dat je het durft toe te passen. (Of je moet zelf actief in de community van dat product zitten maar je kunt niet in alle communities zitten en alle producten op je duimpje kennen).

De theorie "je had het zelf na kunnen lopen" is dus leuk maar levert geen beter resultaat op vind ik.

Je hoeft het niet zelf na te lopen om het te kunnen vertrouwen, de gedachte dat velen voor jou naar de code hebben gekeken regelt dat. Aan de hand van het versienummer, de activiteit binnen de community, de leeftijd van het project kan je bepalen of je het vertrouwt. Blijkt er dan toch iets niet te kloppen zijn er bij een actieve community genoeg mensen die staan te trappelen om het probleem op te lossen met een volgende release.

Dit toont volgens mij aan dat dat dus niet altijd goed werkt. De gedachte dat "De Community" er wel proactief naar kijkt en de fouten eruit haalt kan ertoe leiden dat iedereen verwacht dat zijn/haar buurman dat wel doet... Deze fout is ook niet door "De Community" gevonden, maar door een "cracker".

Indien een fout naar boven komt kan het bij OSS software snel opgelost worden, maar dit is reactief, niet proactief. Crackers die fouten vinden zullen het in het geheim voor eigen gebruik uitbuiten en niet naar "De Community" doorspelen.

Hoe kom je erbij dat het door een cracker is gevonden (staat namelijk nergens in het artikel)? De bank meldt dit en is in feite een deel van de 'community'. Het werkt dus...

Hoe denk je dat bugs/exploits worden gevonden in closed source software? Kijk eens naar je OS of je office pakket, je browser, je games... Ook allemaal achter de feiten aan lopen, als ze al worden opgelost (ook al heb je een onderhouds contract).

Probleem met OsCommerce, heb ik ontdekt, is dat er geen fatsoenlijke documentatie is.
Er is broncode, ook een rammelende slecht leesbare installatie handleiding, maar geen documentatie over structuur, concept, doelstellingen, ontwerpkeuzen, of wat meer vereist is voor inzicht en om het pakket te kwalificeren als serieus ontworpen. Wat dat betreft heeft mddd een punt, je kunt OsCommerce moeilijk beoordelen.
Logisch dat velen dit niet doen. Zo blijven wel de fouten er in zitten!
Idealm is een losse module, bestaat pas een half jaar in deze vorm, denk ik.
Ook daarvan kon ik geen fatsoenlijke documentatie vinden. Logisch dat er nog fouten in Idealm zitten.
Ik heb verder alleen als gebruiker (gunstige) ervaring met OpenSource software. Ik hoop wel dat OsCommerce een uitzondering is, met de slechte documentatie. Anders moet ik mijn opvattingen over Open Source drastisch aanpassen..

Reagerend op je aanvulling:


Jouw eigen knutselsoftware is zeker wel bugfree omdat jij beter programmeert dan een OSS community? Als je zelf iets implementeert komen dit soort bugs inderdaad niet aan het licht, omdat jij de enige bent die de code kan zien.


Bij software ontwikkeling worden simpelweg fouten gemaakt, ongeacht het ontwikkelmodel. Terwijl dit wel een redelijk slordige fout is, kan je onmogelijk over OSS in het algemeen als minder kwalitatief goed spreken. Juist door dit soort ontdekkingen bereikt de software sneller een hoger niveau van volwassenheid. Door gebruik te maken van volwassen OSS componenten zal het resultaat beter zijn dan zelfbouw, of je moet wel heel briljant zijn.

[Reactie gewijzigd door PHiXioN]


Mijn eigen software is ongetwijfeld niet bug-free. Maar tenminste kan ik er op vertrouwen dat ik weet hoe het in elkaar steekt. Ik zeg ook nergens dat OSS van mindere kwaliteit zou zijn dan iets wat een individu (e.g. ikzelf) schrijft. In zijn algemeenheid is OSS vast beter. Maar dit geval geeft wel aan, dat het dus best kan dat er in een stuk OSS een enorm stomme fout zit, terwijl je er juist vanuit zou gaan dat het beter is. Nou daar schrik ik dan wel van ja.

Het gaat mij om de vraag of je er verantwoordelijkheid voor kunt/wilt nemen. Ik doe dat dus liever voor mijn eigen werk dan voor een samenspel van elementen waar je zelf weinig controle over hebt.

terwijl je er juist vanuit zou gaan dat het beter is.
Zo lang je nergens vanuit gaat, verwacht je ook geen verkeerde dingen, verwacht vooral niet dat je eigen code (c) beter is dan Supershop (r) Pro(tm) of OpenShop.

Dat hele verhaal van jou heeft toch niets maar dan ook niets met open source te maken?
Jij schrijft lekker alles zelf omdat je het beter meent te kunnen dan iemand anders. Tot hoever voer je dit eigenlijk door? Schrijf je alle libraries / platforms ook zelf? Je OS? Anders zou er nl nog wel eens een fout in kunnen zitten Als je het zelf schrijft niet.

Jij schrijft lekker alles zelf omdat je het beter meent te kunnen dan iemand anders
Beter lezen, dat zegt hij helemaal niet! Sterker nog:
Ik zeg ook nergens dat OSS van mindere kwaliteit zou zijn dan iets wat een individu (e.g. ikzelf) schrijft. In zijn algemeenheid is OSS vast beter.
Nogmaals eerst lezen, dan pas reageren:
Het gaat mij om de vraag of je er verantwoordelijkheid voor kunt/wilt nemen.

Ik snap nog steeds niet hoe je het nou echt precies bedoelt, maar ja, natuurlijk kunnen (nee eigenlijk zullen) er fouten in OSS zitten die echt wel schade kunnen doen. Niet ieder OSS project heeft zoveel vrijwillige ogen op de code als de Linux kernel. Dus kan je de kwaliteit van de Linux kernel ook nooit elders verwachten.

Er zit een bug in en er is een patch beschikbaar gemaakt. Dat is toch een ideale situatie dat iemand anders al een oplossing voor je kan aandragen?

aan de andere kant, bij contant betalen aan de kassa moeten ook beide partijen altijd goed opletten/controleren. en dat gaat ook wel eens fout aldanniet bewust
dus eigenlijk niets nieuws op de wereld.

wel zaak dat het aangepast moet worden uiteraard.

just my 2(=0) cents


edit//
@graey

dat zou zo zijn in een ideale wereld, helaas blijft iedereen verantwoordelijk voor zijn eigen zaken. zeker bij zogenaamde automatische transacties.
ik heb laatst ook iets via ideal betaald maar ook meteen online de afschrijfing gecontroleerd. en ik weet zeker dat ik daar niet de enige in ben.

[Reactie gewijzigd door Chuckylee]


Mee oneens, het voordeel van een internetwinkel moet (onder andere) juist zijn dat die controle niet nodig is, dat dat automatisch gebeurd...

Ik heb verschillende iDeal implementaties gedaan, de fout zit niet in de iDeal software maar in de software van de aansluiter.
Deze ontvangt van de webshop een bedrag en stuurt dit door naar iDeal.
Ideal rekent dit bedrag af en meld dat het gelukt is.

Dat de webshop zijn bedragen niet onderhuids maar gewoon via de browser naar de aansluiter stuurt is het probleem, zo kan de bezoeker gewoon zelf het bedrag aanpassen.

Alle betaal methoden van multipay waren (of zijn) ook zo te misleiden.

Rabodirect ondersteunde ook het bedrag doorsturen via de klant, maar dan moest er ook een hash meegestuurd worden om zo aanpassingen door de klant tegen te gaan.

@mddd, wat een geflame weer.
Wat heeft dit met open source te maken, je argument "als je niet weet wat er gebeurt" kun je juist weerleggen met opensource software, en niet met closed source software. Of ben je niet kundig genoeg om even te lezen wat er gebeurt onder de motorkap en kun je er alleen op fitten als het jouw uitkomt?

[Reactie gewijzigd door killercow]


Mijn post is absoluut niet als opensource-flame bedoeld hoor. Mijn argument is ook niet 'je kunt het niet controleren', maar 'blijkbaar moet je het zelf alsnog controleren'.

Als je een website bouwt kun je zelf een onderdeel (in dit geval een betaalmodule) bouwen, of je kunt een standaard bouwsteen gebruiken. En dat standaard onderdeel kan dan eventueel gekocht zijn of uit het vrij beschikbare circuit komen.

Het voordeel van een standaard element (zoals oscommerce idealm in dit geval) is natuurlijk dat je niet zelf al het werk hoeft te doen. Als je zelf alsnog de volledige code moet gaan doorspitten om te kijken of alles wel veilig is, dan heeft het m.i. weinig zin om uberhaupt dat element te gebruiken! Dan kun je het net zo goed zelf maken.

Het valt mij nogal tegen dat zo'n veelgebruikt pakket als oscommerce zulke slechte plugins kent. En dat versterkt mijn idee dat ik dus beter zelf een kritisch stuk als een betaalmodule kan schrijven, dan het van het net plukken.

En wat mij nog somberder stemt: er zijn ook zat mensen die zelf niet eens de kennis hebben om zoiets te kúnnen schrijven. Die hebben geen keuze. (Of die webshops zouden moeten bouwen is trouwens ook de vraag, maargoed).

[Reactie gewijzigd door mddd]


Gebruik dat niet "dit soort open source producten", want nu zijn je posts wat mij betreft flamebait of allerminst op onwaarheden gebaseerd.

Je geklaag slaat op open EN closed source... waarbij je bij closed source niet eens de mogelijkheid hebt deze te controleren.

Ik neem aan dat je dus alles zelf schrijft?
Of gebruik je closed source modules? Ik zie weinig closed source die niet ontzettend waanzinnig duur is waarbij de leverancier daadwerkelijk de verantwoording neemt voor fouten onstaan door problemen in hun software.

1. Closed source software wordt voornamelijk geschreven door ervaren programmeurs bij bedrijven die eerst hebben moeten solliciteren. Open source wordt geschreven door jan en alleman. Dit kunnen diezelfde goede programmeurs zijn, maar ook pietje die dus een totaalbedrag via POST verstuurt en er waarschijnlijk geen idee van heeft dat het niet veilig is.
2. Closed source is meestal betaald, en daarvoor verwacht je dat de software uitgebreid getest is. Niemand heeft de iDeal plugin van pietje bekeken, maar honderden winkels gebruiken deze wel.
3. Betaalmodules zijn een van de belangrijkste onderdelen van een webwinkel. Je wilt dat deze goed gebouwd en veilig is. Bij open source heb je de kans om deze in te kijken, bij closed source helaas niet. Máár als je betaald voor een betaalmodule, verwacht je kwaliteit, en bij open source weet je dat het mogelijk is dat pietje het gemaakt heeft.

Hieruit kan je concluderen dat closed source meer vertrouwen wekt als het om betaalmodules gaat. Wil je deze niet inkopen, en kies je voor open source, zorg dan dat je zelf kijkt of het veilig is (was osCommerce trouwens ook had moeten doen bij pietjes module). Als het niet veilig is, pas het dan aan.

Of je bespaart je al deze moeite, en kiest in sommige gevallen om het zelf maar te doen, wat mddd aandraagt.

Het is geen flame, maar een constatering van mogelijkheden en een oplossing daarvoor. Ik ben 100% voor open source, maar zoals dit bericht bewijst: het is een mogelijk beveiligingsrisico.

1. Dit weet je niet, voor hetzelfde geld is het door Floris de stagiair geschreven, maar hierbij ga je dan vaak af op de blauwe ogen (de reputatie) van het bedrijf. Bij OSS projecten kun je vaak wel een beetje een indruk opdoen van hoe met kwaliteit omgegaan word. Bekijk de documentatie (Klote documentatie is of geen serieuze developers, te kleine community, of zo een haast werk dat ze geen tijd meer hadden voor documentatie), lees wat code, en je krijgt vaak wel een indruk van de kwaliteit.

2. Ik heb enkele implementaties van webshops gedaan, en heb derhalve heel wat regels code van osCommerce gelezen (is al weer een poosje terug, dus kwaliteit ervan kan ik me niet meer herinneren). Als vele mensen onafhankelijk van elkaar met eigen ogen code doorlezen, dan is de kans groot dat er veel bugs geplet worden. Closed source modules worden maar door een beperkt aantal verschillende mensen gelezen.
"Verwacht dat deze goed getest is". Lees even een paar pagina's meuktracker door, en verbaas je over enkele commercieele closed source paketten met fouten waarvan je denkt "hadden ze dat niet wat beter kunnen testen". Verwachten/denken moet je zien te voorkomen, ik controleer liever nog eens.

3. Kwaliteit verwachten is iets anders dan krijgen, ik kan hier moeilijk voorbeelden gaan noemen van software waar je kwaliteit van zou verwachten maar het niet krijgt (Want dan loop ik het risico een verzameling fanboys van het betreffende product achter me aan te krijgen), maar er zijn genoeg voorbeelden.

ach word het alleen maar veiliger ;)
goed dat dit soort exploit mensen bestaan eigenlijk.

[Reactie gewijzigd door stewie]

«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 16:20
Vorige 15:25
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: