javascript injection - bescherming?

[BoringDay]

Ik ben benieuwd welke maatregeling jullie nemen tegen javascript injectie.

Zoals wachtwoord verificatie heb ik aan de server kant en daar wordt ook bepaald welke role een gebruiker heeft. Omdat ik veel met javascript objecten om de website dynamisch te houden zijn bepaalde objecten afhankelijk van een role-level. Toch houd ik er geen goed idee aan over dat men zomaar javasrcript, jquery commando's kan uitvoeren via het adressenbalk terwijl ook nog alle js-scripts zichtbaar zijn in de browser consoles. Een beetje ingewijde komt natuurlijk met beetje puzzelen overal op deze manier wel doorheen (helemaal als ze gaan debuggen).

Daarom vraag ik mij af of het niet mogelijk is om te dedecteren van waar een javascript opdracht vandaan komt? Het liefst weer ik elk javascript verzoek dat via het adressenbalk verloopt. Wat zijn de mogelijkheden en hoe gaan jullie hiermee om?

[Snake]

Niet, kan je niet vermijden. Uiteindelijk moet de javascript geparsed worden door jouw browser, dus uiteindelijk kan de user een fake request ook opbouwen. Aan jouw om op de server te controlleren of de request wel valid is in de context van de huidig verbonden user (mag hij die actie wel uitvoeren).

[BoringDay]

Dat is dan wel een blunder in de programmeertalen voor de web! We zijn 2013 en nog geen oplossing terwijl men hier al jaren de tijd voor heeft. Je zou toch verwachten dat er op zijn minst een verificatie methodiek bestaat om te kunnen zien of een script vanuit het js bestand komt of vanuit het adressenbalk?

[PolarBear]

Begrijp ik nu goed dat je client side dingen verbergt met Javascript? Of doe je geen autorisatie checks bij requests?

[EddoH]

Als je afhankelijk bent van het hiden van je client-side code dan ben je verkeerd bezig. Iederen kan jouw js files downloaden en aanpassen (logisch, je browser haalt ze ook met een normale http request op). Verifieren of js code uit de adresbalk of uit een js file komt lost dus helemaal niets op. Server side moet je je input valideren. Punt.

[BoringDay]

Nee en klein beetje ja.

In principe wordt het inloggen geheel server-side afgehandeld. Wachtwoorden zijn gehashed, daar ligt bij mij het probleem nog niet. Wel een probleem met een menu wat wordt opgebouwd op basis van xml waarin een role-level wordt bepaald. Met een js object voer ik een request uit om te valideren of een item zichtbaar is of niet (iets wat ik dus moet aanpassen, of het element wel of niet wordt aangemaakt en m.b.v. db-gegevens moet worden bepaald zodat validatie puur server-side wordt) echter heb je dan nog geen bevoegdheden tot manipuleren van data.

Maar daar ben ik me wel van bewust, gezien het object-georienteerd is het slechts een kwestie van het object aanpassen of een nieuwe ontwerpen. Alleen het valt me wel vies tegen dit soort mogelijkheden bestaan iets waar de ontwikkelaars v.d. talen al lang een effectieve oplossing hadden voor kunnen bedenken ipv ontwikkelaars die met de taal moeten ontwikkelen onnodig veel werk te laten doen. php/js zitten zo slecht in elkaar je de focus niet kan leggen op dingen waar ze behoren.

[EddoH]

BoringDay schreef op donderdag 04 juli 2013 @ 10:18:
php/js zitten zo slecht in elkaar je de focus niet kan leggen op dingen waar ze behoren.

Omdat jouw software architectuur niet klopt zitten de talen slecht in elkaar. Het moet niet gekker worden...

[R4gnax]

"Never trust the client" is zo ongeveer het eerste wat je bij security 101 te leren krijgt.

Als jouw architectuur er van uit gaat dat de client wel te vertrouwen is, dan ben jij zelf verkeerd bezig; geef niet een programmeertaal of -omgeving de schuld van jouw eigen gebrek aan kennis en/of inzicht.

[RobIII]

De Devschuur is traditioneel niet een plek waar je veel plaatjes tegen komt, maar ik ga 't nu toch echt doen:



Je hebt wérkelijk waar géén idee waar je 't over hebt en verwijt 't dan de talen dat 't niet goed is?

BoringDay schreef op donderdag 04 juli 2013 @ 10:18:
Met een js object voer ik een request uit om te valideren of een item zichtbaar is of niet (iets wat ik dus moet aanpassen, of het element wel of niet wordt aangemaakt en m.b.v. db-gegevens moet worden bepaald zodat validatie puur server-side wordt) echter heb je dan nog geen bevoegdheden tot manipuleren van data.

Los van wat je menu wel/niet toont; op 't moment dat je klant X probeert op te halen of product Y's prijs probeert te wijzigen of... dan doe je de controle of de gebruiker wel/niet de juiste rechten heeft. Wanneer dat niet zo is gooi je een UnauthorizedException of een BenJeNouHelemaalVanLotjeGetiktException en klaar.

BoringDay schreef op donderdag 04 juli 2013 @ 10:18:
Maar daar ben ik me wel van bewust, gezien het object-georienteerd is het slechts een kwestie van het object aanpassen of een nieuwe ontwerpen.

*Verwijst nogmaals naar 't plaatje*
Hoe komt hier opeens (weer) OO om de hoek kijken? Dat je een objectje moet aanpassen zal best, maar ik zie totaal niet hoe 't relevant is in dit verhaal om hier over OOP te beginnen? Da's 'tzelfde als concluderen dat je olielampje brandt en bij de garage vermelden dat je op Pirelli banden rijdt.

BoringDay schreef op donderdag 04 juli 2013 @ 10:18:
Alleen het valt me wel vies tegen dit soort mogelijkheden bestaan iets waar de ontwikkelaars v.d. talen al lang een effectieve oplossing hadden voor kunnen bedenken ipv ontwikkelaars die met de taal moeten ontwikkelen onnodig veel werk te laten doen. php/js zitten zo slecht in elkaar je de focus niet kan leggen op dingen waar ze behoren.

Er is zat aan te merken op PHP / JS (en elke andere taal (ja, ook Delphi) en/of platform) maar in dit geval ben jij toch écht degene die hier schittert in 't gebrek aan de nodige kennis.

[BoringDay]

EddoH schreef op donderdag 04 juli 2013 @ 10:26:
[...]

Omdat jouw software architectuur niet klopt zitten de talen slecht in elkaar. Het moet niet gekker worden...

Ten eerste is mijn mening niet op mijn architectuur gebaseerd. Meer op het feit alleen dat het geen volwaardig OOP talen zijn. Het feit alleen al dat javascript-injectie mogelijk is moet denk ik al meer dan genoeg zeggen.

[RobIII]

BoringDay schreef op donderdag 04 juli 2013 @ 10:46:
Het feit alleen al dat javascript-injectie mogelijk is moet denk ik al meer dan genoeg zeggen.

Heb je enig idee wat javascript-injectie inhoudt? Dat een gebruiker javascript:functie(foo) kan typen in de adresbalk ik géén JS "injectie". En again, WTF heeft OOP hier mee te maken? Was JS injectie dan wel onmogelijk geweest als Javascript wel "OOP" was geweest dan? Iets met een klok en een klepel.

[ Voor 18% gewijzigd door RobIII op 04-07-2013 10:49 ]

[EddoH]

It's not worth it Roblll

[BoringDay]

Als JS echte OOP was geweest zeker dan had je meer controle en meer structuur. Maar hoe kan je als programmeur nu ontkennen dat scrips uitvoeren via het url-balk geen probleem is?

[martin_v_z]

TS, het opbouwen van het menu zou je ook server side kunnen doen. Daardoor kan je de validatie op de server houden, daardoor voorkom je dat mensen items zichtbaar kunnen maken die ze niet behoren te zien. Je moet altijd alles valideren op de server want het is nooit 100% zeker dat de request ook daadwerkelijk vanuit jouw gebouwde client (in dit geval jouw website) komt. Iemand kan net zo goed zelf een http request de server op sturen om gegevens op te vragen.

[martin_v_z]

BoringDay schreef op donderdag 04 juli 2013 @ 10:53:
Als JS echte OOP was geweest zeker dan had je meer controle en meer structuur. Maar hoe kan je als programmeur nu ontkennen dat scrips uitvoeren via het url-balk geen probleem is?

Wat is het probleem van een user die zelf scripts uitvoert in de browser. Als de server goed geschreven is kan hij daarmee geen schade toerichten. Iemand kan zelf een browser schrijven en zelf een java script parser. Punt is dat jij nooit weet wat er client side gebeurd, en dat moet ook niet jouw zorg zijn. Als iemand de site wil verpesten door zelf scripts uit te voeren of css aan te passen dan moet hij dit zelf weten.

[BoringDay]

@martin voor het grote deel gebeurd dat ook server-side, namelijk wordt daar ook het template bepaald.
Dat is verder ook geen probleem omdat die vrij eenvoudig is aan te passen.

[RobIII]

BoringDay schreef op donderdag 04 juli 2013 @ 10:53:
Als JS echte OOP was geweest zeker dan had je meer controle en meer structuur.

Ja, want OOP is heilig

BoringDay schreef op donderdag 04 juli 2013 @ 10:53:
Maar hoe kan je als programmeur nu ontkennen dat scrips uitvoeren via het url-balk geen probleem is?

Omdat het geen probleem is. Je denkt dat, zeg, een Facebook of Google of Hotmail of weet-ik-het ook allemaal te "hacken" zijn door even de juiste code in je adresbalk te typen? Je gaat me nu niet lopen vertellen dat daar (JS-)minification voor uitgevonden is hé?

De gegevens waar de client niets mee van doen heeft gaan niet eens over de lijn; zo hoort 't. En als de client ze dan toch probeert op te halen (omdat er iemand met JS ligt te stoeien of, zeg, een URL parameter veranderd van ?foo=bar&id=3 naar ?foo=bar&id=7) dan zorg je dat de server 't vertikt daar antwoord op te geven.

[ Voor 18% gewijzigd door RobIII op 04-07-2013 10:58 ]

[GlowMouse]

RobIII schreef op donderdag 04 juli 2013 @ 10:56:
[...]

Omdat het geen probleem is.

Dat zegt hij toch ook?

[ Voor 11% gewijzigd door GlowMouse op 04-07-2013 10:58 ]

[BoringDay]

Rob ik heb geen idee wat je kennis is van ontwerpen van componenten in een echte omgeving. Maar als je daar heel goed in verdiept hebt dan ga je echt wel OOP waarderen op alle fronten. En als programmeur wil je een hyrachie hebben van objecten en beheersbaar houden. Daar wil je niet halve gare regel codes voor nodig hebben.

[Tharulerz]

BoringDay schreef op donderdag 04 juli 2013 @ 10:53:
Als JS echte OOP was geweest zeker dan had je meer controle en meer structuur.

Ik ga deze quote boven mijn bed hangen denk ik. Kan ik elke dag met een glimlach gaan slapen!

[it0]

Ik vind deze thread trolltastisch!
Ik pak er de popcorn bij!

[RobIII]

BoringDay schreef op donderdag 04 juli 2013 @ 10:58:
Rob ik heb geen idee wat je kennis is van ontwerpen van componenten in een echte omgeving. Maar als je daar heel goed in verdiept hebt dan ga je echt wel OOP waarderen op alle fronten.

Oh, nou, dan ga ik me maar eens verdiepen in OOP. Misschien dat ik de afgelopen 15 jaar wel iets verkeerd heb gedaan

BoringDay schreef op donderdag 04 juli 2013 @ 10:58:
En als programmeur wil je een hyrachie hebben van objecten en beheersbaar houden. Daar wil je niet halve gare regel codes voor nodig hebben.

Even serieus: loop je nou gewoon te trollen of...?

[ Voor 7% gewijzigd door RobIII op 04-07-2013 11:06 ]

[Infinitive]

Overigens bestaat er ook al lang een "oplossing" voor het "probleem" (bewust tussen aanhalingstekens): namelijk terminal servers in kiosk-mode. Een terminal-server sessie is nog een gevirtualiseerd object ook, dus krijg je zelfs de cloud erbij.

[martin_v_z]

BoringDay schreef op donderdag 04 juli 2013 @ 10:56:
@martin voor het grote deel gebeurd dat ook server-side, namelijk wordt daar ook het template bepaald.
Dat is verder ook geen probleem omdat die vrij eenvoudig is aan te passen.

Als het allemaal server side geregeld is zie ik ook geen probleem in als een user zelf gaat klooien in de scripts van de website. Het wordt alleen een probleem indien de user door wijzigingen aan te passen iets kan doen op de server. Bijvoorbeeld met een SQL injection. Maar dat is alleen mogelijk indien er fouten zijn gemaakt in de server side. Het zou mij echt een zorg wezen wat een gebruiker zelf client side doet. Niets weerhoud hem er namelijk van om zelf een website te bouwen die eventueel met jouw server communiceert.

[michiel_hc]

Wat ik altijd doe is de menu structuur in html of wat anders eerst met php opbouwen en dan met javascript de juiste delen weergeven. Dan zorg je er voor dat de onderdelen van het menu die niet weergegeven mogen worden niet clientside te vinden zijn. Dit geld ook voor formulier checks, eerst met javascript alles checken als het verzonden is (om de gebruiker een snelle response te geven) en dan serverside voor het verzenden naar de database het nog een keer check om te kijken of de gebruiker javascript niet uit heeft staan of heeft lopen spelen met javascript.

[Ozzie]

BoringDay schreef op donderdag 04 juli 2013 @ 10:58:
Rob ik heb geen idee wat je kennis is van ontwerpen van componenten in een echte omgeving. Maar als je daar heel goed in verdiept hebt dan ga je echt wel OOP waarderen op alle fronten. En als programmeur wil je een hyrachie hebben van objecten en beheersbaar houden. Daar wil je niet halve gare regel codes voor nodig hebben.

Ik denk dat de meeste programmeurs in de DevSchuur RobIII zijn mening meestal wel waarderen.

[EddoH]

Wacht! Dit is dezelfde BoringDay die laatst helemaal los ging op OOP in het "Ik wil leren programmeren - topic".

Ter info: Hij is erg goed in het aanhalen van 'OOP' bij totaal ongerelateerde onderwerpen en technieken. Daarnaast snapt niemand in de wereld wat 'OOP' is behalve hijzelf.

[BoringDay]

Discussie lijkt me zinloos, als jezelf je echo wil blijven strelen prima vooral doen maar hou mij er dan buiten. Daarbij ben ik zeker niet de enige ontwikkelaar die talen als JS ver onder de maat vinden.

[Amras]

BoringDay schreef op donderdag 04 juli 2013 @ 11:10:
Discussie lijkt me zinloos, als jezelf je echo wil blijven strelen prima vooral doen maar hou mij er dan buiten. Daarbij ben ik zeker niet de enige ontwikkelaar die talen als JS ver onder de maat vinden.

Er is zeker nog wel iets te wensen voor webontwikkelaars en JS heeft inderdaad zijn mankementen, maar dat is volgens mij niet omdat het geen OO-taal is.

[watercoolertje]

BoringDay schreef op donderdag 04 juli 2013 @ 11:10:Daarbij ben ik zeker niet de enige ontwikkelaar die talen als JS ver onder de maat vinden.

Of JS goed/slecht is is hier niet eens aan de orde, jij wil dingen waar het niet voor bedoeld is. Dat ligt gewoon aan jouw.

Ik ga toch ook niet met een waterpistool mensen proberen dood te schieten. Of met een echt pistool mensen proberen nat te spuiten

[ Voor 6% gewijzigd door watercoolertje op 04-07-2013 11:19 ]

[MueR]

Niemand wil z'n echo strelen. Het probleem is een beetje dat niemand snapt wat je nou allemaal voor onzin uitkraamt. Je hele relaas slaat echt als een lul op een drumstel en daar helpt honderd keer OOP roepen echt geen meter bij. Javascript is brak want jij denkt dat je aan de serverkant geen security hoeft in te bouwen. Raar he, een clientside taal die zichtbaar is. Als je dan vervolgens ook nog gaat zaniken dat PHP ruk is omdat woensdag een mooie kleur is nemen we je natuurlijk helemaal niet meer serieus.

Javascript is clientside. Punt.
Javascript is een toevoeging voor je rendering. Punt.
Dat wordt clientside uitgevoerd. Punt.
Daar heb jij geen controle over. Punt.
Zorg voor security in de server kant. Symptoom opgelost.

[RobIII]

BoringDay schreef op donderdag 04 juli 2013 @ 11:10:
Daarbij ben ik zeker niet de enige ontwikkelaar die talen als JS ver onder de maat vinden.

RobIII schreef op donderdag 04 juli 2013 @ 10:45:
Er is zat aan te merken op PHP / JS (en elke andere taal (ja, ook Delphi) en/of platform)

Jij vindt, in dit topic, JS ver onder de maat for all the wrong reasons Maar goed, discussie is inderdaad zinloos dus ik hou 't er hier ook verder bij

[incaz]

watercoolertje schreef op donderdag 04 juli 2013 @ 11:19:
[...]Ik ga toch ook niet met een waterpistool mensen proberen dood te schieten...

Betere analogie lijkt me een watergevecht houden met een echt (en geladen) pistool, en dan klagen dat mensen eraan dood gaan.

[MueR]

Javascript hoort niet in Programming, maar in Webdesign, Markup & Clientside Scripting. Ik verplaats het topic even, hoeven jullie ook niet met je adresbalk te klooien.

[Douweegbertje]

haha jeetje even posten in een epische thread hoor

Maar BoringDay, snap je nu eigenlijk wel het idee achter JS? Het clientside gedeelte?
Anders kan niemand je meer helpen namelijk.

Overigens waarom zit je JS zo hard te bashen? HTML is precies het zelfde, delen van PHP ook.
PHP gebruikt ook zo vaak user input.. het doel is dat JIJ het goed afhandelt, daar kun je geen enkele taal de schuld van geven.

[storeman]

Erg vermakelijk de reacties hier! Alles wat gezegd wordt kan ik hier beamen, behalve de uitspraken van BoringDay.

HTML is ook niet lekker, dat kan ik met elke moderne browser gewoon wijzigen. Als ik dat doe, dan ziet het er verkeerd uit. Daar is CSS verantwoordelijk voor. Waren beide maar volledig OOP, dan was het internet tenminste veilig!

Maar serieus, wat denk je nu? Je kan gewoon je HTML source inzien, dus al was javascript waterdicht, dan kon ik nog steeds verborgen elementen zien en dus eventuele links.

Daarnaast, JS is een prachttaal. Prototyping is heerlijk krachtig maar inderdaad, niet OOP, want prototyped. Als je niet in de prototype gedachte kunt werken, dan kan ik je aanraden om eens naar MooTools te kijken. Deze faked de OOP gedachte en is soms best handig. Echter geneest het JS niet op de manier waarop jij dat zou willen.

[curry684]

BoringDay schreef op donderdag 04 juli 2013 @ 10:58:
Rob ik heb geen idee wat je kennis is van ontwerpen van componenten in een echte omgeving. Maar als je daar heel goed in verdiept hebt dan ga je echt wel OOP waarderen op alle fronten. En als programmeur wil je een hyrachie hebben van objecten en beheersbaar houden. Daar wil je niet halve gare regel codes voor nodig hebben.

Ja Rob, luister eens naar die jongen. Daar kun je nog veel van leren. Hyrarchie is belangrijk.

[Creepy]

En met al dat getroll gaat het topic ook dicht. Reageer normaal, of reageer niet en plaats een TR als je denkt dat dat nodig is.