Je bedoelt dat de JavaScript code - zeker niet vanaf de client - niet rechtstreeks bij de database kan? Dat lijkt me inderdaad heel verstandig!

Je moet hoe dan ook al je invoervalidaties op de server uitvoeren, ook als je ze ook al in de browser uitvoert. Een aanvaller kan de browser namelijk volledig naar zijn hand zetten zodat je niet kan vertrouwen op wat er daar gebeurt.

Verder heeft JavaScript in de browser een heel andere rol dan code (JavaScript, PHP of wat anders) op de server. Aan de browserkant is het gericht op de user interface, op mogelijkheden die je met kaal HTML+CSS niet kan implementeren. Op de server is het gericht op de afhandelen van de requests die vanuit een client binnenkomen.

Database-query's (ik neem aan dat je daar SQL-statements mee bedoelt) horen helemaal niet thuis in de browser. Los van dat je daarmee een aanvaller heel veel informatie geeft over hoe je back-end in elkaar zit zet je er ook de deur mee open om heel andere queries dan de bedoeling is op je database los te laten. Stel die dingen op de server samen, en gebruik daarvoor geparameteriseerde SQL (prepared statements) en ga niet zelf strings aan elkaar rijgen, want ook dat biedt een aanvaller ruimte om ongewenste SQL te injecteren.

Ik word nogal ongemakkelijk van de vragen die je stelt, en hoe je ze stelt. Je geeft de indruk dat je nog geen begin van inzicht hebt in wat er bij het inrichten, beheren en beveiligen van een webserver komt kijken. Dan sta je bij voorbaat fors op achterstand tegenover iedere aanvaller die die server maar kan bereiken, en als die aan het internet hangt dan heb je een menigte van 4,5 miljard andere internetaansluitingen die je server kunnen bereiken, met daaronder genoeg kwaadaardige figuren die veel kundiger zijn dan jij om je serieus zorgen te gaan maken. Die kennisachterstand loop je niet in door wat losse vragen op een forum te stellen. Dit is geen kwestie van wat simpele vuistregels toepassen, dit is een kwestie van een serieuze hoeveelheid kennis en inzicht opbouwen en die ook nog eens actief bijhouden omdat de wereld op dit vlak verandert waar je bij staat. Als je niet serieus op dat vlak bij wilt leren, laat die server dan liever over aan iemand met verstand van zaken.

Client side datavalidatie is erg handig voor de gebruiker/bezoeker. Want die hoeft dan niet op antwoord te wachten van de server dat bijvoorbeeld een email adres geen apenstaartje bevat. Maar dat is het dan ook.

Op de server moet je altijd alles nog eens valideren.

Zie je browser als de douane. En je server als de politie. Als je enkel op de douane vertrouwt en daarna nergens meer op let, dan krijg je problemen. Vooral omdat in de browser precies te zien is waar de douane wel en niet op let.

Werk je met een database, vraag je dan altijd af of je wel een database nodig hebt. Heb je die nodig, dan zeker werken met prepared statements.

Verder nooit te bang zijn om fouten te maken. Van succes leer je weinig. Van fouten veel meer. Alles overlaten aan iemand die meent verstand van zaken te hebben kan ook een leerzame fout zijn.

I'm EJ and I second this message.

@ Eric-Jan H te A,

Beste Eric-Jan,

Wat zijn volgens jou dan de directe best policies om door te voeren op client en webserver bijvoorbeeld.
Welke validatie methoden zijn het meest geeigend?

Met shodan info zie ik nogal wat, dat kwetsbaar is bij excessieve server info proliferatie bijvoorbeeld.
Als je gaat verder gaat doorspitten op gebruikte server software exploits.

Het gedoog-circus o.a. als dat bij een Leasweb Nederland laat dat
via een Maltiverse search query op LeaseWeb dot nl zien.

Bij abuse wordt wel gehandeld, maar aanvankelijk willen ze de buit wel binnen hebben.
Een criminele euro geldt voor hen evenzeer als inkomen als een legitieme, lijkt het wel.

Als al die verzamelde mitigatie en improvement data aanwezig is,
waarom blijft de beveiligingsslag toch steeds weer uit?

Ik vraag me dat al meer dan 12 jaar af.

Het is hierbij vaak net als met 'rooken', de meesten blijven het doen,
tot er iets op/aan de longen wordt gevonden, dan pas zweren ze het af.
Is men, als mens zijnde, soms verslaafd aan onveiligheid?

#sockpuppet

Nu weten we wel zeker dat er een tweede persoon is gekomen die #sockpuppet onder de reacties zet.
Maar goed dat kan iedereen doen natuurlijk.
(het kan evt ook zijn dat hij aan het "rooken" geweest is)

Heb je het hier over node.js?

Ik begrijp niet waarom dit zo'n hype is onder de programmeerjeugd nu. Er wordt veel in gemaakt dus het wordt aangeleerd op school. Ben ik van de oude stempel met mijn Apache en PHP toen we net leerden geen CGI binaries te vertrouwen?

Toen was Javascript op de browser lelijk maar anno nu lijkt JS op de server heel gewoon. Kan iemand dit uitleggen aan deze wat oudere IT man?

Fijn artikel over node.js security:
https://medium.com/@nodepractices/were-under-attack-23-node-js-security-best-practices-e33c146cb87d

Belangrijk steekwoord, dat valt in dit verband, is CSP policies aan de client en aan de server kant
samen met voortgezette validatie natuurlijk.

Maar onthoudt, JavaScript ook met Node.JS en Retire.JS blijft "a can of worms" of kan dit gemakkelijk worden.
Het heeft veiliger trekjes gekregen met babel.js etc. Edoch, het blijft oppassen geblazen.

Hetzelfde geldt overigens voor het oudere PHP werk. Daarmee kun je nog eerder de weg mee kwijtraken.

Weet dat JavaScript ontstond in slechts 10 dagen en Brendan Eich nog steeds beweert,
dat het destijds niet geschikt was voor gebruik met HTML.

JavaScript kan de "royal way in" zijn voor iedere malcreant, hacker, cracker met voldoende talent
en een klein voorkomend gaatje, om zich doorheen te kunnen wurmen, waarna het verdere werken wacht.

Dus fuzz en lint, kijk of code niet net iets langer afloopt dan te verwachten valt, een belangrijke weggever,
dat er wat verder doorgespit moet worden en getest.

En niet vergeten, alle code die u eens verworven heeft, zal t.z.t. ook weer afgevoerd dienen te worden.
Een wet van Meden en Perzen.

luntrus

Alweer verouderd. WebAssembly is het nieuwste van het nieuwste.

https://blog.stackpath.com/webassembly/

Webassembly, statisch compileren met daarachter weer de invloed van Google met Keep.

Maar voor authenticatie, alle browser vendor hebben websassembly by default,
kent het geen eigen authorisatie toegangsregels. Dat moet goed ingeregeld worden.

Er is nu ook Clang voor het compileren van C++ naar Webassembly.

luntrus

Zoals je in het gelinkte artikel kan lezen is WebAssembly ontstaan uit een zeer breed samenwerkingsverband (W3C, Google, Apple, Mozilla, and Microsoft). De browser ondersteuning is daardoor groot maar die behelst niet meer dan het uitvoeren van WebAssembly code. N.B.: er is (nog?) geen rechtstreekse toegang tot de DOM of andere browser API's, noch JavaScript referenties.


Wat je bedoelt met de 'invloed' van Google met Keep is mij onduidelijk. Want Google Keep is gewoon een voorbeeld van een applicatie die WebAssembly gebruikt. Niets meer en niets minder. Er is ook een bèta van Google Earth.

@ Ex Machina,

Ik bedoel daarmee te zeggen, dat Google wel overal een of wellicht wel twee of meer dikke vingers in de pap heeft.
Het positioneert Google's ontwikkelingen graag als "veilig".

Het heeft flinke impact met Google Safe Browsing, na het verwerven van VirusTotal
en zo dus ook binnen security & developer kringen.
Het bekende door het Google hoepeltje springen.

Verschillende Web assembly modules lopen nu reeds in de browser,
als men gebruik maakt van Google web services.

En Google Chrome en op chromium gebaseerde kloons vormen 96 % van de browsers.
Firefox en Cliqz Internet browser zijn maar goed voor een kleine niche van 4%.
Dat betekent dus een verwaarloosbare invloed op Google's strategische zetten
(Internet overhaul via het het Berners-Lee-plan, dat firefox afwijst, DoH, first-party-tracking
& de universal first-party ID tracking door DigiTrust voorstellen, tevens zaken die Mozilla afwijst).

Mijn grote bezwaar is dat de invloed van Google en de andere grote Data Grabbers eigenlijk al niet meer te ontgaan valt.
Hoe onttrek je je aan de invloed deze gigigantisch grote monopolisten, ook als developer en tevens als security man of vrouw? Bij developer toetsen heden ten dage moet je software alerts al uitschakelen.

Lees: https://security.stackexchange.com/questions/171230/is-google-keep-more-secure-than-lastpass-secure-notes

Ik mis de laatste tijd ook asp site scanners (voor o.a. http-only cookies, server info proliferatie etc.).

Security scenarios verschillen verder bijvoorbeeld duidelijk tussen Blazor Server en Blazor WebAssembly apps.

De meest verderfelijke invloed gaat hier, zoals eigenlijk overal, uit van decisionmakers (vaak via stakeholders)
die gespeend van relatieve security kennis en inzicht, beslissingen nemen met security als een soort "last resort item" (sluitpost op de begroting). Liever volgens hen dus dus een gelikte site in Web Assembly dan een veilige.

De recente ransomeware golf laat zien waar dat op den duur toe leidt. Goedkoop = duurkoop in zo'n geval.
Managers en CEO's, wat richten ze allemaal aan in deze wereld? Laat ze eens een vak gaan leren.

m.vr.gr.

luntrus

@luntrus WebAssembly is wel een open standaard: https://webassembly.github.io/spec/core/bikeshed/index.html dus iedere browserontwikkelaar kan het implementeren (en omdat het uit zo'n breed overleg is ontstaan is dat ook grootschalig gebeurd).