web安全常見的8大板塊：
- 老生常談的XSS跨站腳本攻擊
- 警惕iframe帶來的風險
- 別被點擊劫持了
- 錯誤的內容推斷
- 防火防盜防豬隊友：不安全的第三方依賴包
- 用了HTTPS也可能掉坑裏
- 本地存儲數據泄露
- 缺失靜態資源完整性校驗
XSS跨站腳本攻擊
1.繞過XSS-Filter，利用<>標籤注入Html/JavaScript代碼；
2.利用HTML標籤的屬性值進行xss攻擊。例如：<img src=“javascript:alert(‘xss’)”/>；（當然並不是所有的Web瀏覽器都支持Javascript僞協議，所以此類XSS攻擊具有一定的侷限性）
3. 空格、回車和Tab。如果XSS Filter僅僅將敏感的輸入字符列入黑名單，比如javascript，用戶可以利用空格、回車和Tab鍵來繞過過濾，例如：<img src=“javas cript:alert(/xss/);”/>；
4. 利用事件來執行跨站腳本。例如：<img src=“#” onerror= “alert(1)”/>，當src錯誤的視乎就會執行onerror事件；
5. 利用CSS跨站。例如：Body {backgrund-image: url(“javascript:alert(‘xss’)”)}；
6. 擾亂過濾規則。例如：<IMG SRC=“javaSCript: alert(/xss/);”/>；
7.利用字符編碼，透過這種技巧，不僅能讓XSS代碼繞過服務端的過濾，還能更好地隱藏Shellcode；（JS支持unicode、eacapes、十六進制、十進制等編碼形式）
8.拆分跨站法，將xss攻擊的代碼拆分開來，適用於應用程序沒有過濾 XSS關鍵字符（如<、>）卻對輸入字符長度有限制的情況下；
9.DOM型的XSS主要是由客戶端的腳本通過DOM動態地輸出數據到頁面上，它不依賴於提交數據到服務器，而是從客戶端獲得DOM中的數據在本地執行。容易導致DOM型的XSS的輸入源包括：Document.URL、Location(.pathname|.href|.search|.hash)、
Document.referrer、Window.name、Document.cookie、localStorage/globalStorage；
如何防禦：
原則：不相信客戶輸入的數據
注意: 攻擊代碼不一定在<script></script>中
1、輸入過濾
2、HttpOnly Cookie
將重要的cookie標記爲http only, 這樣的話當瀏覽器向Web服務器發起請求的時就會帶上cookie字段，但是在腳本中卻不能訪問這個cookie，這樣就避免了XSS攻擊利用JavaScript的document.cookie獲取cookie：
iframe帶來的風險
既不安全也非常耗性能。
容易被其他第三方惡意網站以精確的iframe盜取我們的用戶信息。
防禦檢測：
1.方式一
if (self.frameElement && self.frameElement.tagName == "IFRAME") {
alert('在iframe中');
}
2.方式二
if (window.frames.length != parent.frames.length) {
alert('在iframe中');
}
3.方式三
if (self != top) {
alert('在iframe中');
}
還好在HTML5中，iframe有了一個叫做sandbox的安全屬性，通過它可以對iframe的行爲進行各種限制，充分實現“最小權限“原則。使用sandbox的最簡單的方式就是隻在iframe元素中添加上這個關鍵詞就好，就像下面這樣：
<iframe sandbox src="..."> ... </iframe>
sandbox還忠實的實現了“Secure By Default”原則，也就是說，如果你只是添加上這個屬性而保持屬性值爲空，那麼瀏覽器將會對iframe實施史上最嚴厲的調控限制，基本上來講就是除了允許顯示靜態資源以外，其他什麼都做不了。比如不準提交表單、不準彈窗、不準執行腳本等等，連Origin都會被強制重新分配一個唯一的值，換句話講就是iframe中的頁面訪問它自己的服務器都會被算作跨域請求。
另外，sandbox也提供了豐富的配置參數，我們可以進行較爲細粒度的控制。一些典型的參數如下：
-
allow-forms：允許iframe中提交form表單
-
allow-popups：允許iframe中彈出新的窗口或者標籤頁（例如，window.open()，showModalDialog()，target=”_blank”等等）
-
allow-scripts：允許iframe中執行JavaScript
-
allow-same-origin：允許iframe中的網頁開啓同源策略
更多詳細的資料，可以參考iframe中關於sandbox的介紹。
別被點擊劫持了
最常見的是惡意網站使用 <iframe> 標籤把我方的一些含有重要信息類如交易的網頁嵌入進去，然後把 iframe 設置透明，用定位的手段的把一些引誘用戶在惡意網頁上點擊。這樣...
防禦方法：
1、不允許被iframe嵌套，
if (top.location.hostname !== self.location.hostname) {
alert("您正在訪問不安全的頁面，即將跳轉到安全頁面！");
top.location.href = self.location.href;
}
2、使用 HTTP 頭防範
通過配置 nginx 發送 X-Frame-Options 響應頭，這樣瀏覽器就會阻止嵌入網頁的渲染。更詳細的可以查閱MDN上關於X-Frame-Options 響應頭的內容。
add_header X-Frame-Options SAMEORIGIN;
錯誤的內容推斷
比如在上傳文件時在文件數據裏面動了手腳，嵌入腳本文件或語句。
防火防盜防豬隊友：不安全的第三方依賴包
前面聖誕老人的雪花不陌生吧，嘻嘻嘻～～～
用了HTTPS也可能掉坑裏
解決這個安全問題的辦法是使用HSTS（HTTP Strict Transport Security），它通過下面這個HTTP Header以及一個預加載的清單，來告知瀏覽器在和網站進行通信的時候強制性的使用HTTPS，而不是通過明文的HTTP進行通信：
Strict-Transport-Security: max-age=; includeSubDomains; preload
本地存儲數據泄露
在前端存儲敏感、機密信息始終都是一件危險的事情，推薦的做法是儘可能不在前端存這些數據。
缺失靜態資源完整性校驗
出於性能考慮，前端應用通常會把一些靜態資源存放到CDN（Content Delivery Networks）上面，例如Javascript腳本和Stylesheet文件。這麼做可以顯著提高前端應用的訪問速度，但與此同時卻也隱含了一個新的安全風險。
如果攻擊者劫持了CDN，或者對CDN中的資源進行了污染，那麼我們的前端應用拿到的就是有問題的JS腳本或者Stylesheet文件，使得攻擊者可以肆意篡改我們的前端頁面，對用戶實施攻擊。
防禦這種攻擊的辦法是使用瀏覽器提供的SRI（Subresource Integrity）功能。顧名思義，這裏的Subresource指的就是HTML頁面中通過瀏覽器在處理這個script元素的時候，就會檢查對應的JS腳本文件的完整性，看其是否和script或link元素中integrity屬性指定的SRI值一致，如果不匹配，瀏覽器則會中止對這個JS腳本的處理。
<link crossorigin="anonymous" integrity="sha256-+hDz/gVbhp24mhOmoIT4Du4F3K5fs9fjjoe0rP5gSLs=" rel="stylesheet" href="/assets/css/home.css" />
這個 integrity 屬性的值來 指定瀏覽器提取的資源（文件）的base64編碼的加密哈希值。如果資源匹配其中一個哈希值，它將被加載。
<script><link>的integrity值 至少一個字符串，每個串包括指示特定散列算法（目前允許的前綴的前綴sha256，sha384和sha512），然後用短劃線，並與實際base64編碼散列結束。例如：
sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC