Dus die Microsoft helper die belde is gewoon genegeerd daar?? Bedoel die man/vrouw had gewoon een probleem met de computer gevonden en wilde het gewoon oplossen.

Tjonge... daar ook datalekken... De tijd is echt voorbij dat je als knutselaar met een hoop branie jezelf kon inkopen in een job als systeembeheerder. Na de introductie begint de pret al en wordt je geroosterd als je niet oppast. 1 foutje en alle data ligt op straat.pff..

Is er wereldwijd nog wel een bank te vinden die nog niet gehacked is?
En waarom krijg ik steeds meer het gevoel dat Internet afgeschaft moet worden?

Simpel, het internet is de gevaarlijkste plaats op Aarde geworden, dus weg er mee.

backend systeem en menselijke fout. De zoveelste maar de naam van dbms is niet genoemd. Mongodb elastic geven geen hits. Het zou zo maar een ontwerp beslissing kunnen zijn om eenvoudiger een app snel af te krijgen.

Er staat duidelijk: onbeveiligde server. Denk je echt dat het uitmaakt welk soort server onbeveiligd is?

Er staat backend systeem, het is een nuance maar wel een belangrijke.
De genoemde dbms systemen Mongodb en elastic samen met aws buckets en wat meer, staan er om bekend vaak op te staan. Bewust of onbewust maakt weinig uit, het is kennelijk te gemakkelijk.
Wat wil je als de aandacht uit gaat naar OSS etc want veilig. Ik heb dat juist vermeden omdat er geen DBMS genoemd is. Het zou voor de gewenste app zelf de snelste en makkelijke manier van implementeren kunnen zijn. Niet eens ondenkbaar.

Wat is het verschil tussen backend systeem en server? Verder maakt het niet uit welke server dan wel backend software er onbeveiligd is. Net zoals het niet uitmaakt bij welk huis de deur open staat. Best lastig niet? Logisch nadenken.

Een backend systeem wordt gewoonlijk weggezet als niet interessant zit maar wat neer dat het doet....
De Frontend wordt gepresenteerd als hoe mooi en prachtis het allemaal is. .. Naar de beslisser.
Wat ontbreekt er? Kwaliteit - betrouwbaarheid beveiliging. (sluitpost)
Ik zie dat je met die logica problemen hebt, toch best basic.

Een backend kan opgezet worden als eigen server eigen datacenter of in de cloud geclustered. Hierbij staat de werking in dit geval als DBM voorop. Een clustered mogelijk als gevitrualiseerd en shared (Multi tenancy) als "de server: zien is wat jaren 70 achtig toen je naar de PDP kast of die van mainframe wees.
Ik zie dat je met die logica problemen hebt, toch best basic.

Een stapje verder is et OSS en meer in dat gebeuren. Waar zo goedkoop mogelijk voorop staat komt het gratis woord en vooral niet zelf nadenken snel op. Dan krijg je vanzelf de combinatie OSS tools (pluk het ergens vandaan) die slecht beheerd worden (iedereen doet het zo) dan wel slecht gebouwd worden (kan niet zo moeilijk zijn toch).
Ik zie dat je met die logica problemen hebt, toch best basic. Het is zo fundamenteel dat je overspoeld wordt met hits.
https://inreachsolutions.com/blog/2017/7/20/good-fast-cheap-the-modern-project-management-triangle

@karma4 irrelevante (en onjuiste, en gewoon domme) uitwijdingen die alleen bedoeld zijn om het voor de hand liggende feit te camoufleren. Namelijk dat er hier ('on-topic') sprake is van iemand die een deur open heeft laten staan en een server/backend systeem onbeveiligd heeft gelaten. Punt. Meer is het niet.

Over 'server' en 'backend systeem': https://www.quora.com/What-is-the-difference-between-server-side-and-back-end. Echt iets voor een papieren tijgertje zoals jij om je daarmee bezig te houden.

Er zal dus een security eindcontrole moeten komen op dergelijke acties. Iemand, die geen vinkje zet, als de "jonge honden" het verkeerd hebben staan (verschil tussen enabled en disabled). CEO en manager zullen dit wel te duur vinden met alle gevolgen van dien.

Ik gebruik een onveilige methode en geen best policy. Ik word daar binnenshuis niet op afgecheckt (veiligheidscontrole).

Voorbeeld linkrot. Ik zoek een filmje op YouTube via een txt link. Antwoord: niet te vinden, account verwijderd. Op titel zoeken, nieuw account aanwezig, andere link heft linkrot op. Nu zelfs MSM-links i.p.v. private U-tuber links, die opkomen. Dit gebeuren is nog gevaarlijker, want hier kun je een IT-er niet op aftikken, dit is main policy van de dienstverlener ten behoeve van betere coire-business resulgtaten.

Conclusie: de veiligheid wordt dus op meerdere manieren ondergraven, niet alleen dus door stommiteiten van degenen, die bij servers aan het inkloppen zijn. Organisatie, tijddruk, incompetentie, menselijke fout, bezuinigingen, bedrijfscultuur (als maar niemand weet dat ik het eigenlijk niet kan, maar toch op de bluf doorgaan)

Als ik met duckduckgo zoek naar een paar tagnamen uit de XML-documenten waar TechCrunch een screenshot van heeft geplaatst die eruit zien alsof ze specifiek voor bepaalde software kunnen zijn (namelijk: submit_sm_gw gw_message_id dlr_params), dan heb ik als eerste hit Jasmin SMS Gateway:
https://jasmin.readthedocs.io/en/latest/apis/ja-http/

@karma4: dat is software die, afgaande op een vrij vluchtige blik op de documentatie, keurig onder een service-account draait, waar gebruikers wachtwoorden hebben etc. Het beeld dat het wel een rommeltje zal zijn want OSS lijkt mee te vallen, het wachtwoord ontbreekt hier niet omdat de makers van de software nooit bij dat soort dingen hebben stilgestaan maar omdat de verantwoordelijken voor die specifieke server geblunderd hebben.

Ik kan me voorstellen dat organisaties die alles zo goedkoop mogelijk proberen te doen (en daarbij heel kortzichtig zijn) gecharmeerd zijn van software die je zonder licentiekosten kan draaien én een potje van het systeembeheer maken omdat ze ook daar geen geld aan uit willen geven. Dus kan ik me voorstellen dat er een statistische correlatie kan bestaan tussen inzet van OSS en de mentaliteit die karma4 beschrijft. Alleen ligt het voor de hand dat de oorzaak niet bij OSS als zodanig ligt maar bij te ver doorgeslagen bespaarwoede en dat OSS op zijn best een indicatie is dat er mogelijk zoiets speelt in een organisatie.

Karma4, de manier waarop jij steeds op OSS afgeeft en de indruk wekt dat het verband met gierigheid en slecht beheer in jouw ogen onvermijdelijk is maakt het moeilijk is om niet de indruk te krijgen dat je OSS als oorzaak van de problemen ziet. Met een achtergrond in data analytics en statistiek zou je moeten weten dat verbanden niet per definitie oorzakelijk zijn, correlation does not imply causation. Is de druk om alles zo goedkoop mogelijk te doen en de race to the bottom die de wereldwijde concurrentiedruk oplevert niet veel voor de hand liggender als bron van de ellende dan de software die men kiest? Verspil je je energie niet door je pijlen te richten op een symptoom in plaats van op de oorzaak?

De code vormt veelal niet het probleem. De mens achter de code wel. De configuratie en implementatie vormen veelal de struikelblokken. De core code is veel minder het directe probleem. Je moet de veiligheidsimplicaties zo ruim mogelijk implementeren. Niet alleen de js bibliotheek uri is kwetsbaar, ook die met de hashtag bijvoorbeeld. Je moet ook weten wat je doet en niet hoeven te gokken. Men weet bijvoorbeeld waar een array begint en eindigt. Waar code kwetsbaar kan zijn (sources/sinks). Waar combinaties van toepassingen extra gevaar gaan opleveren. Experience dus geeft vertrouwen. Je hebt van alles gezien, je bent van alles en nog wat tegengekomen. Good security researchers can hear the code-grass grow and always have their ears on the ground, so to speak. (node.js, bootstrap.js even oppassen hier!).

Als je voor een bepaalde webserver meer dan 500 aanbevelingen kan geven, zijn dat de problemen, maar de achterliggende oorzaak is wat anders. Vaak verkeerde settings en niet toepassen van best policies.

Aan de andere kant is beveiliging een breed constant probleem, terwijl de binnendringer soms maar aan een klein wormgaatje voldoende heeft voor compromitteren. Aan de basis ligt heel vaak excessieve info proliferatie, die dit weer vergemakkelijkt. Alles wat je deelt, kan tegen je gebruikt worden, ook automatisch.

luntrus