http headers en http vars?

[mazz]

vIk ben wat een het kloten met Ideal basic, maar toch heb ik wat vragen over de veiligheid.
In het afhandelscript heb ik dus dit staan:

code:

 <?php
session_start();


$entranceCode = $HTTP_GET_VARS['ec'];


if(!isset($_GET["result"])) { exit;}
if(isset($_GET["result"])){

print $_SESSION["ordernumber"];
unset ($_SESSION["ordernumber"]);

}
?>

Nu weet ik dat http headers te spoofen zijn en dan heb ik ook geprobeerd met deze plugin https://addons.mozilla.org/nl/firefox/addon/967
Als ik daar als header ec invul met als waarde bijvoorbeeld 3434343434 dan wordt deze niet opgepikt en dus lijkt het veilig.
Maar ik wil graag zeker weten dat dit niet te spoofen is. Heeft iemand daar ervaring mee?
Is er uberhaupt een verschil tussen http header en vars?

[ Voor 3% gewijzigd door mazz op 03-04-2009 18:18 ]

[Cartman!]

De $HTTP_* variabelen...zijn die niet enorm depricated?

Wat bedoel jij verder met header in dit verhaal? Volgens mij heb je namelijk niet volledig door wat de veiligheid is van iDeal namelijk. Maw: omschrijf eens duidelijk wat er nu kan gebeuren zodat iets niet veilig zal zijn.

[dev10]

Cartman! schreef op vrijdag 03 april 2009 @ 18:37:
De $HTTP_* variabelen...zijn die niet enorm depricated?

Zijn ze ook en met PHP 6 werken ze ook niet meer.

[mazz]

Wat ik denk dat niet veilig is, is het checken op een http var omdat je deze denk ik wel moet kunnen spoofen.
Ergens las ik ook dat je http headers nooit kunt vertrouwnen omdat deze makkelijk te beinvloeden zijn.

[mazz]

De methode met HTTP_GET_VARS komt dus uit een ideal module van oscommerce die ik ergens zag op de oscommerce site. Deze owrdt dus wel door heel veel mensen gebruikt. Zijn die dan ook allemaal kwetsbaar?

dev10 schreef op vrijdag 03 april 2009 @ 18:48:
[...]


Zijn ze ook en met PHP 6 werken ze ook niet meer.

[Niemand_Anders]

In je topic heb je het over HTTP headers, maar volgens geeft $HTTP_GET_VARS['ec'] de GET variabele ec terug niet de header. Het is voor mij erg lang geleden, maar ik haalde altijd met $_SERVER["HTTP_ACCEPT_LANGUAGE"]; de culture van de bezoeker op.

Heb je al eens page.php?ec=34343434 geprobeerd?

[mazz]

Ja dat was ook het eerste wat in mij opkwam. Om gewoon met het bkende vraagteken te werken.
Maar ook dit lvert niets op. Het script geeft dan gewoon geen output. Blijkbaar is het dus toch iets anders.

[Saven]

$entranceCode = $HTTP_GET_VARS['ec']; !!!!

Gebruik alsjeblieft $_GET !!!!!!!!!!!!!!!!!!!!
of stop met scripten

Modbreak:

Bedankt voor deze zeer zinnige en denigrerende opmerking zonder verdere uitleg of reden. Daar hebben we wat aan.

[ Voor 35% gewijzigd door NMe op 04-04-2009 01:28 ]

[SKiLLa]

Volgens mij moet je in de url niet alleen "ec" meegeven maar ook "result", zie de IF-statements; dus
page.php?ec=1234&result=ja zou wel met je script moeten werken ...

[dev10]

mazz schreef op vrijdag 03 april 2009 @ 18:50:
De methode met HTTP_GET_VARS komt dus uit een ideal module van oscommerce die ik ergens zag op de oscommerce site.

Les 1: ga er niet van uit dat de code die je vindt op het internet nette (lees: goede) code is.

Als ik het goed begrijp is de waarde die je terugkrijgt in de variabele 'ec' de confirmatie van de betaling. Ik mag wel hopen dat dit soort data verstuurd wordt door POST in plaats van GET. Zo niet, dan is dit een hele grote WTF van de payment provider.

[Gomez12]

dev10 schreef op vrijdag 03 april 2009 @ 19:59:
[...]
Als ik het goed begrijp is de waarde die je terugkrijgt in de variabele 'ec' de confirmatie van de betaling. Ik mag wel hopen dat dit soort data verstuurd wordt door POST in plaats van GET. Zo niet, dan is dit een hele grote WTF van de payment provider.

Waarom zou dit een hele grote WTF zijn? POST is niet veiliger dan GET hoor.
POST/GET maakt geen barst uit, alle beveiliging moet toch op een ander nivo liggen

[mazz]

Post en get maakt qua veiligheid niets uit.
Jammer genoeg is er erg weinig documentatie te vinden over ideal basic. En dan vooral over het stulje waar Ideal je terug stuurt naar je website. En welke parameters die dan zou meegeven. Dit heb ik in geen enkel officiel document kunnen vinden....

Als niemand het antwoord echt weet dan moet ik maar eens kijken voor ideal advanced en zorgen dat ik alles met xml uitlees

[Voutloos]

Om eerlijk te zijn: Je huidige probleem zit hem echt niet bij de keuze tussen ideal basic en advanced, maar bij je PHP vaardigheden.
Je assignt iets aan $ec, print een willekeurige sessie variabele en concludeert dat iets 'niet opgepikt wordt'.

[dev10]

Gomez12 schreef op vrijdag 03 april 2009 @ 20:17:
[...]

Waarom zou dit een hele grote WTF zijn? POST is niet veiliger dan GET hoor.
POST/GET maakt geen barst uit, alle beveiliging moet toch op een ander nivo liggen

Omdat je IMHO zulk soort data met een POST request door moet sturen. Dat het niet veiliger is en dat de beveiliging op een ander niveau hoort te zitten ben ik me bewust. Ik heb er alleen twee bezwaren tegen:

1: GET is makkelijker aan te passen door simpelweg in de URL iets te wijzigen, bij een POST request moet je al iets meer moeite doen. (Ja, ik weet dat iemand die kwaad wil die moeite ook neemt)
2: Als je een pakket als Google Analytics hebt draaien, worden daarvan de URL's met de GET variabelen meegenomen. De postvariabelen blijven netjes onzichtbaar. Nu zeg ik niet dat Google niet te vertrouwen is, maar een ander bedrijf is net zo min te vertrouwen. En ik hou zulk soort data toch het liefst uit handen van anderen.

3: Idempotentie

mazz schreef op vrijdag 03 april 2009 @ 20:36:
Post en get maakt qua veiligheid niets uit.
Jammer genoeg is er erg weinig documentatie te vinden over ideal basic. En dan vooral over het stulje waar Ideal je terug stuurt naar je website. En welke parameters die dan zou meegeven. Dit heb ik in geen enkel officiel document kunnen vinden....

Ook niet in de installatiehandleiding? Ik heb verschillende keren een iDEAL of Creditcard module geimplementeerd in een webshop en ik had bij iedere keer dat ik dat deed netjes een handleiding met welke waarden ik terug zou krijgen.

En anders kun je die dingen die je terug krijgt ook laten zien met:

PHP:

var_dump($_REQUEST);

Als niemand het antwoord echt weet dan moet ik maar eens kijken voor ideal advanced en zorgen dat ik alles met xml uitlees

No offence, maar even ter aanvulling op Voutloos: dat zou ik als ik jou was niet doen. Een dergelijke koppeling maken met XML is net even iets lastiger omdat je op veel meer dingen moet letten. Gezien de code die je gepost hebt, vraag ik me af of je dit zou lukken. Als ik jou was, zou ik dit uitbesteden aan iemand die er ervaring mee heeft. Betaling door middel van iDEAL of Creditcard moet je gewoon goed hebben draaien op je website.

@Voutloos: Dat wist ik wel, maar ik kende de uitdrukking niet. In het kort gezegd: om data op te halen gebruik je GET. Voor data waarvan de state verandert (bijvoorbeeld het wijzigen of het verwijderen van een blogpost) gebruik je POST.

[ Voor 44% gewijzigd door dev10 op 03-04-2009 21:10 ]

[Voutloos]

Allebei de bovenstaande redenen missen het echte verschil tussen GET en POST: idempotentie. Een stukje cruciale basic http kennis dat echt bij te veel web devvers ontbreekt, dus ik herhaal het sleutelwoord nog maar een keer: idempotentie, idempotentie, idempotentie.

[Cartman!]

Gelukkig zijn we er al uit dat GET/POST qua veiligheid niks uitmaakt

Het aanpassen van variabelen maakt volgens mij bij iDeal Basic niks uit. Volgens mij is t alleen bedoeld om in je eigen systeem bijv. iets te updaten maar dat is bij Basic iets wat je sowieso met de hand moet checken. Als je dit volautomatisch wil en dat t ook betrouwbaar is moet je kijken naar iDeal advanced.

[Gomez12]

Voutloos schreef op vrijdag 03 april 2009 @ 21:04:
Allebei de bovenstaande redenen missen het echte verschil tussen GET en POST: idempotentie. Een stukje cruciale basic http kennis dat echt bij te veel web devvers ontbreekt, dus ik herhaal het sleutelwoord nog maar een keer: idempotentie, idempotentie, idempotentie.

Herhaal het nog even 50x misschien dat het automatisch duidelijk wordt wat je bedoelt zonder dat je het hoeft uit te leggen...

Want de actie van ideal basic is gewoon idempotent ( zie ideal documentatie ) bedoeld en daarmee 100% correct, dat de webdeveloper er meer aan wil hangen is zijn probleem, de actie van ideal is gewoon goed.

Ideal basic geeft gewoon geen 100% garantie totdat je het op je rekeningafschrift ziet staan. Als jij op basis van een ideal basic respons een niet idempotente actie uitvoert( bijv de order als betaalt beschouwt ) dan is dit je eigen probleem, zij zeggen redelijk pertinent dat het hier niet voor bedoeld is...
Ideal basic biedt een simpel verificatie systeem, geen 100% fullproof betalingssysteem ( daarvoor zijn je afschriften bij ideal basic )

[flashin]

Voutloos schreef op vrijdag 03 april 2009 @ 21:04:
Allebei de bovenstaande redenen missen het echte verschil tussen GET en POST: idempotentie. Een stukje cruciale basic http kennis dat echt bij te veel web devvers ontbreekt, dus ik herhaal het sleutelwoord nog maar een keer: idempotentie, idempotentie, idempotentie.

Totdat je een scriptert tegenkomt die formuliertjes gaat verwerken via GET.

@TS: Ofwel: laat iemand ideal implementeren, of doe het niet. Waarschijnlijk kom je er ook nog heel snel achter dat je toch maar iDeal advanced wilt

[Confusion]

De enige manier om zeker te weten dat de ontvanger ontvangt wat jij verstuurd is door een hashcode over de kritieke velden te berekenen en die mee te sturen. Bij het bericht dat je terug krijgt moet hetzelfde gebeuren. Om bovendien te voorkomen dat een derde partij zich als jouw betalingsafhandelaar voor kan doen, is het noodzakelijk in die hashcode een geheime sleutel te verwerken, die niet in het bericht wordt meegezonden. Als er geen geheime sleutel of hashcode is, dan is het proces per definitie niet veilig te krijgen.

[Cartman!]

En daarom wil je eigenlijk dus alleen maar iDeal Advanced gebruiken

[mazz]

Ik vind het raar dat ik gelijk als een noob wordt weggezet omdat ik even snel een debug scriptje in elkaar flans om het e.e.a te testen.
Maar wij hebben dus Ideal via Ing en in de handleiding staat alleen hoe je naar de server van ing/ideal moet communiceren. Helaas staat er dus niet in wat voor respons je terug moet krijgen.

Misschien ga ik maar eens bellen ofzo, aangezien ik het antwoord ook nog niet echt voorbij heb zien komen hier?

[mazz]

flashin schreef op vrijdag 03 april 2009 @ 22:52:
[...]
Totdat je een scriptert tegenkomt die formuliertjes gaat verwerken via GET.

@TS: Ofwel: laat iemand ideal implementeren, of doe het niet. Waarschijnlijk kom je er ook nog heel snel achter dat je toch maar iDeal advanced wilt

Leuk dat je het over het gebruik van GET hebt. Maar dit heb ik dus even uit een oscommerce module gehaald om te testen aangezien ik 0,0 relevante info kan vinden over ideal. Mocht iemand een handleiding vinden waar in ieder geval instaat wat ik van de server kan verwachten en wat de globale procedure is, dan hoor k het graag

[Cartman!]

Met alle respect verder maar je komt ook wel n beetje over als n noob. Je haalt termen door elkaar, gebruikt depricated code en hebt naar mijn idee gewoon geen idee wat de bedoeling is van de iDeal Basic variant. Check anders eens handleidingen van andere banken, wellicht leggen die het beter uit dan ING.

[mazz]

code:

Enkele kanttekeningen bij iDEAL Lite
Om betalingen via iDEAL Lite te kunnen ontvangen moet je een abonnement afsluiten bij je bank. 
iDEAL Lite biedt GEEN betrouwbare terugkoppeling wat betreft de betaalstatus. Is dit wenselijk/noodzakelijk, gebruik dan iDEAL Professional.

http://www.ideal-simulato...mentatie-handleiding.html

Cartman! schreef op zaterdag 04 april 2009 @ 00:12:
Met alle respect verder maar je komt ook wel n beetje over als n noob. Je haalt termen door elkaar, gebruikt depricated code en hebt naar mijn idee gewoon geen idee wat de bedoeling is van de iDeal Basic variant. Check anders eens handleidingen van andere banken, wellicht leggen die het beter uit dan ING.

Hoevaak moet ik nog zeggen dat dat scriptje even geleend heb uit een standaard Ideal module van oscomerce? Ik wilde gewoon even kijken wat ik voor respons van de server van ideal zou krijgen.
Alsof ik dit soort gare code life ga gebruiken...

Maar goed, zoals hierboven staan aangegeven doe ik er dus WEL verstandig aan up te graden naar advanced

En hier nog een stukje...

finish.php
In het voorbeeld gebruik ik 1 pagina om alle mogelijke statussen (SUCCES, CANCEL of ERROR) af te vangen. Je kunt dit script natuurlijk verder uitbreiden, maar bedenk dat de terugkoppeling ook rechtstreeks ingetypt had kunnen worden. Het resultaat is dus onbetrouwbaar. Ik raad dan ook niet aan om "belangrijke routines" aan de ontvangen status te verbinden.

Saven schreef op vrijdag 03 april 2009 @ 19:49:
$entranceCode = $HTTP_GET_VARS['ec']; !!!!

Gebruik alsjeblieft $_GET !!!!!!!!!!!!!!!!!!!!
of stop met scripten

Waarschijnlijk weet je niet eens waarom die functie deprecated is....

[ Voor 74% gewijzigd door mazz op 04-04-2009 00:30 ]

[Cartman!]

Waarom leen je even een scriptje dan als je zelf gewoon een normaal voorbeeld kunt maken Dan moet je natuurlijk niet raar opkijken als wij je vervolgens inschatten als noob.

Succes iig. met het inbouwen van de advanced