Live editors voor HTML

[ViNyL]

Misschien echt maar ik vraag me het volgende af.

Stel ik heb een dropdown menu op een form. Nu ga ik live in de source van die pagina de "value" key van die optie wijzigen (value="a" naar value="muhaha" en ik POST dit. Dan wordt de waarde die ik heb aangepast in de bron toch gewoon gepost?

Als je een hele boel opties in een dropdown hebt (bijvoorbeeld de categorie die een user kiest voor Vraag & Aanbod), check je de post value dan tegen een array met alle categorien om te kijken of deze wel voorkomt en niet door de user is aangepast in de bron? Anders zou je een niet bestaande categorie kunnen kiezen natuurlijk.

[RobIII]

ViNyL schreef op woensdag 19 december 2012 @ 15:19:
Als je een hele boel opties in een dropdown hebt (bijvoorbeeld de categorie die een user kiest voor Vraag & Aanbod), check je de post value dan tegen een array met alle categorien om te kijken of deze wel voorkomt en niet door de user is aangepast in de bron?

Ja, natuurlijk (althans: zo hoort 't). Never trust user input.
Los daarvan; een waarde kiezen die niet bestaat zal in veel gevallen (bijvoorbeeld) stuiten op een Foreign key constraint oid als je het goed hebt gedaan. Ook zul je in veel gevallen nog moeten controleren of de gebruiker überhaupt gemachtigd is om keuze X te kiezen. En zo zijn er nog wel een zooi checks waar je, als het goed is, tegenaan moet lopen. Dat je voorgedefinieerde waardes in een dropdown zet wil niet zeggen dat je andere "meuk" niet binnen krijgt

[ Voor 34% gewijzigd door RobIII op 19-12-2012 15:22 ]

[ViNyL]

Ok,.just checking Het leek me al het meest logische.

[Stroopwafels]

Alles wat door de client verzonden wordt, moet ook bij de server gecontroleerd worden.

[RobIII]

Overigens; dit geldt natuurlijk niet alleen voor "Live editors" (ik neem aan dat je doelt op Firebug/IE F12 Dev.tools/Chrome Dev.tools/Safari Dev.tools/Opera Dragonfly en consorten). Elk willekeurig stuk code (doorgaans een scriptje van 3 regels of een cURL opdrachtje oid) kan natuurlijk ook gewoon een zooi values naar je server sturen (POST-en).

[ Voor 5% gewijzigd door RobIII op 19-12-2012 15:25 ]

[mcDavid]

Volgens mij is het best knap om een (nuttig) script te verzinnen dat uberhaupt iets gaat doen met POST headers die niet bekend zijn?

[RobIII]

mcDavid schreef op woensdag 19 december 2012 @ 15:25:
Volgens mij is het best knap om een (nuttig) script te verzinnen dat uberhaupt iets gaat doen met POST headers die niet bekend zijn?

Je zou, bijvoorbeeld, hier op GoT kunnen (proberen) een bericht te posten in een forum waar je helemaal geen rechten hebt (zoals een crewforum). Of een POST doen naar onze "admin omgeving" om jezelf meer rechten toe te kennen dan je nu hebt. Of in een willekeurig betaalsysteem proberen je order met een negatief bedrag te plaatsen zodat je én je wasmachine krijgt én een bak geld erbij En zo kun je nog uren doorgaan.

[ Voor 7% gewijzigd door RobIII op 19-12-2012 15:28 ]

[ViNyL]

mcDavid schreef op woensdag 19 december 2012 @ 15:25:
Volgens mij is het best knap om een (nuttig) script te verzinnen dat uberhaupt iets gaat doen met POST headers die niet bekend zijn?

Dat hoeft toch ook niet? Je past de bron aan voor je uberhaupt post en voila.

RobIII schreef op woensdag 19 december 2012 @ 15:24:
Overigens; dit geldt natuurlijk niet alleen voor "Live editors" (ik neem aan dat je doelt op Firebug/IE F12 Dev.tools/Chrome Dev.tools/Safari Dev.tools/Opera Dragonfly en consorten). Elk willekeurig stuk code (doorgaans een scriptje van 3 regels of een cURL opdrachtje oid) kan natuurlijk ook gewoon een zooi values naar je server sturen (POST-en).

Ik bedoel inderdaad de editors. De andere trucs kende ik al wel, alleen ik had hier nooit echt bij stil gestaan.

[mcDavid]

RobIII schreef op woensdag 19 december 2012 @ 15:28:
[...]


Je zou, bijvoorbeeld, hier op GoT kunnen (proberen) een bericht te posten in een forum waar je helemaal geen rechten hebt (zoals een crewforum). Of een POST doen naar onze "admin omgeving" om jezelf meer rechten toe te kennen dan je nu hebt. Of in een willekeurig betaalsysteem proberen je order met een negatief bedrag te plaatsen zodat je én je wasmachine krijgt én een bak geld erbij En zo kun je nog uren doorgaan.

Maar dan zijn het altijd bekende variablen die ik post.

Als ik een POST- of GET-variable "blablaonzinonzin=foobar" toe voeg, zou ik het op zijn minst zéér opmerkelijk vinden als daar uberhaupt op gecontroleerd zou worden, laat staan iets mee gedaan (kan) worden.

Als het gaat om bestaande POST- of GET variablen, dan is het inderdaad wel gebruikelijk dat je de input checkt of deze a) geldig is, en b) toegankelijk is voor de user (in het geval van inlogs en afgeschermde content of functies)

(en ik zie dat het inderdaad om dat tweede gaat, ik dacht abusievelijk dat het in de startpost om dat eerste ging)

[ Voor 5% gewijzigd door mcDavid op 19-12-2012 16:52 ]

[RobIII]

mcDavid schreef op woensdag 19 december 2012 @ 16:51:
Als ik een POST- of GET-variable "blablaonzinonzin=foobar" toe voeg, zou ik het op zijn minst zéér opmerkelijk vinden als daar uberhaupt op gecontroleerd zou worden, laat staan iets mee gedaan (kan) worden.

Moet je eens lezen wat mass assignment (ook wel overposting genoemd) is

[mcDavid]

...Finding and fixing mass assignment problems...
...The mass-assignment feature may become a problem, as it allows an attacker to ...
...Hackers Love Mass Assignment...
...Mass assignment vulnerability...

Eh, nee laat maar

[RobIII]

mcDavid schreef op woensdag 19 december 2012 @ 18:01:
Eh, nee laat maar

Steek je kop maar in 't zand ja

[Ellos]

Simpel te fixen toch?
Als het er al insluipt.

Ook nog eens Rails only gedrag zoals ik het hier zie (uiteraard vast wel varianten in andere talen te vinden, maar staan niet zomaar aan, doet me denken aan REGISTER_GLOBAL.)

[RobIII]

Ellos schreef op woensdag 19 december 2012 @ 19:36:
Ook nog eens Rails only gedrag zoals ik het hier zie

ASP.Net MVC heeft er ook last van als je niet oppast en waarschijnlijk zo'n beetje élk platform waarschijnlijk wel waar gebruik wordt gemaakt van een ORM/Datamapper bijvoorbeeld die een POST -> Entity mapped zonder tussenliggende (of "overpostbare") viewmodels.

Ellos schreef op woensdag 19 december 2012 @ 19:36:
(uiteraard vast wel varianten in andere talen te vinden, maar staan niet zomaar aan, doet me denken aan REGISTER_GLOBAL.)

Zoals de alinea hierboven: élk platform is hier vatbaar voor en het heeft niets met REGISTER_GLOBAL te maken (hoewel 't er inderdaad wel op lijkt van buitenaf); PHP + <random_ORM/Datamapper> is hier, mits niet goed geconfigureerd of rekening mee gehouden dus ook 'vatbaar' voor (eerste voorbeeldje dat ik kon vinden zo snel).

Als je het principe begrijpt zul je zien dat 't overal voor kan komen, ongeacht het platform (net als SQL injection of CSRF etc.)

[ Voor 24% gewijzigd door RobIII op 19-12-2012 20:00 ]

[Grijze Vos]

Overposting is ook meer een probleem van slechte layering van je applicatie. Als je gewoon 'netjes' viewmodels definieert voor je in en outputs, en dan de mapping van die viewmodels van en naar je datalayer, ipv direct je datalayer entities te exposen, dan ben je er al.

Het probleem bij rails en asp.net mvc is juist dat alle voorbeelden in tutorials die men geeft precies dat doen wat insecure is. asp.net mvc is in die zin nog erger, omdat MS hun hele webstack zo ge-ent hebben op direct gebruik van EF entities aan de voorkant.

[RobIII]

Grijze Vos schreef op donderdag 20 december 2012 @ 08:44:
Als je gewoon 'netjes' viewmodels definieert voor je in en outputs, en dan de mapping van die viewmodels van en naar je datalayer, ipv direct je datalayer entities te exposen, dan ben je er al

Dat hoeft natuurlijk niet zo te zijn. Als je een viewmodel hebt voor, zeg, een gebruiker, waarmee beheerders gebruikers kunnen wijzigen dat een IsAdmin property bevat en datzelfde viewmodel ook gebruikt voor gewone gebruikers die daarmee, zeg, hun DisplayName kunnen wijzigen en je mikt dat viewmodel recht naar een UserEntity dan ga je alsnog nat als je (bijv. in het geval van ASP.Net MVC) bij de (Try)UpdateModel niet aangeeft dat je het IsAdmin property wil excluden (blacklist) of juist de rest wil includen (whitelist) in de Save() method van je UserController wanneer een gebruiker geen admin is. Of je moet twee viewmodels maken waarbij het IsAdmin property (in dit simpele voorbeeld) het enige verschil is; gebruikers krijgen een UserModel en admins krijgen een UserModelForAdmins voor hun neus en mogelijk gebruik je zelfs aparte Save() methods of zelfs aparte controllers. Either way: je bent dus niet per definitie veilig en een dergelijke "shortcut" die ik hier beschrijf zal ook meer dan eens genomen worden.

[ Voor 17% gewijzigd door RobIII op 20-12-2012 08:59 ]

[R4gnax]

RobIII schreef op donderdag 20 december 2012 @ 08:56:
[...]

Of je moet twee viewmodels maken waarbij het IsAdmin property (in dit simpele voorbeeld) het enige verschil is; gebruikers krijgen een UserModel en admins krijgen een UserModelForAdmins voor hun neus

Nee. Je moet view models maken die specifiek op één scenario ge-ent zijn. Dat is waar view models origineel voor bedoeld waren; een extra lijmlaag tussen je view en je echte model, welke het model ombouwt om directer op de specifieke rendering concerns van een view aan te sluiten.

Wat Grijze Vos voorstelt is dat je ook een specifiek ge-ent view model gebruikt voor de parameters in de action methods van je controllers. Daarmee wordt over-posting dus feitelijk inderdaad onmogelijk gemaakt.

[RobIII]

R4gnax schreef op donderdag 20 december 2012 @ 09:06:
Nee. Je moet view models maken die specifiek op één scenario ge-ent zijn.

I know De strekking van mijn post staat dan ook in de laatste zin:

Either way: je bent dus niet per definitie veilig en een dergelijke "shortcut" die ik hier beschrijf zal ook meer dan eens genomen worden.

Als je strict bent zit je inderdaad goed, maar ik ken zat devvers die niet zo strikt zijn

[Ellos]

Hmm ja, nou ik het eens nader bekeken heb is dit inderdaad op heel wat platformen mogelijk.
Register global deed me er ook aan denken niet dat het 100% gelijk gedrag was

Ik ben alleen zelf altijd wel van het netjes creeren van specifieke objecten (viewmodels of enkel DTO's) dus ben ik dit probleem ook nog niet eerder tegengekomen, ik zal er nu in ieder geval code van andere op bewust zijn