Bekijk Volledige Versie : Veiligheid gegevens doorgeven met get en post
Paul van der Vlis
08/10/03, 15:15
Hoi,
De methode "get" heeft als nadeel dat mensen gegevens in de URL kunnen
gaan veranderen.
Is er ook een methode om de gegevens die je doorgeeft met "post" te
veranderen? Met andere woorden: hoe veilig is de methode "post"?
Met vriendelijke groet,
Paul van der Vlis.
Ronald Klip
08/10/03, 15:30
Paul van der Vlis schreef:
> Hoi,
Hoi,
> De methode "get" heeft als nadeel dat mensen gegevens in de URL kunnen
> gaan veranderen.
>
> Is er ook een methode om de gegevens die je doorgeeft met "post" te
> veranderen? Met andere woorden: hoe veilig is de methode "post"?
Je bezoeker zou zelf een formulier kunnen maken en de naar smaak
ingevulde gegevens kunnen posten naar jouw server. Of hzij kan een
scriptje maken dat een http-request nabootst. M.a.w.: het kan wel, maar
het is wat omslachtiger dan het bewerken van een URL.
Veilig is het geheel pas als jouw applicatie alle data die binnenkomt
goed bekijkt.
--
groet, Ronald
Paul van der Vlis
08/10/03, 17:15
Ronald Klip wrote:
> Paul van der Vlis schreef:
>>De methode "get" heeft als nadeel dat mensen gegevens in de URL kunnen
>>gaan veranderen.
>>
>>Is er ook een methode om de gegevens die je doorgeeft met "post" te
>>veranderen? Met andere woorden: hoe veilig is de methode "post"?
>
> Je bezoeker zou zelf een formulier kunnen maken en de naar smaak
> ingevulde gegevens kunnen posten naar jouw server. Of hzij kan een
> scriptje maken dat een http-request nabootst. M.a.w.: het kan wel, maar
> het is wat omslachtiger dan het bewerken van een URL.
Bedankt.
> Veilig is het geheel pas als jouw applicatie alle data die binnenkomt
> goed bekijkt.
Waar zou ik zoal op kunnen checken?
Als ik zou kunnen controleren of de vorige pagina (die de aanvraag doet)
op localhost staat, dan ben ik al een heel eind lijkt me. Maar hoe ik
dat zou kunnen controleren weet ik even niet..
Groet,
Paul.
Paul van der Vlis
08/10/03, 17:30
Paul van der Vlis wrote:
>> Veilig is het geheel pas als jouw applicatie alle data die binnenkomt
>> goed bekijkt.
>
> Waar zou ik zoal op kunnen checken?
>
> Als ik zou kunnen controleren of de vorige pagina (die de aanvraag doet)
> op localhost staat, dan ben ik al een heel eind lijkt me. Maar hoe ik
> dat zou kunnen controleren weet ik even niet..
Om nog even terug te komen op mijn vraag: hoe kan een "inbreker" te
weten komen welke hidden variabelen ik doorgeef bij post? Volgens mij
kan hij dat niet, en is daardoor een hidden variabele al een behoorlijk
goede beveiliging. Is dat correct?
Groet,
Paul.
Ronald Klip
08/10/03, 17:45
Paul van der Vlis schreef:
>
> Om nog even terug te komen op mijn vraag: hoe kan een "inbreker" te
> weten komen welke hidden variabelen ik doorgeef bij post? Volgens mij
> kan hij dat niet, en is daardoor een hidden variabele al een behoorlijk
> goede beveiliging. Is dat correct?
Hidden fields staan open en bloot in de html-source. Bij posten worden
ze net als bij GET open en bloot over het net gestuurd en kan een derde
ze onderscheppen - tenzij je een SSL-verbinding gebruikt (https).
--
groet, Ronald
Daniel Tryba
08/10/03, 18:00
Paul van der Vlis <paul@vandervlis.nl> wrote:
> Om nog even terug te komen op mijn vraag: hoe kan een "inbreker" te
> weten komen welke hidden variabelen ik doorgeef bij post? Volgens mij
> kan hij dat niet, en is daardoor een hidden variabele al een behoorlijk
> goede beveiliging.
Wat dacht je van de source te bekijken? Of een packetsniffer renaast te
houden?
>Is dat correct?
Nee dus.
--
Daniel Tryba
Paul van der Vlis
08/10/03, 19:15
Ronald Klip wrote:
> Paul van der Vlis schreef:
>
>>Om nog even terug te komen op mijn vraag: hoe kan een "inbreker" te
>>weten komen welke hidden variabelen ik doorgeef bij post? Volgens mij
>>kan hij dat niet, en is daardoor een hidden variabele al een behoorlijk
>>goede beveiliging. Is dat correct?
>
> Hidden fields staan open en bloot in de html-source. Bij posten worden
> ze net als bij GET open en bloot over het net gestuurd en kan een derde
> ze onderscheppen - tenzij je een SSL-verbinding gebruikt (https).
Oeps, je hebt gelijk. Bedankt.
Groet,
Paul.
Paul van der Vlis
08/10/03, 19:15
Daniel Tryba wrote:
> Paul van der Vlis <paul@vandervlis.nl> wrote:
>
>>Om nog even terug te komen op mijn vraag: hoe kan een "inbreker" te
>>weten komen welke hidden variabelen ik doorgeef bij post? Volgens mij
>>kan hij dat niet, en is daardoor een hidden variabele al een behoorlijk
>>goede beveiliging.
>
> Wat dacht je van de source te bekijken? Of een packetsniffer renaast te
> houden?
>
>>Is dat correct?
>
> Nee dus.
Bedankt.
Groet,
Paul.
Nico Coesel
08/10/03, 19:30
Paul van der Vlis <paul@vandervlis.nl> wrote:
>Paul van der Vlis wrote:
>
>>> Veilig is het geheel pas als jouw applicatie alle data die binnenkomt
>>> goed bekijkt.
>>
>> Waar zou ik zoal op kunnen checken?
>>
>> Als ik zou kunnen controleren of de vorige pagina (die de aanvraag doet)
>> op localhost staat, dan ben ik al een heel eind lijkt me. Maar hoe ik
>> dat zou kunnen controleren weet ik even niet..
>
>Om nog even terug te komen op mijn vraag: hoe kan een "inbreker" te
>weten komen welke hidden variabelen ik doorgeef bij post? Volgens mij
>kan hij dat niet, en is daardoor een hidden variabele al een behoorlijk
>goede beveiliging. Is dat correct?
Nee, de hidden variabelen staan gewoon in de source. Wat je wel kunt
doen is de waardes van variabelen die je al weet in een sessie opslaan
(op de server) zodat je alleen de waardes via een get of post krijgt
die je nog niet weet. Een ander voordeel van sessies is dat je ook
vrijwel zeker weet dat de persoon die de pagina opvraagt ook de vorige
pagina (en de pagina daarvoor, etc, etc) heeft bekeken.
--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
On Wed, 08 Oct 2003 15:05:44 +0200, Paul van der Vlis
<paul@vandervlis.nl> wrote:
>Hoi,
>
>De methode "get" heeft als nadeel dat mensen gegevens in de URL kunnen
>gaan veranderen.
>
>Is er ook een methode om de gegevens die je doorgeeft met "post" te
>veranderen? Met andere woorden: hoe veilig is de methode "post"?
Mensen kunnen alles, maar wat versta jij onder veilig?
--
Ronald - Web Forum for Mailtraq:
http://lijsten.xs4all.nl/webforum/index.asp?id=1
Arend van der Boom
08/10/03, 22:45
On Wed, 08 Oct 2003 17:12:40 +0200, Paul van der Vlis wrote:
<knip>>
>> Veilig is het geheel pas als jouw applicatie alle data die binnenkomt
>> goed bekijkt.
>
> Waar zou ik zoal op kunnen checken?
>
Je FORM variabelen controleren op grootte en of er geen 'vreemde'
commando's mee worden gegeven.
Just my 0.02Eurie
--
Arend van der Boom
#--/\---------^-^-^-^-^----- - -//-~~>
Homepage - http://home.kabelfoon.nl/~avdboom
LCARS - http://lcarsscan.dyndns.org
KTZ - http://kabelzone.dyndns.org
Paul van der Vlis
09/10/03, 11:45
Nico Coesel wrote:
> Paul van der Vlis <paul@vandervlis.nl> wrote:
>
>
>>Paul van der Vlis wrote:
>>
>>
>>>>Veilig is het geheel pas als jouw applicatie alle data die binnenkomt
>>>>goed bekijkt.
>>>
>>>Waar zou ik zoal op kunnen checken?
>>>
>>>Als ik zou kunnen controleren of de vorige pagina (die de aanvraag doet)
>>>op localhost staat, dan ben ik al een heel eind lijkt me. Maar hoe ik
>>>dat zou kunnen controleren weet ik even niet..
>>
>>Om nog even terug te komen op mijn vraag: hoe kan een "inbreker" te
>>weten komen welke hidden variabelen ik doorgeef bij post? Volgens mij
>>kan hij dat niet, en is daardoor een hidden variabele al een behoorlijk
>>goede beveiliging. Is dat correct?
>
>
> Nee, de hidden variabelen staan gewoon in de source. Wat je wel kunt
> doen is de waardes van variabelen die je al weet in een sessie opslaan
> (op de server) zodat je alleen de waardes via een get of post krijgt
> die je nog niet weet. Een ander voordeel van sessies is dat je ook
> vrijwel zeker weet dat de persoon die de pagina opvraagt ook de vorige
> pagina (en de pagina daarvoor, etc, etc) heeft bekeken.
Ik zal me eens wat meer in sessies verdiepen, tot nu toe sla ik de data
steeds direct op in de database.
Nadeel lijkt me, dat het met cookies of sessie-ID's in de URL werkt,
beide hebben hun nadelen.
Groet,
Paul.
Paul van der Vlis
09/10/03, 11:45
Arend van der Boom wrote:
> On Wed, 08 Oct 2003 17:12:40 +0200, Paul van der Vlis wrote:
>
> <knip>>
>
>>>Veilig is het geheel pas als jouw applicatie alle data die binnenkomt
>>>goed bekijkt.
>>
>>Waar zou ik zoal op kunnen checken?
>
> Je FORM variabelen controleren op grootte
Je bedoeld een maximum in de lengte?
> en of er geen 'vreemde' commando's mee worden gegeven.
Je bedoeld in de string gaan zoeken naar bepaalde zaken? Zo ja, welke zaken?
Het gebruik van https, controle op IP-nummer, en een sessie time-out
lijken me ook goed.
Groet,
Paul.
Paul van der Vlis
09/10/03, 13:00
RvB wrote:
> On Wed, 08 Oct 2003 15:05:44 +0200, Paul van der Vlis
> <paul@vandervlis.nl> wrote:
>>Is er ook een methode om de gegevens die je doorgeeft met "post" te
>>veranderen? Met andere woorden: hoe veilig is de methode "post"?
> Mensen kunnen alles, maar wat versta jij onder veilig?
Dat een derde niet aan de data kan komen, die iemand anders heeft
ingevult. En daarbij gaat het me dan niet zozeer om de beveiliging van
de server (dat is niet mijn verantwoordelijkheid), maar om de PHP en
HTML pagina's waarvoor ik wel verantwoordelijk ben.
Wat versta je onder "alles"?
Volgens mij kunnen mensen niet alles ;-)
Groet,
Paul.
On Thu, 09 Oct 2003 12:59:56 +0200, Paul van der Vlis
<paul@vandervlis.nl> wrote:
>RvB wrote:
>> On Wed, 08 Oct 2003 15:05:44 +0200, Paul van der Vlis
>> <paul@vandervlis.nl> wrote:
>
>>>Is er ook een methode om de gegevens die je doorgeeft met "post" te
>>>veranderen? Met andere woorden: hoe veilig is de methode "post"?
>
>> Mensen kunnen alles, maar wat versta jij onder veilig?
>
>Dat een derde niet aan de data kan komen, die iemand anders heeft
>ingevult. En daarbij gaat het me dan niet zozeer om de beveiliging van
>de server (dat is niet mijn verantwoordelijkheid), maar om de PHP en
>HTML pagina's waarvoor ik wel verantwoordelijk ben.
>
>Wat versta je onder "alles"?
>Volgens mij kunnen mensen niet alles ;-)
Op dat vlak wel, en als je wilt beveiligen moet je daar ook vanuit gaan
in het kiezen van een goede beveiligingstrategie.
--
Ronald - Web Forum for Mailtraq:
http://lijsten.xs4all.nl/webforum/index.asp?id=1
Paul van der Vlis wrote:
> Paul van der Vlis wrote:
>
>>> Veilig is het geheel pas als jouw applicatie alle data die binnenkomt
>>> goed bekijkt.
>>
>> Waar zou ik zoal op kunnen checken?
>>
>> Als ik zou kunnen controleren of de vorige pagina (die de aanvraag doet)
>> op localhost staat, dan ben ik al een heel eind lijkt me. Maar hoe ik
>> dat zou kunnen controleren weet ik even niet..
>
> Om nog even terug te komen op mijn vraag: hoe kan een "inbreker" te
> weten komen welke hidden variabelen ik doorgeef bij post? Volgens mij
> kan hij dat niet, en is daardoor een hidden variabele al een behoorlijk
> goede beveiliging. Is dat correct?
Nee, google eens op bookmarklets, en kijk dan eens bij bookmarklets voor
forms. Daarnaast kan je met een simpel perl scriptje zo een browser
nabootsen en alles aanpassen.
Mark
Paul van der Vlis wrote:
> Hoi,
>
> De methode "get" heeft als nadeel dat mensen gegevens in de URL kunnen
> gaan veranderen.
>
> Is er ook een methode om de gegevens die je doorgeeft met "post" te
> veranderen? Met andere woorden: hoe veilig is de methode "post"?
_NIKS_ veiliger dan get. Weliswaar kan je niet de url aanpassen, en is
het aanpassen wat moeilijker voor een leek, maar het is echt even simpel
aan te passen. Beveiliging dien je daarnaast serverside, en niet
clientside te doen.
Mark
Paul van der Vlis wrote:
> Arend van der Boom wrote:
>> On Wed, 08 Oct 2003 17:12:40 +0200, Paul van der Vlis wrote:
>>
>> <knip>>
>>
>>>>Veilig is het geheel pas als jouw applicatie alle data die binnenkomt
>>>>goed bekijkt.
>>>
>>>Waar zou ik zoal op kunnen checken?
>>
>> Je FORM variabelen controleren op grootte
>
> Je bedoeld een maximum in de lengte?
Serverside checken, clientside maximum kan je heel simpel overriden.
>> en of er geen 'vreemde' commando's mee worden gegeven.
>
> Je bedoeld in de string gaan zoeken naar bepaalde zaken? Zo ja, welke zaken?
bijvoorbeeld, jij hebt een script dat een dirlisting kan geven. je
krijgt als invoer een directorynaam, en geeft als uitvoer de inhoud van
die directory, hiervoor gebruik je onder andere het volgende commando:
system("ls -la " + $dir);
waarbij $dir dus de variabele is die je van de form meekrijgt. Als
iemand nu bijvoorbeeld in dir het volgende zet:
/ ; rm -rf ~/
en je controleert de invoer niet, dan heb je na uitvoer een lege
homedirectory :(
Mark
Paul van der Vlis wrote:
> RvB wrote:
>> On Wed, 08 Oct 2003 15:05:44 +0200, Paul van der Vlis
>> <paul@vandervlis.nl> wrote:
>
>>>Is er ook een methode om de gegevens die je doorgeeft met "post" te
>>>veranderen? Met andere woorden: hoe veilig is de methode "post"?
>
>> Mensen kunnen alles, maar wat versta jij onder veilig?
>
> Dat een derde niet aan de data kan komen, die iemand anders heeft
> ingevult. En daarbij gaat het me dan niet zozeer om de beveiliging van
> de server (dat is niet mijn verantwoordelijkheid), maar om de PHP en
> HTML pagina's waarvoor ik wel verantwoordelijk ben.
Het enige wat het veiliger maakt is dat de url's niet in proxy logs
komen. Voor zaken als wachtwoorden moet je inderdaad ook post
gebruiken. Over het algemeen worden POST requests niet gelogd (iig niet
de parameters), door de history van de browser, proxy's, referrers, etc.
Mark
Arend van der Boom
11/10/03, 14:30
<knip>
>> Je FORM variabelen controleren op grootte
>
> Je bedoeld een maximum in de lengte?
>
Ja, dat een invoer veld voor een postcode b.v. niet meer dan 255 tekens
mag bevatten.
>> en of er geen 'vreemde' commando's mee worden gegeven.
>
> Je bedoeld in de string gaan zoeken naar bepaalde zaken? Zo ja, welke
> zaken?
>
Ik bedoel meer dat als je aan de hand van gebruikers invoer een shell
commando wilt laten uitvoeren 'wat iets doet' dat je die invoer dan
controleert. In PHP kan dat met de escapeshellcmd functies.
--
Arend van der Boom
#--/\---------^-^-^-^-^----- - -//-~~>
Homepage - http://home.kabelfoon.nl/~avdboom
KabArch - http://kabarch.dyndns.org
LCARS - http://lcarsscan.dyndns.org
KTZ - http://kabelzone.dyndns.org
Arend van der Boom wrote:
><knip>
>>> Je FORM variabelen controleren op grootte
>>
>> Je bedoeld een maximum in de lengte?
>>
> Ja, dat een invoer veld voor een postcode b.v. niet meer dan 255 tekens
> mag bevatten.
kan je beter (server-side) checken of die aan /^[0-9]{4,} ?[A-Z]{2,}$/
voldoet...
Mark