Apa yang salah dengan menggunakan $ _REQUEST []?


116

Saya telah melihat sejumlah posting di sini yang mengatakan untuk tidak menggunakan $_REQUESTvariabel. Biasanya saya tidak melakukannya, tetapi terkadang lebih nyaman. Apakah ada yang salah?


2
Lihat pertanyaan dan jawaban terkait: stackoverflow.com/questions/1149118/…
Gordon

2
Sejak php 5.3 default php.ini hanya mengatakan GET dan data POST dimasukkan ke dalamnya $_REQUEST. Lihat php.net/request_order Saya baru saja tersandung pada jeda kompatibilitas mundur ini ketika mengharapkan data cookie masuk $_REQUESTdan bertanya-tanya mengapa itu tidak berfungsi! Jadi, alasan terbesar untuk menghindari penggunaan $ _REQUEST adalah karena skrip Anda tidak dapat disetel request_ordersendiri PHP_INI_PERDIR, jadi perubahan php.ini dapat dengan mudah mematahkan asumsi yang menjadi dasar pembuatan skrip Anda. Lebih baik memasukkan asumsi tersebut langsung ke dalam naskah Anda.
Darren Cook

Jawaban:


184

Sama sekali tidak ada yang salah dengan mengambil masukan dari keduanya $_GETdan $_POSTdengan cara gabungan. Faktanya, itulah yang hampir selalu ingin Anda lakukan:

  • untuk permintaan idempoten biasa yang biasanya dikirimkan melalui GET, ada kemungkinan jumlah data yang Anda inginkan tidak akan muat dalam URL sehingga telah dimutasi menjadi permintaan POST sebagai masalah praktis.

  • untuk permintaan yang memiliki efek nyata, Anda harus memeriksa apakah permintaan tersebut dikirim dengan metode POST. Tetapi cara untuk melakukannya adalah dengan memeriksa $_SERVER['REQUEST_METHOD']secara eksplisit, tidak bergantung pada $_POSTkekosongan untuk GET. Dan bagaimanapun, jika metodenya adalah POST, Anda mungkin masih ingin mengambil beberapa parameter kueri dari URL.

Tidak, masalah dengan $_REQUESTtidak ada hubungannya dengan parameter GET dan POST yang digabungkan. Itu juga, secara default, termasuk $_COOKIE. Dan cookie sama sekali tidak seperti parameter pengiriman formulir: Anda hampir tidak pernah ingin memperlakukannya sebagai hal yang sama.

Jika Anda tidak sengaja mendapatkan cookie yang ditetapkan di situs Anda dengan nama yang sama dengan salah satu parameter formulir Anda, formulir yang mengandalkan parameter tersebut akan berhenti bekerja secara misterius karena nilai cookie menimpa parameter yang diharapkan. Ini sangat mudah dilakukan jika Anda memiliki banyak aplikasi di situs yang sama, dan bisa sangat sulit untuk di-debug ketika Anda hanya memiliki beberapa pengguna dengan cookie lama, Anda tidak lagi menggunakannya untuk berkeliaran dan merusak formulir dengan cara tidak -tidak ada yang bisa mereproduksi.

Anda dapat mengubah perilaku ini menjadi urutan yang lebih masuk akal GP(tidak C) dengan konfigurasi request_order di PHP 5.3. Jika hal ini tidak memungkinkan, saya pribadi akan menghindari $_REQUESTdan, jika saya membutuhkan gabungan GET + POST array, buat secara manual.


2
Situasi ini (data terlalu lama untuk dikirimkan melalui GET) adalah pengecualian, bukan aturan
Ben James

1
Jawaban bagus. Saya juga memperhatikan bahwa dengan kerangka kerja seperti Zend Framework GET dan parameter POST digabungkan menjadi 1 objek permintaan. Saya tidak pernah terpikir sampai saya membaca posting Anda.
Jay Sidri

Secara default, konfigurasi request_order diatur ke "GP" di php.ini pada PHP 5.4+ jadi saya akan mengatakan lakukanlah ... tetapi seperti biasa, lanjutkan dengan hati-hati.
bcmoney

jika $ _POST adalah a="foo"dan $ _COOKIE a="bar", apakah akan ada penggantian / konflik di sini?
Karat

75

Saya telah menggali beberapa posting newsgroup di PHP Internals dan menemukan diskusi menarik tentang topik tersebut. Thread awal adalah tentang sesuatu yang lain, tapi pernyataan oleh Stefan Esser, (jika tidak dalam ) ahli keamanan di dunia PHP berubah diskusi terhadap implikasi keamanan menggunakan $ _REQUEST untuk beberapa posting.

Mengutip Stefan Esser di PHP Internals

$ _REQUEST adalah salah satu kelemahan desain terbesar di PHP. Setiap aplikasi yang menggunakan $ _REQUEST kemungkinan besar rentan terhadap masalah Pemalsuan Permintaan Lintas Situs Tertunda. (Ini pada dasarnya berarti jika misalnya cookie bernama (usia) ada, itu akan selalu menimpa konten GET / POST dan oleh karena itu permintaan yang tidak diinginkan akan dilakukan)

dan di balasan nanti ke utas yang sama

Ini bukan tentang fakta bahwa seseorang dapat memalsukan GET, POST; Variabel COOKIE. Ini tentang fakta bahwa COOKIE akan menimpa data GET dan POST di REQUEST.

Oleh karena itu saya dapat menginfeksi browser Anda dengan cookie yang mengatakan misalnya action = logout dan sejak hari itu Anda tidak dapat menggunakan aplikasi lagi karena REQUEST [action] akan keluar selamanya (sampai Anda menghapus cookie secara manual).

Dan untuk menginfeksi Anda dengan COOKIE sangatlah sederhana ...
a) Saya dapat menggunakan XSS vuln di aplikasi apa pun di subdomain
b) Pernah mencoba menyetel cookie untuk * .co.uk atau * .co.kr ketika Anda memiliki a domain tunggal di sana?
c) Lintas domain lainnya dengan cara apa pun ...

Dan jika Anda yakin bahwa ini bukan masalah, saya dapat memberi tahu Anda bahwa ada kemungkinan sederhana untuk menyetel cookie fea * .co.kr yang mengakibatkan beberapa versi PHP hanya menampilkan halaman putih. Bayangkan: Hanya satu cookie untuk mematikan semua halaman PHP di * .co.kr

Dan dengan menetapkan ID sesi ilegal dalam cookie yang valid untuk * .co.kr dalam variabel bernama + PHPSESSID = ilegal Anda masih dapat melakukan DOS setiap aplikasi PHP di korea menggunakan sesi PHP ...

Pembahasan berlanjut hingga beberapa postingan lagi dan menarik untuk dibaca.


Seperti yang Anda lihat, masalah utama dengan $ _REQUEST bukanlah karena ia memiliki data dari $ _GET dan $ _POST, tetapi juga dari $ _COOKIE. Beberapa orang lain dalam daftar menyarankan untuk mengubah urutan pengisian $ _REQUEST, misalnya mengisinya dengan $ _COOKIE terlebih dahulu, tetapi hal ini dapat menyebabkan banyak masalah potensial lainnya, misalnya dengan penanganan Sesi .

Anda dapat sepenuhnya menghilangkan $ _COOKIES dari $ _REQUEST global, sehingga tidak ditimpa oleh array lain (sebenarnya, Anda dapat membatasinya ke kombinasi apa pun dari konten standarnya, seperti manual PHP pada pengaturan variabel_order ini memberitahu kami:

variable_order Menyetel urutan penguraian variabel EGPCS (Environment, Get, Post, Cookie, dan Server). Misalnya, jika variable_order diset ke "SP" maka PHP akan membuat superglobals $ _SERVER dan $ _POST, tetapi tidak membuat $ _ENV, $ _GET, dan $ _COOKIE. Menyetel ke "" berarti tidak ada superglobals yang akan disetel.

Tetapi sekali lagi, Anda mungkin juga mempertimbangkan untuk tidak menggunakan $ _REQUEST sama sekali, hanya karena di PHP Anda dapat mengakses Environment, Get, Post, Cookie, dan Server di global mereka sendiri dan mengurangi satu vektor serangan. Anda masih harus membersihkan data ini, tetapi ada satu hal yang perlu dikhawatirkan.


Sekarang Anda mungkin bertanya-tanya, mengapa $ _REQUEST ada dan mengapa itu tidak dihapus. Ini juga ditanyakan pada PHP Internal. Mengutip Rasmus Lerdorf tentang Mengapa $ _REQUEST ada? di Internal PHP

Semakin banyak hal seperti ini yang kami hapus, semakin sulit bagi orang untuk segera beralih ke versi PHP yang lebih baru, lebih cepat, dan lebih aman. Hal itu menyebabkan lebih banyak frustrasi bagi semua orang daripada beberapa fitur warisan yang "jelek". Jika ada alasan teknis, kinerja, atau keamanan yang layak, maka kita perlu melihatnya dengan saksama. Dalam hal ini, hal yang harus kita perhatikan bukanlah apakah kita harus menghapus $ _REQUEST tetapi apakah kita harus menghapus data cookie darinya. Banyak konfigurasi telah melakukannya, termasuk semua milik saya, dan ada alasan keamanan valid yang kuat untuk tidak menyertakan cookie di $ _REQUEST. Kebanyakan orang menggunakan $ _REQUEST yang berarti GET atau POST, tidak menyadari bahwa itu juga bisa berisi cookie dan karena itu orang jahat berpotensi melakukan beberapa trik injeksi cookie dan merusak aplikasi yang naif.

Bagaimanapun, harapan itu memberi sedikit cahaya.


1
+1 senang melihat beberapa diskusi tentang ini ... Saya pikir saya sudah gila!
bobince

2
Saya pikir diskusi itu agak terlalu umum. Masalah sebenarnya adalah ketidaksadaran pengembang, bukan keberadaan cookie di $ _REQUEST per se. PHPSESSID yang terpaku misalnya akan disetel ulang dengan cookie per domain dengan kode penanganan sesi kontemporer. Dan untuk beberapa aplikasi, vars permintaan pengesampingan cookie mungkin benar-benar diinginkan (misalnya sort_order = ASC menimpa formulir pencarian GET var). Padahal pengkodean dalam perilaku seperti itu secara eksplisit lebih masuk akal.
mario

1
Posting yang sangat komprehensif, inilah jawabannya. Mungkin orang takut posting panjang;)
Dzung Nguyen

Sayangnya, Rasmus mengomentari hal ini pada tahun 2009, namun $ _REQUEST pada dasarnya sama sekarang, pada tahun 2015.
Kzqai

10

$_REQUESTmengacu pada semua jenis permintaan (GET, POST, dll ..). Ini terkadang berguna, tetapi biasanya lebih baik untuk menentukan metode yang tepat ($ _GET, $ _POST dll).


19
Jawaban ini menjelaskan apa itu $ _REQUEST, tetapi tidak menjawab pertanyaannya.
zombat

1
Dia mengatakan bahwa adalah praktik yang lebih baik untuk mengetahui jenis permintaan apa yang akan masuk dan kode ke permintaan khusus itu.
Polaris878

8

$_REQUEST umumnya dianggap berbahaya karena alasan yang sama bahwa transformasi data dengan kompleksitas sederhana hingga menengah sering dilakukan dalam kode aplikasi alih-alih dideklarasikan dalam SQL: beberapa pemrogram payah.

Dengan demikian, jika seseorang cenderung menggunakan di $_REQUESTmana-mana, saya dapat melakukan apa saja melalui GET yang saya bisa melalui POST, yang berarti menyiapkan <img>tag di situs saya (berbahaya) yang menyebabkan pengguna masuk ke modul e-niaga Anda untuk membeli produk secara diam-diam, atau saya dapat menyebabkan mereka mengeklik tautan yang akan mengakibatkan tindakan berbahaya atau terbukanya informasi sensitif (mungkin bagi saya).

Namun, ini karena seorang pemula, atau setidaknya tidak berpengalaman, programmer PHP membuat kesalahan sederhana. Pertama, ketahui kapan data jenis apa yang sesuai. Misalnya, saya memiliki layanan web yang dapat mengembalikan respons dalam URLEncoding, XML atau JSON. Aplikasi memutuskan bagaimana memformat respons dengan memeriksa header HTTP_ACCEPT, tetapi dapat dipaksakan menjadi satu secara khusus dengan mengirimkan formatparameter.

Saat memeriksa konten dari parameter format, itu bisa dikirim melalui querystring atau postdata, tergantung pada banyak faktor, tidak sedikit di antaranya apakah aplikasi pemanggil ingin "& format = json" bercampur dengan permintaannya atau tidak. Dalam hal ini, $_REQUESTsangat nyaman karena saya tidak perlu mengetik sesuatu seperti ini:

$format = isset($_POST['format']) ? $_POST['format'] 
    : (isset($_GET['format']) ? $_GET['format'] : null);

Saya tidak akan mengoceh lebih jauh, tetapi cukup untuk mengatakan bahwa $_REQUESTpenggunaan tidak dicegah karena secara inheren berbahaya - itu hanya alat lain yang melakukan persis apa yang diminta darinya, apakah Anda memahami implikasi tersebut atau tidak - itu adalah keputusan yang buruk, malas atau kurang informasi dari programmer yang malas, malas atau tidak berpengalaman yang menyebabkan masalah ini.

Cara menggunakan $_REQUESTdengan aman


  1. Ketahui data Anda: Anda harus memiliki ekspektasi tentang jenis data apa yang akan Anda dapatkan, jadi bersihkan dengan semestinya. Data untuk database? addslashes()atau *_escape_string(). Akan menampilkannya kembali kepada pengguna? htmlentities()atau htmlspecialchars(). Mengharapkan data numerik? is_numeric()atau ctype_digit(). Faktanya, filter_input()dan fungsi terkaitnya dirancang untuk tidak melakukan apa pun selain memeriksa dan membersihkan data. Gunakan alat ini, selalu.
  2. Jangan mengakses data superglobals yang disediakan pengguna secara langsung . Biasakan membersihkan data Anda, setiap saat, dan pindahkan data Anda ke variabel bersih, meskipun itu adil $post_clean. Atau, Anda bisa langsung membersihkannya di superglobals, tetapi alasan saya menganjurkan menggunakan variabel terpisah adalah karena hal itu memudahkan untuk menemukan kerentanan dalam kode, karena apa pun yang mengarah langsung ke superglobal dan bukan yang setara dengan sanitasi dianggap sebagai kesalahan berbahaya. .
  3. Ketahui dari mana data Anda seharusnya berasal. Mengacu pada contoh saya di atas, sangat masuk akal untuk mengizinkan variabel format respons dikirim melalui GET atau POST. Saya juga mengizinkan variabel "tindakan" untuk dikirim melalui salah satu metode. Namun, tindakan itu sendiri memiliki persyaratan yang sangat spesifik mengenai HTTP Verb mana yang dapat diterima . Fungsi, misalnya, yang mengubah data yang digunakan oleh layanan hanya dapat dikirim melalui POST. Permintaan untuk jenis data non-hak istimewa rendah atau tertentu (seperti gambar peta yang dibuat secara dinamis) dapat disajikan sebagai tanggapan atas permintaan dari salah satu metode.

Sebagai kesimpulan, ingat aturan sederhana ini:

KEAMANAN ADALAH YANG ANDA BUAT, ORANG!

EDIT:

Saya sangat merekomendasikan saran bobince: jika Anda bisa, setel request_orderparameter di php.ini ke "GP"; artinya, tidak ada komponen cookie. Hampir tidak ada alasan rasional untuk ini dalam 98% + kasus, karena data cookie seharusnya tidak pernah dianggap sebanding dengan querystring atau postdata.

PS, Anekdot!

Saya kenal seorang programmer yang memikirkan $_REQUESTsebuah tempat untuk menyimpan data yang dapat diakses dengan cara superglobal. Nama pengguna dan kata sandi penting, jalur ke file, sebut saja dan disimpan di $_REQUEST. Dia agak terkejut (meskipun tidak lucu, sayangnya) ketika saya memberi tahu dia bagaimana variabel itu berperilaku. Tak perlu dikatakan, praktik itu telah digulingkan.


8

Permintaan GET harus idempoten dan permintaan POST umumnya tidak. Ini berarti bahwa data dalam $_GETdan $_POSTumumnya harus digunakan dengan cara yang berbeda.

Jika aplikasi Anda menggunakan data dari $_REQUEST, itu akan berperilaku sama untuk permintaan GET dan POST, yang melanggar idempotensi GET.


1
tapi bukankah itu tergantung pada implementasinya? "Indempoten" adalah kata baru bagi saya, tetapi jika saya memahaminya dengan benar, akan mudah untuk membayangkan menyiapkan situasi GET yang tidak indempoten. Misalnya, penghitung halaman biasanya meningkat setiap kali Anda meminta url tertentu.
sprugman

1
@sprugman - juga, Anda dapat mengalami situasi di mana Anda memiliki data GET dan data POST dalam permintaan yang sama, dalam hal ini metode permintaan pada dasarnya tidak ada artinya saat dikontekstualisasikan dengan data permintaan.
zombat

sprugman, jelas setiap permintaan GET mengubah sesuatu karena dicatat oleh server web. Itu masih bisa tidak berdaya dalam domain aplikasi, di mana metadata ini tidak terlalu penting.
Ben James

@sprugman - ide umumnya di sini adalah Anda tidak boleh memiliki permintaan GET yang mengubah data. Contoh umum mengapa ini buruk adalah laba-laba web yang merayapi situs Anda dan mengikuti tautan yang secara tidak sengaja mengubah data. Misalnya link "bendera" pada posting SO.
Eric Petroelje

Itu adalah contoh yang sepele. Bagaimana jika saya menggunakan GET melalui ajax karena lebih cepat (seperti yang disarankan dalam posting ini di carsonified carsonified.com/blog/dev/the-definitive-guide-to-get-vs-post ).
sprugman

7

Itu tidak jelas. Anda tidak benar - benar tahu bagaimana data tersebut sampai kepada Anda karena itu membawa data pos, get, dan cookie. Saya tidak selalu berpikir itu selalu hal yang buruk, kecuali jika Anda perlu mengetahui atau membatasi metode pengiriman.


3

Saya sebenarnya suka menggunakannya. Ini memberi Anda fleksibilitas untuk menggunakan GET atau POST yang dapat berguna untuk hal-hal seperti formulir pencarian di mana sebagian besar data waktu POST, tetapi terkadang Anda ingin mengatakan tautan ke pencarian tertentu, sehingga Anda dapat menggunakan parameter GET sebagai gantinya .

Juga, jika Anda melihat banyak bahasa lain (ASP.NET misalnya) mereka tidak membedakan sama sekali antara variabel GET dan POST.

ETA :

Saya tidak pernah menggunakan REQUEST untuk mendapatkan nilai COOKIE, tetapi saya pikir Kyle Butt membuat poin yang bagus dalam komentar di posting ini tentang itu. BUKAN ide yang baik untuk menggunakan REQUEST untuk mendapatkan nilai COOKIE. Saya yakin dia benar bahwa ada potensi nyata untuk pemalsuan permintaan lintas situs jika Anda melakukannya.

Selain itu, urutan item dimuat ke REQUEST dikontrol oleh parameter konfigurasi di php.ini (variable_order dan request_order). Jadi, jika Anda memiliki variabel yang sama yang diteruskan melalui POST dan GET, variabel mana yang benar-benar masuk ke REQUEST bergantung pada pengaturan ini. Ini dapat mempengaruhi portabilitas jika Anda bergantung pada urutan tertentu dan pengaturan tersebut dikonfigurasi secara berbeda dari yang Anda harapkan.


itu adalah kesalahan besar. Bagaimana Anda bisa menjamin bahwa tindakan non-idempoten dilakukan melalui POST?
Kyle Butt

1
@K - dengan tidak menggunakannya untuk tindakan non-idempoten. Saya pasti tidak akan menggunakannya untuk semuanya, hanya menunjukkan bahwa itu berguna, seperti untuk pencarian seperti yang saya sebutkan dalam contoh saya.
Eric Petroelje

1
Ide ajaib bahwa _POST aman dan _GET tidak harus pergi. Jika saya tidak menggunakan perangkat lunak Anda dengan benar, maka hanya ada sedikit perbedaan (jika ada) bagi saya dalam mengirim permintaan POST versus permintaan GET. Keamanan ada pada apa yang Anda lakukan dengan data, bukan dari mana asalnya. Sedangkan untuk eksploitasi XSS / Request sederhana, sangat mungkin itu menggunakan _REQUEST hanya untuk nilai yang akan valid dengan POST atau GET, dan menggunakan _POST hanya untuk hal-hal yang harus POST. Akal sehat, bukan penggunaan superglobal magis.
Dereleased

1
@Kyle - Saya masih tidak melihat bagaimana Anda tidak dapat melakukan apa yang Anda sebutkan semudah menggunakan sesuatu seperti curl () atau posting ajax untuk meneruskan data yang sama melalui POST dan COOKIE. Apakah Anda menggunakan REQUEST, GET, POST atau COOKIE, semua data pada akhirnya datang dari klien dan selalu dapat dipalsukan.
Eric Petroelje

1
@zombat: Permintaan curl yang Anda bentuk tidak akan masuk sebagai pengguna yang rentan. Tautan yang Anda buat dan tempatkan di situs Anda akan. @Dereleased: Ini bukan pemikiran ajaib, dan masih ada banyak kerentanan dengan GET. tetapi lebih aman untuk mempercayai POST dari pengguna yang masuk daripada GET dari pengguna yang masuk.
Kyle Butt

2

Penting untuk memahami kapan harus menggunakan POST, kapan menggunakan GET dan kapan menggunakan cookie. Dengan $ _REQUEST, nilai yang Anda lihat bisa berasal dari salah satu dari mereka. Jika Anda berharap mendapatkan nilai dari POST atau GET atau dari COOKIE, lebih informatif bagi seseorang yang membaca kode Anda untuk menggunakan variabel spesifik daripada $ _REQUEST.

Orang lain juga menunjukkan bahwa Anda tidak ingin semua POST atau cookie diganti oleh GET karena ada aturan lintas situs yang berbeda untuk semuanya, misalnya, jika Anda mengembalikan data ajax saat menggunakan $ _REQUEST, Anda rentan ke serangan skrip lintas situs.


2

$_REQUESTBukan ide yang buruk hanya menggunakan waktu dengan GET.

  • Jika Anda menggunakannya untuk memuat nilai POST, Anda berisiko mengalami pemalsuan permintaan lintas situs
  • Jika Anda menggunakannya untuk memuat nilai cookie, sekali lagi Anda berisiko terhadap pemalsuan permintaan lintas situs

Dan bahkan dengan GET, $_GETlebih pendek untuk mengetik daripada $_REQUEST;)


Meskipun saya setuju dengan Anda, saya rasa penting untuk dicatat mengapa ini benar dan / atau berbahaya: seseorang harus menggunakan $_POSTketika penting bahwa datanya menjadi POSTDATA. Satu harus digunakan $_REQUESTketika datanya agnostik dengan HTTP Verb yang digunakan. Seseorang harus dalam semua kasus ini dengan hati-hati membersihkan semua data masukan.
Dereleased

1
Saya tidak melihat bagaimana sumber data berkaitan dengan kemungkinan pemalsuan permintaan lintas situs. Seorang penyerang dapat mengatur parameter POST secara sempurna dengan mudah dengan menyediakan pengguna dengan formulir POST yang diarahkan ke situs Anda; Anda akan membutuhkan tindakan perlindungan anti-XSRF yang sama terlepas dari apakah kiriman berasal dari GET atau POST.
bobince

Jauh lebih mudah untuk menyalahgunakan GET untuk pemalsuan. Misalnya, Anda cukup memiliki tag img dengan srcnya disetel dengan parameter yang Anda inginkan. Ini akan bekerja tanpa pengguna menyadarinya.
Jani Hartikainen

0

Saya mungkin digunakan hanya jika Anda ingin mengambil url atau nama host saat ini, tetapi untuk benar-benar mengurai data dari URL tersebut seperti parmeter menggunakan simbol &, mungkin itu bukan ide yang bagus. Secara umum, Anda tidak ingin menggunakan deskripsi yang tidak jelas tentang apa yang Anda coba lakukan. Jika Anda perlu spesifik di situlah $ _REQUEST buruk, jika Anda tidak perlu spesifik maka silakan menggunakannya. Saya akan berpikir.


Apa yang kamu coba katakan? Apakah Anda membingungkan $_REQUESTdengan $_SERVER['QUERY_STRING']?
Dereleased

0

Jika Anda tahu data apa yang Anda inginkan, Anda harus memintanya secara eksplisit. IMO, GET, dan POST adalah dua hewan yang berbeda dan saya tidak dapat memikirkan alasan yang tepat mengapa Anda perlu mencampur data posting dan string kueri. Jika ada yang punya, saya akan tertarik.

Akan lebih mudah untuk menggunakan $ _REQUEST ketika skrip Anda mungkin merespons GET atau POST dengan cara yang sama. Saya berpendapat bahwa ini harus menjadi kasus yang sangat jarang, dan dalam kebanyakan kasus dua fungsi terpisah untuk menangani dua konsep terpisah, atau paling tidak memeriksa metode dan memilih variabel yang benar, lebih disukai. Alur program biasanya jauh lebih mudah diikuti jika tidak perlu melakukan referensi silang dari mana variabel mungkin berasal. Bersikaplah baik kepada orang yang harus menjaga kode Anda dalam waktu 6 bulan. Mungkin Anda.

Selain masalah keamanan dan WTF yang disebabkan oleh cookie dan variabel lingkungan dalam variabel REQUEST (jangan mulai saya di GLOBAL), pertimbangkan apa yang mungkin terjadi di masa mendatang jika PHP mulai mendukung metode lain seperti PUT dan DELETE. Meskipun sangat kecil kemungkinannya ini akan digabungkan ke dalam superglobal REQUEST, ada kemungkinan mereka dapat dimasukkan sebagai opsi dalam pengaturan variable_order. Jadi Anda benar-benar tidak tahu apa pun yang dimiliki REQUEST, dan apa yang diutamakan, terutama jika kode Anda diterapkan di server pihak ketiga.

Apakah POST lebih aman daripada GET? Tidak juga. Lebih baik menggunakan GET jika memungkinkan karena lebih mudah untuk melihat di log Anda bagaimana aplikasi Anda dieksploitasi ketika diserang. POST lebih baik untuk operasi yang memengaruhi status domain karena spider umumnya tidak mengikutinya, dan mekanisme pengambilan prediktif tidak akan menghapus semua konten Anda saat Anda masuk ke CMS. Namun, pertanyaannya bukanlah tentang manfaat GET vs POST, melainkan tentang bagaimana penerima seharusnya memperlakukan data yang masuk dan mengapa tidak baik untuk menggabungkannya, jadi ini benar-benar hanya BTW.


0

Saya rasa tidak ada masalah $_REQUEST, tapi kita harus berhati-hati saat menggunakannya karena ini adalah kumpulan variabel dari 3 sumber (GPC).

Saya kira $_REQUESTmasih tersedia untuk membuat program lama kompatibel dengan versi php baru, tetapi jika kita memulai proyek baru (termasuk perpustakaan baru) saya pikir kita tidak boleh menggunakan $_REQUESTlagi untuk membuat program lebih jelas. Kami bahkan harus mempertimbangkan untuk menghapus penggunaan $_REQUESTdan menggantinya dengan fungsi pembungkus untuk membuat program lebih ringan, terutama dalam memproses data teks besar yang dikirimkan, karena $_REQUESTberisi salinan $_POST.

// delete $_REQUEST when program execute, the program would be lighter 
// when large text submitted
unset($_REQUEST);

// wrapper function to get request var
function GetRequest($key, $default = null, $source = '') 
{
  if ($source == 'get') {
    if (isset($_GET[$key])) { 
      return $_GET[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'post') {
    if (isset($_POST[$key])) { 
      return $_POST[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'cookie') {
    if (isset($_COOKIE[$key])) { 
      return $_COOKIE[$key]; 
    } else { 
      return $default; 
    }
  } else {
    // no source specified, then find in GPC
    if (isset($_GET[$key])) {
      return $_GET[$key];     
    } else if (isset($_POST[$key])) {
      return $_POST[$key]; 
    } else if (isset($_COOKIE[$key])) {
      return $_COOKIE[$key]; 
    } else {
      return $default; 
    } 
  }
}

0

Darren Cook: "Sejak php 5.3, php.ini default mengatakan hanya GET dan POST data yang dimasukkan ke dalamnya$_REQUEST . Lihat php.net/request_order Saya baru saja tersandung pada jeda kompatibilitas mundur ini ketika mengharapkan data cookie masuk $_REQUESTdan bertanya-tanya mengapa tidak ada ' t bekerja! "

Wow ... baru saja beberapa skrip saya berhenti berfungsi karena peningkatan ke PHP 5.3 . Melakukan hal yang sama: asumsikan bahwa cookie akan disetel saat menggunakan $_REQUESTvariabel. Dengan peningkatan yang tepat berhenti bekerja.

Sekarang saya menyebut nilai cookie secara terpisah menggunakan $_COOKIE["Cookie_name"]...


-1

Masalah utamanya adalah itu berisi cookie, seperti yang dikatakan orang lain.

Di PHP 7 Anda dapat melakukan ini:

$request = array_merge($_GET ?? [], $_POST ?? []);

Ini menghindari masalah cookie dan paling buruk memberi Anda array kosong dan paling baik penggabungan $ _GET dan $ _POST dengan yang terakhir diutamakan. Jika Anda tidak terlalu repot dengan mengizinkan injeksi URL parameter melalui string kueri, itu cukup nyaman.


Mereka yang memilih untuk tidak memberikan suara, tolong jelaskan untuk peneguhan saya.
amh15

-2

Sangat tidak aman. Juga canggung karena Anda tidak tahu apakah Anda mendapatkan POST atau GET, atau permintaan lain. Anda benar-benar harus mengetahui perbedaan di antara mereka saat mendesain aplikasi Anda. GET sangat tidak aman karena diteruskan di URL dan tidak cocok untuk hampir semua hal selain navigasi halaman. POST, meskipun tidak aman dengan sendirinya, memberikan satu tingkat keamanan.


4
Tidak ada perbedaan keamanan antara $ _POST dan $ _GET, selain Anda tidak dapat mengetik permintaan POST ke bilah URL browser. Namun, hanya perlu 5 detik untuk menyiapkan permintaan cURL baris perintah menggunakan POST.
zombat

3
@Zombat: Kami perlu memulai semacam kampanye untuk meyakinkan orang bahwa POST pada dasarnya tidak aman, atau bahkan lebih aman, daripada GET. Keamanan adalah cara Anda memperlakukan data, bukan HTTP Verb yang digunakan untuk mendapatkannya di sana.
Dereleased

@Dereleased - Saya mengusulkan gambar dua warna ikonik dari awan dengan beberapa petir untuk mewakili internet, dengan kata "PERUBAHAN" di bawahnya.
zombat

1
@GuyT: Itu pandangan yang sangat sempit. Ini bukan hanya tentang seberapa "aman" itu, tetapi seberapa rahasia itu. Parameter GET dapat ditampilkan sebagai pelengkapan otomatis di url browser, bahkan riwayat browser. Selain itu, keamanan tidak hanya terbatas pada browser. Misalnya, banyak server mencatat url http, jadi apa pun yang ada di url akan dicatat, misalnya. Memiliki nama pengguna / kata sandi yang muncul di log Apakah membuat perbedaan. Di sisi yang aman, selalu hindari meneruskan informasi sensitif sebagai parameter GET.
stan

1
Khususnya log akses Apache. Url permintaan apa pun akan dicatat, dan SIAPA PUN yang memiliki akses ke log dapat melihat kredensial Anda masuk.
stan
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.