Kirjautuminen

Haku

Tehtävät

Keskustelu: Nettisivujen teko: $_GET, $_POST ja $_REQUEST

Sivun loppuun

volume [12.02.2011 18:12:53]

#

olen käytellyt lomakkeen tietojen lähetyksessä $_GET ja $_POST-metodeja. olisiko itseasiassa käytännöllisempi käyttää $_REQUEST-metodia. miksiköhän viimemainitusta ei juurikaan näy mainintoja esim tällä saitilla, vaikka joissakin ohjeissa suorastaan suositellaan sen käyttöä? mitkähän olisivat niiden käytön "periaatteelliset" erot -mihin viimeksimainittu mielestänne voisi sopia?

Teknkik [12.02.2011 18:25:10]

#

Mutta eikös $_REQUEST voi aiheuttaa tietoturvariskin, koska silloin vaikkapa postilla lähetettyä dataa voi syöttää myös get-methodilla lähetetyllä datalla.. en tiedä sitten mitä siitä tapahtuu.

Teuro [12.02.2011 19:14:25]

#

Voihan sitä postia laitella ihan muutenkin ei se ole mikään ongelma. Ongelmia tulee vasta, jos sitä käyttäjän antamaa dataa ei suodatella mitenkään.

makumaku [12.02.2011 19:31:50]

#

Kyllä kai tuo on enempi mielipidekysymys mitä metodia käyttää. Joidenkin milestä koodi on selvempää kun tarkistetaan vain se metodi josta tietoa odotetaan. Toisten mielestä on sitten selvempää kun käytetään aina _REQUESTia. Tietenkin tuo _REQUESTIN käyttö tekee koodista hieman monipuolisempaa, koska voit esim muuttaa formin lähetystavan jälkeenpäin, tai jos formi lähettää _POSTilla niin voit testata vastaanottavaa tiedostoa antamalla parametrit osoiterivillä, jne..
Olipa sitten kyseessä $_GET, $_POST, $_REQUEST tai $_COOKIE niin inputti pitäisi aina validoida eikä luottaa että sieltä tulee varmasti oikeata dataa.

The Alchemist [13.02.2011 07:31:29]

#

Teknkik kirjoitti:

Mutta eikös $_REQUEST voi aiheuttaa tietoturvariskin, koska silloin vaikkapa postilla lähetettyä dataa voi syöttää myös get-methodilla lähetetyllä datalla.. en tiedä sitten mitä siitä tapahtuu.

$_GET, $_POST ja $_REQUEST eivät ole metodeja vaan muuttujia. Aivan tavallisia array-muuttujia. Ainoat tietoturvariskit ovat sellaisia, että alkaa tulla välinpitämättömäksi sen suhteen, käyttääkö postia vai gettiä formiensa kanssa. Jos alkaa login-lomakkeen tietoja lähetellä getillä, niin tällöin riskeeraa käyttäjän tunnukset, jne.

mikkop92 [13.02.2011 10:24:40]

#

The Alchemist kirjoitti:

Jos alkaa login-lomakkeen tietoja lähetellä getillä, niin tällöin riskeeraa käyttäjän tunnukset, jne.

Vaikka GET-metodia käytettäessä esim. käyttäjätunnus ja salasana näkyvätkin suoraan URL:stä ei POST-metodikaan ole täysin varma niiden salaamisessa, sillä POST-metodia käytettäessä tiedot lähetetään URL:n sijaan HTTP-otsikoissa aivan selväkielisinä. Tällöin esimerkiksi samassa lähiverkossa voidaan suhteellisen helposti paketteja nuuskimalla saada selville käyttäjän tietoja, tai jopa suoraan kaapata käyttäjän istunto kopioimalla toisen käyttäjän palvelimelle lähettämässä sivupyynnössä oleva istuntotunnus.

Asia tietystikin muuttuu jos käytetään salattua yhteyttä.

Grez [13.02.2011 10:34:28]

#

Lähinnähän tuo ongelma GET:n käyttämiseen on, jos esim bookmarkkaa sivun ja lähettää kaverille tai on joku hakukoneen searchbar tms. käytössä joka välittää tietoja. Ne kyllä käsittääkseni pyrkivät kirjautumistunnuksia eliminoimaan URLeista, mutta ei ne välttämättä kaikkia tajua.

Eli GETin ei pitäisi aikaansaada muutosta järjestelmän tilaan. Jos tätä väärinkäytetään, niin siitä potentiaalisesti aiheutuu kaikenlaisia ongelmia.

The Alchemist [13.02.2011 13:19:37]

#

mikkop92 kirjoitti:

The Alchemist kirjoitti:

Jos alkaa login-lomakkeen tietoja lähetellä getillä, niin tällöin riskeeraa käyttäjän tunnukset, jne.

Vaikka GET-metodia käytettäessä esim. käyttäjätunnus ja salasana näkyvätkin suoraan URL:stä ei POST-metodikaan ole täysin varma niiden salaamisessa, sillä POST-metodia käytettäessä tiedot lähetetään URL:n sijaan HTTP-otsikoissa aivan selväkielisinä.

En tarkoittanut, että tunnusten kaappaaminen netin yli vaikeutuisi, vaan pohdin ihan lokaaleja uhkia. Jos vaikka kirjaston koneella käy surffailemassa, niin tunnukset voisivat jäädä näkyviin sivuhistoriaan jne.


Sivun alkuun

Vastaus

Aihe on jo aika vanha, joten et voi enää vastata siihen.

Tietoa sivustosta