當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

读白帽子讲WEB安全，摘要

發布時間：2024/1/8 编程问答 32 豆豆

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

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

文章目錄

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

我的安全世界觀

安全三要素-CIA

機密性 Confidentiality

數據不被泄漏
- 加密

完整性 Integrity

保護數據內容完整的、沒有被篡改
- 數字簽名

可用性 Availability

DOS-Denial Of Service 攻擊會破壞可用性

拓展：可審計性、不可抵賴性

如何實施安全評估

互聯網安全的核心問題，是數據安全的問題。

資產等級劃分

了解公司最重要的資產是什么，他們最看重的數據是什么。通過訪談的形式，安全部門才能熟悉、了解公司的業務，公司所擁有的數據，以及不同數據的重要程度，為后續的安全評估過程指明方向

信任域和信任邊界,網絡邏輯上來劃分。比如最重要的數據放在數據庫里，那么把數據庫的服務器圈起來； Web 應用可以從數據庫中讀/寫數據，并對外提供服務，那再把 Web 服務器圈起來；最外面是不可信任的 Internet

威脅分析

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

可能會出現的損失稱為風險（Risk）

威脅建模

什么是威脅分析？威脅分析就是把所有的威脅都找出來。怎么找？一般是采用頭腦風暴法。當然，也有一些比較科學的方法，比如使用一個模型，幫助我們去想，在哪些方面有可能會存在威脅，這個過程能夠避免遺漏，這就是威脅建模。

STRIDE 模型

威脅定義對應的安全屬性

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

風險分析

我們判斷風險高低的過程，就是風險分析的過程 .

風險由以下因素組成：

Risk = Probability * Damage Potential
- DREAD 模型

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

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

確認解決方案
安全評估的產出物，就是安全解決方案。
設計解決方案不難，難的是如何設計一個好的解決方案。設計一個好的解決方案，是真正考驗安全工程師水平的時候。很多人認為，安全和業務是沖突的，因為往往為了安全，要犧牲業務的一些易用性或者性能，筆者不太贊同這種觀點。從產品的角度來說，安全也應該是產品的一種屬性。一個從未考慮過安全的產品，至少是不完整的。
沒有不安全的業務，只有不安全的實現方式。
安全方案必須能夠有效抵抗威脅，但同時不能過多干涉正常的業務流程，在性能上也不能拖后腿。
，一個優秀的安全方案應該具備以下特點：
能夠有效解決問題；
用戶體驗好；
高性能；
低耦合；
易于擴展與升級

白帽子兵法

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

不同的層面、不同的角度對系統做出整體的解決方案。

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

在常見的入侵案例中，大多數是利用 Web 應用的漏洞，攻擊者先獲得一個低權限的 webshell，然后通過低權限的 webshell 上傳更多的文件，并嘗試執行更高權限的系統命令，嘗試在服務器上提升權限為 root；接下來攻擊者再進一步嘗試滲透內網，比如數據庫服務器所在的網段。

Web 應用安全、 OS 系統安全、數據庫安全、網絡環境安全等。在這些不同層面設計的安全方案，將共同組成整個防御體系，這也就是縱深防御的思想。

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

這一原則廣泛適用于各種由于“注入”而引發安全問題的場景。

實際上，緩沖區溢出，也可以認為是程序違背了這一原則的后果——程序在棧或者堆中，將用戶數據當做代碼執行，混淆了代碼與數據的邊界，從而導致安全問題的發生。

在 Web 安全中，由“注入”引起的問題比比皆是，如 XSS、 SQL Injection、 CRLF Injection、 X-Path Injection 等。此類問題均可以根據“數據與代碼分離原則”設計出真正安全的解決方案，因為這個原則抓住了漏洞形成的本質原因。
不可預測性原則

不可預測性原則，可以巧妙地用在一些敏感數據上。比如在 CSRF 的防御技術中，通常會使用一個 token 來進行有效防御。這個 token 能成功防御 CSRF，就是因為攻擊者在實施 CSRF 攻擊的過程中，是無法提前預知這個 token 值的，因此要求 token 足夠復雜時，不能被攻擊者猜測到。
客戶端安全

瀏覽器安全

同源策略

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

瀏覽器只是同源策略的一種實現。

瀏覽器的同源策略，限制了來自不同源的"document" 或腳本，對當前的“document ”讀取或者設置某些屬性。

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

但瀏覽器中

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

隨著業務的發展，跨域請求越來越迫切。因此W3C委員會制定了XMLHttpRequest跨域訪問的要求，他需要通過目標域返回的HTTP頭來授權是否允許跨域訪問，因為http頭對于javascript來說一般是無法控制的，所以這個方案是可以實施的，這個跨域方案的安全基礎:javaScript 無法控制該Http頭。如果信任基礎被打破。則此方案將不在安全。

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

瀏覽器沙箱

采用sandbox技術，讓不受信任的腳本允許在一個受限制的環境中，從而可以保證本地桌面系統的安全。

惡意網址攔截

掛馬攻擊是在正常的網頁中，通過 script 或 iframe 等標簽加載惡意的網址。

釣魚網站、詐騙網站對用戶來說也是一種惡意網址。

惡意網址的攔截非常簡單，定期從服務器端獲取一份最新的惡意網址清單。用戶在瀏覽惡意網站時會彈出警告。

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

高速發展的瀏覽器安全

IE 推出Xss filter

firefox 推出的csp

XSS 跨站腳本攻擊

XSS簡介

XSS = cross site script

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

XSS 攻擊進階

初探XSS Payload

從攻擊者的角度來體驗下XSS的威力。

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

常見的payload就是cookie劫持。

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

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

強大的xss payload

構造GET和POST請求。

一個網站只接受http協議中的get和post請求，對攻擊者來說，只通過JavaScript就可以讓瀏覽器發送此請求。

此不需要劫持用戶的cookie，只要構造網站的現有get或post方法。即可控制客戶的瀏覽器。

XSS釣魚
xss的攻擊過程都是JavaScript自動進行的，也就是說缺少交互過程。

如果在構造post請求是，加上驗證碼，但也不能徹底防止。

攻擊者：對于驗證碼可以把驗證碼圖片發送到攻擊者后臺識別。
此外在大多數修改密碼的功能會要求輸入舊密碼。但是這也不能防止xss payload。

修改密碼問題稍微復雜，需要將XSS與"釣魚"相結合。

實現思路：使用javascript在當前頁面上"畫出"一個偽造的登陸框，當用戶在登錄框輸入用戶名與密碼，將密碼發送至黑客的服務器上。

識別用戶瀏覽器
識別用戶安裝的軟件

CSS history hack

利用style的visited屬性，如果用戶曾經訪問過某個鏈接，那么這個鏈接的顏色會變的與眾不同。

獲取用戶的真實IP

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

XSS 攻擊平臺

attach api
BeEF
XSS-Proxy

終極武器 XSS Worm

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

調試JavaScript

firebug
ie 8 developer tools
fiddler
httpwatch

XSS構造技巧

利用字符編碼
繞過長度限制。

利用事件，加載location.hash的值
利用注釋，合并2個input標簽

使用base標簽。在設計XSS 安全方案時一定要過濾這個非常危險的標簽
window.name 的妙用。

window 對象時瀏覽器窗體

變廢為寶 Mission Impossible

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

XSS 防御

XSS的本質是HTML注入。將用戶的數據當作代碼執行。

HttpOnly

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

服務器可以設置多個cookie，可以給制定的cookie設置HttpOnly。

setHeader

(

"Set-Cookie"

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

)

;

輸入檢查

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

對 script 和 javascript onclick alert 等以下關鍵字處理。

輸出檢查

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

安全的編碼函數

編碼分為很多種，針對html代碼的編碼方式是HtmlEncode。HtmlEncode不是專有名字，是一種函數的實現。作用就是將字符轉換成HTMLEntries，對應的標準是ISO-8859-1。

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

正確的防御XSS攻擊

處理富文本

防御 DOM Base XSS

CSFR跨站請求偽造

cross site request forgery

CSRF 進階

瀏覽器的cookie策略

cookie分為：

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

出于安全考慮，IE默認禁止了瀏覽器在<img>、<iframe>、<script>、<link>等標簽發送第三方cookie。

Firefox chrome 默認會發送第三方cookie。

P3P

the platform for privacy preferences

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

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

在網站業務中，P3P頭主要用于類似廣告的等需要跨域的訪問頁面。但遺憾的是P3P頭設置后，對cookie的影響到了整個域的頁面，因為cookie是以域和path為單位的。這并不符合“最小權限”原則。

cookie是以域和path為單位的

誘導用戶訪問惡意鏈接?？烧{用系統的現有的接口，導致出現一些客戶不知情的操作。

get or post

get和post都能發起csrf攻擊。

Flash CSRF

IE6 IE7，flash發送的網絡請求可以帶上本地cookie，從ie8起，flash發起的網絡請求不再發送本地cookie。

CSRF worm

CSRF防御

驗證碼
Referer check

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

常見的互聯網應用，頁面與頁面之間都具有邏輯關系，這使得每個正常的請求Referer具有一定的規律。

缺陷：服務器并非任何時候都能獲取Referer。
refer policy說明

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

Anti CSRF Token

CSRF 為什么能成功，因為重要操作的所有參數是可以被攻擊者猜測到的。

新增一個參數Token，token是安全的隨機數生成算法。

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

還有一些XSS漏洞或者跨域漏洞可能讓攻擊者竊取到Token值。
Token 僅僅是用于對抗CSRF攻擊，當網站還有其他XSS漏洞時，這個方案會變得無效。因為XSS可以模擬客戶端瀏覽器執行任意操作。攻擊者完全可以請求頁面后，讀出頁面token的值，然后再構造一個合法的請求，這個過程可以稱為 XSRF和CSRF區分開。

點擊劫持

ClickJacking

點擊劫持是一種視覺上的欺騙。往往使用透明的iframe嵌入目標網站。欺騙目標網站用戶，竊取客戶信息。

flash點擊劫持:

圖片覆蓋攻擊

拖拽劫持和數據竊取

觸屏劫持

智能終端上的觸屏劫持

防御點擊劫持

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

frame busting

是指利用js判斷location以防止網頁被別人iframe內嵌的一個實現

比如以下代碼:

(

)

{

;

}

常見的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 條件判斷為真，常見的動為以下：

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（不能針對 top.location，只能針對 parent.location）
利用 onbeforeunload 事件
xss
構造referer繞過js referer檢查
瀏覽器漏洞。
iframe security屬性（僅IE支持）
iframe sandbox屬性（HTML5）
瀏覽器designmode
部分手機站點

相關總結：

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

X-Frame-Options

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

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

HTML5安全

html新標簽的xss

可嵌入javascript實現xss攻擊。

有研究者建立了一個html5 security cheatsheet項目。

iframe 的sandbox屬性

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

link types ： noreferer

html5的標簽可以指定noreferer，瀏覽器在請求該標簽指定的地址時不再發送Referer.

這是出于保護敏感信息和隱私的考慮，因為通過referer可能會泄露一些敏感數據。

canvas的妙用

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

其他安全問題

cross-origin resource sharing CORS

瀏覽器的同源策略 same origin policy 限制了腳本的跨域請求。互聯網的趨勢越來越開放?？缬蛟L問需要越來越急迫。出現很多跨域的技術 jsonp 、iframe 等。

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

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

postMessage 跨窗口傳遞消息

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

服務器端應用安全

注入攻擊

注入攻擊的本質是將用戶的數據當作代碼來執行。
兩個關鍵條件

用戶能控制輸入
2.程序原本要執行的代碼，拼接了用戶輸入的數據。

sql注入

盲注
timing attack

數據庫攻擊技巧

數據庫防御

找到所有的sql注入漏洞
修補這些漏洞

使用預編譯語句
使用存儲過程
檢查數據類型

嚴格過濾檢查用戶的輸入數據。

使用安全函數

其他注入

xml注入

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

代碼注入
CRLF 注入

cr = carriage return
lf = lind feed

文件上傳文件

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

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

功能還是漏洞

apache 文件解析問題
apache 1.x 2.x 對于不認識的文件按照php文件處理。

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

釣魚網站在傳播的時候，會通過利用xss，服務端的302跳轉等功能，從正常網站跳轉到釣魚網站。

設置安全的文件上傳功能

1.文件上傳的目錄設置為不可執行
2.判斷文件類型
3.使用隨機數改寫文件名稱和路徑
4.單獨設置文件服務器域名

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

認證和會話管理

認證目的是認出用戶是誰。就是認證用戶憑證的過程。

而授權的目的是為了決定用戶能夠做什么。

密碼那些事兒

密碼必須是不可逆加密算法或者單向散列算法，加密后存儲在數據庫中的，sha-1 、md5 存儲。
多因素認證，以支付寶為例，支付密碼，安全問題，實名認證，短信驗證，證書等等。

session 與認證

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

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

session fixation 攻擊

登錄后需要重寫sessionId。

session保持攻擊

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

sso 單點登錄 single sign on

訪問控制

what can i do ?

某個主體 subject能對某個個體 object 需要實施某種操作

垂直權限管理

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

水平越權管理

可稱之為基于數據的訪問控制

加密算法與隨機數

Web框架安全

mvc 框架安全

view 負責用戶視圖、頁面展示工作
control 負責用戶邏輯的實現，接受view傳送的數據，并轉發給model處理
model model負責數據處理。

web框架與csrf 策略

模板引擎與xss防御

post請求添加token

session 綁定token
form 表單自動添加token
ajax請求中自動添加token
在服務器端對比post參數的token與session的token是否一致

http header 的管理

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

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

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

類似針對30X返回號的http response ,瀏覽器將會跳轉到location制定的url，攻擊者往往利用此類功能實施釣魚和咋騙。

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

管理好跳轉地址很重要

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

數據庫與sql注入

還能想到什么

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

web框架的自身安全

關注業界前沿。框架漏洞。

##應用層拒絕服務攻擊

PHP安全

Web Server 配置安全

安全開發流程

安全運營

修補漏洞流程

安全監控

入侵檢測

緊急響應流程

郵件 im 短信

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。