常見前端安全總結 - XSS/CSRF/cookie/密碼/HTTP傳輸/點擊劫持

時間 2019-11-10

標籤常見前端安全總結 xss csrf cookie 密碼 http 傳輸點擊劫持欄目系統安全简体版

原文原文鏈接

XSS

XSS定義：

Cross site
本網站運行了來自其餘網站的代碼
數據變成了程序

XSS實例:

頁面上輸出query參數
頁面上顯示搜索框腳本
引入外部js資源
富文本 - 寫日誌 - 富文本 - 塞入的 - 加入scrpit
在線商城 - 訂單信息input消息的填寫 - 訂單信息流入後臺 - 獲取後臺的管理員信息和後臺地址

XSS危害：

獲取頁面數據
獲取cookie document.cookie
劫持前端邏輯
發送請求

XSS攻擊分類：

XSS攻擊點：包含用戶輸入行爲

1.HTML節點內容

2.HTML屬性

紅框內爲輸入內容，致使屬性標籤閉合 添加了新的屬性

3.javascript代碼 - 強制標籤閉合 - 搜索

4.富文本：富文本自帶HTML

防護方法

1.瀏覽器自帶 X-XSS-Protection

取值： 0關閉 1默認(開啓) 1後面帶參數 - 攔截後自動發送到該網址上
    限制：只攔截反射類型注入 - 只對HTML屬性和節點內容有用

demo（koa）javascript

2.HTML節點內容/屬性 - 轉義成HTML實體

不被瀏覽器解析正常顯示
< > 內容
「 ‘ 是屬性

3.javascript代碼

JSON.stringfy  - 全部的單引號/雙引號都會被轉義

4.富文本

黑名單 - 正則替換 - 由於變形有不少，只能阻擋一部分
  白名單 - 在白名單的HTML容許寫入 - 實現複雜 - 把html解析成樹狀結構 - 依次分析過濾每一個節點的name,attr，過濾掉不在白名單內的屬性和tag
  使用npm包 - xss自動實現 https://www.npmjs.com/package/xss

5.csp - http的頭

content security policy
內容安全策略，用於指定哪些內容可執行

類型css

Child-src 頁面子內容 iframe
Connect-src ajax
Default-src fallback 全部的內容
Font-src
Frame-src
Img-src
Manifest-src webapp
Media-src audio/video
Object-src 插件
Script-src 
Style-src
Worker-src serviceWorker

配置選項 - 那些可信任那些不可信任html

<host-source> 主機域名
<scheme-source> 協議
Self 同域 - 引入的資源
Unsafe-inline 直接插入頁面的內容
Unsafe-eval 
none 不信任任何內容 
Nonce-<base64-value> 指定一次性憑證 憑證匹配時可執行
<hash-source>
Stric-dynamic 引入的後續網址是否

demo
沒有指定的所有不信任,只信任同源的引入文件，對於直接插入的不信任前端

CSRF

CSRF定義

cross site request forgy
跨站請求僞造
Cross-site: 其餘網站對本網站進行的影響，在用戶不知情的額狀況下向目標網站發送請求
打開鏈接就可能對其餘網站進行操做
post請求 - 第三方站點攻擊時 - 須要構建表單

<body>
    hello，這裏什麼也沒有。
    <script>
      document.write(`
        <form name="commentForm" target="csrf" method="post" action="http://localhost:1521/post/addComment">
          <input name="postId" type="hidden" value="1">
          <textarea name="content">來自CSRF！</textarea>
        </form>`
      );

      var iframe = document.createElement('iframe');
      iframe.name = 'csrf';
      iframe.style.display = 'none';
      document.body.appendChild(iframe);

      setTimeout(function(){
        document.querySelector('[name=commentForm]').submit();
      },1000);
    </script>
  </body>

Form在提交時會刷新 - 但若是指向一個iframe,則頁面刷新會發生在iframe中
get會更容易，並且能夠是一張圖片等其餘信息java

csrf危害

更容易傳播-把這種鏈接分享到社交網絡中
利用用戶登陸態
用戶不知情
完成業務請求

demo
qq音樂分享到qq空間，點擊連接又能夠發送node

csrf攻擊原理

s1:用戶登陸A網站
s2:A網站確認身份
s3:B網站頁面向A網站發起請求（帶A網站身份）web

csrf解決思考

B網站向A網站請求,帶A網站Cookies
不訪問A網站前端
referer爲B網站ajax

csrf解決方法

1.禁止第三方網站帶Cooike

- same-site屬性[strict/Lax]
    Strict - 任何請求都不能帶上
    Lax - ajax/form不容許，連接能夠
    對於匿名無效
    只對chrome/oprea支持

2.不通過A的前端頁面

1.圖像驗證碼 - ccap
    必須通過A頁面，去頁面上拿到驗證碼，且用戶必須輸入
2.頁面生成隨機token -
   攻擊者必須經由前端頁面才能拿到咱們的頁面
   校驗請求中的token和用戶cookie中的token
   Token均可以拿到，是否有意義？
   ajax提交 - 吧token信息不讓用戶輸入，而是放在頁面的meta標籤中來獲取
 WT:若是我打開了不少個頁面，每打開一個頁面就新生成一個token,致使只有最後的那個能夠被提交，由於cookie中的被覆蓋，怎麼解決？

3.referer爲B網站

referer http請求頭, 請求來自於那裏
驗證請求referer 只容許本網站 - 不能直接indexOf域名，不嚴謹

Cookie

cookie特色

前端數據存儲，可讀寫
後端經過Http頭設置，請求時經過http頭傳給後端
遵照同源策略

cookie一旦設置，同源下的請求頭上，都會帶上cookie,只要是請求，就算是對css等靜態資源的請求redis

login接口的響應中能夠看到設置cookie算法

cookie操做

前端操做：

Document.cookie - 獲取
Document.cookie = ‘key=value’ 不是覆蓋是追加？cookie特性
刪除cookie - 設置cookie過時

cookie屬性：

路勁：對網站不一樣層級設置不一樣的cookie
域名：
有效期：session(會話內有效)
Http-only: 只容許請求,請求的發送和接受，js不能使用cookie，js中看不到
Secure: 只容許在https使用cookie
Same-site:

cookie做用

存儲個性化設置
存儲未登陸時用戶惟一標識
存儲已登陸用戶的憑證
存儲其餘業務數據

cookie登陸用戶憑證

存儲個性化設置
存儲未登陸時用戶惟一標識
存儲已登陸用戶的憑證
存儲其餘業務數據

cookie加密demo

用戶ID - 可使用document.cookie隨意更改 - 安全隱患
用戶ID+簽名 - crypto
        篡改該用戶名時，你永遠不知道他的簽名值是是多少

設置簽名防止，篡改用戶id
用戶id，標識用戶信息

校驗簽名：

sessionId - 服務器根據這個區尋找用戶信息，再去驗證你的身份
實現： 
生成sessionId  
缺點：服務重啓會丟失
session持久化：文件、數據庫、緩存(redis)

登陸成功設置sessionID

評論驗證獲取userId

cookie與xss

xss可能偷取cookies
http-only的cookies不會被偷

cookie與xsrf

cookie存在瀏覽器端，當發送請求時，自動尋找該域下沒有過時的cookie

csrf利用了用戶cookies
攻擊站點沒法讀寫cookies
最好能阻止第三方使用cookies

cookie安全策略

簽名防篡改
私有變換（加密）
http-only（防止XSS）
secure
same-site

cookie加密、解密demo

前端點擊劫持

特徵：

用戶操做
    用戶不知情
    點點點的遊戲 - 打開攝像頭

防護

javascript防護
直接頁面和內嵌iframe頁面的區別：top window不相等

反擊：
Html5 iframe新屬性 - shadow:禁止腳本運行，只容許表單提交

X-Frame-Options ie8+

請求頭屬性
        DENY - 禁止內嵌
        SAME-ORIGIN -  同一個網站
        ALLOW-FROM - 只容許指定網站![clipboard.png](/img/bVbpTkt)

其餘手段 - 驗證碼 - 輔助手段

HTTP傳輸安全

鏈路層？
http協議請求明文發佈無加密
鏈路層有不少節點 - 傳輸過程當中 - 轉發這些流量數據 - 請求數據對這些節點都是公開透明的
Traceroute www.xingshulin.com

HTTP劫持和篡改

e.g.:
    運營商劫持 - 校園網登陸/提示續費網頁
    網站被塞廣告
    局域網劫持 支付寶網頁 - 局域網流量走本身的機器，設置了一個網關，劫持了請求
    公共wifi - 全部的流量 都通過這個 公共網絡

解決：

改用https - TSL(SSL) 加密 將明文轉爲 密文 傳輸

可是存在仍是存在僞造，劫持

解決：

發佈證書 - CA
信任CA列表在 鑰匙串訪問  - 系統根證書
12306 security

保證這幾個節點的安全：

證書沒法僞造
    證書不會被偷走，私鑰不會被泄露
    域名管理權不泄露 - CA在給該域名發佈證書時，須要對域名的管理權進行驗證
    CA堅守原則 - CA不驗證域名的話，不給發證書

部署

服務器申請證書：
 Ca 訪問指定地址要求你給出指定的返回
 訪問一個域名 - 給出一個給定的值
 模擬：https://www.sslforfree.com/

獲得的CA:

把前兩個合併

在一個web站點配置一個https的項目

1.服務器下新建項目目錄
    2.寫入nignx配置文件

3.經過工具自動申請證書到服務器

自動腳本獲取證書

curl https://get.acme.sh | sh

方法是：寫入cert要求的內容

獲得

4.把獲得的證書放入配置文件

密碼安全

泄露渠道

數據庫被偷
服務器被入侵
通信被竊聽
內部人員泄露數據
其餘網站（撞庫）

密碼存儲

嚴禁明文存儲（防泄露）
單向變換（防泄漏）
變換複雜度要求（防猜解）
密碼複雜度要求（防猜解）
加鹽（防猜解）

哈希算法 - 32字符串/提取/信息摘要算法

明文 - 密文一一對應
雪崩效應
密文 - 明文沒法反推
密文固定長度
常見哈希算法：md5 sha1 sha256

單向變換彩虹表

加鹽+增長用戶的密碼複雜度

變換次數越多越安全 - 密碼加密解密只存在登陸時
 加密成本幾乎不變（生成密碼時速度慢一些）
 彩虹表失效（）

密碼傳輸的安全性

密碼加密 - 服務端實現

https傳輸

頻率限制 - 避免猜出密碼 - 一分鐘輸入10次
    前端加密 - 意義有限 - http傳輸時，仍能夠拿到 - 意義：防止拿到明文密碼登錄其餘相關網站

Npm install js-md5

密碼加密 - 服務端實現

舊用戶沒有salt,升級
if (!user.salt) {
var salt = password.getSalt();
var newPassword = password.encryptPassword(salt, user.password)
await query(`update user set password = '${newPassword}', salt = '${salt} where id = ${user.id}'`)
user.salt = salt
user.password = newPassword
}

var encryptPassword = password.encryptPassword(user.salt,user.password)
if (encryptPassword !== user.password) {
throw new Error('密碼不正確')
}

上傳問題

定義

公司使用的基本都是node服務，不過分敘述了哈哈哈~

上傳文件
再次訪問上傳的文件
上傳的文件被當作程序解析

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。