Origineel gepost door Vincent

Dan is het dus schijnveiligheid.
Je data wordt net zo goed verstuurd en in beide gevallen net zo makkelijk te manipuleren.

GET Manipuleren is makkelijker? Gewoon de URL veranderen... post is meer "kloten" ookal is het zo gedaan, maar we waren er al uit dat post veiliger was, lees ik? En ik denk dat de topic starter zijn antwoord ook al heeft.

Origineel gepost door Damiaan Reijnaers

GET Manipuleren is makkelijker? Gewoon de URL veranderen... post is meer "kloten" ookal is het zo gedaan, maar we waren er al uit dat post veiliger was, lees ik? En ik denk dat de topic starter zijn antwoord ook al heeft.

Daar waren "we" helemaal niet uit. GET is door elke idioot te manipuleren, maar dat maakt POST niet veiliger! Als iemand kwaad wil doen maakt het voor de veiligheid niet uit of je POST of GET gebruikt, het gaat erom hoe je met de gegevens uit zo'n POST- of GET-request omgaat.

Ik wil het zelfs nog sterker zeggen: als je POST gebruikt omdat dat veiliger zou zijn is dat in werkelijkheid onveiliger dan GET. Dan ben je je namelijk niet of minder bewust van de risico's.

Eindelijk nog iemand met verstand, zoals gezegd; het is schijnveiligheid.

Origineel gepost door Vincent

POST is net zo onveilig, ik weet niet hoe je er bij komt dat GET onveiliger is?

Not true

Veiligheid zit hem niet in de POST of GET maar in de programmeur die het programma ontwikkeld. Ik wil nu een enorm lang verhaal voorkomen dus wil ik even wijzen op het volgend punt:

"Gebruik waar het gebruikt voor moet worden, bij een formulier is dat dus POST!"

Origineel gepost door Arek van Schayk

Not true

Veiligheid zit hem niet in de POST of GET maar in de programmeur die het programma ontwikkeld. Ik wil nu een enorm lang verhaal voorkomen dus wil ik even wijzen op het volgend punt:

"Gebruik waar het gebruikt voor moet worden, bij een formulier is dat dus POST!"

Maar dan klopt het toch wat ik zeg, dat het beide net zo onveilig is?

Want je punt dat het uiteindelijk de software erachter is die het veilig maakt bewijst dat juist.

Origineel gepost door Vincent

Maar dan klopt het toch wat ik zeg, dat het beide net zo onveilig is?

Helemaal mee eens, tussen GET en POST zit geen verschil qua veiligheid.

Uiteindelijk maakt het helemaal niet uit of userdata via get, post, http, smtp of whatever binnenkomt. Controleren moet je het toch en in zoverre is het allemaal 'even' veilig/onveilig.

Maar veiligheid heeft niet alleen te maken met het checken van je code natuurlijk. Dat is maar een deel ervan. Ook het minder toegankelijk voor de meute maken is een onderdeel van je beveiliging. Voorkomen dat logingegevens via een achterdeur zoals de weblogs opeens op straat liggen, hoort ook gewoon bij beveiliging.

@Vincent, in pricipe heb je ook gelijk wat betreft de veiligheid van get/post (in het algemeen), maar in de context van een loginscherm is een get gebruiken gewoon fout, terwijl het in de context van een zoekfunktie, een get veel gebruikersvriendelijker en meestal ook beter is.

Origineel gepost door Vincent

Maar dan klopt het toch wat ik zeg, dat het beide net zo onveilig is?

Want je punt dat het uiteindelijk de software erachter is die het veilig maakt bewijst dat juist.

Oh sorry, lees nu even alle quotes terug maar je gaat inderdaad in op iemand die beweerd dat iets onveiliger is. Dat was dus niet echt de bedoeling.
Maar inderdaad, de software bepaald de veiligheid. En gebruik POST gewoon waar je POST moet gebruiken.

Bedankt voor al jullie antwoorden. Wil het liefst wel gewoon POST blijven gebruiken. Back button zit al in de website maar is toch vervelend als mensen de back button in de browser gebruiken en ze krijgen dan zo'n error. Is dat niet op te lossen op een simpele manier ??

Origineel gepost door John Timmer

Omdat je hiermee het probleem van de back button makkelijk oplost. Heeft niks met de veiligheid te maken uiteraard, maar dat weet je vast ook wel ;)

SSL helpt overigens niets met een GET. In dat geval wordt eerst de url naar een get omgevormt en dan welliswaar over SSL verstuurd.... Maar hij komt toch leesbaar in de logs te staan, kan eenvoudig gebookmarkt worden en kan zelfs door de gebruiker doorgestuurd worden naar een andere gebruiker. Het maakt het alleen iets lastiger om 'onderweg' de boel te wijzigen.

Oke, ja dat kan
@GET en SSL: Dacht ik al, dit wist ik niet zeker dus dan ga ik dit ook niet roepen;) Bedankt voor de info.

Is het anders mogelijk toch een $_GET te gebruiken maar dat na het inloggen de username en password wel uit de adresbalk verdwijnen ? De site waarvoor de login is, is niet top secret ofzo dus als er ooit een ongenode gast binnenkomt is dat geen ramp. Daarom ook dit vrij basic login script.

[edit]
Ik haal 2topics door elkaar, na het zien van de startpost zal dit voldoende moeten zijn:

PHP Code:

function showform()
{
?>
<meta http-equiv="REFRESH" content="0;URL=http://www.site.com/index.php">
<?php
}
?>

Veranderen in:

PHP Code:

function showform()
{
die(header("Location: http://www.site.com/index.php"));
}
?> 


[/edit]

Origineel gepost door Vincent

Eindelijk nog iemand met verstand, zoals gezegd; het is schijnveiligheid.

Thanks Maarten ;)

Origineel gepost door Vincent

Eindelijk nog iemand met verstand, zoals gezegd; het is schijnveiligheid.

POST blijft veiliger, vooral met SSL. Ik zeg ook niet dat het echt veilig is, maar het is wat betreft de aangehaalde punten zeker veiliger. En van SSL en GET had ik geen verstand, maar voor normaal GET en POST wel. GET is onveiliger omdat een URL zo aan te passen is en dus opgenomen wordt in logboeken.

EDIT: uiteindelijk blijft het onveilig natuurlijk, maar hier wat meer info waarom je POST zou moeten gebruiken bij dit soort dingen:
http://www.w3.org/Protocols/rfc2616/....html#sec9.1.1

En dat een login voor jou niet belangrijk is, kan voor de bezoeker anders zijn. Als hij/zij het wachtwoord ook op een andere site gebruikt welke wel belangrijk is, kan diegene de gegevens daarvoor proberen te gebruiken.

@Z Tas : Op deze mannier werkt het wel beter. Het enige wat nog niet kan is als je bent ingelogd kom je op de news pagina. Als je dan naar pagina b gaat en je gebruikt de back button dan krijg je nog een error. Is dit ook nog op te lossen ? En is het mogelijk bij de header redirect nog iets van een javascript popup melding te geven dat de inlog gegevens niet kloppen ?