這個系列來自之前做的內部培訓，刪減了業務相關的部分，如有錯誤，歡迎指出。

鑒於知乎文章編輯器呵呵的體驗，可能會有排版錯誤，如發現也請指正。

系列目錄：

jnoodle：前端技術演進（一）：Web前端技術基礎?

zhuanlan.zhihu.com圖標jnoodle：前端技術演進（二）：前端與協議?

zhuanlan.zhihu.com圖標jnoodle：前端技術演進（三）：前端安全?

zhuanlan.zhihu.com圖標jnoodle：前端技術演進（四）：前端三層結構與應用?

zhuanlan.zhihu.com圖標jnoodle：前端技術演進（五）：現代前端交互框架?

zhuanlan.zhihu.com圖標jnoodle：前端技術演進（六）：前端項目與技術實踐?

zhuanlan.zhihu.com圖標jnoodle：前端技術演進（七）：前端跨棧技術?

zhuanlan.zhihu.com圖標jnoodle：前端技術演進（八）：未來前端趨勢?

zhuanlan.zhihu.com圖標

Web前端安全方面涵蓋的內容較多，也是前端項目開發中必須要關注的一個重要部分。在Web站點開發中，如果沒有很好的安全防護措施，不僅可能因為攻擊者的惡意行為影響站點頁面功能、泄露用戶投權隱私，甚至還可能會直接帶來用戶經濟上的損失。

安全當然不只是前端的事情，這裡主要介紹和前端相關的一些安全知識。

XSS

跨站腳本攻擊（Cross Site Script，XSS攻擊），通常指黑客通過「HTML注入」篡改了網頁，插入了惡意的腳本，從而在用戶瀏覽網頁時，控制用戶瀏覽器的一種攻擊。

XSS的本質是一種「HTML注入」，用戶的數據被當成了HTML代碼一部分來執行，從而產生了新的語義。

根據攻擊腳本引入的位置，XSS可以分為三類：

反射型XSS

非持久化，將用戶輸入的數據反射給瀏覽器，經過後端，不經過資料庫。黑客需要誘使用戶「點擊」一個惡意鏈接，才能攻擊成功。

存儲型XSS

持久化，代碼儲存在資料庫中，經過後端，經過資料庫。如在個人信息或發表文章等地方，假如代碼，如果沒有過濾或過濾不嚴，那麼這些代碼將儲存到資料庫中，用戶訪問該頁面的時候觸發代碼執行。

比如一個表單，輸入用戶簽名，前端直接把簽名內容展示在頁面上，如果沒有進行XSS處理，假設輸入：

<script>alert(1)</script>

瀏覽器顯示用戶簽名的時候，可能就會觸發彈框。注意這裡的腳本只是演示，在攻擊時，腳本可能會執行各種動作，比如獲取Cookie或所有本地存儲並發送到某處，打開一個非法網址等等。

DOM Based XSS

通過修改頁面的DOM節點形成的XSS，不經過後端。

比如前端直接通過獲取URL參數渲染頁面DOM：

http://localhost:8080/dvwa/vulnerabilities/xss_d/?default=English<script>alert(1)</script>

頁面彈窗：

XSS攻擊挑戰：https://xss-game.appspot.com

解法：gist.github.com/pbssubh點擊預覽

防禦方式

一般使用對HTML字元編碼轉義來防範XSS，比如：

function HTMLEncode(str) {
let s;
if (str.length === 0) return "";
s = str.replace(/&/g, "&gt;");
s = s.replace(/</g, "&lt;");
s = s.replace(/>/g, "&gt;");
s = s.replace(/ /g, "&nbsp;");
s = s.replace(//g, "");
s = s.replace(/"/g, "&quot;");
s = s.replace(/
/g, "<br>");
return s;
}

function HTMLDecode(str) {
let s;
if (str.length === 0) return "";
s = str.replace(/&gt;/g, "&");
s = s.replace(/&lt;/g, "<");
s = s.replace(/&gt;/g, ">");
s = s.replace(/&nbsp;/g, " ");
s = s.replace(//g, "");
s = s.replace(/&quot;/g, """);
s = s.replace(/<br>/g, "
");
return s;
}

但是繞過過濾的方式有很多，比如：

data協議執行javascript：

<a href=data:text/html;base64,PHNjcmlwdD5hbGVydCgzKTwvc2NyaXB0Pg==>

Jsfuck：

[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()

深入遊戲：http://prompt.ml/

建議使用成熟的庫來防範，比如：github.com/leizongmin/j

保護好用戶的Cookie，加上HttpOnly屬性，加上了這個屬性的Cookie欄位，js是無法進行讀寫的。

前後端一定都要過濾，在界面顯示用戶輸入的內容時要謹慎。

SQL注入

SQL 注入就是指在輸入的字元串中注入 SQL 語句，如果應用相信用戶的輸入而對輸入的字元串沒進行任何的過濾處理，那麼這些注入進去的 SQL 語句就會被資料庫誤認為是正常的 SQL 語句而被執行。

比如後端代碼：

$un = @$_POST[un];
$pw = @$_POST[pw];

// ...

$sql = "select * from user where un=$un and pw=$pw";

前端輸入時，我們將un賦為admin，pw賦為 or 1=1。則整個 SQL 語句會變為：

select * from user where un=admin and pw= or 1=1

就成功繞過了身份驗證。

SQL注入太知名，大家比較熟悉，這裡不做過多介紹。

CSRF

CSRF（Cross-site request forgery跨站請求偽造，也被稱為「One Click Attack」或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用。XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。

例如：

一個銀行站點存在一個CSRF漏洞，用戶A轉賬給B用戶2000元，執行轉賬操作後會對銀行發送一次請求：http://www.bank.com/money?use...，然後A用戶就會把自己的2000元轉到B的賬戶下。在發送這個請求給銀行伺服器時，伺服器首先會驗證這個請求是否為一個合法的session，並且用戶A確認登陸才可以驗證通過。

如果此時有一個惡意用戶C想把A用戶的錢轉到自己的賬戶下，那麼他可以構造 http://www.bank.com/money?use... 這個請求，但是這個請求必須有A用戶發出才可以生效，此時惡意用戶C可以搭建一個自己的網站，在網站中寫入如下代碼：<img src="http://www.bank.com/money?user=A&num=2000&transfer=C">

之後誘導A用戶訪問自己的網站，當A訪問這個網站時，這個網站就會把img標籤里的URL發給銀行伺服器，而此時除了這個請求以外，還會把A用戶的cookie一起發到伺服器，如果此時A用戶的瀏覽器與銀行的session沒有過期，那麼就會在A用戶毫不知情的情況下執行轉賬給C的操作。

CSRF?一般會用於以下場景：

1、對網站管理員進行攻擊：誘騙管理員點擊存在漏洞的鏈接，執行增加刪除網站管理賬戶的操作，從而進行下一步滲透得到網站shell許可權。

Discuz! X2.5 / X3 / X3.1 可CSRF刪管理員賬號

發帖插入 Discuz! 代碼，其中修改uidarray可以刪除多個指定用戶：

[img]admin.php?frame=no&action=members&operation=clean&submit=1&uidarray=1&confirmed=yes[/img]

2、修改受害網站上的用戶賬戶和數據：對賬戶密碼進行重置，改郵箱綁定，修改個人資料、個人設置，刪除用戶發布的文章帖子等。

美麗說網CSRF重置任意用戶帳號密碼(已經拿到商家帳號證明)

3、賬戶劫持：修改密碼處沒有驗證原有密碼，無token驗證，發送一個修改密碼的鏈接即可。或者發送一個修改綁定郵箱的鏈接，再進行密碼重置。

微信公眾平台CSRF可導致公眾賬號被劫持

4、傳播CSRF蠕蟲進行大規模攻擊：此類攻擊發生的場景一般在SNS站點，批量關注、發微博、改個人資料處。

新浪微博CSRF之點我鏈接發微博（可蠕蟲）

5、利用csrf進行拖庫。

Discuz可CSRF脫褲

6、利用其他漏洞進行組合拳攻擊。

防禦方式

1、使用驗證碼：

CSRF攻擊一般都是在受害者不知情的情況下進行發起的，使用驗證碼可以有效的防止攻擊，但是每次請求都要輸入驗證碼會影響用戶體驗，所以通常只在用戶登錄註冊，還有一些特定業務場景下使用，比如銀行轉賬。如何使用驗證碼要根據業務和場景來決定。

2、驗證http Referer：

http頭中的referer欄位記錄了請求來源地址，比如從 http://www.test.com 點擊鏈接到 http://m.test.com 之後，那麼referer就是 http://www.test.com 這個地址。攻擊者在對受害者進行攻擊的時候，是在攻擊者自己的伺服器上構建自己的惡意腳本，誘騙受害者點擊，所以此時的referer值就是攻擊者自己的URL地址。通過以上可知，CSRF攻擊都是跨域發起的，所以在服務端針對referer欄位驗證是否屬於安全可靠的域名，可在一定程度上有效防禦此類攻擊。

但是此類方法並非萬無一失，在低版本存在漏洞的瀏覽器中，黑客可以篡改referer值。另一種情況是CSRF結合XSS進行攻擊，此時就不需要跨域發起，也可以繞過referer驗證。

3、使用token

當用戶第一次進行登錄的時候，客戶端會通過用戶名和密碼去請求伺服器登錄，服務端在收到請求後會驗證客戶端傳來的用戶名和密碼，如果驗證通過，伺服器就會簽發一個token發給客戶端，並且將token放到session或者報文中，客戶端收到token後存儲到本地，以後客戶端只要每次請求伺服器就要帶上token，經過伺服器驗證通過後才會返迴響應數據，否則報錯。

CSRF攻擊成功的前提條件是攻擊者可以完全偽造出受害者的所有請求，而且請求中的驗證信息都在cookie中，黑客只要使用用戶的cookie通過安全驗證就可以完成攻擊。了解了這些之後，想要防止CSRF攻擊，就要在http請求中放置黑客不可以偽造的信息，而且該信息不可以存在於cookie中，否則就無效。而token令牌最大的特點就是隨機性，不可預測，並且不存在於cookie當中。

最後注意一點，如果在同域下存在XSS漏洞，那麼這種使用token的防禦將形同虛設。

SSRF

很多 Web 應用都提供了從其他伺服器上獲取數據的功能。使用用戶指定的 URL，web 應用可以獲取圖片，下載文件，讀取文件內容等。這個功能如果被惡意使用，可以利用存在缺陷的 Web 應用作為代理，攻擊遠程和本地伺服器。這種形式的攻擊成為伺服器請求偽造（SSRF，Server-Side Request Forgery）。

比如下列代碼：

<?php
$url = @$_GET[url];
if($url) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
$co = curl_exec($ch);
curl_close($ch);
echo $co;
}

這段代碼從 URL 中讀取url參數，之後訪問url參數所指向的 URL 資源，最後把資源顯示在頁面上。

我們訪問 localhost/ssrf.php?url=http://www.baidu.com：

這個漏洞還可以用於訪問本地的資源，我們再訪問file:///C:/Windows/win.ini

以下業務場景容易出現這種漏洞：

  • 應用從用戶指定的 URL 獲取圖片，然後把它用一個隨機名稱保存在硬碟上，並展示給用戶。
  • 應用獲取用戶指定 URL 的數據（文件或者 HTML）。這個函數會使用 socket 和 伺服器建立 TCP 連接，傳輸原始數據。
  • 應用根據用戶提供的 URL，抓取用戶的 Web 站點，並且自動生成移動 Wap 站。
  • 應用提供測速功能，能夠根據用戶提供的 URL，訪問目標站點，以獲取其在對應經緯度的訪問速度。

比如：有道翻譯某處SSRF可通網易內網

防禦方式

  • 過濾返回信息，驗證遠程伺服器對請求的響應，是比較容易的方法。如果 Web 應用獲取某種類型的文件，那麼可以在把返回結果展示給用戶之前先驗證返回信息是否符合標準。
  • 統一錯誤信息，避免用戶根據錯誤信息來判斷遠程伺服器埠狀態。
  • 限制請求的埠為 HTTP 常用埠，比如 80、443、8080、8090。
  • 黑名單內網 IP，避免應用被用來獲取內網數據，攻擊內網。
  • 禁用不需要的協議。僅僅允許 HTTP 和 HTTPS 請求。可以防止類似於file://、gopher://和ftp://等引起的問題。

劫持

很多的時候，我們的網站不是直接就訪問到我們的伺服器上的，中間會經過很多層代理，如果在某一個環節，數據被中間代理層的劫持者所截獲，他們就能獲取到使用你網站的用戶的密碼等保密數據。

HTTP劫持

HTTP劫持是指，在用戶瀏覽器與訪問的目的伺服器之間所建立的網路數據傳輸通道中從網關或防火牆層上監視特定數據信息，當滿足一定的條件時，就會在正常的數據包中插入或修改成為攻擊者設計的網路數據包，目的是讓用戶瀏覽器解釋「錯誤」的數據，或者以彈出新窗口的形式在使用者瀏覽器界面上展示宣傳性廣告或者直接顯示某塊其他的內容。

這種情況下一般用戶請求源網站的IP地址及網站載入的內容和腳本都是正確的，但是在網站內容請求返回的過程中，可能被ISP ( Internet Service Provider，互聯網服務提供商）劫持修改，最終在瀏覽器頁面上添加顯示一些廣告等內容信息。

也有可能是我們在各種飯館裡面，連一些奇奇怪怪的wifi，如果這個wifi是黑客所建立的熱點wifi，那麼黑客就可以截獲該用戶收發的所有數據，之前315也演示過這個場景。

對於這些情況，網站開發者常常就無法通過修改網站代碼程序等手段來進行防範了。請求劫持唯一可行的預防方法就是盡量使用HTTPS協議來訪問目標網站。還有就是盡量不蹭網。

DNS劫持

DNS劫持通常是指攻擊者劫持了DNS伺服器，通過某些手段取得某域名的解析記錄控制權，進而修改此域名的解析結果，導致用戶對該域名地址的訪問由原IP地址轉入到修改後的指定IP地址的現象，其結果就是讓正確的網址不能解析或被解析指向另一網站IP，實現獲取用戶資料或者破壞原有網站正常服務的目的。DNS劫持一般通過篡改DNS伺服器上的域名解析記錄，來返回給用戶一個錯誤的DNS查詢結果實現。

DNS劫持也沒有好的解決方法，盡量外出不蹭網，網站盡量使用HTTPS協議。

點擊劫持

點擊劫持（ClickJacking）是一種視覺上的欺騙手段。攻擊者使用一個透明的、不可見的iframe，覆蓋在一個網頁上，然後誘使用戶在網頁上進行操作，此時用戶將在不知情的情況下點擊透明的iframe頁面。通過調整iframe頁面的位置，可以誘使用戶恰好點擊在iframe頁面的一些功能性按鈕上。

點擊劫持的危害在於，攻擊利用了受害者的用戶身份，在其不知情的情況下進行一些操作。如果只是迫使用戶關注某個微博賬號的話，看上去彷彿還可以承受，但是如果是刪除某個重要文件記錄，或者竊取敏感信息，那麼造成的危害可就難以承受了。

點擊劫持的防範主要是設置HTTP請求頭(X-Frame-Options)，X-Frame-Options HTTP 響應頭，可以指示瀏覽器是否應該載入一個iframe中的頁面。網站可以通過設置X-Frame-Options阻止站點內的頁面被其他頁面嵌入從而防止點擊劫持。

通過寫JavaScript來禁止iframe嵌套也可以，不過很容易繞過：

//------------------------------------
// 防止網站被其他網頁作為iframe嵌入
//------------------------------------

if (self != top) {
top.location.href = self.location.href;
}

代碼執行

由於開發人員編寫源碼時，沒有針對代碼中可執行的特殊函數入口做過濾，導致客戶端可以提交惡意構造語句，並交由服務端執行。命令注入攻擊中，Web 伺服器沒有過濾類似system、eval和exec等函數，是該漏洞攻擊成功的主要原因。

比如代碼：

<?php
// code-exe.php:
$code=@$_GET[code];//http://localhost/subject/code-exe.php?code=
echo "<center>Payload:".$code."<br/>Result:</center>
eval($code);

訪問 http://localhost/code-exe.php... 就可以看到 php info 了。

百度某站點python模板遠程代碼執行

不安全的第三方依賴

據統計一個應用有將近80%的代碼其實是來自於第三方組件、依賴的類庫等，而應用自身的代碼其實只佔了20%左右。無論是後端伺服器應用還是前端應用開發，絕大多數時候我們都是在藉助開發框架和各種類庫進行快速開發。

舉個例子，jQuery就存在多個已知安全漏洞，例如 jQuery issue 2432，使得應用存在被XSS攻擊的可能。而Node.js也有一些已知的安全漏洞，比如 CVE-2017-11499，可能導致前端應用受到DoS攻擊。另外，對於前端應用而言，除開使用到的前端開發框架之外，通常都還會依賴不少Node組件包，它們可能也有安全漏洞。

也可能有人惡意編寫有漏洞的 JS 文件，並且把它放到 CDN 上給別人用，所有使用它的站點都會受到影響。

NPM就有過這樣的例子：軟體包 getcookies 潛藏後門程序，而express-cookies和http-fetch-cookies依賴於getcookies，而mailparser依賴於http-fetch-cookies。

blog.npmjs.org/post/173

還有很多名稱類似的項目，比如原版包名稱為js-cookie，惡意作者上傳js-cookies，jscookie，jscookies等包，騙取下載。在使用第三方依賴時一定要再三確認。

弱口令

弱口令沒有嚴格和準確的定義，通常認為容易被別人（它們有可能對你很了解）猜測或被破解工具破解的口令均為弱口令。弱口令指的是僅包含簡單數字和字母的口令，例如"123"、"abc"等，因為這樣的口令很容易被別人破解。

普通型

普通型弱口令就是常見的密碼，比如，有人特地整理了常用的弱口令（Top 100）：

123456 a123456 123456a 5201314 111111 woaini1314 qq123456 123123 000000 1qaz2wsx 1q2w3e4r
qwe123 7758521 123qwe a123123 123456aa woaini520 woaini 100200 1314520 woaini123 123321
q123456 123456789 123456789a 5211314 asd123 a123456789 z123456 asd123456 a5201314 aa123456
zhang123 aptx4869 123123a 1q2w3e4r5t 1qazxsw2 5201314a 1q2w3e aini1314 31415926 q1w2e3r4
123456qq woaini521 1234qwer a111111 520520 iloveyou abc123 110110 111111a 123456abc w123456
7758258 123qweasd 159753 qwer1234 a000000 qq123123 zxc123 123654 abc123456 123456q qq5201314
12345678 000000a 456852 as123456 1314521 112233 521521 qazwsx123 zxc123456 abcd1234 asdasd
666666 love1314 QAZ123 aaa123 q1w2e3 aaaaaa a123321 123000 11111111 12qwaszx 5845201314
s123456 nihao123 caonima123 zxcvbnm123 wang123 159357 1A2B3C4D asdasd123 584520 753951 147258
1123581321 110120 qq1314520

對於網站後台而言，一般為：

  • admin
  • manager
  • root
  • root123
  • tomcat
  • jboss
  • admin123
  • admin888
  • admin666
  • ...

條件型

條件型弱口令就是和用戶信息相關的密碼，比如生日+手機號、姓名首字母+生日、愛人姓名首字母+生日+常用字母（520、1314 等）。

黑客拿到用戶的信息，根據密碼心理學，社會工程學之類的，來猜測密碼。我們看的很多影片，都是社會工程學，比如特工偷取工卡、偽造證件之類的，安全最大的漏洞其實是人。

撞庫型

很多用戶會在各個網站上使用同一個密碼，黑客利用第三方已經泄露的用戶資料庫中的用戶名、郵件地址或者手機號等去匹配明文密碼，有一定概率命中。

這裡可以查詢是否被搞：haveibeenpwned.com/

之前很多知名的社工庫都被搞了，大部分都在暗網交易。可以試試這個：publicdbhost.dmca.gripe

查人：https://pipl.com

註冊網站找回：zhaohuini.com/

防禦方式

  • 每個網站設置不同的密碼，密碼12位以上，不要和自己的個人信息相關。
  • 銀行取款密碼不要和生日、身份證號之類相關。
  • 千萬不要在雲存儲中存儲證件照片，特別是手持身份證照片。

文件上傳

瀏覽器通過上傳頁面將文件儲存到伺服器中。一般這些上傳頁面都會有限制（比如限制格式為jpg/gif/png等等，或者限制文件大小）。漏洞頁面大致分為兩種，一種是不限制任何格式，隨意上傳，這種現在比較少了。另一種是限制Content-type，雖然它限制了文件類型，但可以突破它。

任意文件上傳

比如我們把一句話 <?php @eval($_POST[a]) ?> 寫入1.php，然後把它上傳到伺服器。之後，嘗試直接訪問所上傳的文件 xxx/upload/1.php。

文件類型限制

如果只是前端做了擴展名限制，可以通過介面工具繞過。如果後端加上了校驗，這個校驗必須很謹慎。黑客也有可能利用伺服器的已知漏洞。比如之前Nginx、Apache、IIS 都爆出過解析漏洞。

例如：假設存在漏洞的站點上有一張圖片，URL 地址為：xxx.com/logo.jpg

我們正常訪問時，Nginx 會把它當做非腳本，直接讀取並傳給客戶端。但是如果我們這樣訪問：

www.xxx.com/logo.jpg/a.php

他就會把logo.jpg當做 PHP 文件來執行。或者是：

www.xxx.com/logo.jpg%00.php

也會導致圖片執行，往圖片裡面加一句 <?php @eval($_POST[a]) ?> ，post參數a里的內容就會被執行。

釣魚

釣魚也是一種非常古老的攻擊方式了。很多人會有這樣的經歷，QQ群裡面有人發什麼兼職啦、什麼自己要去國外了房子車子甩賣了，詳情在我QQ空間里啦，之類的連接。打開之後發現一個QQ登錄框，其實一看域名就知道不是QQ，不過做得非常像QQ登錄，不明就裡的用戶們，就真的把用戶名和密碼輸入了進去，結果沒登錄到QQ，用戶名和密碼卻給人發過去了。

還有很多釣魚簡訊常會偽裝成銀行發送的簡訊，一般都是警告用戶的銀行賬戶出現了安全問題，誘使用戶點擊簡訊中的鏈接地址來解決。釣魚簡訊會鏈接到一個高仿的正規網站，這個高仿網站從表面上看不論是圖標還是頁面設計和官方網站一樣，給用戶造成一種假象，覺得這個網站沒問題。接著就是要求用戶提供儘可能多的個人信息。

釣魚郵件是指黑客偽裝成同事、合作夥伴、朋友、家人等用戶信任的人，通過發送電子郵件的方式，誘使用戶回復郵件、點擊嵌入郵件正文的惡意鏈接或者打開郵件附件以植入木馬或間諜程序，進而竊取用戶敏感數據、個人銀行賬戶和密碼等信息，或者在設備上執行惡意代碼實施進一步的網路攻擊活動。

還有一種是魚叉式釣魚攻擊，魚叉式釣魚攻擊與其他類型的釣魚式攻擊的不同之處在於，魚叉式釣魚針對的是特定人員或特定公司的員工。網路犯罪分子會精心收集目標對象的信息，使」誘餌」更具誘惑力。精心製作的魚叉式釣魚電子郵件可能很難與合法的電子郵件區分開來。所以，魚叉式釣魚攻擊更容易使目標上鉤。

以人力資源部為例。該部門員工會收到各種格式不一的大量簡歷，所以收來一份附件來源不明的電子郵件是很平常的事，不會引起懷疑。簡歷里如果再附上一些作品鏈接或者作品附件之類的，就很容易中招。

防禦釣魚攻擊只能靠細心，別貪便宜，別輕信鏈接和附件，記憶常用域名。

越權

越權（或者說許可權提升，Privilege Escalation）是指攻擊者能夠執行他本身沒有資格執行的一些操作。簡單講，就是「超越了你你擁有的許可權，幹了你本來不可能幹的事兒」。越權漏洞的成因主要是開發人員在對數據進行增、刪、改、查時對客戶端請求的數據過於信任而遺漏了許可權的判定。越權漏洞和前端的關係略小，不過因為在互聯網金融領域太常見，所以一起說下。

中國金融認證中心（CFCA）抽選和分析了2017年113個電子銀行系統的滲透測試結果顯示，發現的306個中高風險等級的安全漏洞中，與業務安全相關的漏洞佔比最大，有210個，而傳統滲透測試中常見的安全漏洞，如跨站腳本攻擊、SQL注入、任意文件上傳、遠程命令執行等WEB應用安全漏洞，在電子銀行系統中存在的情況相對較少。我們的安全級別並不比電子銀行系統高多少，所以上面的漏洞都應當注意。

通常情況下，我們使用一個web應用程序提供的功能時，流程是：登錄—>提交請求—>驗證許可權—>資料庫查詢—>返回結果。如果在「驗證許可權」環節存在缺陷，那麼便會導致越權。一種常見的存在越權的情形是：Web應用程序的開發者安全意識不足，認為通過登錄即可驗證用戶的身份，而對用戶登錄之後的操作不做進一步的許可權驗證，進而導致越權問題。比如：

1、通過隱藏URL實現訪問控制：

有些應用程序僅通過URL實現訪問控制。例如：使用管理員身份登錄後可以看到後台管理頁面的鏈接，但是以普通用戶登錄則看不到該鏈接。但是直接輸入鏈接，比如 xx/admin/userlist 之類的，普通用戶就可以訪問管理頁面。

2、直接對象引用：

例如，在一個網銀系統中，用戶可以使用以下URL查詢賬戶信息：

https://www.onlinebank.com/viewInfo.php?accountId=12345678

其中accountId是用戶自己的賬戶ID。用戶登錄自己的賬戶後，該URL的鏈接會出現在用戶賬戶頁面中，用戶點擊即可跳轉到賬戶信息頁面。雖然其他用戶無法看到這個鏈接，但是如果該網銀系統的訪問控制不完善，攻擊者完全可以通過枚舉accountId進而構造出URL，然後越權查看他人的賬戶信息。

3、多階段功能：

應用程序的一些功能通過幾個階段執行，並且在執行過程中向伺服器依次提交多個請求。這種情況很常見，比如轉賬功能、找回密碼功能等，需要先驗證用戶的身份，驗證通過後才允許用戶執行後續動作。多階段功能本身並沒有問題，但是如果開發者認為到達驗證過程後續階段的用戶一定已經擁有了相關的許可權，並在後續階段執行操作時不再對用戶提交的請求進行驗證，那麼就很有可能存在越權漏洞。攻擊者完全有可能繞過前幾階段的驗證階段，直接執行後續的動作。

比如某網站在找回密碼時做了很嚴格的驗證，需要驗證姓名、手機號、身份證號等信息，驗證通過了才能修改密碼。校驗很嚴格，但是該網站的「找回密碼」功能被設計成了兩步（提交了兩個請求報文）：第一步驗證用戶身份，這時提交第一個請求報文，驗證成功之後，進入第二步；第二步才是真正的修改密碼的動作，而修改密碼的POST數據包有3個請求參數，分別是新密碼、確認新密碼以及賬號值。問題就出在第二步，在執行修改密碼的動作時，伺服器並未驗證被修改密碼的賬戶是否是第一步中通過身份驗證的賬戶，因此攻擊者可以很容易的以自己的身份通過認證，然後修改第二步提交的報文，實現對任意賬戶的密碼修改！

常見的越權高發功能點有：根據訂單號查訂單、根據用戶ID查看帳戶信息、修改/找回密碼等。

4、靜態文件：

有些Web應用程序在用戶訪問動態頁面時會執行相應的訪問控制檢查，以確定用戶是否擁有執行相關操作所需的許可權。但是，用戶仍然會提交對靜態資源的訪問請求，如下載網站中的word、excel、pdf文檔等。這些文檔都是完全靜態的資源，其內容直接由Web伺服器返回，它並不在伺服器上運行。因此，靜態資源自身並不能執行任何檢查以確認用戶的訪問許可權。如果這些靜態資源沒有得到有效的保護，那麼任何知曉URL命名規則的人都可以越權訪問這些靜態資源。比如Google hacking一下：

互聯網金融的很多系統就有越權漏洞，具體不點名了。

宜信某平台多處越權及任意用戶登錄

防禦方式

實現應用程序的完善的訪問控制不是件容易的事，因此越權漏洞防不勝防。對於開發者而言，一定要有安全意識，時刻保持警惕。比如：

  • 永遠不要相信來自客戶端（用戶）的輸入。
  • 執行關鍵操作前必須驗證用戶身份，多階段功能的每一步都要驗證用戶身份。
  • 對於直接對象引用，加密資源ID，以防止攻擊者對ID進行枚舉。
  • 在前端實現的驗證並不可靠，前端可以驗證用戶的輸入是否合規，在伺服器端驗證用戶許可權。

注意：《網路安全法》實施之後，所有未經授權的滲透都是非法行為，so，大部分白帽子的行為都是非法的，大家不要嘗試。

前端技術演進系列參考文章

以下鏈接可能不全，如果沒有列出的，請私信我告知，多謝。

特別感謝《現代前端技術解析》的作者張成文。
  • book.douban.com/subject
  • developers.google.com/w
  • juejin.im/post/5b148a2c
  • html5rocks.com/en/tutor
  • hit-alibaba.github.io/i
  • ruanyifeng.com/blog/201
  • jianshu.com/p/80e25cb1d
  • developers.google.com/w
  • zhuanlan.zhihu.com/p/29
  • developers.google.com/w
  • imtangqi.com/2016/04/07
  • ruanyifeng.com/blog/201
  • zcfy.cc/article/rest-ap
  • graphql.cn/learn/
  • jerryzou.com/posts/10-q
  • jianshu.com/p/2ad286397
  • medium.freecodecamp.org
  • xiaomingplus.com/full-s
  • juejin.im/post/5a3f1b89
  • juejin.im/post/58cdeba6
  • blog.ymfe.org/%E6%B7%B7
  • insights.thoughtworks.cn
  • legacy.gitbook.com/book
  • cloud.tencent.com/devel
  • momomoxiaoxi.com/2017/1
  • jsfuck.com/
  • kanxue.com/book-6-59.ht
  • cfca.com.cn/20180605/10
  • frontendmasters.com/boo
  • html5rocks.com/zh/tutor
  • cnblogs.com/coco1s/p/57
  • developers.google.com/w
  • developers.google.com/w
  • developers.google.com/w
  • javascript.ruanyifeng.com
  • ibm.com/developerworks/
  • segmentfault.com/a/1190
  • developer.mozilla.org/z
  • developers.google.com/w
  • juejin.im/post/5acd0c8a
  • blog.csdn.net/caijunfen
  • github.com/ruanyf/jstra
  • slimhill.com/webpack/
  • zhuanlan.zhihu.com/p/30
  • medium.com/jsdownunder/
  • segmentfault.com/a/1190
  • yq.aliyun.com/articles/
  • liaoxuefeng.com/wiki/00
  • nodejs.org/zh-cn/docs/g
  • cnblogs.com/yeyinfu/p/7
  • frontendmasters.com/boo
  • github.com/ruanyf/jstra

推薦閱讀：

相关文章