Web 安全概念

時間 2019-12-08

標籤 web 安全概念欄目 HTML 简体版

原文原文鏈接

Web 安全概念

Web 應用中存在不少安全風險，這些風險會被黑客利用，輕則篡改網頁內容，重則竊取網站內部數據，更爲嚴重的則是在網頁中植入惡意代碼，使得用戶受到侵害。常見的安全漏洞以下：javascript

XSS 攻擊：對 Web 頁面注入腳本，使用 JavaScript 竊取用戶信息，誘導用戶操做。
CSRF 攻擊：僞造用戶請求向網站發起惡意請求。
釣魚攻擊：利用網站的跳轉連接或者圖片製造釣魚陷阱。
HTTP參數污染：利用對參數格式驗證的不完善，對服務器進行參數注入攻擊。
遠程代碼執行：用戶經過瀏覽器提交執行命令，因爲服務器端沒有針對執行函數作過濾，致使在沒有指定絕對路徑的狀況下就執行命令。

安全威脅`XSS`的防範

XSS（cross-site scripting跨域腳本攻擊）攻擊是最多見的 Web 攻擊，其重點是『跨域』和『客戶端執行』。php

xss 能幹什麼

獲取頁面數據
獲取cookies
劫持前端邏輯
發送請求
偷取網站任意數據
偷取用戶資料
偷取用戶密碼和登陸狀態

案例

站酷，能夠穿js，導入一個圖片，利用src來取到cookies，就能取到登陸態
qq空間

xss攻擊注入xss

@1型 html節點內容
@2型 html屬性
@3型 javascript代碼
@4型富文本
XSS 攻擊通常分爲兩類：html
Reflected XSS（反射型的 XSS 攻擊）
Stored XSS（存儲型的 XSS 攻擊）前端

Reflected XSS

主要是url帶上參數，發送給別人，能夠轉成短網址java

反射型的 XSS 攻擊，主要是因爲服務端接收到客戶端的不安全輸入，在客戶端觸發執行從而發起 Web 攻擊。好比：node

在某購物網站搜索物品，搜索結果會顯示搜索的關鍵詞。搜索關鍵詞填入<script>alert('handsome boy')</script>, 點擊搜索。頁面沒有對關鍵詞進行過濾，這段代碼就會直接在頁面上執行，彈出 alert。web

Stored XSS

基於存儲的 XSS 攻擊，是經過提交帶有惡意腳本的內容存儲在服務器上，當其餘人看到這些內容時發起 Web 攻擊。通常提交的內容都是經過一些富文本編輯器編輯的，很容易插入危險代碼。ajax

JSONP XSS

JSONP 的 callback 參數很是危險，他有兩種風險可能致使 XSS算法

一、callback 參數意外截斷js代碼，特殊字符單引號雙引號，換行符均存在風險。sql

二、callback 參數惡意添加標籤（如 <script> ），形成 XSS 漏洞。

XSS 的防範方式

有兩種態度能夠選擇：第一種是前置過濾，即將用戶全部數據都進行轉義，在輸出時候在前端（模板渲染）層面直接輸出。第二種是用戶輸入的數據不通過轉義就直接存儲起來，前端在使用時候保證對數據進行轉義。

一、(@1型@2型)瀏覽器自帶防護,設置x-xss-protection，但只能防止html相關的，可是不是每一種瀏覽器都支持，只支持反型
二、(@1型@2型)將不可信變量輸出到 div / body / attribute / javascript tag / style 以前，對 & < > " ' / 進行轉義，轉義能夠在存儲時，也能夠在顯示時
三、(@1型@2型@3型)儘可能不在特定地方輸出不可信變量：script / comment / attribute / tag / style，由於逃脫 HTMl 規則的字符串太多了。
四、(@4型)富文本類型，按白名單保留部分標籤和屬性。好處是比較全面，可是比較麻煩，黑名單不全面.可使用cheerio來實現
將不可信變量輸出 URL 參數以前，進行 URLEncode
使用合適的 HTML 過濾庫進行過濾
預防 DOM-based XSS，見 DOM based XSS Prevention Cheat Sheet
開啓 HTTPOnly cookie，讓瀏覽器接觸不到 cookie
CSP也是一種方案
白名單xss或者使用xss的那個庫

const cheerio = require('cheerio');
const fs = require('fs');

const html = fs.readFileSync('./html.html', 'utf8');

const $ = cheerio.load(html);

const whiteList = {
  'img': ['src']    
}
console.log($.html());
$('*').each((index, elem) => {
  if (!whiteList[elem.name]) {
    $(elem).remove();
    return;
  }

  for(let attr in elem.attribs) {
    if (whiteList[elem.name].indexOf(attr) === -1){
      $(elem).attr(attr, null)
    }
  }
})

console.log('d', $.html());

CSP

W3C 的 Content Security Policy，簡稱 CSP，主要是用來定義頁面能夠加載哪些資源，減小 XSS 的發生。
CSP 的實質就是白名單制度，開發者明確告訴客戶端，哪些外部資源能夠加載和執行，等同於提供白名單。它的實現和執行所有由瀏覽器完成，開發者只需提供配置。

過濾 Html 標籤可否防止 XSS?

請列舉不能的狀況?

用戶除了上傳
<script>alert('xss');</script>
還可使用圖片 url 等方式來上傳腳本進行攻擊
<table background="javascript:alert(/xss/)"></table>
<img src="javascript:alert('xss')">
還能夠經過各類編碼轉換 (URL 編碼, Unicode 編碼, HTML 編碼, ESCAPE 等) 來繞過檢查
<img%20src=%22javascript:alert('xss');%22>
<img src="javascrip&#116&#58alert(/xss/)">

安全威脅 CSRF 的防範

CSRF（Cross-site request forgery跨站請求僞造，也被稱爲 One Click Attack 或者 Session Riding，一般縮寫爲 CSRF 或者 XSRF，是一種對網站的惡意利用。
CSRF 攻擊會對網站發起惡意僞造的請求，嚴重影響網站的安全。所以框架內置了 CSRF 防範方案。

危害

利用用戶登陸態
用戶不知情
完成業務請求

案例
qq遊戲利用q幣買東西

防範方式

一般來講，對於 CSRF 攻擊有一些通用的防範方案，簡單的介紹幾種經常使用的防範方案：

Synchronizer Tokens：經過響應頁面時將 token 渲染到頁面上，在 form 表單提交的時候經過隱藏域提交上來。
Double Cookie Defense：將 token 設置在 Cookie 中，在提交 post 請求的時候提交 Cookie，並經過 header 或者 body 帶上 Cookie 中的 token，服務端進行對比校驗。
Custom Header：信任帶有特定的 header（例如 X-Requested-With: XMLHttpRequest）的請求。這個方案能夠被繞過，因此 rails 和 django 等框架都放棄了該防範方式。
cookies可使用samesite來設置，能夠限制cookies的攜帶，可是隻要chrome支持，
能夠referer頭能夠判斷是否是來自本身的網址
框架結合了上述幾種防範方式，提供了一個可配置的 CSRF 防範策略。
可使用圖片驗證碼

使用方式

同步表單的 CSRF 校驗

在同步渲染頁面時，在表單請求中增長一個 name 爲 _csrf 的 url query，值爲 ctx.csrf，這樣用戶在提交這個表單的時候會將 CSRF token 提交上來：

AJAX 請求

在 CSRF 默認配置下，token 會被設置在 Cookie 中，在 AJAX 請求的時候，能夠從 Cookie 中取到 token，放置到 query、body 或者 header 中發送給服務端。

In jQuery:

var csrftoken = Cookies.get('csrfToken');

function csrfSafeMethod(method) {
  // these HTTP methods do not require CSRF protection
  return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method));
}
$.ajaxSetup({
  beforeSend: function(xhr, settings) {
    if (!csrfSafeMethod(settings.type) && !this.crossDomain) {
      xhr.setRequestHeader('x-csrf-token', csrftoken);
    }
  },
});

默認配置下，框架會將 CSRF token 存在 Cookie 中，以方便 AJAX 請求獲取到。可是全部的子域名均可以設置 Cookie，所以當咱們的應用處於沒法保證全部的子域名都受控的狀況下，存放在 Cookie 中可能有被 CSRF 攻擊的風險。框架提供了一個配置項，能夠將 token 存放到 Session 中。

刷新 CSRF token

當 CSRF token 存儲在 Cookie 中時，一旦在同一個瀏覽器上發生用戶切換，新登錄的用戶將會依舊使用舊的 token（以前用戶使用的），這會帶來必定的安全風險，所以在每次用戶登錄的時候都必須刷新 CSRF token。

cookies

同源策略

特性

域名
有效期
路徑
http-only
secure 只要https還可使用
same-site

做用
存儲個性化的設置
存儲爲登陸是的惟一標示
保存通信狀態
存儲登陸的憑證

cookies的安全策略

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

點擊劫持

用戶親手操做，可是用戶不知情，從而盜取用戶資金（轉帳消費）、獲取用戶信息

網頁iframe要操做的網頁，而後把目標網站透明的設爲0，讓點擊按鍵與攻擊者設計的背景設置成一止

點擊劫持防護

js禁止內嵌，top是不一樣的，iframe的top的window是不同的，可是在iframe中設置snadbox屬性就能夠禁止掉js，js跳轉失效
"" 應用如下全部的限制。
allow-same-origin 容許 iframe 內容被視爲與包含文檔有相同的來源。
allow-top-navigation 容許 iframe 內容從包含文檔導航（加載）內容。
allow-forms 容許表單提交。
allow-scripts 容許腳本執行。
X-FRAME-OPTIONS禁止內嵌
X-Frame-Options 響應頭有三個可選的值：
DENY：頁面不能被嵌入到任何iframe或frame中；
SAMEORIGIN：頁面只能被本站頁面嵌入到iframe或者frame中；
ALLOW-FROM：頁面容許frame或frame加載。
其餘輔助手段比較添加驗證碼等

中間人攻擊與http傳輸竊聽
竊聽用戶密碼
竊聽傳輸敏感信息
加廣告
重定向

HTTP 是網絡應用普遍使用的協議，負責 Web 內容的請求和獲取。然而，內容請求和獲取時會通過許多中間人，主要是網絡環節，充當內容入口的瀏覽器、路由器廠商、WIFI提供商、通訊運營商，若是使用了代理、FQ軟件則會引入更多中間人。因爲 HTTP 請求的路徑、參數默認狀況下均是明文的，所以這些中間人能夠對 HTTP 請求進行監控、劫持、阻擋。

在沒有 HTTPS 時，運營商可在用戶發起請求時直接跳轉到某個廣告，或者直接改變搜索結果插入自家的廣告。若是劫持代碼出現了 BUG ，則直接讓用戶沒法使用，出現白屏。

數據泄露、請求劫持、內容篡改等等問題，核心緣由就在於 HTTP 是全裸式的明文請求，域名、路徑和參數都被中間人們看得一清二楚。HTTPS 作的就是給請求加密，讓其對用戶更加安全。對於自身而言除了保障用戶利益外，還可避免本屬於本身的流量被挾持，以保護自身利益。

儘管 HTTPS 並不是絕對安全，掌握根證書的機構、掌握加密算法的組織一樣能夠進行中間人形式的攻擊。不過HTTPS是現行架構下最安全的解決方案，而且它大幅增長了中間人攻擊的成本。

密碼安全

密碼的做用
密碼的存儲
密碼的傳輸
密碼的替代方案
生物特徵密碼的問題

密碼傳輸的安全性

http傳輸
頻率限制
前端加密意義有限

Sql/Nosql 注入

注入攻擊是指當所執行的一些操做中有部分由用戶傳入時, 用戶能夠將其惡意邏輯注入到操做中. 當你使用 eval, new Function 等方式執行的字符串中有用戶輸入的部分時, 就可能被注入攻擊. 上文中的 XSS 就屬於一種注入攻擊. 前面的章節中也提到過 Node.js 的 child_process.exec 因爲調用 bash 解析, 若是執行的命令中有部分屬於用戶輸入, 也可能被注入攻擊。

防治手段