MySql LOAD_FILE bizzare權限問題？

Question

我在工作中管理的網站是SQL注入攻擊的受害者 。 通過檢查日志，看來攻擊者使用sqlmap帶有文件讀取選項的 sqlmap並從服務器上獲取了一堆配置文件，這是由於我們的Web開發人員草率並使用了root mysql帳戶進行了連接（具有FILE權限） 。

這是我要理解的怪異部分。 讀取文件-我知道是-因為攻擊者隨后在其中一個文件中使用了密碼來進行一些系統滲透。 在查看日志時，他首先獲取了index.php，該文件引用了config.php和其他一些文件。 他們都是目標。

為了加強安全性，我抓起了sqlmap並命中了我們的服務器，並弄清了它的工作原理之后，便能夠抓取這些文件。

我們的SQL Server並非面向外部，因此攻擊者無法嘗試此操作。 這是奇怪的部分：

我從桌面連接到我們的MySQL server ，並嘗試選擇LOAD_FILE以及LOAD DATA INFILE into TABLE.

他們中有些人工作了。 例如， select LOAD_FILE('/etc/passwd')返回/etc/passwd.

但並非所有人都奏效。

select LOAD_FILE('/var/www/site_name/index.php') 返回 NULL 。

LOAD DATA INFILE '/var/www/site_name/index.php' INTO temp; 回來：

錯誤29（HY000）：找不到文件'/var/www/site_name/index.php'（錯誤代碼：13）

什么？ 文件未找到？ ?？

因此，我針對相同的文件運行了sqlmap，並下載了該文件。

我用-v 6運行了sqlmap ，所以我可以看到所有內容-它正在使用LOAD_FILE來獲取文件。

為什么LOAD_FILE在注入攻擊中起作用，但是從mysql客戶端命令行加載文件返回NULL或找不到文件？ 但是僅適用於某些文件嗎？ / etc / passwd和/ etc / hosts可讀。

有什么線索嗎？

Answer 1

事實證明，經過幾天的努力，我發現另一位管理員搬來搬去，使面向外部的服務器（我認為自己遇到的那台服務器）實際上將端口80轉發到了另一台更新的服務器上。 兩台服務器上都有一個數據庫副本。 因此，當執行SQL注入時，它正在訪問內部/較新的數據庫，並且可以讀取該服務器上的文件。 當我用mysql客戶端命中相同的IP地址時，它正在讀取數據庫的舊副本，該副本位於不同的文件系統上，該文件沒有與另一台服務器相同的文件。

從那以后，頭就滾了。 感謝您的努力，也很抱歉浪費任何人的時間。