Subdomain dikongsi, dua pintu masuk: siapa melihat rekod yang mana?

Klinik A dan Klinik B berkongsi satu pangkalan kod, dua subdomain dan campuran pelawat dari pejabat dan melalui VPN. Pasukan rangkaian cenderung mengkonfigurasi kedua-dua pintu masuk secara berasingan, dan itu tidak mengapa, selagi aplikasi tidak berbuat demikian. Pemeriksaan di bawah ini harus berada dalam aplikasi dan harus berkelakuan sama tanpa mengira pintu mana yang digunakan oleh permintaan itu.

Pertama: nama hos hanya menamakan penyewa

Selesaikan nama hos yang diminta terhadap pemetaan yang diselenggara oleh pentadbir, dan tolak apa sahaja yang tidak diketahui. Gunakan nilai hos yang disahkan oleh rangka kerja dan bukan pengepala mentah, supaya Host yang direka tidak dapat menyuntik kunci carian. Padanan yang berjaya memberitahu kod konfigurasi penyewa dan penjenamaan mana yang perlu dimuatkan. Ia tidak mengatakan apa-apa tentang sama ada pemanggil boleh melihat data penyewa itu. Simpan soalan kedua itu dalam fungsi berasingan dengan input berasingan.

Fungsi pembantu kongsi yang mengembalikan kedua-dua konteks dan kebenaran daripada satu carian nama hos ialah permulaan pepijat.

Kedua: keahlian datang daripada sesi

Cari keahlian aktif pengguna yang disahkan dan bandingkan dengan penyewa daripada pemeriksaan pertama. Pengguna yang menjadi ahli kedua-dua klinik boleh bertukar, tetapi pertukaran itu harus menjadi tindakan jelas yang direkodkan dalam konteks permintaan, bukan kesimpulan daripada URL. Pengguna yang menjadi ahli satu klinik dan meminta klinik yang satu lagi ditolak, termasuk untuk muat turun dan panggilan API.

Uji kes negatif dengan mengedit pengecam rekod dan parameter penyewa. Jika mana-mana perubahan mengembalikan data, skop dibaca daripada permintaan dan bukan daripada keahlian yang disahkan.

Skop kuki dan log masuk tunggal menentukan di mana akaun boleh dibentangkan. Kedua-duanya tidak menentukan apa yang boleh dibaca oleh akaun itu.

Ketiga: rangkaian tidak membuktikan apa-apa tentang orang itu

Gerbang VPN mengesahkan terowong, dan senarai kebenaran awam mengesahkan julat alamat. Kedua-duanya tidak mengenal pasti seseorang. NAT menggabungkan ramai pengguna ke dalam satu alamat sumber, dan julat pejabat melakukan perkara yang sama untuk semua orang di dalam bangunan. Anggap kedua-duanya sebagai fakta pengangkutan dan simpan kebenaran dalam aplikasi, atau dalam integrasi yang menyatakan identiti secara jelas dan disemak sebagai sedemikian.

DNS ialah fakta pengangkutan ketiga. Jawapan peribadi memerlukan laluan peribadi, dan bahagian hadapan awam memerlukan laluan asal yang disokong. Tiada satu pun daripadanya membawa kebenaran.

Satu ayat untuk ditampal di dinding: rangkaian menentukan bagaimana permintaan tiba, dan aplikasi menentukan apa yang boleh dibacanya.

Keempat: jalankan matriks di kedua-dua pintu masuk

Gunakan akaun terkawal untuk menguji A di A, B di B, A di B, nama hos yang tidak diketahui dan akaun yang disahkan tanpa keahlian. Yang keempat dan kelima harus gagal tertutup dan tidak sekali-kali jatuh kepada penyewa lalai. Jalankan matriks yang sama melalui pintu masuk VPN juga, dengan satu balang sesi bagi setiap akaun:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

Kemudian ubah satu entri senarai kebenaran dan jalankan semula. Hasil yang bergerak bermaksud kawalan rangkaian sedang membuat keputusan kebenaran.

Ulang matriks selepas setiap perubahan pada bahagian hadapan, kerana laluan kod kedua yang melangkau pemeriksaan ialah cara paling biasa sempadan ini terhakis. Hasil yang dijangka membosankan: setiap pintu masuk menghasilkan jawapan yang sama.