Bir GET isteği neden sunucudaki verileri değiştirmemeli?

İnternet üzerinden aşağıdaki önerileri görüyorum:

Bir GET hiçbir zaman sunucudaki verileri değiştirmemelidir; bunun için bir POST isteği kullanın.

Bu fikrin temeli nedir?

Veritabanına veri ekleyen bir php servisi yaparsam ve onu GET sorgu dizgisine geçirirsem, neden bu yanlış? (SQL Injection ile ilgilenmek için hazırlanmış ifadeleri kullanıyorum). POST isteği bir şekilde daha güvenli midir?

Yoksa bunun tarihi bir nedeni var mı? Eğer öyleyse, bu tavsiye bugün ne kadar geçerli?

Bu tavsiye değil.

HTTP protokolündeGET bu şekilde A tanımlanır . Düzensiz ve güvenli olması gerekiyordu .

Neden olarak - a GETönbelleğe alınabilir ve bir tarayıcıda yenilenebilir. Tekrar ve tekrar.

Bu, GETtekrar aynısını yaparsanız tekrar veritabanınıza ekleyeceğiniz anlamına gelir .

GETBir bağlantı haline gelirse ve bir arama motoru tarafından taranırsa bunun ne anlama gelebileceğini düşünün . Veritabanınızı yinelenen verilerle dolu olacak.

Ayrıca URI'leri, Adreslenebilirliği ve HTTP GET ve POST kullanımını da öneririm .

Bazı tarayıcılarda bağlantı önceden getirme konusunda da bir sorun var - bunlar sayfa yazarı tarafından belirtilmemiş olsa bile, getirme öncesi bağlantıları arayacaklar.

Oturumu kapattığınızda, sitenizdeki her sayfadan bağlantılı bir "GET" in arkasındaysa, bu davranış nedeniyle insanlar oturumu kapatabilir.

Her HTTP fiilinin kendi sorumluluğu vardır. Örneğin GET, RFC tarafından tanımlandığı gibi

Talep-URI'sı ile tanımlanmış herhangi bir bilgiyi (bir varlık şeklinde) almak anlamına gelir.

POSTdiğer yandan, biçimsel olarak ya da daha fazla biçim vermek

POST yöntemi, kaynak sunucunun istekte bulunan
varlığı
İstek Satırında İstek URI'sı tarafından tanımlanan kaynağın yeni bir alt öğesi olarak kabul etmesini istemek için kullanılır

Bu şekilde tutmak için nedenler:

• Çok basit ve 1991'den bu yana küresel İnternet ölçeğinde çalışıyor
• Tek sorumluluk ilkesine sadık kalın
• Diğer taraflar GETbilgi alma ve veri madenciliği aracı olarak hareket etmekte kullanılır
• GET, hiçbir zaman kaynağın durumunu değiştirmeyen güvenli bir işlem olarak kabul edilir.
• Güvenlik noktaları, GETetkili olan okuma , oysa POSTetkili olan yazma
• GET tarayıcılar, ağdaki düğümler, İnternet Servis Sağlayıcıları tarafından önbelleğe alınır
• İçerik değişmezse, GETaynı URL’nin tüm kullanıcılara aynı sonuçları döndürmesi gerekir, aksi halde geri döndürülen sonuçta bu şekilde bir güveniniz olmaz.

Bütünlüğü ve sadece doğru kullanımı zorlamak için (kaynak) :

• GETParametreler, 4000'den fazla karakteri destekleyen bazı sunucularla, varsayılan olarak küçük ve sınırlı uzunluktaki 256 karakter uzunluğunda olan URL'nin bir parçası olarak iletilir. Uzun bir kayıt eklemek istiyorsanız, bu verileri içeri aktarmak için yasal bir yol yoktur.
• Ne zaman kullanarak güvenli bağlantı, ̶ gibi TLS, ̶ URL da kalkmamak şifreli ̶ dolayısıyla her parametrelerin ̶ ̶G̶E̶T̶̶ devredilip düz metin. URL aslında TLS ile şifrelenmiştir, bu yüzden TLS iyidir.
• Kullanarak ikili veri veya ASCII olmayan karakterler ekleme GETpratik değildir
• GET Bir kullanıcı bir tarayıcıda Geri düğmesine basarsa yeniden yürütülür
• Bazı eski tarayıcılar, ?içinde bir işaret bulunan URL’leri endekslemeyebilir

EDIT: Daha önce POST'un CSRF'ye karşı korunmasına yardımcı olduğunu söyledim ama bu yanlış. Bunu doğru düşünmedim. CSRF'ye karşı koruma sağlamak amacıyla verileri değiştirmek için tüm isteklerinizde oturum kapsamı benzersiz bir gizli belirteç gerekir.

İnternetin ilk günlerinde tarayıcı hızlandırıcıları vardı. Bu programlar, içeriği önbelleğe almak için bir sayfadaki bağlantıları tıklamaya başlar. Google Web Accelerator bu programlardan biriydi. Bu, bir link tıklandığında değişiklik yapan bir uygulamaya zarar verebilir. Hızlandırıcı yazılımı kullanan hala insanlar olduğunu varsayardım.

Proxy sunucuları ve tarayıcılar, GET isteklerini önbelleğe alır, böylece kullanıcı sayfaya tekrar eriştiğinde, kullanıcının bir eylemde bulunduğunu düşünmesi için isteğinizi uygulamanıza göndermeyebilir, ancak gerçekten yapmadılar.

Veritabanına veri ekleyen bir php servisi yaparsam ve onu GET sorgu dizgisine geçirirsem, neden bu yanlış?

En basit cevap " GETdemek istediğin değil çünkü" dır .

Kullanılması GET"- ŞİMDİ ACT ÖZEL TEKLİF!" Güncelleştirme için veri aktarmak için bir aşk mektubu yazma ve bir zarf içinde göndermeden gibidir işaretlenmiş Her iki durumda da, alıcı ve / veya aracıların mesajınızı yanlış yönlendirmesine şaşırmamalısınız .

Sizin için REZİL veritabanı merkezli uygulamada operasyonlarda şu şemayı kullanın:

Okuma İşlemleri için HTTP GET Kullan (SQL SELECT)

Güncelleme İşlemleri için HTTP PUT kullanın (SQL UPDATE)

İşlemler Oluşturmak için HTTP POST kullanın (SQL INSERT)

Silme İşlemleri için HTTP DELETE Kullan (SQL DELETE)

Bir GET hiçbir zaman sunucudaki verileri değiştirmemelidir; bunun için bir POST isteği kullanın.

Bu tavsiye ve buradaki tüm cevaplar yanlıştır. Açıkçası aşırı dramatik oluyorum, diğer cevaplar mükemmel, ancak kesin tavsiyenin şu şekilde verilmesi gerektiğine inanıyorum:

Bir GET sunucudaki verileri nadiren değiştirmeli - bunun için bir POST isteği kullanmalı

"Asla" demek çok aşırı değildir ve buradaki diğer cevaplar neden "nadiren" yapmanız gerektiğini doğru bir şekilde açıklasa da, verileri GET ile değiştirmenin gerçekten makul olduğu bazı senaryolar vardır. Örnek, bir defalık kullanım e-posta doğrulama bağlantısıdır. Genellikle bu bağlantılar, erişildiğinde verileri değiştirmek zorunda kalacak bir GUID içerir. Doğru şekilde uygulanırsa müteakip aynı GET istekleri göz ardı edilir.

Bu açıkça bir kenar davası ama kesinlikle kayda değer.