常見問題介紹：
（學習影片分享：程式設計影片）
1、跨站腳本攻擊(XSS攻擊)
XSS(Cross Site Scripting)，跨站腳本攻擊。 XSS是常見的Web攻擊技術之一.所謂的跨站腳本攻擊指得是:惡意攻擊者往Web頁面裡注入惡意Script程式碼，使用者瀏覽這些網頁時，就會執行其中的惡意程式碼，可對使用者進行盜取cookie資訊、會話劫持等各種攻擊.
解決方案:
(1) 輸入過濾。永遠不要相信使用者的輸入，對使用者輸入的資料做一定的過濾。如輸入的資料是否符合預期的格式，例如日期格式，Email格式，電話號碼
碼格式等等。這樣可以初步對XSS漏洞進行防禦。上面的措施只在web端做了限制，攻擊者通抓包工具如Fiddler還是可以繞過前端輸入的限制，修改請求注入攻擊腳本。
因此，後台伺服器需要在接收到使用者輸入的資料後，對特殊危險字元進行過濾或轉義處理，然後再儲存到資料庫中。 (2) 輸出編碼。伺服器端輸出到瀏覽器的數據，
可以使用系統的安全函數來進行編碼或轉義來防範XSS攻擊。在PHP中，有htmlentities()和htmlspecialchars()兩個函數可以滿足安全要求。對應的JavaScript的編
碼方式可以使用JavascriptEncode。 (3) 安全編碼。開發需盡量避免Web客戶端文件重寫、重定向或其他敏感操作，同時要避免使用客戶端數據，這些操作需盡量在服
務器端使用動態頁面來實現。 (4) HttpOnly Cookie。預防XSS攻擊竊取用戶cookie最有效的防禦手段。 Web應用程式在設定cookie時，將其屬性設為HttpOnly，
就可以避免該網頁的cookie被客戶端惡意JavaScript竊取，保護使用者cookie資訊。 (5)WAF(Web Application Firewall)，Web應用防火牆，主要的功能是防範諸如網頁木馬、
XSS以及CSRF等常見的Web漏洞攻擊。由第三方公司開發，在企業環境中深受歡迎。
2、跨站請求偽造(CSRF攻擊)
CSRF(Cross Site Request Forgery)，即跨站請求偽造，是一種常見的Web攻擊，但許多開發者對它很陌生。 CSRF也是Web安全中最容易被忽略的一種 網站攻擊
CSRF攻擊的原理:CSRF攻擊過程的受害者使用者登入網站A，輸入個人訊息，在本地保存伺服器產生的cookie。然後在A網站點擊由攻擊者建立一條惡意連結跳到
B網站, 然後B網站攜帶著的使用者cookie訊息去造訪B網站.讓A網站造成是使用者自己造訪的假相,從而來進行一些列的操作,常見的就是轉帳.
解決方案:
(1) 驗證碼。在應用程式和使用者進行互動過程中，特別是帳戶交易這種核心步驟，強制使用者輸入驗證碼，才能完成最終請求。在通常情況下，驗證碼足夠很好地遏制
CSRF攻擊。但增加驗證碼降低了使用者的體驗，網站不能為所有的操作加上驗證碼。所以只能將驗證碼當作輔助手段，在關鍵業務點設定驗證碼。 (2) Referer Check。
HTTP Referer是header的一部分，當瀏覽器向web伺服器發送請求時，一般會帶上Referer資訊告訴伺服器是從哪個頁面連結過來的，伺服器來源此可以獲得一些資訊用於處
理。可以透過檢查請求的來源來防禦CSRF攻擊。正常請求的referer具有一定規律，如在提交表單的referer必定是在該頁面發起的請求。所以透過檢查http包頭referer的值
是不是這個頁面，來判斷是不是CSRF攻擊。但在某些情況下如從https跳到http，瀏覽器處於安全考慮，不會發送referer，伺服器就無法進行check了。若與該網站同域的
其他網站有XSS漏洞，那麼攻擊者可以在其他網站注入惡意腳本，受害者進入了此類同域的網址，也會遭受攻擊。基於以上原因，無法完全依賴Referer Check作為防禦CSRF
的主要手段。但是可以透過Referer Check來監控CSRF攻擊的發生。 (3) Anti CSRF Token。目前比較完善的解決方案是加入Anti-CSRF-Token，即發送請求時在HTTP 請
#求中以參數的形式加入一個隨機產生的token，並在伺服器建立一個攔截器來驗證這個token。伺服器讀取瀏覽器目前域cookie中這個token值，會進行校驗該請求當中的token
#和cookie當中的token值是否都存在且相等，才認為這是合法的請求。否則認為這次請求是違法的，拒絕該次服務。這種方法相比Referer檢查要安全很多，token可以在用戶
登陸後產生並放於session或cookie中，然後在每次請求時伺服器把token從session或cookie中拿出，與本次請求中的token 進行比對。由於token的存在，攻擊者無法再建構
出一個完整的URL實作CSRF攻擊。但在處理多個頁面共存問題時，當某個頁面消耗掉token後，其他頁面的表單保存的還是被消耗掉的那個token，其他頁面的表單提交時會出
#現token錯誤。
3、SQL注入攻擊
SQL注入(SQL Injection)，應用程式在向後台資料庫傳遞SQL(Structured Query Language，結構化查詢語言)時，攻擊者將SQL指令插入到Web表單提交或輸入網域或頁面請求的查詢字串，最終達到欺騙伺服器執行惡意的SQL指令.
解決方案:
(1) 防止系統敏感資訊外洩。設定php.ini選項display_errors=off，防止php腳本出錯之後，在web頁面輸出敏感資訊錯誤，讓攻擊者有機可乘。 (2) 數據轉義。設定php.ini選項magic_quotes_gpc=on，它會將提交的變數中所有的'(單引號)，」(雙引號)，\(反斜線)，空白字元等都在前面自動加上\。或採用mysql_real_escape()函數或addslashes()函數進行輸入參數的轉義。(3) 增加黑名單或白名單驗證。白名單驗證一般指，檢查使用者輸入是否為符合預期的類型、長度、數值範圍或其他格式標準。黑名單驗證是指，若在用戶輸入中，包含明顯的惡意內容則拒絕該條用戶請求。在使用白名單驗證時，一般會配合黑名單驗證。
#4、文件上傳漏洞
上傳漏洞在DVBBS6.0時代被駭客利用的最為猖獗，利用上傳漏洞可以直接得到WEBSHELL，危害等級超級高，現在的入侵中上傳漏洞也是常見的漏洞。該漏洞允許用戶上傳任意檔案可能會讓攻擊者註入危險內容或惡意程式碼，並在伺服器上執行。檔案上傳漏洞的原理：由於檔案上傳功能實作程式碼沒有嚴格限制使用者上傳的檔案後綴以及檔案類型，導致允許攻擊者向某個可透過Web 存取的目錄上傳任何PHP文件，並且能夠將這些文件傳遞給PHP 解釋器，就可以在遠端伺服器上執行任意PHP腳本。
解決方案：
# (1) 檢查伺服器是否判斷了上傳檔案類型及後綴。(2) 定義上傳檔案類型白名單，即只允許白名單裡面類型的檔案上傳。(3) 檔案上傳目錄禁止執行腳本解析，避免攻擊者進行二次攻擊。 Info漏洞Info漏洞就是CGI把輸入的參數原樣輸出到頁面，攻擊者透過修改輸入參數而達到欺騙用戶的目的。
詳細介紹：網站安全
以上是前端開發常見的安全問題介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！
