當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

读白帽子讲WEB安全，摘要

發(fā)布時(shí)間：2024/1/8 编程问答 39 豆豆

生活随笔收集整理的這篇文章主要介紹了读白帽子讲WEB安全，摘要小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

讀<白帽子講WEB安全>摘要

文章目錄

- 我的安全世界觀
- - 安全三要素-CIA
  - 如何實(shí)施安全評(píng)估
  - 白帽子兵法
客戶端安全
- 瀏覽器安全
- - 同源策略
  - 瀏覽器沙箱
  - 惡意網(wǎng)址攔截
  - 高速發(fā)展的瀏覽器安全
- XSS 跨站腳本攻擊
- - XSS簡(jiǎn)介
  - XSS 攻擊進(jìn)階
  - - 初探XSS Payload
    - 強(qiáng)大的xss payload
    - 構(gòu)造GET和POST請(qǐng)求。
    - XSS釣魚
  - CSS history hack
  - 獲取用戶的真實(shí)IP
  - XSS 攻擊平臺(tái)
  - 終極武器 XSS Worm
  - 調(diào)試JavaScript
  - XSS構(gòu)造技巧
- XSS 防御
- - HttpOnly
  - - 解決XSS攻擊中的cookie劫持問題。
  - 輸入檢查
  - 輸出檢查
  - 正確的防御XSS攻擊
  - 處理富文本
  - 防御 DOM Base XSS
- CSFR跨站請(qǐng)求偽造
- - CSRF 進(jìn)階
  - - 瀏覽器的cookie策略
    - P3P
    - get or post
    - Flash CSRF
    - CSRF worm
- CSRF防御
- - - 驗(yàn)證碼
    - Referer check
  - 點(diǎn)擊劫持
  - 觸屏劫持
  - 防御點(diǎn)擊劫持
  - - X-Frame-Options
- HTML5安全
- - html新標(biāo)簽的xss
  - - iframe 的sandbox屬性
    - link types ： noreferer
    - canvas的妙用
  - 其他安全問題
  - - cross-origin resource sharing CORS
    - postMessage 跨窗口傳遞消息
- 服務(wù)器端應(yīng)用安全
- 注入攻擊
- - sql注入
  - 數(shù)據(jù)庫(kù)攻擊技巧
  - 數(shù)據(jù)庫(kù)防御
  - 其他注入
- 文件上傳文件
- - 設(shè)置安全的文件上傳功能
- 認(rèn)證和會(huì)話管理
- - 密碼那些事兒
  - session 與認(rèn)證
  - session fixation 攻擊
  - session保持攻擊
  - sso 單點(diǎn)登錄 single sign on
- 訪問控制
- - what can i do ?
  - 垂直權(quán)限管理
  - 水平越權(quán)管理
- 加密算法與隨機(jī)數(shù)
- Web框架安全
- - mvc 框架安全
  - web框架與csrf 策略
  - 模板引擎與xss防御
  - http header 的管理
  - - 管理好跳轉(zhuǎn)地址很重要
    - X-frame-options
    - httponly
  - 數(shù)據(jù)庫(kù)與sql注入
  - 還能想到什么
  - web框架的自身安全
- PHP安全
- Web Server 配置安全
- 安全開發(fā)流程
- 安全運(yùn)營(yíng)
- - 安全運(yùn)營(yíng)
  - 修補(bǔ)漏洞流程
  - 安全監(jiān)控
  - 入侵檢測(cè)
  - 緊急響應(yīng)流程

我的安全世界觀

安全三要素-CIA

機(jī)密性 Confidentiality

數(shù)據(jù)不被泄漏
- 加密

完整性 Integrity

保護(hù)數(shù)據(jù)內(nèi)容完整的、沒有被篡改
- 數(shù)字簽名

可用性 Availability

DOS-Denial Of Service 攻擊會(huì)破壞可用性

拓展：可審計(jì)性、不可抵賴性

如何實(shí)施安全評(píng)估

互聯(lián)網(wǎng)安全的核心問題，是數(shù)據(jù)安全的問題。

資產(chǎn)等級(jí)劃分

了解公司最重要的資產(chǎn)是什么，他們最看重的數(shù)據(jù)是什么。通過訪談的形式，安全部門才能熟悉、了解公司的業(yè)務(wù)，公司所擁有的數(shù)據(jù)，以及不同數(shù)據(jù)的重要程度，為后續(xù)的安全評(píng)估過程指明方向

信任域和信任邊界,網(wǎng)絡(luò)邏輯上來劃分。比如最重要的數(shù)據(jù)放在數(shù)據(jù)庫(kù)里，那么把數(shù)據(jù)庫(kù)的服務(wù)器圈起來； Web 應(yīng)用可以從數(shù)據(jù)庫(kù)中讀/寫數(shù)據(jù)，并對(duì)外提供服務(wù)，那再把 Web 服務(wù)器圈起來；最外面是不可信任的 Internet

威脅分析

危害的來源稱為威脅（Threat）

可能會(huì)出現(xiàn)的損失稱為風(fēng)險(xiǎn)（Risk）

威脅建模

什么是威脅分析？威脅分析就是把所有的威脅都找出來。怎么找？一般是采用頭腦風(fēng)暴法。當(dāng)然，也有一些比較科學(xué)的方法，比如使用一個(gè)模型，幫助我們?nèi)ハ?#xff0c;在哪些方面有可能會(huì)存在威脅，這個(gè)過程能夠避免遺漏，這就是威脅建模。

STRIDE 模型

威脅定義對(duì)應(yīng)的安全屬性

Spoofing（偽裝）	冒充他人身份	認(rèn)證
Tampering（篡改）	修改數(shù)據(jù)或代碼	完整性
Repudiation（抵賴）	否認(rèn)做過的事情	不可抵賴性
InformationDisclosure（信息泄露）	機(jī)密信息泄露	機(jī)密性
Denial of Service（拒絕服務(wù)）	拒絕服務(wù)	可用性
Elevation of Privilege（提升權(quán)限）	未經(jīng)授權(quán)獲得許可	授權(quán)

風(fēng)險(xiǎn)分析

我們判斷風(fēng)險(xiǎn)高低的過程，就是風(fēng)險(xiǎn)分析的過程 .

風(fēng)險(xiǎn)由以下因素組成：

Risk = Probability * Damage Potential
- DREAD 模型

等級(jí)高(3)中(2)低(1)

Damage Potential	獲取完全驗(yàn)證權(quán)限；執(zhí)行管理員操作；非法上傳文件	泄露敏感信息	泄露其他信息
Reproducibility	攻擊者可以隨意再次攻擊	攻擊者可以重復(fù)攻擊，但有時(shí)間限制	攻擊者很難重復(fù)攻擊過程
Exploitability	初學(xué)者在短期內(nèi)能掌握攻擊方法	熟練的攻擊者才能完成這次攻擊	漏洞利用條件非?？量?/td>
Affected users	所有用戶，默認(rèn)配置，關(guān)鍵用戶	部分用戶，非默認(rèn)配置	極少數(shù)用戶，匿名用戶
Discoverability	漏洞很顯眼，攻擊條件很容易獲得	在私有區(qū)域，部分人能看到，需要深入挖掘漏洞	發(fā)現(xiàn)該漏洞極其困難

確認(rèn)解決方案
安全評(píng)估的產(chǎn)出物，就是安全解決方案。
設(shè)計(jì)解決方案不難，難的是如何設(shè)計(jì)一個(gè)好的解決方案。設(shè)計(jì)一個(gè)好的解決方案，是真正考驗(yàn)安全工程師水平的時(shí)候。很多人認(rèn)為，安全和業(yè)務(wù)是沖突的，因?yàn)橥鶠榱税踩?#xff0c;要犧牲業(yè)務(wù)的一些易用性或者性能，筆者不太贊同這種觀點(diǎn)。從產(chǎn)品的角度來說，安全也應(yīng)該是產(chǎn)品的一種屬性。一個(gè)從未考慮過安全的產(chǎn)品，至少是不完整的。
沒有不安全的業(yè)務(wù)，只有不安全的實(shí)現(xiàn)方式。
安全方案必須能夠有效抵抗威脅，但同時(shí)不能過多干涉正常的業(yè)務(wù)流程，在性能上也不能拖后腿。
，一個(gè)優(yōu)秀的安全方案應(yīng)該具備以下特點(diǎn)：
能夠有效解決問題；
用戶體驗(yàn)好；
高性能；
低耦合；
易于擴(kuò)展與升級(jí)

白帽子兵法

Secure By Default 原則，也可以歸納為白名單、黑名單的思想
黑名單、白名單
最小權(quán)限原則
縱深防御原則

不同的層面、不同的角度對(duì)系統(tǒng)做出整體的解決方案。

我們常常聽到“木桶理論”這個(gè)詞，說的是一個(gè)桶能裝多少水，不是取決于最長(zhǎng)的那塊板，而是取決于最短的那塊板，也就是短板。設(shè)計(jì)安全方案時(shí)最怕出現(xiàn)短板，第 1 章我的安全世界觀 19 木桶的一塊塊板子，就是各種具有不同作用的安全方案，這些板子要緊密地結(jié)合在一起，才能組成一個(gè)不漏水的木桶。

在常見的入侵案例中，大多數(shù)是利用 Web 應(yīng)用的漏洞，攻擊者先獲得一個(gè)低權(quán)限的 webshell，然后通過低權(quán)限的 webshell 上傳更多的文件，并嘗試執(zhí)行更高權(quán)限的系統(tǒng)命令，嘗試在服務(wù)器上提升權(quán)限為 root；接下來攻擊者再進(jìn)一步嘗試滲透內(nèi)網(wǎng)，比如數(shù)據(jù)庫(kù)服務(wù)器所在的網(wǎng)段。

Web 應(yīng)用安全、 OS 系統(tǒng)安全、數(shù)據(jù)庫(kù)安全、網(wǎng)絡(luò)環(huán)境安全等。在這些不同層面設(shè)計(jì)的安全方案，將共同組成整個(gè)防御體系，這也就是縱深防御的思想。

縱深防御的第二層含義，是要在正確的地方做正確的事情。如何理解呢？它要求我們深入理解威脅的本質(zhì)，從而做出正確的應(yīng)對(duì)措施。
數(shù)據(jù)與代碼分離原則

這一原則廣泛適用于各種由于“注入”而引發(fā)安全問題的場(chǎng)景。

實(shí)際上，緩沖區(qū)溢出，也可以認(rèn)為是程序違背了這一原則的后果——程序在棧或者堆中，將用戶數(shù)據(jù)當(dāng)做代碼執(zhí)行，混淆了代碼與數(shù)據(jù)的邊界，從而導(dǎo)致安全問題的發(fā)生。

在 Web 安全中，由“注入”引起的問題比比皆是，如 XSS、 SQL Injection、 CRLF Injection、 X-Path Injection 等。此類問題均可以根據(jù)“數(shù)據(jù)與代碼分離原則”設(shè)計(jì)出真正安全的解決方案，因?yàn)檫@個(gè)原則抓住了漏洞形成的本質(zhì)原因。
不可預(yù)測(cè)性原則

不可預(yù)測(cè)性原則，可以巧妙地用在一些敏感數(shù)據(jù)上。比如在 CSRF 的防御技術(shù)中，通常會(huì) 使用一個(gè) token 來進(jìn)行有效防御。這個(gè) token 能成功防御 CSRF，就是因?yàn)楣粽咴趯?shí)施 CSRF 攻擊的過程中，是無法提前預(yù)知這個(gè) token 值的，因此要求 token 足夠復(fù)雜時(shí)，不能被攻擊者猜測(cè)到。
客戶端安全

瀏覽器安全

同源策略

same origin policy 時(shí)瀏覽器也是最核心的功能。如果缺少同源策略，瀏覽器的正常功能都會(huì)受影響。

瀏覽器只是同源策略的一種實(shí)現(xiàn)。

瀏覽器的同源策略，限制了來自不同源的"document" 或腳本，對(duì)當(dāng)前的“document ”讀取或者設(shè)置某些屬性。

影響源的由 host (域名或ip地址）、子域名、端口、協(xié)議。

但瀏覽器中

XMLHttpRequest受到同源策略的約束，不能跨域訪問資源。

隨著業(yè)務(wù)的發(fā)展，跨域請(qǐng)求越來越迫切。因此W3C委員會(huì)制定了XMLHttpRequest跨域訪問的要求，他需要通過目標(biāo)域返回的HTTP頭來授權(quán)是否允許跨域訪問，因?yàn)閔ttp頭對(duì)于javascript來說一般是無法控制的，所以這個(gè)方案是可以實(shí)施的，這個(gè)跨域方案的安全基礎(chǔ):javaScript 無法控制該Http頭。如果信任基礎(chǔ)被打破。則此方案將不在安全。

對(duì)于瀏覽器來說，處理DOM、cookie、XMLHttpRequest受到同源策略的限制外。瀏覽器加載的一些第三方插件也有各自的同源策略。最常見的插件有 flash、java applet、silverlight、 google gears等都有自己的控制策略。

瀏覽器沙箱

采用sandbox技術(shù)，讓不受信任的腳本允許在一個(gè)受限制的環(huán)境中，從而可以保證本地桌面系統(tǒng)的安全。

惡意網(wǎng)址攔截

掛馬攻擊是在正常的網(wǎng)頁中，通過 script 或 iframe 等標(biāo)簽加載惡意的網(wǎng)址。

釣魚網(wǎng)站、詐騙網(wǎng)站對(duì)用戶來說也是一種惡意網(wǎng)址。

惡意網(wǎng)址的攔截非常簡(jiǎn)單，定期從服務(wù)器端獲取一份最新的惡意網(wǎng)址清單。用戶在瀏覽惡意網(wǎng)站時(shí)會(huì)彈出警告。

常見的惡意網(wǎng)址分兩類：一類是掛馬網(wǎng)站、一類是釣魚網(wǎng)站。

高速發(fā)展的瀏覽器安全

IE 推出Xss filter

firefox 推出的csp

XSS 跨站腳本攻擊

XSS簡(jiǎn)介

XSS = cross site script

XSS 通常指黑客通過 “html注入” 篡改了網(wǎng)頁，插入了惡意的腳本。而從在用戶瀏覽網(wǎng)頁時(shí)，控制用戶瀏覽器的一種攻擊。這種攻擊的演示案例是跨域的，所以叫跨站腳本，但是發(fā)展到今天，是否跨域已經(jīng)不在重要。
- 反射型XSS
簡(jiǎn)單的把腳本反射給瀏覽器，黑客往往要誘使客戶‘"點(diǎn)擊"一個(gè)惡意鏈接。才能攻擊成功。
- 存儲(chǔ)型XSS
把用戶輸入的數(shù)據(jù)存儲(chǔ)在服務(wù)器端，這種XSS具有很強(qiáng)的穩(wěn)定性。
- DOM Based XSS
通過修改頁面的dom節(jié)點(diǎn)形成的XSS，稱之為DOM based XSS

XSS 攻擊進(jìn)階

初探XSS Payload

從攻擊者的角度來體驗(yàn)下XSS的威力。

XSS攻擊成功后，攻擊者能夠?qū)Ξ?dāng)前瀏覽器的頁面植入惡意腳本，通過惡意腳本?？刂朴脩舻臑g覽器，用于完成具體功能的惡意腳本。被稱之為“xss payload”。

常見的payload就是cookie劫持。

cookie中一般保存了當(dāng)前用戶的登錄憑證。如果cookie丟失，往往意味著用戶的登錄憑證丟失。換句話說，攻擊者可以不通過密碼，而直接登錄進(jìn)用戶的賬戶。

攻擊者獲取到用戶的cookie后，可以使用此cookie發(fā)起攻擊。

強(qiáng)大的xss payload

構(gòu)造GET和POST請(qǐng)求。

一個(gè)網(wǎng)站只接受http協(xié)議中的get和post請(qǐng)求，對(duì)攻擊者來說，只通過JavaScript就可以讓瀏覽器發(fā)送此請(qǐng)求。

此不需要劫持用戶的cookie，只要構(gòu)造網(wǎng)站的現(xiàn)有g(shù)et或post方法。即可控制客戶的瀏覽器。

XSS釣魚
xss的攻擊過程都是JavaScript自動(dòng)進(jìn)行的，也就是說缺少交互過程。

如果在構(gòu)造post請(qǐng)求是，加上驗(yàn)證碼，但也不能徹底防止。

攻擊者：對(duì)于驗(yàn)證碼可以把驗(yàn)證碼圖片發(fā)送到攻擊者后臺(tái)識(shí)別。
此外在大多數(shù)修改密碼的功能會(huì)要求輸入舊密碼。但是這也不能防止xss payload。

修改密碼問題稍微復(fù)雜，需要將XSS與"釣魚"相結(jié)合。

實(shí)現(xiàn)思路：使用javascript在當(dāng)前頁面上"畫出"一個(gè)偽造的登陸框，當(dāng)用戶在登錄框輸入用戶名與密碼，將密碼發(fā)送至黑客的服務(wù)器上。

識(shí)別用戶瀏覽器
識(shí)別用戶安裝的軟件

CSS history hack

利用style的visited屬性，如果用戶曾經(jīng)訪問過某個(gè)鏈接，那么這個(gè)鏈接的顏色會(huì)變的與眾不同。

獲取用戶的真實(shí)IP

xss攻擊框架 “attack ip” 由可以獲取本地api

XSS 攻擊平臺(tái)

attach api
BeEF
XSS-Proxy

終極武器 XSS Worm

一般來說，用戶之間發(fā)生發(fā)生交互行為的頁面，如果存在存儲(chǔ)型XSS，比較容易發(fā)起XSS Worm

調(diào)試JavaScript

firebug
ie 8 developer tools
fiddler
httpwatch

XSS構(gòu)造技巧

利用字符編碼
繞過長(zhǎng)度限制。

利用事件，加載location.hash的值
利用注釋，合并2個(gè)input標(biāo)簽

使用base標(biāo)簽。在設(shè)計(jì)XSS 安全方案時(shí) 一定要過濾這個(gè)非常危險(xiǎn)的標(biāo)簽
window.name 的妙用。

window 對(duì)象時(shí)瀏覽器窗體

變廢為寶 Mission Impossible

apache expect header xss
anehta的回旋鏢
flash xss
JavaScript 開發(fā)框架真的安全么
dojo
yui
jquery

XSS 防御

XSS的本質(zhì)是HTML注入。將用戶的數(shù)據(jù)當(dāng)作代碼執(zhí)行。

HttpOnly

解決XSS攻擊中的cookie劫持問題。

服務(wù)器可以設(shè)置多個(gè)cookie，可以給制定的cookie設(shè)置HttpOnly。

setHeader

(

"Set-Cookie"

"cookieName=value;Path=/;Domain=domainValue;Max-Age=seconds;HTTPOnly"

)

;

輸入檢查

XSS攻擊和Sql Injection。需要對(duì)輸入進(jìn)行檢查。這種檢查被稱為“XSS Filter”。

對(duì) script 和 javascript onclick alert 等以下關(guān)鍵字處理。

輸出檢查

一般來說，除了富文本輸出外，在變量輸出到HTML頁面時(shí)，可以使用編碼或轉(zhuǎn)義的方式來防御XSS攻擊。

安全的編碼函數(shù)

編碼分為很多種，針對(duì)html代碼的編碼方式是HtmlEncode。HtmlEncode不是專有名字，是一種函數(shù)的實(shí)現(xiàn)。作用就是將字符轉(zhuǎn)換成HTMLEntries，對(duì)應(yīng)的標(biāo)準(zhǔn)是ISO-8859-1。

在javascript可以使用JavaScriptEncode。
& -> & > -> > < -> < " -> " ' -> ' / -> /
- 1
- 2
- 3
- 4
- 5
- 6

正確的防御XSS攻擊

處理富文本

防御 DOM Base XSS

CSFR跨站請(qǐng)求偽造

cross site request forgery

CSRF 進(jìn)階

瀏覽器的cookie策略

cookie分為：

“session cookie” 又叫 “臨時(shí)cookie”。瀏覽器關(guān)閉就失效。
“third party cookie” 也稱為"本地cookie"、第三方cookie。在set-cookie時(shí)設(shè)置了Expire時(shí)間，到了Expire時(shí)間，cookie失效。

出于安全考慮，IE默認(rèn)禁止了瀏覽器在<img>、<iframe>、<script>、<link>等標(biāo)簽發(fā)送第三方cookie。

Firefox chrome 默認(rèn)會(huì)發(fā)送第三方cookie。

P3P

the platform for privacy preferences

如果http返回的 header中含有P3P頭，在某種程度上將允許瀏覽器發(fā)送第三方cookie，在IE下即使是>&#12289;

但是如果設(shè)置了P3P 頭可以允許跨域訪問隱私數(shù)據(jù)，從而使跨域set-cookie成功。

在網(wǎng)站業(yè)務(wù)中，P3P頭主要用于類似廣告的等需要跨域的訪問頁面。但遺憾的是P3P頭設(shè)置后，對(duì)cookie的影響到了整個(gè)域的頁面，因?yàn)閏ookie是以域和path為單位的。這并不符合“最小權(quán)限”原則。

cookie是以域和path為單位的

誘導(dǎo)用戶訪問惡意鏈接。可調(diào)用系統(tǒng)的現(xiàn)有的接口，導(dǎo)致出現(xiàn)一些客戶不知情的操作。

get or post

get和post都能發(fā)起csrf攻擊。

Flash CSRF

IE6 IE7，flash發(fā)送的網(wǎng)絡(luò)請(qǐng)求可以帶上本地cookie，從ie8起，flash發(fā)起的網(wǎng)絡(luò)請(qǐng)求不再發(fā)送本地cookie。

CSRF worm

CSRF防御

驗(yàn)證碼
Referer check

常見的應(yīng)用就是"防止圖片盜鏈"。Referer check 也可以被用于檢查請(qǐng)求是否來自合法的源。

常見的互聯(lián)網(wǎng)應(yīng)用，頁面與頁面之間都具有邏輯關(guān)系，這使得每個(gè)正常的請(qǐng)求Referer具有一定的規(guī)律。

缺陷：服務(wù)器并非任何時(shí)候都能獲取Referer。
refer policy說明

https://w3c.github.io/webappsec-referrer-policy/#referrer-policies

Anti CSRF Token

CSRF 為什么能成功，因?yàn)橹匾僮鞯乃袇?shù)是可以被攻擊者猜測(cè)到的。

新增一個(gè)參數(shù)Token，token是安全的隨機(jī)數(shù)生成算法。

提交表單時(shí)，帶上隨機(jī)token，token的值也存在session中，在提交處理中校驗(yàn)token是否存在
Token 的使用原則
防御CSRF的Token，是根據(jù)“不可測(cè)性原則”設(shè)計(jì)的方案，需要使用安全的隨機(jī)數(shù)生成Token.
Token的目的不是為了防重復(fù)提交。雖然可以達(dá)到此效果。
Token 應(yīng)保持保密性，如出現(xiàn)在URL中，可能會(huì)在Referer中泄漏。應(yīng)該使用ajax或post提交。

還有一些XSS漏洞或者跨域漏洞可能讓攻擊者竊取到Token值。
Token 僅僅是用于對(duì)抗CSRF攻擊，當(dāng)網(wǎng)站還有其他XSS漏洞時(shí)，這個(gè)方案會(huì)變得無效。因?yàn)閄SS可以模擬客戶端瀏覽器執(zhí)行任意操作。攻擊者完全可以請(qǐng)求頁面后，讀出頁面token的值，然后再構(gòu)造一個(gè)合法的請(qǐng)求，這個(gè)過程可以稱為 XSRF和CSRF區(qū)分開。

點(diǎn)擊劫持

ClickJacking

點(diǎn)擊劫持是一種視覺上的欺騙。往往使用透明的iframe嵌入目標(biāo)網(wǎng)站。欺騙目標(biāo)網(wǎng)站用戶，竊取客戶信息。

flash點(diǎn)擊劫持:

圖片覆蓋攻擊

拖拽劫持和數(shù)據(jù)竊取

觸屏劫持

智能終端上的觸屏劫持

防御點(diǎn)擊劫持

可以寫一段JavaScript代碼，以禁止iframe嵌套，這種方法是 frame busting。

frame busting

是指利用js判斷l(xiāng)ocation以防止網(wǎng)頁被別人iframe內(nèi)嵌的一個(gè)實(shí)現(xiàn)

比如以下代碼:

(

)

{

;

}

常見的frame busting 條件判斷

if (top.location != self.location)
if (top.location != location)
if (parent.frames.length > 0)
if (window != top)
if (window.top !== window.self)
if (window.self != window.top)
if (parent && parent != window)
if (parent && parent.frames && parent.frames.length>0)
if((self.parent&&!(self.parent===self))&&(self.parent.frames.length!=0))

如果frame busting 條件判斷為真，常見的動(dòng)為以下：

top.location = self.location
top.location.href = document.location.href
top.location.href = self.location.href
top.location.replace(self.location)
top.location.href = window.location.href
top.location.replace(document.location)
top.location.href = window.location.href
top.location.href = “URL”
document.write(’’)
top.location = location
top.location.replace(document.location)
top.location.replace(‘URL’)
top.location.href = document.location
top.location.replace(window.location.href)
top.location.href = location.href
self.parent.location = document.location
parent.location.href = self.document.location
top.location.href = self.location
top.location = window.location
top.location.replace(window.location.pathname)
windowwindow.top.location = window.self.location
setTimeout(function(){document.body.innerHTML=’’;},1);
window.self.onload = function(evt){document.body.innerHTML=’’;}
var url = window.location.href; top.location.replace(url)
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69

幾種攻擊方法：

二次frame（不能針對(duì) top.location，只能針對(duì) parent.location）
利用 onbeforeunload 事件
xss
構(gòu)造referer繞過js referer檢查
瀏覽器漏洞。
iframe security屬性（僅IE支持）
iframe sandbox屬性（HTML5）
瀏覽器designmode
部分手機(jī)站點(diǎn)

相關(guān)總結(jié)：

http://seclab.stanford.edu/websec/framebusting/

X-Frame-Options

DENY 拒絕當(dāng)前頁面記載任何iframe
SAMEORIGIN iframe只能是同源域名下的頁面
ALLOW-FROM origin 可以定義iframe可以加載的地址

X-Frame-Options
firefox 的content security policy和noscript 也能有效防御click-jacking
用hidden 元素的方法，有點(diǎn)山寨，不過有用且通用

HTML5安全

html新標(biāo)簽的xss

可嵌入javascript實(shí)現(xiàn)xss攻擊。

有研究者建立了一個(gè)html5 security cheatsheet項(xiàng)目。

iframe 的sandbox屬性

allow-same-origin	允許 iframe 內(nèi)容被視為與包含文檔有相同的來源。
allow-top-navigation	允許 iframe 內(nèi)容從包含文檔導(dǎo)航（加載）內(nèi)容。
allow-forms	允許表單提交。
allow-scripts	允許腳本執(zhí)行。

link types ： noreferer

html5的標(biāo)簽可以指定noreferer，瀏覽器在請(qǐng)求該標(biāo)簽指定的地址時(shí)不再發(fā)送Referer.

這是出于保護(hù)敏感信息和隱私的考慮，因?yàn)橥ㄟ^referer可能會(huì)泄露一些敏感數(shù)據(jù)。

canvas的妙用

canvas可以使javascript可以操作圖片的像素。

其他安全問題

cross-origin resource sharing CORS

瀏覽器的同源策略 same origin policy 限制了腳本的跨域請(qǐng)求。互聯(lián)網(wǎng)的趨勢(shì)越來越開放?？缬蛟L問需要越來越急迫。出現(xiàn)很多跨域的技術(shù) jsonp 、iframe 等。

XMLHttpRequest 在ie中可以使用XDomainRequest來跨域。
使用response的header中設(shè)置Access-Control-Allow-Origin的值*，但是很不安全。

https://w3c.github.io/webappsec-referrer-policy/#referrer-policies
可以使用request中header中origin 。origin不像referer一樣容易被偽造或者置為空。

postMessage 跨窗口傳遞消息

在跨站腳本攻擊一章中，曾經(jīng)提到利用 window.name 來跨窗口，跨域傳遞信息。window對(duì)象幾乎不受同源策略限制。很多腳本都利用了window對(duì)象這一個(gè)特點(diǎn)。

服務(wù)器端應(yīng)用安全

注入攻擊

注入攻擊的本質(zhì)是將用戶的數(shù)據(jù)當(dāng)作代碼來執(zhí)行。
兩個(gè)關(guān)鍵條件

用戶能控制輸入
2.程序原本要執(zhí)行的代碼，拼接了用戶輸入的數(shù)據(jù)。

sql注入

盲注
timing attack

數(shù)據(jù)庫(kù)攻擊技巧

數(shù)據(jù)庫(kù)防御

找到所有的sql注入漏洞
修補(bǔ)這些漏洞

使用預(yù)編譯語句
使用存儲(chǔ)過程
檢查數(shù)據(jù)類型

嚴(yán)格過濾檢查用戶的輸入數(shù)據(jù)。

使用安全函數(shù)

其他注入

xml注入

xml注入越要滿足注入的攻擊的兩大條件。用戶能控制輸入的數(shù)據(jù)，程序拼湊了數(shù)據(jù)。
與html一樣，將“語言本身的保留字符”進(jìn)行轉(zhuǎn)義處理。

代碼注入
CRLF 注入

cr = carriage return
lf = lind feed

文件上傳文件

上傳漏洞概述漏洞
文件上傳常見漏洞

上傳的文件是web腳本語言，服務(wù)器的web容器解釋并執(zhí)行用戶上傳的腳本，導(dǎo)致代碼執(zhí)行。
上傳文件時(shí)flash的策略文件domain.xml,類似瀏覽器下的跨域。
上傳文件是病毒和木馬、黑客用以誘騙用戶或者管理員下載執(zhí)行。
刪除的是釣魚圖片或者包含了腳本的圖片，在某些版本的瀏覽器中會(huì)被作為腳本執(zhí)行，被用于釣魚和欺詐。
繞過文件上傳檢查功能。

功能還是漏洞

apache 文件解析問題
apache 1.x 2.x 對(duì)于不認(rèn)識(shí)的文件按照php文件處理。

IIS文件解析問題
PHP的cgi問題
利用上傳文件釣魚

釣魚網(wǎng)站在傳播的時(shí)候，會(huì)通過利用xss，服務(wù)端的302跳轉(zhuǎn)等功能，從正常網(wǎng)站跳轉(zhuǎn)到釣魚網(wǎng)站。

設(shè)置安全的文件上傳功能

1.文件上傳的目錄設(shè)置為不可執(zhí)行
2.判斷文件類型
3.使用隨機(jī)數(shù)改寫文件名稱和路徑
4.單獨(dú)設(shè)置文件服務(wù)器域名

由于瀏覽器同源策略，一系列的客戶端攻擊將失效，比如上傳crossdomain、上傳包含javascript的xss利用等問題將解決。

認(rèn)證和會(huì)話管理

認(rèn)證目的是認(rèn)出用戶是誰。就是認(rèn)證用戶憑證的過程。

而授權(quán)的目的是為了決定用戶能夠做什么。

密碼那些事兒

密碼必須是不可逆加密算法或者單向散列算法，加密后存儲(chǔ)在數(shù)據(jù)庫(kù)中的，sha-1 、md5 存儲(chǔ)。
多因素認(rèn)證，以支付寶為例，支付密碼，安全問題，實(shí)名認(rèn)證，短信驗(yàn)證，證書等等。

session 與認(rèn)證

session一旦在聲明周期內(nèi)被竊取，就等于賬戶失竊，Session是用戶登陸的憑證，黑客將不在登陸，因此黑客不再需要登錄過程。
session泄漏的途徑很多，xss攻擊、網(wǎng)絡(luò)sniff以及本地木馬竊取。
xss攻擊通過設(shè)置httponly解決，對(duì)于網(wǎng)絡(luò)嗅探，本地木馬只能通過客戶端解決。

sessionId 生成必須要要有隨機(jī)性。
手機(jī)很多瀏覽器都不支持session，都是在url中傳輸sessionId。

session fixation 攻擊

登錄后需要重寫sessionId。

session保持攻擊

session保持攻擊，可以通過不斷的訪問后臺(tái)，保持服務(wù)器session有效。
甚至攻擊者可以把session cookie 增加一個(gè)expire date變成了third party session。永遠(yuǎn)的持久化在客戶本地。
如何防御
強(qiáng)制將session過期，或者客戶存在多個(gè)session。以最后一個(gè)session生效。其他的session都是失效。

sso 單點(diǎn)登錄 single sign on

訪問控制

what can i do ?

某個(gè)主體 subject能對(duì)某個(gè)個(gè)體 object 需要實(shí)施某種操作

垂直權(quán)限管理

訪問控制實(shí)際上是建立用戶與權(quán)限的關(guān)系。
現(xiàn)在由一種通用的方法，基于角色的訪問控制,role base access contorl 簡(jiǎn)稱RBAC.
不同角色的權(quán)限有高低，往往高權(quán)限能防訪問低權(quán)限的資源。
用戶->角色->權(quán)限
以spring security為例

水平越權(quán)管理

可稱之為基于數(shù)據(jù)的訪問控制

加密算法與隨機(jī)數(shù)

Web框架安全

mvc 框架安全

view 負(fù)責(zé)用戶視圖、頁面展示工作
control 負(fù)責(zé)用戶邏輯的實(shí)現(xiàn)，接受view傳送的數(shù)據(jù)，并轉(zhuǎn)發(fā)給model處理
model model負(fù)責(zé)數(shù)據(jù)處理。

web框架與csrf 策略

模板引擎與xss防御

post請(qǐng)求添加token

session 綁定token
form 表單自動(dòng)添加token
ajax請(qǐng)求中自動(dòng)添加token
在服務(wù)器端對(duì)比post參數(shù)的token與session的token是否一致

http header 的管理

在web框架中，可以對(duì)http頭進(jìn)行全局化的處理，因此一些基于http頭的安全方案很好實(shí)施。

對(duì)http返回頭的crlf攻擊，所有的head都是key value 鍵值對(duì)。

location : http://www.a.com
host:127.0.0.1
對(duì)抗CRLF的方案只需要在value中編碼所有的 \r``\n

類似針對(duì)30X返回號(hào)的http response ,瀏覽器將會(huì)跳轉(zhuǎn)到location制定的url，攻擊者往往利用此類功能實(shí)施釣魚和咋騙。

HTTP/1.1 302 Moved Temporarily
Location: http://www.fakesite.com

管理好跳轉(zhuǎn)地址很重要

X-frame-options

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

httponly

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Secure_and_HttpOnly_cookies

數(shù)據(jù)庫(kù)與sql注入

還能想到什么

凡是在web框架可能實(shí)現(xiàn)的方案，只要對(duì)性能沒有太大的損耗，都應(yīng)該考慮實(shí)施。
spring security為spring mvc的用戶提供了很多安全的功能，比如針對(duì)url的控制訪問。
加密方法、證書支持、openId支持。但是還是缺乏的xss、csrf等問題的解決方案。
在設(shè)計(jì)整體框架安全解決方案時(shí)，比較科學(xué)的方法是建立威脅模型
在設(shè)計(jì)web框架安全解決方案時(shí)，還需要保存好安全檢查日志，比如發(fā)生XSS 攻擊時(shí)，可以記錄下攻擊者的ip、時(shí)間、useragent、目標(biāo)url、用戶名等信息。

web框架的自身安全

關(guān)注業(yè)界前沿?？蚣苈┒础?/p>

##應(yīng)用層拒絕服務(wù)攻擊

PHP安全

Web Server 配置安全

安全開發(fā)流程

安全運(yùn)營(yíng)

修補(bǔ)漏洞流程

安全監(jiān)控

入侵檢測(cè)

緊急響應(yīng)流程

郵件 im 短信

總結(jié)

以上是生活随笔為你收集整理的读白帽子讲WEB安全，摘要的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。