Oturum Güvenliği

Oturum modülü bir oturumda saklanan verinin sadece oturumun kullanıcısı tarafından görüldüğünü garanti edemez. Oturumun bütünlüğünü etkin olarak korumak için oturumun önemine bağlı olarak ek tedbirler alınması gerekir.

Oturumlarınız tarafından taşınan verinin önemine ve konuşlandırdığınız ek korumalara bağlı olarak ki, bunun bir fiyatı vardır, kullanıcının rahatı azalır. Örneğin, kullanıcılarınızı basit sosyal mühendislik taktiklerinden korumak için session.use_only_cookies yönergesi etkin kılınmalıdır. Bu durumda, çerezler kullanıcı tarafında koşulsuz olarak etkin kılınmalıdır yoksa oturum çalışmayacaktır.

Bir mevcut oturum kimliğinin üçüncü şahıslara ifşa olmasının çeşitli yolları vardır. Örneğin, JavaScript zerkleri, URL'lerdeki oturum kimlikleri, paket koklama, cihaza fiziksel erişim vb. İfşa edilmiş bir oturum kimliği, üçüncü tarafın o kimlik ile ilişkilendirilmiş tüm özkaynaklara erişmesini mümkün kılar. İlk olarak oturum kimliğini taşıyan URL'ler ifşa olur. Harici bir siteye bir bağ verilirse oturum kimliğini içeren URL, harici sitenin günlük kayıtlarına geçebilir. İkinci olarak, daha etkin bir saldırgan ağ trafiğini dinleyebilir. Eğer şifreleme yapılmıyorsa oturum kimlikleri ağ üzerinden salt metin olarak akacaktır. Bu noktada çözüm, sunucunuzun SSL bağlantılar kurmasını sağlamak ve bunu kullanıcılarınız için zorunlu kılmaktır. Güvenliği arttırmak için HSTS kullanılmalıdır.

Bilginize: HTTPS bile gizli verileri her zaman koruyamaz. Örneğin, CRIME ve Beast güvenlik açıkları, bir saldırganın verileri okumasını sağlayabilir. Ayrıca, birçok ağın denetim amacıyla HTTPS MITM vekilleri kullandığı unutulmamalıdır. Saldırganlar da böyle bir vekil sunucu kurabilir.

Uyumsuz Oturum Yönetimi

PHP'nin oturum yöneticisi şu anda öntanımlı olarak uyarlanabilir durumdadır. Uyarlanabilir bir oturum yöneticisi ek riskler içerir.

session.use_strict_mode etkin olduğunda ve oturum kayıt işleyicisi destekliyorsa, ilklendirilmemiş bir oturum kimliği reddedilir ve yenisi oluşturulur. Bu, kullanıcıyı bilinen bir oturum kimliğini kullanmaya zorlayan bir saldırıyı engeller. Bir saldırgan bağlantıları kopyalayabilir ve oturum kimliği içeren bağlantıları epostalarda yollayabilir. Örneğin, http://example.com/page.php?PHPSESSID=123456789 eğer session.use_trans_sid etkinse, kurban, saldırgan tarafından sağlanan oturum kimliğini kullanarak bir oturum başlatacaktır. session.use_strict_mode bu riski azaltır.

Oturum kimliği çerezine domain, path, httponly, secure ve PHP 7.3 ve sonrasında SameSite öznitelikleri atanabilir. Tarayıcılarda tanımlı öncelikler vardır. Öncelik kullanarak bir saldırganın kalıcı olarak kullanılabilecek oturum kimliği ataması mümkündür. session.use_only_cookies kullanımı bu sorunu çözümlemez. session.use_strict_mode bu riski azaltır. session.use_strict_mode=On ile ilklendirilmemiş bir oturum kimliği reddedilir.

Bilginize: session.use_strict_mode uyarlanabilir oturum yönetimi riskini azaltsa da, bir saldırgan yine de kullanıcıyı ilklendirilmemiş bir oturum kimliğini kullanmaya zorlayabilir; böyle bir oturum kimliği saldırgan tarafından JavaScript zerki ile oluşturulabilir. Bu saldırının riskleri bu kılavuzun tavsiyelerine uyularak azaltılabilir. Bu kılavuzu izleyerek, geliştiriciler, session.use_strict_mode yönergesini etkin kılmalı, zaman damgalı oturum yönetimi kullanmalı ve tavsiye edilen yordamlarla session_regenerate_id() kullanarak oturum kimliklerini yeniden üretmelidir. Geliştirici yukarıdakilerin tümünü uyguladığı takdirde saldırgan üretimi oturum kimliği silinecektir. Eski bir oturuma erişim gerçekleştiğinde, bu bilgiler, müteakip bir soruşturma için geçerli olacağından, geliştiriciler kullanıcının tüm etkin oturum verilerini kaydetmelidir. Kullanıcının tüm oturumları zorla kapatılmalı ve yeniden kimlik doğrulaması yapması istenmelidir. Bu, saldırganların çalınan oturumları kötü amaçlarla kullanmasını engeller.

PHP 7.1.0 ve sonrası için, session_create_id() eklendi. Bu işlev, bir kullanıcının oturum kimliklerinin önüne kullanıcı kimliği eklenerek tüm etkin oturumlarına verimli bir şekilde erişmek için çalıştırılabilir. session.use_strict_mode'u etkinleştirmek bu gerçeklenim için çok önemlidir. Aksi takdirde, kötü niyetli kullanıcılar diğer kullanıcılar için kötü amaçlı bir oturum kimliği atayabilir.

Bilginize: PHP 7.1.0 öncesinde gelitiriciler yeni bir oturum kimliği üretmek için /dev/urandom gibi bir CSPRNG veya aş işlevlerini ve random_bytes() işlevini kullanmalıdır. session_create_id() çakışma algılama özelliğine sahiptir ve oturumun INI ayarlarına göre bir oturum kimliği üretir.

Oturum Kimliğinin Yeniden Üretilmesi

session.use_strict_mode iyi bir acı azaltıcıdır ancak yetersizdir. Geliştiriciler oturum güvenliğini sağlamak için aynı zamanda session_regenerate_id() işlevini de kullanmalıdır.

Oturum kimliğinin yenilenmesi oturum kimliklerinin çalınma riskini azaltır, bu bakımdan session_regenerate_id() belirli aralıklarla sürekli çağrılmalıdır. Örneğin, güvenlik açısından hassas içerik için oturum kimliğini her 15 dakikada bir yeniden oluşturun. Bir oturum kimliğinin çalınması durumunda bile, hem meşru kullanıcının hem de saldırganın oturumu sona erecektir. Başka bir deyişle, kullanıcı veya saldırgan tarafından erişim, eski bir oturuma erişim hatası üretecektir.

Oturum kimlikleri, kullanıcı ayrıcalıkları yükseltildiğinde, kimlik doğrulamasından sonra yapıldığı gibi yeniden oluşturulmalıdır. Kimlik doğrulama bilgisi $_SESSION dizisine atamadan önce session_regenerate_id() çağrılmalıdır. (PHP 7.0.0'dan itibaren, session_regenerate_id(), zaman damgasını/ve benzerlerini geçerli oturuma kaydetmek için mevcut oturum verilerini otomatik olarak kaydeder.) Yalnızca yeni oturumun doğrulanmış bayrağı içerdiğinden emin olun.

Geliştiriciler, session.gc_maxlifetime değerine göre oturum kimliğinin süresinin dolmasına güvenmemelidir. Saldırganlar, süresinin dolmasını önlemek ve kimliği doğrulanmış bir oturum da dahil olmak üzere oturumu kullanmaya devam edebilmek için bir kurbanın oturum kimliğine düzenli aralıklarla erişebilir.

Bunun yerine, geliştiricilerin zaman damgasına dayalı oturum verisi yönetimini gerçeklemesi gerekir.

session_regenerate_id() öntanımlı olarak eski oturumları silmez. Eski kimliği doğrulanmış oturumlar kullanım için mevcut olabilir. Geliştiriciler, eski oturumların herkes tarafından tüketilmesini engellemeli, zaman damgalarını kullanarak eski oturum verilerine kendi başlarına erişimi yasaklamalıdır.

session.use_only_cookies ve session_regenerate_id() öğelerinin doğru kullanımı, saldırganlar tarafından ayarlanan silinemeyen çerezlerle kişisel DoS'a neden olabilir. Bu durumda geliştiriciler, kullanıcıları çerezleri kaldırmaya davet edebilir ve bir güvenlik sorunundan etkilenebileceklerini bildirebilir. Saldırganlar, güvenlik açığı bulunan bir web uygulaması, açıkta kalan/kötü niyetli bir tarayıcı eklentisi, fiziksel olarak güvenliği ihlal edilmiş bir cihaz vb. aracılığıyla kötü amaçlı çerezler atayabilir.

Oturum Verisinin Silinmesi

Eski oturum verisi erişilemez ve silinmiş olmalıdır. Geçerli oturum modülü bunu gerektiği gibi yerine getiremez.

Eski oturum verileri mümkün olan en kısa sürede silinmelidir. Ancak, etkin oturumlar hemen kaldırılmamalıdır. Bu gereksinimleri karşılamak için geliştiriciler, zaman damgasına dayalı oturum veri yönetimini kendi başlarına uygulamalıdır.

$_SESSION içinde zaman aşımı damgasını ayarlayın ve yönetin. Güncel olmayan oturum verilerine erişimi yasaklayın. Eski oturum verilerine erişim tespit edildiğinde, kullanıcının oturumlarından tüm kimliği doğrulanmış durumları kaldırıp onları yeniden kimlik doğrulamaya zorlamanız önerilir. Eski oturum verilerine erişim bir saldırıyı temsil edebilir. Bunu başarmak için geliştiriciler, her kullanıcının tüm etkin oturumlarını takip etmelidir.

Bilginize: Eski bir oturuma erişim, kararsız bir ağ ve/veya siteye eşzamanlı erişim nedeniyle de gerçekleşebilir. Örneğin, sunucu bir çerez aracılığıyla yeni bir oturum kimliği belirlemeye çalışmış, ancak bağlantının kesilmesi nedeniyle Set-Cookie paketi istemciye ulaşmamış olabilir. Bir bağlantıya session_regenerate_id() tarafından yeni bir oturum kimliği verilebilir, ancak başka bir eşzamanlı bağlantı henüz yeni oturum kimliğini almamış olabilir. Bu nedenle, geliştiriciler daha sonraki bir aşamada eski oturuma erişimi yasaklamalıdır. Yani zaman damgası tabanlı oturum yönetimi zorunludur.

Özetle, oturum verileri ne session_regenerate_id() ne de session_destroy() ile yok edilmeli, oturum verilerine erişimi denetlemek için zaman damgaları kullanılmalıdır. session_gc()'nin oturum veri deposundaki eski verileri silmesine izin verin.

Oturum Kilitleme

Yarış koşullarından kaçınmak için oturum verileri öntanımlı olarak kilitlenir. Oturum verilerinin istekler arasındaki tutarlılığını sağlamak için kilitleme zorunludur.

Ancak oturum kilitleme, saldırganlar tarafından DoS saldırıları gerçekleştirmek için kötüye kullanılabilir. Oturum kilitleyerek DoS saldırısı riskini azaltmak için kilitleri en aza indirin. Oturum verilerinin güncellenmesi gerekmediğinde salt okunur oturumlar kullanın. session_start() işlevini 'read_and_close' seçeneği ile kullanın: session_start(['read_and_close'=>1]); session_commit() kullanarak $_SESSION güncellendikten hemen sonra, mümkün olan en kısa sürede oturumu kapatın.

Geçerli oturum modülü, oturum etkin olmadığında $_SESSION üzerinde herhangi bir değişiklik algılamaz. Oturum etkin değilken $_SESSION üzerinde değişiklik yapmamak geliştiricinin sorumluluğundadır.

Etkin Oturumlar

Developers should keep track of all active sessions for every user. And notify them of how many active sessions, from which IP (and area), how long it has been active, etc. PHP does not keep track of these. Developers are supposed to do so.

Various ways to implement this exist. One possible implementation is setting up a database that keeps track of the required data and stores any relevant information. Since session data is GCed, developers must take care of the GCed data to maintain the active session database consistency.

One of the simplest implementations is "User ID prefixed session ID" and store the required information in $_SESSION. Many databases posses good performance for selecting string prefix. Developers MAY use session_regenerate_id() and session_create_id() for this.

Timestamp based session management is mandatory to detect access to obsolete sessions. When access to an obsolete session is detected, authentication flags should be removed from all active sessions of the user. This prevents attackers to keep exploiting stolen sessions.

Oturum ve Otomatik Oturum Açmak

Developers must not use long life session IDs for auto-login because it increases the risk of stolen sessions. An auto-login feature should be implemented by the developer.

Use a secure one time hash key as an auto-login key using setcookie(). Use a secure hash stronger than SHA-2. E.g. SHA-256 or greater with random data from random_bytes() or /dev/urandom.

If the user is unauthenticated, check whether the one-time auto-login key is valid or not. In the case it is valid, authenticate the user and set a new secure one-time hash key. An auto-login key must only be used once, i.e. never reuse an auto-login key, always generate a new one.

An auto-login key is a long life authentication key, it should be protected as much as possible. Use path/httponly/secure/SameSite cookie attributes to secure it. I.e. never transmit the auto-login key unless required.

Developer must implement the features that disables auto-login and removes unneeded auto-login key cookie.

CSRF (Siteler Arası Talep Sahtekarlıkları) Saldırıları

Sessions and authentication do not protect against CSRF attacks. Developers must implement CSRF protection by themselves.

output_add_rewrite_var() can be used for CSRF protection. Refer to the manual page for more details.

Bilginize: PHP prior to 7.2.0 uses the same output buffer and INI setting as trans sid. Therefore, use of output_add_rewrite_var() with PHP prior to version 7.2.0 is not advised.

Most web application frameworks support CSRF protection. Refer to the web application framework manual for more details.

As of PHP 7.3 the SameSite attribute for the session cookie can be set. This is an additional measure which can mitigate CSRF vulnerabilities.