簡體   English   中英

大型POST傳輸僅適用於已登錄的用戶?

[英]Large POST transfer only for logged-in users?

在我的主頁上,應該允許“登錄”(通過PHP會話)的用戶上傳非常大的文件(通過標准HTML5 / PHP / XMLHttpRequest / POST形式)。 因此,我將“ post_max_size”設置為0,以消除對文件大小的任何限制。

但是,我要避免現在每個人都可以向我的服務器發送任意大的POST數據並將其阻止。 要先驗證登錄名, 然后接受非常大的POST傳輸才能開始。

如何實現呢?

受到賈里(Jari)評論的啟發,我實施了以下策略,對我來說效果很好。 由於我將HTTPS用於網站和文件上傳,因此這種策略甚至可以避免網絡嗅探攻擊。

我的網站基於php,已登錄的用戶在其中檢索php-session(-id)。

php.ini的默認值為post_max_size = 8M back,因此我的服務器通常不接受大的POST傳輸。

登錄時,我在客戶端設置了一個臨時cookie secret=XXXXXXXX ,其中X代表一個隨機字符串,該字符串也保存在服務器端的$_SESSION["secret"]

在服務器端,我為每個會話創建一個可通過網絡訪問的“用戶目錄” tmp-YYYYYYYY ,其中Y只是另一個隨機字符串。 在此目錄中,我放置了一個指向我的全局upload.php -script的符號鏈接,該upload.php通過POST通過POST從上載表單接收文件上載(您也可以將upload.php復制到用戶目錄中)。 現在,為了允許對tmp-YYYYYYYY/upload.php的POST傳輸具有無限大小,我還創建了文件tmp-YYYYYYYY/.htaccess ,其中包含php_value post_max_size 0 這樣可以將大小不受限制的POST數據傳遞到鏈接的上載腳本。 但是,這在某種意義上是不安全的,因為每個知道/ tmp-YYYYYYYY/upload.php URL tmp-YYYYYYYY/upload.php都可以向該文件發送任意大的POST數據,這可能會淹沒服務器的tmp目錄。 為了避免這種情況,我完整的.htaccess -file如下所示:

RewriteEngine On
RewriteCond %{HTTP_COOKIE} !secret=XXXXXXXX;?
RewriteRule ^ https://www.myserver.com/secreterror.php [L]
php_value post_max_size 0

也就是說,只要發送大量POST數據與秘密值沒有cookie中的客戶端,那么我再直接 (因為目標是一個絕對URL)他的一些錯誤通知腳本。 這種重定向轉發后的數據,所以沒有POST數據存儲我在這種情況下,服務器上。 如果客戶端設置了正確的秘密Cookie,則對於用戶目錄(對於upload.php ,最大允許POST數據大小將設置為無限制。

最后評論:

  • 您也可以使用post_max_size 4G ,以防止“真正”任意大數據
  • 您還可以在此處覆蓋其他php值, 列表中所有標記為PHP_INI_PERDIR的值
  • 為了能夠覆蓋.htaccess post_max_size ,apache不能以CGI模式運行php,而應作為apache模塊運行。 您可以在“服務器API”字段中通過phpinfo()進行檢查。 這里這里
  • 必須啟用mod_rewrite apache模塊,例如通過sudo a2enmod rewrite加上重新啟動apache service apache2 restart
  • 可能必須修改您的虛擬主機配置,以便允許.htaccess啟用重寫,例如,通過AllowOverride All
  • 如果沒有HTTPS,則cookie的傳輸是不安全的,因此該方法容易受到網絡嗅探器的攻擊,就像通常通過HTTP進行php會話一樣
  • 與其為每個會話創建一個目錄(而不是為單個密鑰包含自己的.htaccess -file),還可以為所有用戶使用相同的上傳文件(在其單個目錄中),並存儲/更新所有臨時密鑰。數據庫中的密鑰,然后使用修改后的RewriteCond來檢查此數據庫中是否存在Cookie中傳遞的密鑰

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM