web網絡安全

web安全

一，xss

跨站腳本攻擊(全稱Cross Site Scripting,為和CSS（層疊樣式表）區分，簡稱為XSS)是指惡意攻擊者在Web頁面中插入惡意javascript代碼（也可能包含html代碼），當用戶瀏覽網頁之時，嵌入其中Web里面的javascript代碼會被執行，從而達到惡意攻擊用戶的目的。XSS是攻擊客戶端，最終受害者是用戶，當然，網站管理員也是用戶之一。
XSS漏洞通常是通過php的輸出函數將javascript代碼輸出到html頁面中，通過用戶本地瀏覽器執行的，所以xss漏洞關鍵就是尋找參數未過濾的輸出函數。

1.1.危害：
????????1.用戶的Cookie被獲取，其中可能存在Session ID等敏感信息。若服務器端沒有做相應防護，攻擊者可用對應Cookie登陸服務器。
????????2.攻擊者能夠在一定限度內記錄用戶的鍵盤輸入。
????????3.攻擊者通過CSRF等方式以用戶身份執行危險操作。
????????4.XSS蠕蟲。
????????5.獲取用戶瀏覽器信息。
????????6.利用XSS漏洞掃描用戶內網。
?2.2.防御：
????????1.標簽過濾
????????2.事件過濾
????????3.敏感字符過濾
????????4.設置httponly防止Cookie被獲取
????????5.內容安全策略（CSP）
????????6.在將不可信數據插入到HTML標簽之間時，對這些數據進行HTML Entity編碼
????????7.在將不可信數據插入到HTML屬性里時，對這些數據進行HTML屬性編碼
????????8.在將不可信數據插入到SCRIPT里時，對這些數據進行SCRIPT編碼
????????9.在將不可信數據插入到Style屬性里時，對這些數據進行CSS編碼

當然，如果過過濾不全，或者CSP配置錯誤，也可能被繞過。

參考文章：https://blog.csdn.net/lady_killer9/article/details/107126005

二，CSRF

CSRF (Cross—Site Request Forgery)，既跨站點請求偽造，也被叫做 XSRF，和 XSS 一樣也是一種比較常見的 web 攻擊。CSRF攻擊者會過過構造的第三方頁面誘導受害者完成加載或者點擊，利用受害者的權限，以其身份向合法網站發起惡意請求，通常用戶發生狀態改變的請求，比如虛擬貨幣的轉賬，賬號信息修改，惡意發郵件等等，由于具有一定的隱蔽性，所以比較防范。

2.1.CSRF 的防范

? 目前主要有如下幾種方式：

添加 Referer 域名白名單：HTTP 的 Referer 頭記錄了當前請求的來源頁面的URL，如果用戶是通過瀏覽器打開的網頁一般都會帶有這個信息。可以驗證 URL 的域名是否在網站允許的白名單呢內，如果不在則拒絕請求。這種方式實現比較簡單，而且可以在web 服務器層統一配置，減少了后端開發成本，當 Referer 頁可以偽造，用戶瀏覽器的可靠性也不能完全信賴，判斷 Referer 可以做為一種輔助手段，但不能根治 CSRF。
令牌 (Token )驗證：令牌驗證的方式，這是目前方法CSRF的一種普遍方法，其原理是在用戶正式提交數據更新之前，給用戶生成一個 token，一方面token保存在服務端，比如Session 或者緩存中，一方面輸出請求發生的頁面上，在用戶提交請求時連同token一同提交，服務獲得接收到請求之后再做token驗證，token 不存在、或者token不一致，或者失效都算作驗證失敗。token 的生成具有一定的隨機性，而且是在提交數據的頁面生成，攻擊這往往難于偽造。token 一般作為一個post 字段提交，或者作為ajax請求的header信息提交

2.2.為什么token可以防止CSRF攻擊，cookies不可以？

CSRF（Cross-Site Request Forgery，跨站請求偽造）攻擊是一種利用用戶已經在其他網站上登錄并保存了相關認證憑證（如Cookies）的情況下，通過惡意網站發起偽造請求的攻擊方式。攻擊者通過誘使用戶訪問惡意網站，利用已保存的認證憑證執行非法操作，例如進行轉賬、更改密碼等。

Token可以防止CSRF攻擊的主要原因有以下幾點：

隨機性：Token是由服務器生成的隨機字符串，每次請求都會生成一個新的Token，并將其與用戶會話相關聯。攻擊者無法獲知這個隨機字符串，因此無法構造有效的偽造請求。
不自動發送：與Cookies不同，Token不會自動附加在每個請求中。在需要驗證用戶身份的請求中，服務器會要求客戶端主動發送該Token。這樣，即使攻擊者成功偽造了請求，但缺少正確的Token，服務器會拒絕執行該請求。
防止被竊取：Cookies存儲在瀏覽器中，容易受到XSS（跨站腳本攻擊）等攻擊手段的竊取。而Token通常是存儲在HTTP請求頭中或作為請求參數發送，不會自動附加到每個請求中，因此更難以被竊取。

雖然Cookies也可以采取一些措施來減少CSRF攻擊的風險（如SameSite屬性、HttpOnly屬性等），但這些措施仍然無法完全防止CSRF攻擊。相比之下，Token通過引入隨機性和主動驗證的方式，提供了更可靠的防護機制。

需要注意的是，為了保證Token的安全性，開發者需要采取一些措施，例如使用HTTPS協議傳輸、設置適當的Token過期時間、確保Token的隨機性和獨一性等。只有在正確實施的情況下，Token才能有效地防止CSRF攻擊。

2.3.為什么Token存儲在HTTP請求頭中或作為請求參數中，就不容易被竊取？Cookies存儲在瀏覽器中，容易被竊取？

Token 存儲在 HTTP 請求頭或請求參數中相較于存儲在瀏覽器的 Cookies 中，更難被竊取的原因主要有以下幾點：

存儲位置不同：Cookies 是存儲在客戶端瀏覽器中的，而 HTTP 請求頭或請求參數通常是由服務端返回給客戶端，然后由客戶端發送給服務端的。由于服務端可以采用一些安全措施來保證 Token 的傳輸過程的安全性，例如使用 HTTPS 加密傳輸，因此 Token 存儲在 HTTP 請求頭或請求參數中更難被竊取。
相對短暫：為了確保 Token 的安全性，它們通常被設定為相對短暫的有效期，一旦過期就需要重新獲取。這樣即使攻擊者竊取到 Token，也只能在一段時間內進行惡意操作。相比之下，Cookies 可能會存儲很長時間，具有較高的風險。
不可見性：HTTP 請求頭或請求參數是不可見的，除非通過網絡抓包等手段才能獲取到其中的信息。而 Cookies 存儲在瀏覽器中，可以通過瀏覽器的開發者工具等手段來查看和修改。

需要注意的是，即使 Token 存儲在 HTTP 請求頭或請求參數中，也并不能完全避免被竊取的風險。為了保證 Token 的安全性，開發者還需要采取其他一些措施，例如確保 Token 的隨機性和獨一性、設置適當的有效期、限制 Token 的使用范圍等。同時，開發者還需要對服務端進行認真的安全評估和漏洞掃描，及時修復可能存在的安全問題。

參考文章：https://coderxing.gitbooks.io/architecture-evolution/content/di-san-pian-ff1a-bu-luo/641-web-an-quan-fang-fan/6412-csrf.html

三，SQL

? SQL 注入頁也是一種常見的 Web 攻擊方式，主要是利用后端程序的漏洞，針對數據庫（主要是關系型數據庫）進行攻擊。攻擊者通常通過輸入精心構造的參數，繞過服務器端的驗證，來執行惡意 SQL 語句，SQL注入會造成拖庫（原始數據表被攻擊者獲取），繞過權限驗證，或者串改、破壞、刪除數據。數據往往是一個網站甚至一個公司的生命，一但SQL漏洞被攻擊者利用通常會產生非常嚴重的后果，對于SQL 注入的防范需要開發者倍加重視。下面通過一個例子來演示SQL注入的攻擊過程，對于一個登陸驗證的請求一般需要通過用戶輸入的用戶名和密碼進行查詢驗證，查詢SQL 語句如下：

SELECT * FROM users WHERE username = "$username" AND password = "$password";

比如攻擊者已知一個用戶名archer2017，可以構造密碼為?anywords" OR 1=1，此時，此時后端程序的執行的SQL語句為：

SELECT * FROM users WHERE username = "archer2017" AND password = "anywords" OR 1=1;

?這樣無論輸入什么樣的密碼，都會要繞過驗證，如果更驗證一些，構造密碼為?anywords" OR 1=1;DROP TABLE users?，那么整個表都將被刪除，執行SQL如下:

SELECT * FROM users WHERE username = "archer2017" AND password = "anywords" OR 1=1;DROP TABLE users;

3.1.SQL 注入的防范

? SQL 注入發生絕大多數情況都是直接使用戶輸入參數拼裝 SQL 語句造成的，防范 SQL 注入，主要的方式丟失避免直接使用用戶輸入的數據。

? 使用預編譯語句（PreparedStatement）：一方面可以加速 SQL 的執行，一方面可以防止SQL注入。理解 PreparedStatement 防范 SQL 注入的原理，先要理解預編譯語句的原理，如下圖所示：

（TODO重新畫）

3.2.SQL 語句的編譯分為如下幾個階段：

基本解析：包括SQL語句的語法、語義解析，以及對應的表和列是否存在等等。
編譯：將 SQL 語句編譯成機器理解客理解的中間代碼格式。
查詢優化：編譯器在所有的執行方案中選擇一個最優的。
緩存：緩存優化后的執行方案。
執行階段：執行最終查詢方案并返回給用戶數據。

? 預編譯語句指的是在緩存之后，在執行階段的之前的編譯后的語句，通過占位符來替代查詢查詢參數。同樣的SQL，如果參數不同普通的SQL語句每次請求都會進行編譯，而預編譯語句只會編譯一次，在執行階段會從緩存中取出預編譯語句并將占位符替換成查詢參數數據，而在這個階段SQL 語句已經是編譯后的語句，參數數據只能最為純數據使用，不能作為SQL語句的一部分，通過SQL字符串的拼裝已經不起作用，所以可以避免SQL注入。

Java 代碼中使用預編譯語句：

String query = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, username); 
pstmt.setString( 2, password); 
ResultSet results = pstmt.executeQuery( );

PHP 中使用預編譯語句:

$sth = $dbh->prepare('SELECT * FROM users WHERE username = ? AND password = ?');
$sth->bindParam(1, $username, PDO::PARAM_STR, 20);
$sth->bindParam(2, $password, PDO::PARAM_STR, 16);
$sth->execute();

預編譯語句需要數據庫支持，不過目前主流的關系型數據庫如 MySQL，PostgreSQL都支持預編譯語句。

? 如果不可避免地使用 SQL 語句進行拼裝，可以對用戶輸入數據進行轉移，尤其是多單雙引號的轉義。

? Java 中可以使用 Apache Common類庫的?StringEscapeUtils?中的方法，例如：

StringEscapeUtils.escapeSql(sql);

StringEscapeUtils.escapeSql 方法在最新版的Apache Common 類庫中被移除掉，按照官方文檔的說法，是為了避免引起程序員在處理SQL時的產生誤解，官方推薦使用與預編譯語句，而不是拼裝字符串的方法。

或者使用 ESAPI （OWASP Enterprise Security API），是一套開源的企業級的安全過濾組件。

Codec MYSQL_CODEC = new MySQLCodec(MySQLCodec.Mode.STANDARD);
String query = "SELECT * FROM users WHERE username = '"+ ESAPI.encoder().encodeForSQL(MYSQL_CODEC, username) + "' AND password = '" + ESAPI.encoder().encodeForSQL(MYSQL_CODEC, password) + "'";

在 PHP 中，如下面方法：

$username = mysql_real_escape_string($username);//或 addslashes($username)
$password = mysql_real_escape_string($password);
$sql = "SELECT * FROM users WHERE username = '$username'' AND password = '$password'";

另外，除了上述兩種方案意外，還要用戶輸入的數據進行校驗，Java 中可以使用 Apache Commons Validator 類庫，PHP 中可以使用 filter_var 中的過濾器，可以參考（TODO）XSS 一節。