我最為熟悉的便是Apache了，先來研究它的檔案解析漏洞。百度許久，又谷歌一番，最終發覺，Apache關於檔案解析，似乎只有三種“漏洞”。之所以打引號是因為我覺得這三種“漏洞”都不是Apache的漏洞，只是其特性，而很多程式設計師不瞭解這種特性，故而寫出有問題的程式碼，這才給黑客可趁之機，造成漏洞。但大家都稱呼這是Apache的檔案解析漏洞，我也只好隨大流了。

1.多字尾名

先說第一種特性：多字尾名。這是怎麼的一種鮮為人知的特性呢？原來是這樣的，Apache認為，一個檔案可以有多個字尾，如：werner.txt.png.mp3。這一檔案，放在Windows裡，毫無疑問，就是個mp3檔案，Windows只認最後一個“.”及其後面的字元“mp3”，覺得該檔案字尾為“.mp3”，這也是大多數作業系統、應用軟體的處理方式、是正常人習慣。而在Apache中，則可能有所不同，如果有必要，Apache會從後（右）往前（左），一一辨別字尾。何時有必要？當Apache不認識某個字尾時，便有必要。如某檔名為：werner.mp3.html.qwe.arex，Apache在處理時，先讀取最後一個字尾，為“.arex”，一看，這啥玩意啊，不認識，繼續讀取下一個字尾“.qwe”，一看，呀，這又是啥，還是不認識，繼續讀下一個字尾“.html”，一看，哦，這是個超文字標記語言檔案，俗稱網頁檔案，這回認識了，也就不繼續讀下一個字尾了。若是所有後綴都看完了沒有一個認識怎麼辦？此時就會把該檔案當做預設型別進行處理了，一般來說，預設型別是text/plain。據說在Apache的配置檔案中搜索“DefaultType”就能看到預設型別的明確定義了，但我卻不知為何，沒有找到。

哪些字尾Apache認識，哪些不認識？有一個名為mime.types的檔案，其中記錄著Apache認識的字尾。在Ubuntu下，該檔案位於/etc/mime.types，在Windows下，該檔案位於C:/apache/conf/mime.types（類似這樣的，注意Apache的安裝路徑）。該檔案是一個一對多的對映表，定義了某一種檔案型別，對應的幾種字尾。除了該檔案，在Apache的配置檔案中，還可以用AddCharset語句新增對映，如：

  AddCharset us-ascii   .ascii .us-ascii
  AddCharset ISO-2022-CN .iso2022-cn .cis

mime.types是個很長的檔案，大概看了下，Apache認識的字尾比我多多了。節選部分如下所示：

  application/java-archive          jar
  application/m3g                         m3g
  application/java-vm                   class
  application/javascript                js
  application/json                    json
  text/html                             html htm shtml
  text/x-diff                             diff patch
  video/x-flv
 
                             flv
  video/x-la-asf                          lsf lsx
  video/x-mng                             mng
  video/x-ms-asf                          asf asx
  video/x-ms-wm                         wm

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12

這一特性會帶來什麼問題呢？網站往往有上傳檔案的功能，但一定不想讓使用者上傳程式，因為這很可能會危害網站安全，故而會檢查上傳檔案的字尾名，若是.php，則拒絕上傳（假設這是個php站）。此時使用者只需上傳檔案evildoer.php.qwe，若是程式設計師不瞭解Apache的這一特性，編寫的程式檢查字尾時只看“.qwe”，而認為這不是程式檔案，允許上傳，則使用者成功地繞過了上傳時的安全檢查，上傳了php程式檔案。該檔案的最後一個字尾“.qwe”是Apache不認識的，故而Apache會以倒數第二個字尾“.php”為準，把該檔案當做是php檔案，解析執行。

這總是奏效的嗎？按理來說，由於這是特性而不是漏洞，所以適用於所有版本的Apache。這一奇怪的特性，說不定正是Apache的自豪之處呢。但是，在我的測試中卻發現，類似aaa.php.xxx的檔案並不會被作為php程式執行，而是被當成文字檔案，返回給瀏覽器，在瀏覽器中可以看到php原始碼，而不是執行結果。測試環境是Ubuntu14.04+Apache2.4.7+php5。

這是怎麼回事？難道前面幾百字都是廢話，說的是錯的？我們來做個實驗。準備一個檔案，內容隨意，命名為test.jpg.aaa，放置在Apache中，然後在瀏覽器中訪問它，結果如下圖所示：

可見瀏覽器是將該檔案作為圖片處理的。瀏覽器為何認為test.jpg.aaa是圖片呢？aaa可不是圖片檔案的字尾。這是因為伺服器的響應HTTP頭中的Content-Type欄位值為image/jpeg，瀏覽器看到image/jpeg，便知這是圖片檔案。這說明伺服器（此處即Apache）是把test.jpg.aaa當做圖片的，也說明，前面分析的Apache的多字尾處理是沒有錯的。

那麼aaa.php.xxx為何沒有被作為php程式碼執行呢？我猜是這樣的，當然只是我的猜測，實在是找不到相關資料，只好猜了。Apache看到檔案aaa.php.xxx，按照多字尾名的解析規則，認為該檔案是php程式檔案，把該檔案作為php程式檔案處理。怎麼處理呢？交給php直譯器，Apache本身並不懂php。而php直譯器卻有著和Apache不同的字尾解析規則，可能只認最後一個字尾，故而認為aaa.php.xxx不是php程式檔案，拒絕執行。在我的測試環境中，php以模組（module）的模式工作於Apache的領導下。這種模式下php接受到領導Apache分配的任務——aaa.php.xxx，一看，不是php程式檔案，沒法執行，但也沒有報錯，而是返回了檔案內容本身。php還可以以FASTCGI的模式工作於Apache中，此種模式下php遇到類似aaa.php.xxx這種不是php程式的檔案，會觸發500錯誤。

php本身是如何識別檔案的呢？我在Apache的模組的配置檔案中找到了php5.conf，內容如下：

  <FilesMatch ".+\.ph(p[345]?|t|tml)$">
      SetHandler application/x-httpd-php
  </FilesMatch>
  <FilesMatch ".+\.phps$">
      SetHandler application/x-httpd-php-source
      # Deny access to raw php sources by default
      # To re-enable it's recommended to enable access to the files
      # only in specific virtual host or directory
      Order Deny,Allow
      Deny from all
  </FilesMatch>
  # Deny access to files without filename (e.g. '.php')
  <FilesMatch "^\.ph(p[345]?|t|tml|ps)$">
      Order Deny,Allow
      Deny from all
  </FilesMatch>

  # Running PHP scripts in user directories is disabled by default
  #
  # To re-enable PHP in user directories comment the following lines
  # (from <IfModule ...> to </IfModule>.) Do NOT set it to On as it
  # prevents .htaccess files from disabling it.
  <IfModule mod_userdir.c>
      <Directory /home/*/public_html>
          php_admin_flag engine Off
      </Directory>
  </IfModule>

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27

閱讀上示配置檔案可知，被當做php程式執行的檔名要符合正則表示式：”.+\.ph(p[345]?|t|tml)"，其中“"，其中“”符號在正則中匹配結束，故而可知php本身確實是只看最後一個字尾的。就算Apache把某檔案當php程式，php自己不認它，也是無用。

進一步試驗，把php5.conf檔案中剛剛提到的正則表示式的“$”換成“\.”，即：

  ".+\.ph(p[345]?|t|tml)\."

• 1

然後重啟Apache使配置檔案生效，再在瀏覽器中訪問aaa.php.xxx，這次，aaa.php.xxx果然被當做php程式執行了，在瀏覽器中，看到的是程式執行結果而不是原始碼。這也從側面驗證了，我的猜測是正確的。測試完之後，一定要記得改回去。

2.罕見字尾

計算機世界自開天闢地以來，便自由多彩。還記得mime.types檔案嗎？在該檔案中搜索“php”這三個字母，結果如下所示：

  [email protected]:~$ cat /etc/mime.types | grep php
  #application/x-httpd-php          phtml pht php
  #application/x-httpd-php-source           phps
  #application/x-httpd-php3         php3
  #application/x-httpd-php3-preprocessed        php3p
  #application/x-httpd-php4         php4
  #application/x-httpd-php5         php5

• 1
• 2
• 3
• 4
• 5
• 6
• 7

還記得正則表示式”.+\.ph(p[345]?|t|tml)$”嗎，該正則表示式匹配的不僅僅有php，還有php3、php4、php5、pht和phtml。

好吧，原來不僅php，就連phtml、pht、php3、php4和php5都是Apache和php認可的php程式的檔案字尾。我原本只知道“.php”的，真是大開眼界。這就好比，不僅py是Python程式檔案的字尾，還有pyc和pyo也都是。寫上傳過濾規則的程式設計師是否博學多識，也知道這些知識呢？我想，大抵是不知道的。利用這些“罕見”的字尾名，也可能繞過安全檢查，幹些“壞事”。

我在Ubuntu14.04+Apache2.4.7中進行測試，先準備檔案text.php，其內容是經典的Hello World：

  <?php echo 'HELLO WORLD'; ?>

然後在瀏覽器中開啟它，成功顯示“HELLO WORLD”。再修改該檔案字尾為各種字尾，進行測試。測試結果是，以php、phtml、pht、php3、php4和php5為字尾，能成功看到“HELLO WORLD”；以phps為字尾，會報403錯誤，Forbidden；以php3p為字尾，會在瀏覽器中看到原始碼。

3.妙用.htaccess

.htaccess是Apache的又一特色。一般來說，配置檔案的作用範圍都是全域性的，但Apache提供了一種很方便的、可作用於當前目錄及其子目錄的配置檔案——.htaccess（分散式配置檔案）。

要想使.htaccess檔案生效，需要兩個條件，一是在Apache的配置檔案中寫上：

  AllowOverride All

若這樣寫則.htaccess不會生效：

  AllowOverride None

二是Apache要載入mod_Rewrite模組。載入該模組，需要在Apache的配置檔案中寫上：

  LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so

若是在Ubuntu中，可能還需要執行命令：

  sudo a2enmod rewrite

配置完後需要重啟Apache。

需要注意Apache可能有多個配置檔案，後加載的配置檔案會覆蓋先載入的配置檔案中的配置。所以在某個配置檔案中將AllowOverride設定成All，若是其後載入的某個配置檔案中AllowOverride的設定是None，則也是沒有用的。一般來說，先載入httpd.conf，再載入conf.d/中的配置檔案，最後載入sites-enabled/中的配置檔案。

這意味著，.htaccess並不總是有效的。而且不幸的是，在我的測試環境中.htaccess預設無效。好吧，為了測試，我只好將它改為有效。以下討論均在.htaccess有效的前提下進行。

.htaccess檔案可以配置很多事情，如是否開啟站點的圖片快取、自定義錯誤頁面、自定義預設文件、設定WWW域名重定向、設定網頁重定向、設定圖片防盜鏈和訪問許可權控制。但我們這裡只關心.htaccess檔案的一個作用——MIME型別修改。如在.htaccess檔案中寫入：

  AddType application/x-httpd-php xxx

就成功地使該.htaccess檔案所在目錄及其子目錄中的字尾為.xxx的檔案被Apache當做php檔案。另一種寫法是：

  <FilesMatch "shell.jpg">
    SetHandler application/x-httpd-php
  </FilesMatch>

• 1
• 2
• 3

該語句會讓Apache把shell.jpg檔案解析為php檔案。

下面是一次測試，測試前已經開啟Apache對.htaccess檔案的支援。在網站根目錄中準備如下檔案樹：

  │
  ├── htaccess_test/
  │   ├── .htaccess
  │   ├── shell.jpg
  │   ├── type.xxx
  │   └── test/
  │       ├── shell.jpg
  │       └── type.xxx
  ├── shell.jpg
  └── type.xxx

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10

其中，檔案.htaccess的內容為：

  AddType application/x-httpd-php xxx

  <FilesMatch "shell.jpg">
  SetHandler application/x-httpd-php
  </FilesMatch>

• 1
• 2
• 3
• 4
• 5

檔案shell.jpg和type.xxx的內容相同，均為：

  <?php echo 'HELLO WORLD'; ?>

然後在瀏覽器中訪問各檔案，結果如下表所示：

這一測試結果和預期是相符的。

但是，按照前面的猜測，就算Apache認為type.xxx是php檔案，php自己不這麼認為，不也是不能執行的嗎？這次怎麼就能執行了，好生奇怪。但不管怎麼說，我們都已經知道，當.htaccess檔案有效時，用.htaccess檔案可以很好地設定檔案字尾的解析方式。