它曾是世界性圖書館夢的開始,現在它是全球知識的聚集地,它是目前最流行的,人們将應用都部署之上的網際網路。
它是靈活的代表,它不是單一的實體,它由用戶端和服務端組成,它的功能在不斷地強大,它還有标準。
雖然越來越多的解決方案非常适用于發現什麼可行,什麼不可行,但它幾乎沒有一緻性,沒有易于應用的程式設計模型。俗話說的好:事情越簡單,越安全。簡單的事物很難有像XSS,CSRF或點選挾持的漏洞。
由于HTTP是一個可擴充的協定,各浏覽器廠商都率先推出了有效的頭部,來阻止漏洞利用或提高利用漏洞的難度。了解它們是什麼,掌握如何應用,可以提高系統的安全性。
1. Content-Security-Policy
它怎麼就那麼好?
怎麼才能盡可能不遭受XSS攻擊呢?如果有人在你的伺服器上寫了如下代碼浏覽器可能不去解析?<script>alert(1);</script>,
下面是内容安全規範中的說明。
添加内容安全規範頭部并賦以适當的值,可以限制下面屬性的來源:
- script-src: JavaScript code (biggest reason to use this header)
- connect-src: XMLHttpRequest, WebSockets, and EventSource.
- font-src: fonts
- frame-src: frame ulrs
- img-src: images
- media-src: audio & video
- object-src: Flash (and other plugins)
- style-src: CSS
需要特别指定的:
- Content-Security-Policy: script-src 'self' https://apis.google.com
這就意味着腳本檔案隻能來自目前檔案或apis.google.com(谷歌的JavaScript CDN)
另一個有用的特性就是你可以自動應用
沙盒模式于整個站點。如果你想試一試效果,你可以用“Content-Security-Policy-Report-Only”頭部運作一下,讓浏覽器傳回一個你選的URL。推薦閱讀一下
HTML5Rocks上的一篇CSP的介紹。
有什麼收獲?
遺憾的是IE還是隻支援沙盒模式,并且用的是“X”字首。安安卓它支援最新的4.4版。
當然,它也不是萬能的,如果你動态的産生一個JavaScript,黑客還是能把惡意JS植入你的伺服器中。包含它不會産生危害,在Chrome、 Firefox 和 iOS都能保護使用者。
支援哪些浏覽器?
Unnamed QQ Screenshot20140225201216
在哪還能學到更多它的知識呢?
HTML5Rocks有不錯的關于它的介紹。
W3C規範也是個不錯的選擇。
2. X-Frame-Options
它有什麼好的呢?
它能阻止點選挾持攻擊,隻需一句:
X-Frame-Options: DENY
這可使浏覽器拒絕請求該頁的資料。 它的值還有“SAMEORIGIN”,可允許同一源的資料。以及“ALLOW FROM
http://url-here.example.com”,它可設定源(IE不支援)。
一些廠商不支援這個頭部,它可能會被整合到Content-Security-Policy 1.1。但到目前,沒人給出足夠的理由說不能使用它。
哪些浏覽器支援?
IE | Firefox | Chrome | iOS Safari | Android Browser |
8+ | 3.6.9+ | 4.1.249+ | ? |
(資料來源
Mozilla Developer Network)
沒有多少要學,想了解更多,可通路
上關于此問題的文章。
Coding Horror上也有比較不錯的文章。
3. X-Content-Type-Options
讓使用者上傳檔案具有危險性
,服務上傳的檔案危險更大,而且很難獲得權限。
浏覽器進行二次猜測服務的Content-Type并不容易,即使内容是通過MIME嗅探擷取的。
X-Content-Type-Options頭允許你更有效的告知浏覽器你知道你在做什麼,當它的值為“nosniff”是才表明Content-Type是正确的。
GitHub上應用了這一頭部,你也可以試試。
雖然這取決于你使用者,他們占你正保護的訪客的65%,但這個頭部隻在IE和Chrome中有用。
- (bug 471020) | 1+ | - |
FOX IT上有一篇關于MIME嗅探的優秀文章:
MIME 嗅探: 特性還是漏洞?IT Security Stackexchange上也有個專題:
X-Content-Type-Options真能防止内容嗅探攻擊嗎?4. Strict-Transport-Security
我的線上銀行使用的是HTTPS來保證真實性(我确實連接配接到了自己的銀行)及安全性(傳輸過程進行加密)的。然而,這還是有問題的…
當我在位址欄中輸入”onlinebanking.example.com”時,預設使用的是簡單的HTTP。隻有當伺服器重定向到使用者時,才使用能提供安全的HTTPS(
理論上并不安全,但實際上很好用)。偏巧的是重定向的過程會給黑客提供中間人攻擊。為了解決這一問題,Strict-Transport-Security頭部應運而生。
HTTP的Strict-Transport-Security(HSTS)頭部強制浏覽器使用HTTPS在指定的時候。比如說,如果你進入
https://hsts.example.com,它會傳回這樣的頭部:
Strict-Transport-Security: max-age=31536000; includeSubDomains
即使敲入
http://hsts.example.com,浏覽器也會自動變成
. 隻要HSTS頭部一直有效,浏覽器就會預設這麼做。在上例的情況下,從發送頭部到得到響應,有效性可保持1年。是以,如果我2013年1月1日通路了某網站,知道2014年1月1日,浏覽器都會使用HTTPS。但如果我2013年12月31日又通路了一次,那有效期也會變成2014年12月31日。
目前它僅适用于Chrome和Firefox,IE使用者依然存在此漏洞。然而它已經成為了IETF的标準,是以說接下IE應該盡快地也使用Strict-Transport-Security頭部。
當然如果使用了HTTPS,就可不必使用此頭部了,是以說為什麼不用HTTPS呢?切記HTTPS不僅能保證你的内容被加密、不被攔截,還能提供真實性。向使用者承諾内容的确來自你。
使用HTTPS還存在着
不同的争論,事實上,部落格和這個頭部都不是基于HTTPS的,是以争論還會持續很久。
Mozilla Developer Network上有一篇不錯的文章:
HTTP的 Strict Transport Security頭部如果你正在進行Symfony2或Drupal開發
了解更多 Symfony2可以看
Nelmio安全包,而
Drupal 在安全元件子產品有詳細說明。閱讀它們可以使你更了解上述介紹的頭部。
殇之館: X-Requested-With
預設情況下jQuery 發送X-Requested-With頭。它認為這個頭部可以預防僞造跨站請求。然而這個頭部不會産生請求,一個使用者會話可由第三方發起,比如在浏覽器中XMLHttpRequest就可以自定義頭部。
不幸的是,
Ruby On Rails 的Ruby架構和
Django Python架構的快速建立,雖然這能成為很好的防禦手段,但它可以不完全依賴于像Java或Adobe Flash第三方插件了。
總結
使用以上HTTP頭部可幫你快速容易地預防XSS攻擊、點選挾持攻擊、MIME嗅探和中間人攻擊。如果目前還沒使用,通過介紹給你,你可以在你的應用或伺服器上使用。
請確定使用者的安全性。