SQL üzerinden dosya yetkisini kapattım, dosya gönderme ile ilgili güvenlik açığı oluşur mu?

Sunucuya dosya gonderip erisim sahibi olmak ne demek? Neye erisim sahibi oluyorlardi? Dosya gondermekle SQL'in ne alakasi var?
Tam olarak problemi belirtirsen yardimci olabilir insanlar, su sorunun ne oldugu belli degil.

bitwise dedi:

Sunucuya dosya gonderip erisim sahibi olmak ne demek? Neye erisim sahibi oluyorlardi? Dosya gondermekle SQL'in ne alakasi var?
Tam olarak problemi belirtirsen yardimci olabilir insanlar, su sorunun ne oldugu belli degil.

Genişletmek için tıkla...

Bu açıklamayı yaptığınıza göre SQL ile dosya göndermeyi bilmiyor olmalısınız. SQL üzerinde "FILE" isminde yetki bulunuyor. Bu yetki açık olduğunda SQL açığı sayesinde dosya sistemine shell dosyası enjekte edilebiliyor. Bundan bahsediyorum.

Mucosoft dedi:

SQL ile dosya göndermeyi bilmiyor olmalısınız

Genişletmek için tıkla...

SQL ile dosya gondermek diye bir sey yok cunku. File grant var, o da MySQL de var.
SQL dedigin seyin zibilyon tane implementoru var, Oracle'da yardimci toollar'la import edersin, Snowflake'de file grant diye bir sey zaten yok. SQL yerine MySQL dahi yazmamissin.

Mucosoft dedi:

PHP üzerinden

Genişletmek için tıkla...

Diye baslamissin soze. Dosya direkt senin yazdigin backend sisteme geliyorsa kullanici nasil DB manipulasyonu yapiyor o kisim muamma. Bugun onu yapan yarin SQL injection yapar sistemi gocurur, senin problemin grant'ten fazlasi gibi duruyor.

Sadece 1 kullaniciya file grant'i ver, standart CRUD islemleri icin farkli kullanici kullan. Anladigim kadariyla verebilecegim tavsiye bu. Zaten olmasi gereken read - write yetkisini bolusturup durume gore farkli pool'dan islem yapmak. Bulk islemler icin batch mode'u inceleyebilirsin.

bitwise dedi:

SQL ile dosya gondermek diye bir sey yok cunku. File grant var, o da MySQL de var.
SQL dedigin seyin zibilyon tane implementory var, Oracle'da yardimci toollar'la import edersin, Snowflake'de file grant diye bir sey zaten yok. SQL yerine MySQL dahi yazmamissin.

Diye baslamissin soze. Dosya direkt senin yazdigin backend sisteme geliyorsa kullanici nasil DB manipulasyonu yapiyor o kisim muamma. Bugun onu yapan yarin SQL injection yapar sistemi gocurur, senin problemin grant'ten fazlasi gibi duruyor.

Sadece 1 kullaniciya file grant'i ver, standart CRUD islemleri icin farkli kullanici kullan. Anladigim kadariyla verebilecegim tavsiye bu. Zaten olmasi gereken read - write yetkisini bolusturup durume gore farkli pool'dan islem yapmak. Bulk islemler icin batch mode'u inceleyebilirsin.

MySQL :: MySQL 8.0 Reference Manual :: 5.5 Using mysql in Batch Mode

dev.mysql.com

Genişletmek için tıkla...

Bilgi için teşekkürler. SQL injection yapan bir yazılımcı, FILE yetkisi sebebiyle dosya sistemine shell dosyası ekliyordu. Bu sorunu çözdük, artık SQL ile dizine dosya eklenmiyor. Zaten bu yetkiyi kullanmıyordum, ekstra kullanıcı açmaya gerek bulunmuyor.

Benim sorduğum soru SQL dışında PHP üzerinde oluşan güvenlik açığı ile hangi yöntemlerle shell dosyası yüklenebildiği. Bunlara karşı da önlem almak istiyorum.

Mucosoft dedi:

Bilgi için teşekkürler. SQL injection yapan bir yazılımcı, FILE yetkisi sebebiyle dosya sistemine shell dosyası ekliyordu. Bu sorunu çözdük, artık SQL ile dizine dosya eklenmiyor. Zaten bu yetkiyi kullanmıyordum, ekstra kullanıcı açmaya gerek bulunmuyor.

Benim sorduğum soru SQL dışında PHP üzerinde oluşan güvenlik açığı ile hangi yöntemlerle shell dosyası yüklenebildiği. Bunlara karşı da önlem almak istiyorum.

Genişletmek için tıkla...

Bence MySQL yetkisini kaldirmak pisligi halinin altina supurmek. Kullanicinin senin yetkilerini zor duruma sokmamasi gerekir.

Guvenlik acigi hakkinda yorum yapmak icin sistemi bilmek gerek. Sadece 443 portunu expose ederek, kullanicidan dosya aldigin zaman bu dosyayi sanitize ederek ve olusturdugun SQL query'lerini prepared statement ve sanitized input yardimiyla olusturarak yola baslayabilirsin.

ORM sistemleri vardir PHP icin, optimizasyon gerekmedikce query yazmana gerek yok.
Ayrica sistem elveriyorsa DB ile web server ayni fiziksel makinede olmamali. Senin web sunucuya yuklenen herhangi bir dosyanin ayni zamanda DB sunucusuna da yukleniyor olmasi buyuk risk.

bitwise dedi:

Bence MySQL yetkisini kaldirmak pisligi halinin altina supurmek. Kullanicinin senin yetkilerini zor duruma sokmamasi gerekir.

Guvenlik acigi hakkinda yorum yapmak icin sistemi bilmek gerek. Sadece 443 portunu expose ederek, kullanicidan dosya aldigin zaman bu dosyayi sanitize ederek ve olusturdugun SQL query'lerini prepared statement ve sanitized input yardimiyla olusturarak yola baslayabilirsin.

ORM sistemleri vardir PHP icin, optimizasyon gerekmedikce query yazmana gerek yok.
Ayrica sistem elveriyorsa DB ile web server ayni fiziksel makinede olmamali. Senin web sunucuya yuklenen herhangi bir dosyanin ayni zamanda DB sunucusuna da yukleniyor olmasi buyuk risk.

Genişletmek için tıkla...

SQL kısmını hallettik diyelim. SQL dışında yazılımcıların bir web sitesinde JS ile oluşan açıkla beraber dosya yüklemeleri mümkün mü? Bu şekilde bir açık oluşabilir mi?

Mucosoft dedi:

SQL kısmını hallettik diyelim. SQL dışında yazılımcıların bir web sitesinde JS ile oluşan açıkla beraber dosya yüklemeleri mümkün mü? Bu şekilde bir açık oluşabilir mi?

Genişletmek için tıkla...

JS client tarafta calisiyor, dosya yuklemek icin server'a istek atmasi gerekiyor. Yani backend saglamsa hayir. Sunucuna SSH ile uzaktan baglanilmayacagini varsayarak yaziyorum, network guvenligini duzgun saglamak gerekiyor. Yoksa tek yapmalari gereken portscan atip brute force yardirmak.

Client'tan aldigin dosyalari read-only permission ile tercihen 3. bir dosya sunucusunda ( backend - db - fileServer ) saklarsin. Unix chmod 400 gibi. Execute edilemez, uzerine yazilamaz, senin belirledigin kullanici disinda birisi okuyamaz.


Bir de "JS ile olusan acik" ya da "PHP ile olusan acik" seklinde degerlendirmek dogru degil. Programlama dili kaynakli acik cok cok nadir olur, hemen patchlenir. Esas acigi yazilim gelistiren kisi olusturur.