前端技術演進（三）：前端安全

時間  2021-08-13
標籤 javascript php html 前端 java python jquery git github web 欄目 系統安全 简体版
原文   原文鏈接
這個來自以前作的培訓，刪減了一些業務相關的，參考了不少資料（ 參考資料列表），謝謝前輩們，麼麼噠 😘

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

安全固然不僅是前端的事情，這裏主要介紹和前端相關的一些安全知識。php

XSS

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

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

根據攻擊腳本引入的位置，XSS能夠分爲三類：java

反射型XSS

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

image.png | center | 734x479

存儲型XSS

持久化，代碼儲存在數據庫中，通過後端，通過數據庫。如在我的信息或發表文章等地方，假如代碼，若是沒有過濾或過濾不嚴，那麼這些代碼將儲存到數據庫中，用戶訪問該頁面的時候觸發代碼執行。jquery

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

<script>alert(1)</script>複製代碼

瀏覽器顯示用戶簽名的時候，可能就會觸發彈框。注意這裏的腳本只是演示，在攻擊時，腳本可能會執行各類動做，好比獲取Cookie或全部本地存儲併發送到某處，打開一個非法網址等等。github

DOM Based XSS

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

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

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

頁面彈窗：

image.png | center | 827x500

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

解法：gist.github.com/pbssubhash/…

點擊預覽

防護方式

通常使用對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(/\n/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, "\n");
    return s;
}複製代碼

可是繞過過濾的方式有不少，好比：

data協議執行javascript：

<a href=data:text/html;base64,PHNjcmlwdD5hbGVydCgzKTwvc2NyaXB0Pg==>複製代碼

Jsfuck：

[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()複製代碼

深刻遊戲：prompt.ml/

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

保護好用戶的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則經過假裝來自受信任用戶的請求來利用受信任的網站。

image.png | center | 827x511

例如：
一個銀行站點存在一個CSRF漏洞，用戶A轉帳給B用戶2000元，執行轉帳操做後會對銀行發送一次請求：www.bank.com/money?use..…，而後A用戶就會把本身的2000元轉到B的帳戶下。在發送這個請求給銀行服務器時，服務器首先會驗證這個請求是否爲一個合法的session，而且用戶A確認登錄才能夠驗證經過。

若是此時有一個惡意用戶C想把A用戶的錢轉到本身的帳戶下，那麼他能夠構造 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​通常會用於如下場景：

一、對網站管理員進行攻擊：誘騙管理員點擊存在漏洞的連接，執行增長刪除網站管理帳戶的操做，從而進行下一步滲透獲得網站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]複製代碼

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

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

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

微信公衆平臺CSRF可致使公衆帳號被劫持

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

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

五、利用csrf進行拖庫。

Discuz可CSRF脫褲

六、利用其餘漏洞進行組合拳攻擊。

防護方式

一、使用驗證碼：

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

二、驗證http Referer：

http頭中的referer字段記錄了請求來源地址，好比從 www.test.com 點擊連接到 m.test.com 以後，那麼referer就是 www.test.com 這個地址。攻擊者在對受害者進行攻擊的時候，是在攻擊者本身的服務器上構建本身的惡意腳本，誘騙受害者點擊，因此此時的referer值就是攻擊者本身的URL地址。經過以上可知，CSRF攻擊都是跨域發起的，因此在服務端針對referer字段驗證是否屬於安全可靠的域名，可在必定程度上有效防護此類攻擊。

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

三、使用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=www.baidu.com：

image.png | center | 827x445

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

image.png | center | 827x445

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

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

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

防護方式

  • 過濾返回信息，驗證遠程服務器對請求的響應，是比較容易的方法。若是 Web 應用獲取某種類型的文件，那麼能夠在把返回結果展現給用戶以前先驗證返回信息是否符合標準。
  • 統一錯誤信息，避免用戶根據錯誤信息來判斷遠程服務器端口狀態。
  • 限制請求的端口爲 HTTP 經常使用端口，好比 80、44三、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查詢結果實現。

image.png | center | 600x343

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/173526…

還有不少名稱相似的項目，好比原版包名稱爲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/

查人：pipl.com

註冊網站找回：www.zhaohuini.com/

防護方式

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

文件上傳

瀏覽器經過上傳頁面將文件儲存到服務器中。通常這些上傳頁面都會有限制（好比限制格式爲jpg/gif/png等等，或者限制文件大小）。漏洞頁面大體分爲兩種，一種是不限制任何格式，隨意上傳，這種如今比較少了。另外一種是限制Content-type，雖然它限制了文件類型，但能夠突破它。

任意文件上傳

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

文件類型限制

若是隻是前端作了擴展名限制，能夠經過接口工具繞過。若是後端加上了校驗，這個校驗必須很謹慎。黑客也有可能利用服務器的已知漏洞。好比以前Nginx、Apache、IIS 都爆出過解析漏洞。

例如：假設存在漏洞的站點上有一張圖片，URL 地址爲：www.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，用戶名和密碼卻給人發過去了。

image.png | center | 300x532.5

還有不少釣魚短信常會假裝成銀行發送的短信，通常都是警告用戶的銀行帳戶出現了安全問題，誘使用戶點擊短信中的連接地址來解決。釣魚短信會連接到一個高仿的正規網站，這個高仿網站從表面上看不管是圖標仍是頁面設計和官方網站同樣，給用戶形成一種假象，以爲這個網站沒問題。接着就是要求用戶提供儘量多的我的信息。

image.png | center | 475x363

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

image.png | center | 762x386

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

以人力資源部爲例。該部門員工會收到各類格式不一的大量簡歷，因此收來一份附件來源不明的電子郵件是很日常的事，不會引發懷疑。簡歷裏若是再附上一些做品連接或者做品附件之類的，就很容易中招。

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

越權

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

image.png | center | 640x387

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

一般狀況下，咱們使用一個web應用程序提供的功能時，流程是：登陸—>提交請求—>驗證權限—>數據庫查詢—>返回結果。若是在「驗證權限」環節存在缺陷，那麼便會致使越權。一種常見的存在越權的情形是：Web應用程序的開發者安全意識不足，認爲經過登陸便可驗證用戶的身份，而對用戶登陸以後的操做不作進一步的權限驗證，進而致使越權問題。好比：

一、經過隱藏URL實現訪問控制：

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

二、直接對象引用：

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

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

其中accountId是用戶本身的帳戶ID。用戶登陸本身的帳戶後，該URL的連接會出如今用戶帳戶頁面中，用戶點擊便可跳轉到帳戶信息頁面。雖然其餘用戶沒法看到這個連接，可是若是該網銀系統的訪問控制不完善，攻擊者徹底能夠經過枚舉accountId進而構造出URL，而後越權查看他人的帳戶信息。

三、多階段功能：

應用程序的一些功能經過幾個階段執行，而且在執行過程當中向服務器依次提交多個請求。這種狀況很常見，好比轉帳功能、找回密碼功能等，須要先驗證用戶的身份，驗證經過後才容許用戶執行後續動做。多階段功能自己並無問題，可是若是開發者認爲到達驗證過程後續階段的用戶必定已經擁有了相關的權限，並在後續階段執行操做時再也不對用戶提交的請求進行驗證，那麼就頗有可能存在越權漏洞。攻擊者徹底有可能繞過前幾階段的驗證階段，直接執行後續的動做。

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

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

四、靜態文件：

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

image.png | center | 794x464

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

宜信某平臺多處越權及任意用戶登陸

防護方式

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

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

注意：《網絡安全法》實施以後，全部未經受權的滲透都是非法行爲，so，大部分白帽子的行爲都是非法的，你們不要嘗試。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程