標籤：

web安全怎樣有實踐經驗？

01-23

有意申請百度的安全工程師的實習崗位，裡面有如下要求：

具有以下條件者優先：

-有安全攻防經驗或安全工具經驗優先 ；

-獲安全領域相關比賽獎項、有專業期刊文章或發明專利優先；

-主導/參與國內外知名安全開源項目者優先

完全沒有頭緒，請問非名校大二學生能否參加國內外知名安全開源項目，有什麼安全領域相關比賽

謝謝

我司聯合創始人 肖光宇 的一篇文章：關於Web安全，99%的網站都忽略了這些

寫得很全面，可以了解一下，也可以看看我司官博，還有其他網站安全相關內容：

WildDog Blog

Web安全是一個如何強調都不為過的事情，我們發現國內的眾多網站都沒有實現全站https，對於其他安全策略的實踐更是很少，本文的目的並非討論安全和攻擊的細節，而是從策略的角度引發對安全的思考和重視。

1. 數據通道安全

http協議下的網路連接都是基於明文的，信息很有可能被泄露和篡改，甚至用戶都不知道通信的對方是否就是自己希望連接的伺服器，因此，信息通道安全有以下兩個目標：

  • 身份認證
  • 數據不被泄漏和篡改

幸運的是https解決了上述問題的。

（更多關於https的細節可以看下扒一扒HTTPS網站的內幕）

理論上https是安全的，即使如此，https依然應該被重視，因為理論上理論和實踐是一樣的，但實踐中又是另外一回事。前段時間爆發的心血漏洞就是一個例子。

2. 瀏覽器安全

https解決了點到點的安全問題和身份認證問題，接下來會出現問題的地方就只有2個：瀏覽器和伺服器，這個層面上的安全問題並沒有https一樣的銀色子彈可以一次性解決。

2.1 origin 源

了解瀏覽器安全，有一個概念特別重要，那就是源(origin) 什麼是源呢？

  • 相同的HOST
  • 相同的協議
  • 相同的埠

舉栗子

  • https:// 和 http://非同源，因為協議不同。
  • http://wilddog.com 和 http://www.wilddog.com非同源，因為域名不同。
  • http://wilddog.com 和 http://wilddog.com:8080 非同源，因為埠不同。

源這個概念為甚這麼重要，這要從同源策略說起。

2.2 同源策略

同源策略限制了一個源（origin）中載入文本或腳本與來自其它源（origin）中資源的交互方式。簡單的說就是一個源的頁面上的js只能訪問當前源的資源，不能訪問其他源的資源。

那麼資源是什麼呢？

  • DOM
  • 通過AJAX請求的網路資源
  • Cookie
  • WebStorage，webSql
  • …

很顯然，同源策略以源為單位，把資源天然分隔，保護了用戶的信息安全。

同源策略是一堵牆，然而牆並非不透風。有很多方法可以繞過同源策略讓javascript訪問其他源的資源。比如：

JSONP

基於iframe的方法（iframe+window.name iframe+window.domain iframe+webMessage）

CORS

更多細節可以看下我的另一篇博客跨域資源訪問的幾種方式

其中我認為只有CORS是」正當的」繞過同源策略的方法

同源策略是瀏覽器安全策略的基礎，但同源策略面對很多攻擊是無能為力的，比如XSS

2.3 XSS(Cross-Site Script)

跨站腳本攻擊，名字跟同源策略很像，事實上他們之間基本沒有關係。跨站腳本攻擊本質上是一種注入攻擊（有興趣了解更多注入攻擊可以看這裡）。其原理，簡單的說就是利用各種手段把惡意代碼添加到網頁中，並讓受害者執行這段腳本。XSS的例子只要百度一下有很多。XSS能做用戶使用瀏覽器能做的一切事情。可以看到同源策略無法保證不受XSS攻擊，因為此時攻擊者就在同源之內。

XSS攻擊從攻擊的方式可以分為

  • 反射型
  • 存儲型
  • 文檔型

這種分類方式有些過時，長久以來，人們認為XSS分類有以上三種，但實際情況中經常無法區分，所以更明確的分類方式可以分為以下兩類：

  • client(客戶端型)
  • server(服務端型)

當一端xss代碼是在服務端被插入的，那麼這就是服務端型xss，同理，如果代碼在客戶端插入，就是客戶端型xss。

2.4 防止xss攻擊–轉義

無論是服務端型還是客戶端型xss，攻擊達成需要兩個條件

  • 代碼被注入
  • 代碼被執行

其實只要做好無論任何情況下保證代碼不被執行就能完全杜絕xss攻擊。詳情可以看下這篇文檔

這裡簡單說下結論:

任何時候都不要把不受信任的數據直接插入到dom中的任何位置,一定要做轉義。

2.4.1 對於某些位置,不受信任的數據做轉義就可以保證安全

  • 一般的標籤屬性值
  • div body 的內部html

2.4.2 對於某些位置，即使做了轉義依然不安全

  • &中
  • 注釋中
  • 表簽的屬性名名
  • 標籤名
  • css標籤中

2.4.3 使用JSON.parse 而不是eval,request 的content-type要指定是Content-Type: application/json;

2.4.4 如果鏈接的URL中部分是動態生成的，一定要做轉義。

2.5 HTML轉義：

--&> amp;
&< --&> < &> --&> >
" --&> quot;
" --&> #x27;
/ --&> #x2F;

2.6 使用瀏覽器自帶的xss-filter

現代瀏覽器都對反射型xss有一定的防禦力，其原理是檢查url和dom中元素的相關性。但這並不能完全防止反射型xss。另外，瀏覽器對於存儲型xss並沒有抵抗力，原因很簡單，用戶的需求是多種多樣的。所以，抵禦xss這件事情不能指望瀏覽器。

可以通過http頭控制是否打開 xss-filter,當然默認是打開的.X-XSS-Protection

2.7 CSP(Content Security Policy)

從原理上說防止xss是很簡單的一件事，但實際中，業務代碼非常多樣和複雜，漏洞還是是不是會出現。 CSP 並不是用來防止xss攻擊的，而是最小化xss發生後所造成的傷害。事實上，除了開發者自己做好xss轉義，並沒有別的方法可以防止xss的發生。CSP可以說是html5給web安全帶來的最實惠的東西。。CSP的作用是限制一個頁面的行為不論是否是javacript控制的。如何引入CSP呢？

通過response頭

//只允許腳本從本源載入Content-Security-Policy: script-src 『self』

通過HTML的META標籤

//作用同上&

那麼CSP 除了限制script-src 之外還能限制什麼呢？

base-uri : 限制這篇文檔的uri
child-src ：限制子窗口的源(iframe,彈窗等),取代frame-src
connect-src ：限制腳本可以訪問的源
font-src : 限制字體的源
form-action : 限制表單能夠提交到的源
frame-ancestors : 限制了當前頁面可以被哪些頁面以iframe,frame,object等方式載入
frame-src ：deprecated with child-src,限制了當前頁面可以載入哪些源，與frame-ancestors對應
img-src : 限制圖片可以從哪些源載入
media-src : 限制video, audio, source, track 能夠從哪些源載入
object-src ：限制插件可以從哪些源載入
sandbox ：強制打開沙盒模式

可以看出，CSP是一個強大的策略，幾乎可以限制了所有能夠用到的資源的來源。使用好CSP可以很大成都降低XSS帶來的風險

另外，CSP還提供一個報告的頭 Content-Security-Policy-Report-Only，使用這個頭瀏覽器向伺服器報告csp狀態，細節先不討論。

Content-Security-Policy-Report-Only: script-src "self";
report-uri /csp-report-endpoint/

CSP 目前有兩版，CSP1 和CSP2， 兩版的支持狀態可以在http://caniuse.com/#search=csp 中查到。

CSP1:

CSP2:

2.8 X-Frame-Options

這是response 頭個現在正在使用，但以後可以被CSP的 frame-ancestors取代。目前支持的狀態比起 CSP frame-ancestors要好 使用的方式:

X-Frame-Options:DENY//這個頁面不允許被以frame的方式載入
X-Frame-Options:SAMEORIGIN//這個頁面只允許同源頁面載入
X-Frame-Options:& //這個頁面只能被特定的域載入

2.9 Http-Only

使用http-only 保護cookie，可以保證即使發生了xss，用戶的cookie也是安全的。使用http-only 保護的cookie是不會被javascript讀寫的。

2.10 iframe 沙箱環境

雖然有同源策略，iframe的問題還是有很多的，比如各種利用iframe進行跨源。HTML5為iframe提供了安全屬性 sandbox，如果使用此屬性，iframe的能力將會被限制,細節我們將會在以後的文章中詳細討論。

2.11 其他安全相關的HTTP 頭

X-Content-Type-Options 阻止瀏覽器進行content-type 嗅探。告訴瀏覽器相信此伺服器下發的資源的類型，防止類型嗅探攻擊。

HPKP(Public Key Pinning) Public Key Pinning 是一個response 頭，用來檢測一個證書的公鑰是否發生了改變，防止中間人攻擊。

HSTS (HTTP Strict-Transport-Security) 強制使用TSL作為數據通道。在扒一扒HTTPS網站的內幕中也有詳細介紹

說了這麼多我們看以下一些各個網站實現的情況。

谷歌是行業的標杆，在互聯網無出其右，學習Google就對了！

www.wilddog.com 同樣也實現了幾個重要的http頭。

百度做的就比較差了，一家如此大規模的互聯網公司，對於安全，對於技術如此不敏感，只能說是很悲哀，充分說明中國互聯網企業對安全的重視是非常低的！值得注意的是，百度的http到https的跳轉居然是服務端做的。

3. HTML5 對web安全的影響

html5帶來了很多新的特性，讓瀏覽器和javascript獲得了更大的能力。然而能力越大，被攻破後的危險就越大。

HTML5 對xss的影響主要體現在:

  • 更大的攻擊面，html5帶來來更多的標籤和更多的屬性，xss發生的可能性更大
  • 更大的危害，HTML5更多的資源可以被xss利用。黑客可以利用瀏覽器的一切許可權，比如本地存儲，GEO，WebSocket，Webworker。

遺憾的是HTML並沒有針止XSS和XSRF帶來系統性解決方案。在這個前提下，CSP變得非常重要，可以大大降低XSS後的危害。

HTML5時代實際對開發者提出來更高的要求，因為有更多的交互，更多的前端行為，HTML5有更多的API。希望共勉，不做蒙古大夫，與廣大的開發者一同提高中國互聯網的用戶體驗！

關於作者：Sigularity

4. references

安全相關的HTTP頭

同源策略

CSP

HPKP

w3c iframe element

MDN web security

XSS cheet sheet

題主，我覺得這個回答非常適合你

web安全滲透方面的學習路線? - 滲透測試

推薦知道創宇技能表 http://blog.knownsec.com/Knownsec_RD_Checklist/v2.2.html

最後講一句，其實你在知乎搭配一下關鍵詞能出來很多合適的結果。

另外，去這兒玩兒吧

NaviSec.it

多關注烏雲的一些案例，不同的時間段會有一些比較典型的普遍漏洞，接觸的多了，自己可以去找找，慢慢就會積累一些經驗！多烏雲，多機會！

建議可以看一下淺談滲透實戰中的一些經驗 - 知乎專欄 這篇文章。希望對你有好處。

推薦閱讀：

※Web 安全是建立在內核等技術的基礎上的，所以 Web 安全相對低級？

TAG:網路安全 | 實習申請 | Web安全測試 | 滲透測試 |