Web 安全

XSS 攻擊

跨站腳本攻擊(Cross Site Scripting)，爲了避免和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站腳本攻擊縮寫爲XSS。惡意攻擊者往Web頁面裏插入惡意Script代碼，當用戶瀏覽該頁之時，嵌入其中Web裏面的Script代碼會被執行，從而達到惡意攻擊用戶的目的。

XSS攻擊分紅兩類，一類是來自內部的攻擊，主要指的是利用程序自身的漏洞，構造跨站語句，如:dvbbs的showerror.asp存在的跨站漏洞。

另外一類則是來自外部的攻擊，主要指的本身構造XSS跨站漏洞網頁或者尋找非目標機之外的有跨站漏洞的網頁。如當咱們要滲透一個站點，咱們本身構造一個有跨站漏洞的網頁，而後構造跨站語句，經過結合其它技術，如社會工程學等，欺騙目標服務器的管理員打開。

XSS分爲:存儲型和反射型

存儲型XSS:存儲型XSS，持久化，代碼是存儲在服務器中的，如在我的信息或發表文章等地方，加入代碼，若是沒有過濾或過濾不嚴，那麼這些代碼將儲存到服務器中，用戶訪問該頁面的時候觸發代碼執行。這種XSS比較危險，容易形成蠕蟲，盜竊cookie(雖然還有種DOM型XSS，可是也仍是包括在存儲型XSS內)。

反射型XSS:非持久化，須要欺騙用戶本身去點擊連接才能觸發XSS代碼(服務器中沒有這樣的頁面和內容)，通常容易出如今搜索頁面。

一句話總結：xss 其實就是 javascript 腳本注入攻擊。

防範措施

XSS漏洞是Web應用程序中最多見的漏洞之一。若是您的站點沒有預防XSS漏洞的固定方法，那麼就存在XSS漏洞。這個利用XSS漏洞的病毒之因此具備重要意義是由於，一般難以看到XSS漏洞的威脅，而該病毒則將其發揮得淋漓盡致。

工做流程

1)惡意用戶，在一些公共區域(例如，建議提交表單或消息公共板的輸入表單)輸入一些文本，這些文本被其它用戶看到，但這些文本不只僅是他們要輸入的文本，同時還包括一些能夠在客戶端執行的腳本。如:

<script>

this.document = "*********";

</script>

2)惡意提交這個表單

3)其餘用戶看到這個包括惡意腳本的頁面並執行，獲取用戶的cookie等敏感信息。

 

舉栗子：

例如在提交表單後，展現到另外一個頁面，可能會受到XSS腳本注入，讀取本地cookie遠程發送給黑客服務器端。

 

<script>alert('sss')</script>

<script>window.location.href='http://www.baidu.com';</script>

對應html源代碼: <script>alert('sss')</script>

最好使用火狐瀏覽器演示效果

XSS 攻擊使用 JS 腳本語言，由於瀏覽器默認支持腳本語言執行，若是在表單提交的時候，提交一些腳本參數，可能瀏覽器直接進行執行。例如：<script>window.location.href='http://www.baidu.com';</script>  若是沒有作XSS防護，一旦執行 瀏覽器就會跳轉到 百度的網站。在真正的項目中，這種現象是不容許存在的。

XSS漏洞場景：

論壇評論的時候沒有作XSS漏洞防護。

解決方案

對一些特殊字符進行轉義處理，<script>window.location.href='http://www.baidu.com';</script> 對這段腳本中的 <、> 符號進行轉義，轉化爲 &lt、&gt。這樣就能夠防護XSS 攻擊。

在程序中咱們只須要在攔截器，攔截全部的請求對請求參數作轉義處理便可，將腳本特殊字符，轉換成html源代碼進行展現。

漢子編碼http://www.mytju.com/classcode/tools/encode_gb2312.asp

步驟：編寫過濾器攔截全部getParameter參數，重寫httpservletwrapp方法

將參數特殊字符轉換成html源代碼保存.

public static void main(String[] args) {
    String name = "<script>";
    System.out.println("轉化前：" + name);
    //對特殊字符串進行轉義處理
    System.out.println("轉化後：" + StringEscapeUtils.escapeHtml(name));
}

輸出結果爲：

       轉化前：<script>
       轉化後：&lt;script&gt;

XSS原理

* xss 原理：
* 1.使用過濾器 攔截全部請求的參數
* 2.重寫 getParameter() 方法
* 3.對特殊字符參數進行轉義】

Sql 注入

什麼是 Sql 注入

SQL注入：利用現有應用程序，將（惡意）的SQL命令注入到後臺數據庫執行一些惡意的sql操做。

 

形成SQL注入的緣由是由於程序沒有有效過濾用戶的輸入，使攻擊者成功的向服務器提交惡意的SQL查詢代碼，程序在接收後錯誤的將攻擊者的輸入做爲查詢語句的一部分執行，致使原始的查詢邏輯被改變，額外的執行了攻擊者精心構造的惡意代碼

SQL注入防攻擊手段

不要使用拼接SQL語句方式、最好使用預編譯方式，在mybatis編寫sql語句的時候，最好使用?傳參數方式，不要使用#傳參數，由於#傳參數方式，可能會受到sql語句攻擊。

 

Sql 注入的原理

若是在程序代碼中，sql 語句若是使用拼接的方式，那麼可能會出現 Sql 注入的問題。在寫程序中，sql 語句中咱們應該使用預編譯方式，使用 # 符號,而不是使用 $ 符號。

Mybatis 中 $ 與 # 區別

 

#{}: 解析爲一個 JDBC 預編譯語句（prepared statement）的參數標記符，一個 #{ } 被解析爲一個參數佔位符,能夠防止SQL注入問題。

 

${}: 僅僅爲一個純碎的 string 替換，在動態 SQL 解析階段將會進行變量替換。

 

Mybatis 中，sql 語句傳遞參數的時候，最好使用 #號，由於# 號是預編譯的能夠有效的防止 Sql 語句注入攻擊。$ 號 是使用 Sql 語句拼接，可能會受到 Sql 語句的攻擊。 

 舉栗子：

@Select(" SELECT  * FROM userInfo where userName='${userName}' and password='${password}'")
UserEntity login(UserEntity userEntity);

由上面的訪問可知，我訪問登陸接口沒有傳密碼最後也登錄成功，這顯示是不正確的。咱們的sql語句應該使用預編譯方式，以下。

 

@Select(" SELECT  * FROM userInfo where userName=#{userName} and password=#{password}")
UserEntity login(UserEntity userEntity);

 

由以上結果可知，使用預編譯方式，能夠防止 Sql 注入的問題。

Http請求防盜鏈

什麼是防盜鏈

好比A網站有一張圖片，被B網站直接經過img標籤屬性引入，直接盜用A網站圖片展現。

至關於限制資源(圖片、視頻、、文件)只能在某個域名(限制某個服務器)來源上進行訪問。

 

如何實現防盜鏈

判斷http請求頭Referer域中的記錄來源的值，若是和當前訪問的域名不一致的狀況下，說明該圖片可能被其餘服務器盜用。Referer 字段中記錄了訪問的相關信息。

 防盜鏈技術底層原理

使用 http 協議請求頭中的 Referer 記錄請求來源與要限制的域名進行比較，若是一致則是限制的域名，若是不一致 說明可能被盜用了。

我在本地 hosts 文件中配置了2個域名作爲演示，hosts 文件目錄：C:\Windows\System32\drivers\etc

 

項目中我容許訪問地址是：www.test.com:8080。

地址一致：

地址不一致：

 

出現以上的效果說明，防盜鏈功能已經作好了。

注意測試的時候,最好開啓兩個不一樣的瀏覽器測試，避免圖片緩存的緣由

 

CSRF攻擊

什麼是CSRF

（Cross Site Request Forgery, 跨站域請求僞造）是一種網絡的攻擊方式，它在 2007 年曾被列爲互聯網 20 大安全隱患之一,也被稱爲「One Click Attack」或者Session Riding，一般縮寫爲CSRF或者XSRF，是一種對網站的惡意利用也就是人們所知道的釣魚網站。儘管聽起來像跨站腳本（XSS），但它與XSS很是不一樣，而且攻擊方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則經過假裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊每每不大流行（所以對其進行防範的資源也至關稀少）和難以防範，因此被認爲比XSS更具危險性。

一句話總結：CSRF 也就是模擬請求。

互聯網公司裏面會話信息可能使用的是Token方式進行保存的。

 

什麼是API接口冪等性

也就是保證數據的惟一性，不容許重複。例如：防止表單重複提交。

API接口冪等性的解決方案

怎麼樣防止重複提交

怎麼防止網絡延遲狀況下的重複提交

MVCC方案：適合於秒殺場景，不適合用於冪等性解決方案

　多版本併發控制，該策略主要使用 update with condition（更新帶條件來防止）來保證屢次外部請求調用對系統的影響是一致的。在系統設計的過程當中，合理的使用樂觀鎖，經過 version 或者 updateTime（timestamp）等其餘條件，來作樂觀鎖的判斷條件，這樣保證更新操做即便在併發的狀況下，也不會有太大的問題。例如

  select * from tablename where condition=#condition# // 取出要跟新的對象，帶有版本 versoin

  update tableName set name=#name#,version=version+1 where version=#version#

 在更新的過程當中利用 version 來防止，其餘操做對對象的併發更新，致使更新丟失。爲了不失敗，一般須要必定的重試機制。

去重表：效率低、須要去插入去重表進行判斷

在插入數據的時候，插入去重表，利用數據庫的惟一索引特性，保證惟一的邏輯。

悲觀鎖：阻塞式會致使程序進行等待、 不推薦

select for update，整個執行過程當中鎖定該訂單對應的記錄。注意：這種在 DB 讀大於寫的狀況下儘可能少用。

 

Token機制,防止頁面重複提交

 

業務要求：表單只能被提交一次，不能進行重複提交。

 

發生緣由：因爲重複點擊或者網絡重發，或者 nginx 重發等狀況會致使數據被重複提交。

 

解決辦法：

 

集羣環境：採用 token 加 redis（redis 單線程的，處理須要排隊）

 

單 JVM 環境：採用 token 加 redis 或 token 加 jvm 內存

 

處理流程：

 

數據提交前要向服務的申請 token，token 放到 redis 或 jvm 內存，token 有效時間

 

提交後後臺校驗 token，同時刪除 token，生成新的 token 返回

 

token 特色:要申請，一次有效性，能夠限流

基於Token方式防止API接口冪等

客戶端每次在調用接口的時候,須要在請求頭中，傳遞令牌參數，每次令牌只能用一次。

一旦使用以後，就會被刪除，這樣能夠有效防止重複提交。

步驟:

1.生成令牌接口

2. 接口中獲取令牌驗證

防護CSRF攻擊手段

如何防止機器模擬請求(使用小程序模擬發送請求，例如：使用httpClient 技術)

 

使用圖形驗證碼防止機器模擬接口請求攻擊或者使用Nginx 實現限流、配置黑名單和白名單。

建議：在調用核心業務接口時，好比支付、下單、等接口，最好使用手機短信驗證驗證或者是人臉識別，防止其餘用戶使用Token僞造請求。

如何防止僞造Token請求

在互聯網公司中，會話信息使用令牌方式保存的。

如何防止黑客使用抓包工具分析到token，而後黑客使用令牌僞造支付、下單等核心操做。

目前市場上沒有絕對可以防止黑客不能抓包分析token的技術。

咱們可使用短信驗證碼方式或者圖像識別(人臉識別)的方式來提升安全性。