PHP安全性問題總結

#                                                        

##1-XSS

#Cross-Site Scripting（跨站腳本上攻擊時）簡稱為 XSS，是一種代碼注入攻擊。攻擊者透過在目標網站上註入惡意腳本，使其在使用者的瀏覽器上運作。利用這些惡意腳本，攻擊者可取得使用者的敏感資訊如 Cookie、SessionID 等，進而危害資料安全。

來源

• 來自使用者的UGC 資訊

• 來自第三方的連結

• URL 參數

• POST 參數

• #Referer（可能來自不可信的來源）

• Cookie （可能來自其他子網域注入）

轉義、過濾、限制長度

2-SQL注入

透過SQL語句，實現無帳號登錄，甚至竄改資料庫。

攻擊實例

String sql = "select * from user_table where username=
' "+userName+" ' and password=' "+password+" '";

--当输入了上面的用户名和密码，上面的SQL语句变成：
SELECT * FROM user_table WHERE username=
'’or 1 = 1 -- and password='’

"""
--分析SQL语句：
--条件后面username=”or 1=1 用户名等于 ” 或1=1 那么这个条件一定会成功；

--然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用，这样语句永远都--能正确执行，用户轻易骗过系统，获取合法身份。
--这还是比较温柔的，如果是执行
SELECT * FROM user_table WHERE
username='' ;DROP DATABASE (DB Name) --' and password=''
--其后果可想而知…

如何防禦SQL注入

　1、檢查變數資料類型和格式
　2、過濾特殊符號
　3、綁定變量，使用預編譯語句

3-CSRF

CSRF一般指跨站請求偽造

CSRF攻擊的全名為跨站請求偽造（cross site request forgery)，是一種對網站的惡意利用

CSRF則是透過偽裝來自受信任用戶的請求來利用受信任的網站,攻擊者盜用了你的身份，以你的名義向第三方網站發送惡意請求。 CRSF能做的事情包括利用你的身分發送電子郵件、發送簡訊、進行交易轉帳等，甚至盜取你的帳號。

例如：

如下：其中Web A為有CSRF漏洞的網站，Web B為攻擊者建構的惡意網站，User C為Web A網站的合法使用者

3-1 CSRF攻擊攻擊原則及流程如下：

1.使用者C開啟瀏覽器，造訪受信任網站A，輸入使用者名稱和密碼請求登入網站A；

2.在使用者資訊通過驗證後，網站A產生Cookie訊息並回傳給瀏覽器，此時使用者登入網站A成功，可以正常傳送請求到網站A；

3.在使用者未退出網站A之前，在同一瀏覽器中，打開一個TAB頁訪問網站B；

4.網站B接收到使用者請求後，返回一些攻擊性代碼，並發出一個請求要求訪問第三方站點A；

5.瀏覽器在接收到這些攻擊性代碼後，根據網站B的請求，在用戶不知情的情況下攜帶Cookie訊息，向網站A發出請求。網站A並不知道該請求其實是由B發起的，所以會根據用戶C的Cookie資訊以C的權限處理該請求，導致來自網站B的惡意程式碼被執行。

3-2防禦CSRF攻擊

目前防禦CSRF 攻擊主要有三種策略：驗證HTTP Referer 欄位；在請求位址中新增token並驗證；在HTTP 頭中自訂屬性並驗證。

1-驗證 HTTP Referer 欄位

根據 HTTP 協議，在 HTTP 頭中有一個欄位叫 Referer，它記錄了該 HTTP 請求的來源位址。在通常情況下，造訪安全受限頁面的請求來自於同一個網站，例如需要造訪http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，使用者必須先登陸bank.example，然後透過點擊頁面上的按鈕來觸發轉帳事件。這時，該轉帳請求的 Referer 值就會是轉帳按鈕所在的頁面的 URL，通常是以 bank.example 網域開頭的位址。而如果駭客要對銀行網站實施 CSRF 攻擊，他只能在他自己的網站建構請求，當使用者透過駭客的網站發送請求到銀行時，該請求的 Referer 是指向駭客自己的網站。因此，要防禦 CSRF 攻擊，銀行網站只需要對於每一個轉帳請求驗證其 Referer 值，如果是以 bank.example 開頭的域名，則說明該請求是來自銀行網站自己的請求，是合法的。如果 Referer 是其他網站的話，則有可能是駭客的 CSRF 攻擊，拒絕該請求。

這種方法的顯而易見的好處就是簡單易行，網站的普通開發人員不需要操心CSRF 的漏洞，只需要在最後給所有安全敏感的請求統一增加一個攔截器來檢查Referer 的值就可以。特別是對於目前現有的系統，不需要改變目前系統的任何現有程式碼和邏輯，沒有風險，非常方便。

然而，這種方法並非萬無一失。 Referer 的值是由瀏覽器提供的，雖然 HTTP 協定上有明確的要求，但是每個瀏覽器對於 Referer 的特定實作可能有差別，並不能保證瀏覽器本身沒有安全漏洞。使用驗證 Referer 值的方法，就是把安全性都依賴第三方（即瀏覽器）來保障，從理論上來講，這樣並不安全。事實上，對於某些瀏覽器，例如 IE6 或 FF2，目前已經有一些方法可以竄改 Referer 值。如果 bank.example 網站支援 IE6 瀏覽器，駭客完全可以將使用者瀏覽器的 Referer 值設為以 bank.example 網域開頭的位址，這樣就可以通過驗證，從而進行 CSRF 攻擊。

即使是使用最新的瀏覽器，駭客無法竄改 Referer 值，這種方法仍然有問題。因為 Referer 值會記錄下使用者的存取來源，有些使用者認為這樣會侵犯到他們自己的隱私權，特別是有些組織擔心 Referer 值會把組織內網中的某些資訊洩漏到外網中。因此，用戶自己可以設定瀏覽器使其在發送請求時不再提供 Referer。當他們正常造訪銀行網站時，網站會因為要求沒有 Referer 值而認為是 CSRF 攻擊，拒絕合法使用者的造訪。

2-在請求位址中新增token 並驗證

CSRF 攻擊之所以能夠成功，是因為駭客可以完全偽造使用者的請求，該請求中所有的使用者驗證資訊都是存在於cookie 中，因此駭客可以在不知道這些驗證資訊的情況下直接利用使用者自己的cookie 來通過安全驗證。要抵禦 CSRF，關鍵在於在請求中放入駭客所不能偽造的信息，並且該信息不存在於 cookie 之中。可以在HTTP 請求中以參數的形式加入一個隨機產生的token，並在伺服器端建立一個攔截器來驗證這個token，如果請求中沒有token 或token 內容不正確，則認為可能是CSRF 攻擊而拒絕該請求。

這種方法要比檢查Referer 要安全一些，token 可以在用戶登陸後產生並放於session 之中，然後在每次請求時把token 從session 中拿出，與請求中的token進行比對，但這種方法的困難在於如何把token 以參數的形式加入請求。對於 GET 要求，token 會附在請求位址之後，這樣 URL 就變成 http://url?csrftoken=tokenvalue。而對於 POST 請求來說，要在 form 的最後加上 ，這樣就把 token 以參數的形式加入請求了。但是，在一個網站中，可以接受請求的地方非常多，要對於每個請求都加上token 是很麻煩的，並且很容易漏掉，通常使用的方法就是在每次頁面加載時，使用javascript 遍歷整個dom 樹，對於dom 中所有的a 和form 標籤後加入token。這樣可以解決大部分的請求，但是對於在頁面載入之後動態產生的 html 程式碼，這種方法就沒有作用，還需要程式設計師在編碼時手動新增 token。

此方法還有一個缺點是難以保證 token 本身的安全。特別是在一些論壇之類支援用戶自己發表內容的網站，駭客可以在上面發布自己個人網站的地址。由於系統也會在這個地址後面加上 token，駭客可以在自己的網站上得到這個 token，並馬上就可以發動 CSRF 攻擊。為了避免這一點，系統可以在添加 token 的時候增加一個判斷，如果這個鏈接是鏈到自己本站的，就在後面添加 token，如果是通向外網則不加。不過，即使這個 csrftoken 不以參數的形式附加在請求之中，黑客的網站也同樣可以透過 Referer 來得到這個 token 值以發動 CSRF 攻擊。這也是為什麼有些使用者喜歡手動關閉瀏覽器 Referer 功能的原因。

3-在HTTP 頭中自訂屬性並驗證

這種方法也是使用token 並進行驗證，和上一種方法不同的是，這裡並不是把token 以參數的形式置於HTTP 請求之中，而是把它放到HTTP 頭中自訂的屬性裡。透過 XMLHttpRequest 這個類，可以一次給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，並把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便，同時，透過 XMLHttpRequest 請求的位址不會被記錄到瀏覽器的位址欄，也不用擔心 token 會透過 Referer 洩漏到其他網站中去。

然而這種方法的限制非常大。 XMLHttpRequest 請求通常用於Ajax 方法中對於頁面局部的非同步刷新，並非所有的請求都適合用這個類別來發起，而且透過該類別請求得到的頁面不能被瀏覽器所記錄下，從而進行前進，後退，刷新，收藏等操作，造成使用者不便。另外，對於沒有進行CSRF 防護的遺留系統來說，要採用這種方法來進行防護，要把所有請求都改為XMLHttpRequest 請求，這樣幾乎是要重寫整個網站，這代價無疑是不能接受的

4-CC攻擊

#4-1 CC攻擊的原理：

#　CC攻擊的原理就是攻擊者控制某些主機不停地發大量封包給對方伺服器造成伺服器資源耗盡，一直到宕機崩潰。 CC主要是用來消耗伺服器資源的，每個人都有這樣的體驗：當一個網頁訪問的人數特別多的時候，打開網頁就慢了，CC就是模擬多個用戶(多少線程就是多少用戶)不停地進行存取那些需要大量資料操作(就是需要大量CPU時間)的頁面，造成伺服器資源的浪費，CPU長時間處於100%，永遠都有處理不完的連接直至就網路擁塞，正常的存取被中止。

4-2 CC攻擊的種類：

CC攻擊的種類有三種，

• 直接攻擊
• 代理攻擊
• 殭屍網路攻擊

直接攻擊主要針對有重要缺陷的WEB應用程序，一般說來是程式寫的有問題的時候才會出現這種情況，比較少見。殭屍網路攻擊有點類似DDOS 攻擊了，從WEB 應用程式層面上已經無法防禦，所以代理攻擊是CC 攻擊者一般會操作一批代理伺服器，比方說100 個代理，然後每個代理同時發出10 個請求，這樣WEB 伺服器同時收到1000 個並發請求的，並且在發出請求後，立刻斷掉與代理的連接，避免代理返回的數據將本身的頻寬堵死，而不能發動再次請求，這時WEB 伺服器會將回應這些請求的進程進行佇列，資料庫伺服器也同樣如此，這樣一來，正常請求將會被排在很後被處理，就像本來你去食堂吃飯時，一般只有不到十個人在排隊，今天前面卻插了一千個人，那麼輪到你的機會就很小很小了，這時就出現頁面打開極其緩慢或者白屏。

4-3 CC攻擊與DDOS的差異

DDoS是針對IP的攻擊，而CC攻擊的是伺服器資源。

5-DOS攻擊

DOS：中文名稱是拒絕服務，一切能引起DOS行為的攻擊都稱為DOS攻擊。此攻擊的效果是使得電腦或網路無法提供正常的服務。常見的DOS攻擊有針對電腦網路頻寬和連接性的攻擊。 DOS是單機於單機之間的攻擊。

DOS攻擊的原理：首先攻擊者向被攻擊的伺服器發送大量的虛假IP請求，被攻擊者在收到請求後返回確認訊息，等待攻擊者進行確認，（此處需要擁有HTTP協定工作方式和TCP三次握手的基本知識）該過程需要TCP的三次握手，由於攻擊者發送的請求信息是虛假的，所以伺服器接收不到返回的確認訊息，在一段時間內伺服器會處與等待狀態，而分配給這次請求的資源卻沒有被釋放。當被攻擊者等待一定的時間後，會因連線逾時而斷開，這時攻擊者在次發送新的假訊息請求，這樣最終伺服器資源被耗盡，直到癱瘓。

6-DDOS攻擊

DDoS攻擊就是分散式的拒絕服務攻擊，DDoS攻擊手段是在傳統的DoS攻擊基礎之上產生的一類攻擊方式。單一的DoS攻擊一般是採用一對一方式的，隨著電腦與網路技術的發展，DoS攻擊的困難程度加大了。於是就產生了DDoS攻擊，它的原理就很簡單：電腦與網路的處理能力加大了10倍，用一台攻擊機來攻擊不再能起作用，那麼DDoS就是利用更多的傀儡機來發起進攻，以比從前更大的規模來進攻受害者。常用的DDoS軟體有：LOIC。
在這裡補充兩點：第一就是DDOS攻擊不僅能攻擊計算機，還能攻擊路由器，因為路由器是一台特殊類型的計算機；第二是網速決定攻擊的好和快，比如說，如果你一個被限制網速的環境下，它們的攻擊效果不是很明顯，但是快的網速相比之下更加具有攻擊效果。

以上是PHP安全性問題總結的詳細內容。更多資訊請關注PHP中文網其他相關文章！