開發中一些常見的安全性問題

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把輸入的參數原樣輸出到頁面，攻擊者經過修改輸入參數而達到欺騙用戶的目的。

 

4   iframe安全隱患問題；

　　有時候前端頁面爲了顯示別人的網站或者一些組件的時候，就用iframe來引入進來，好比嵌入一些廣告等等。可是有些iframe安全性咱們沒法去評估測試，有時候會攜帶一些第三方的插件啊，或者嵌入了一下不安全的腳本啊，這些都是值得咱們去考慮的。

解決方案：

　　1.使用安全的網站進行嵌入；

　　2.在iframe添加一個叫sandbox的屬性，瀏覽器會對iframe內容進行嚴格的控制，詳細瞭解能夠看看相關的API接口文檔。

 

5  本地存儲數據問題；

　　不少開發者爲了方便，把一些我的信息不經加密直接存到本地或者cookie，這樣是很是不安全的，黑客們能夠很容易就拿到用戶的信息，全部在放到cookie中的信息或者localStorage裏的信息要進行加密，加密能夠本身定義一些加密方法或者網上尋找一些加密的插件，或者用base64進行屢次加密而後再屢次解碼，這樣就比較安全了。

 

6  第三方依賴的安全性問題；

　　現在的項目開發，不少都喜歡用別人寫好的框架，爲了方便快捷，很快的就搭建起項目，本身寫的代碼很是少，過多的用第三方依賴或者插件，一方面會影響性能問題，另外一方面第三方的依賴或者插件存在不少安全性問題，也會存在這樣那樣的漏洞，因此使用起來得謹慎。

解決辦法：手動去檢查那些依賴的安全性問題基本是不可能的，最好是利用一些自動化的工具進行掃描事後再用，好比NSP(Node Security Platform)，Snyk等等。

 

7  HTTPS加密傳輸數據；

　　在瀏覽器對服務器訪問或者請求的過程當中，會通過不少的協議或者步驟，當其中的某一步被黑客攔截的時候，若是信息沒有加密，就會很容易被盜取。因此接口請求以及網站部署等最好進行HTTPS加密，這樣防止被人盜取數據。