安全測試

1.安全測試在作什麼？
掃描？在不少人的眼中，作安全的就是成天拿個工具在哪裏作掃描操做，使用各類不一樣的工具作掃描。是的，掃描是安全測試的很重要的一部分，掃描能夠快速有效的發現問題。掃描工具的易用性、方便性決定了重要地位。可是掃描工具的侷限性、程序的不夠靈活等缺點也是顯而易見的。無論是掃描報告的分析、漏洞的深度挖掘、測試的組織等等的工做都離不開安全測試人員，因此只能說掃描工具減輕了測試人員的工做量，是安全測試的一種手段。
2.安全測試者是怎樣定位本身的？
咱們常常能夠從身邊的朋友口中聽到一些有關安全的名稱，向什麼軟件安全、信息安全、網絡安全、計算機安全等一些詞組，這些領域都是作安全的，那麼咱們是屬於哪個呢？
你們能夠上百度百科查看下這些詞組的概念。軟件安全往小了說就是某一個軟件產品，說大了除了硬件就是軟件了啊。信息安全看名字咱們就知道關鍵是信息兩個字，可是什麼是信息呢，客戶的數據仍是一切有用的數據？網絡安全，什麼是網絡，網絡系統硬件、軟件這都是寫模糊的可大可小的概念。在看計算機安全，PC？服務器？路由器？好吧咱們能夠看到這些概念往大了說就成了組成咱們今天互聯網的各類設備包括各類的嵌入式機器、外接USB、浴室櫃尺寸價格專賣藍牙等設備的共同體的硬軟件，以及使用、維護、木桶箱子專賣廠家價格管理等這些東西的人的整個的安全問題。在看他們的區別，他們已不一樣的地方做爲其主要關注點，或者說出發點，他們並無明顯的界線卻有着本身的側重點。而咱們的側重點是什麼呢，咱們產品是一個什麼樣的產品呢？咱們有WEB服務、接口服務、文件服務、視屏等服務等咱們把它們統一稱爲咱們的系統，那麼咱們就是在作這個系統的安全測試，因此我以爲咱們應該定位爲系統安全測試。
固然咱們的系統運行中也涉及到人、涉及到硬件，

好比這些站安全比較好

 

 

此處都不是咱們的關注點，咱們只從軟件技術的角度來識別它。那麼，系統安全測試就成了區別於功能測試，和性能測試同樣，單獨列出來的專項測試了。

3.安全的本質是什麼？
信任、人性（網絡安全的最大漏洞是人）、止損、攻防
以上是當前網上一些主要的論點，以信任或者不信任做爲本質出發點的仍是佔據主流的。
4.概念定義
敏感數據：
敏感數據的具體範圍取決於產品具體的應用場景，產品應根據風險進行分析和判斷。典型的敏感數據包括口令、銀行賬號、大批量我的數據、用戶通訊內容和密鑰等。
我的數據：
指直接經過該數據或者結合該數據與其餘的信息，能夠識別出天然人的信息。
匿名化：
指對我的數據進行的更改（例如單向散列、截短、替換等，如需保留我的數據真實值與替換值之間的對應關係，可使用對稱加密或映射表方式，但密鑰/映射表必須由數據全部者控制），使原來有關我的的信息再也不能歸屬到一個可識別的天然人，或推理這種歸屬須要耗費過多、不相稱的時間、費用和精力

5.咱們應該如何去着手
如何着手去作這個系統安全測試呢？做爲一個測試人員要保證系統總體的安全，這就須要有一個總體的結構的框架，就像蓋房子同樣，先造鋼筋混凝土框架，而後磚塊去填充它。這裏的鋼筋混凝土框架就是安全特性方向，其實就是從總體方向上的一個劃分，能夠有以下簡單的劃分。
5.1.測試的特性
安全特性：操做系統安全、數據庫安全、WEB安全、軟件的發佈和安裝安全、協議與接口攻防、敏感數據保護、手機端安全、靜態代碼分析。
5.1.1.操做系統安全
操做系統安全咱們能夠把它分爲如下幾塊：
系統漏洞（操做系統補丁）、系統配置（安全加固）
業界權威工具Nessus，其餘如retina、綠盟、天鏡等。開源的工具可使用OpenVAS。
5.1.2.數據庫
數據庫安全咱們能夠把它分爲如下幾塊：
數據庫漏洞（補丁）、數據庫配置特產（安全加固）
工具可使用Ngs
5.1.3.web安全
數據庫安全咱們能夠把它分爲如下幾塊：
身份驗證、驗證碼、會話管理、權限管理、敏感信息傳輸、安全審計、信息泄露、輸入校驗、輸出編碼、上傳下載、異常處理、註釋代碼等
容器的安全（tomcat）
應用軟件安全（nginx、負載均衡軟件、jquery等）
掃描工：appScan、awvs
5.1.4.軟件的發佈與安裝安全
發佈件的完整性校驗（簽名、哈希）
防病毒：須要安裝的軟件須要通過經常使用的殺毒軟件（如360、卡巴斯基、金山毒霸等）的掃描，保證沒有病毒特種碼，以避免被殺軟處理掉。
5.1.5.協議與接口攻防
業務交互數據在網絡中使用的協議安全性測試
協議測試工具：codenomical
對外開放的端口:系統對外開放的端口必須是必須的，禁止開放無用端口
端口掃描工具：Nmap，近端能夠直接在服務器上使用命令查看
接口：接口接受的數據須要作嚴格的處理
接口數據嚴格校驗測試
5.1.6.敏感數據保護
識別敏感數據：密碼、祕鑰、會話標識；我的信息、商業機密、客戶信息等
保護：加密、存儲位置、傳輸方式；獲取數據脫敏、匿名化

5.1.7.手機端安全
一、app的簽名、反逆向
二、用戶隱私
三、文件權限
四、網絡通信
五、運行時解釋保護
六、組件權限保護
七、升級
八、3rd庫

移動APP測試要點：http://blog.nsfocus.net/mobile-app-security-security-test/
5.1.8.靜態代碼分析（純白盒）
白盒測試主要是經過對代碼的瀏覽來發現問題，固然問題的類型多是跟咱們黑灰盒總結的一致，拿出來單獨講是由於其不一樣於其餘的測試方式。
一、危險函數、方法
二、工具檢測
三、邏輯漏洞

灰盒
結合白盒和黑盒的一些思路，在實際的代碼審計中建議採用灰盒的方式，在須要的地方對代碼進行動態調試查看。審計中思路能夠考慮以下這些部分：
一、涉及敏感數據的時候，檢查是get、post哪一種形式發送數據
Get傳輸的數據會被記錄在代理、瀏覽器、web容器tomcat等的日誌中
二、提交銘感數據的時候是否有防止csrf的token、refer、驗證碼等
三、sql注入
1）Statement和preparestatement
2）mybitas框架 #和$
四、XSS
咱們用的antisamy只能過濾基於標籤的XSS僞造，其餘的沒法過濾，須要作二次過濾
五、邏輯
此處是指，邏輯思路不合理，不符合安全的一些思想，如權限最小化等等
六、參數範圍是否形成dos或者影響系統性能
七、權限校驗、越權
1)橫、縱、多步驟關聯性
2）
八、session會話管理
1）常規cookie及session形式
2）把token做爲session的形式，特別注入登陸用戶和token的綁定關係
九、參數是不是簡單形式，是否能夠形成遍歷
十、代碼中使用的第三方插件、開源軟件是不是最新、是否有安全漏洞
十一、代碼中所使用的加密算法，是不是安全的
十二、跳轉中的redirect形式中不要帶敏感信息，會被髮回客戶端從新請求的，至關於把這些參數放在了get請求中
1三、SSRF服務端請求僞造，注意url中含有另一個url的請求
1）源碼中使用urlconnection 支持的協議除了http和https之外，還有file、ftp、jar、mailto等
request、httpurlconnecttion、httpClient、URL等發起網絡請求
1四、加密算法的使用，是否使用的是不合場景的弱算法

1五、數據插入自增Id攻擊
數據傳入過來作插入動做，而且使用spring自動綁定對象方法獲取數據，以後使用生成的插入sql
此時自動增加id不要寫到更新語句中，若是寫入可能形成惡意注入integer範圍最大值2147483647，使功能不可用dos
1六、Spring自動綁定參數，參數擴展攻擊
後臺使用的對象參數自動綁定獲取，相應的sql使用了自動的if是否爲null和爲空的判斷條件，前臺能夠根據猜想
注入隊形的相應的屬性實現非預料結果
5.2.WEB安全測試
5.2.1.身份驗證 
爲防止密碼破解和猜想：
複雜度要求，必須由大寫、小寫、數字等組成；
時效性要求，建議用戶3個月更改一次口令；
密碼長度要求，最小8位，最大？位；
管理員重置密碼後密碼必須在下次登陸更改；
強度要求，不能跟原密碼一致，不能與用戶名類似（如，不能包含用戶名正寫反寫大小寫等），
（最新也有說法不建議頻繁修改http://www.secdoctor.cn/html/sec/35995.html）
口令認證必須在服務端進行。
必需要有驗證碼機制。
登陸鎖定，登陸須要有鎖定機制即就是屢次登陸失敗後鎖定帳號或者ip，在一段時間後自動解鎖。
手機驗證碼轟炸
手機驗證碼超時機制
帳戶枚舉測試

弱密碼概念：https://help.aliyun.com/knowledge_detail/37509.html?spm=5176.7837442.2.5.ZotsLv
5.2.2.驗證碼 （普通驗證碼、知識驗證碼、無需思考的滑動驗證碼）
驗證碼字符生成算法的安全隨機數
驗證碼字符不能被驗證碼識別工具識別
驗證碼必須是一次性的
驗證碼超時（驗證碼有效期的意義：一、增長圖片處理識別的難度；二、驗證碼沒有有效期的話致使服務器驗證碼堆積）
在忘記密碼處作安全問答測試

 

建議的驗證碼形式：
當前的最流行的滑動塊驗證碼，有點用戶無需動腦，不會打斷用戶的思考。
（驗證碼的前世此生：http://www.freebuf.com/articles/web/102276.html）

5.2.3.會話管理 
登陸先後會話標示要有變化
安全退出會話標示註銷
會話標示安全隨機
會話標示的長度適度
會話超時機制
會話標識的傳輸和存儲
會話標識誇PC訪問
5.2.4.權限管理 
經過灰化（隱藏）使功能失效
縱向越權
橫向越權
權限分離
（系統管理、安全管理、審計管理
系統管理員主要負責用戶管理和系統平常運做相關的維護工做；
安全管理員負責安全策略的配置和系統資源安全屬性的設定；
審計管理員則對系統審計信息進行管理）
參看《關於越權》

5.2.5.敏感信息傳輸及存儲 
敏感信息不能以get方式提交
傳輸通道使用https（關鍵數據提交服務端不接收http明文數據）
嚴格安全傳輸HSTS（確保從瀏覽器發出的請求就是https的）
在url中有session
對用戶保密的信息不能傳輸到客戶端
含有敏感信息的頁面須要設置不緩存
5.2.6.安全審計 
登陸、退出、操做等都要有日誌
日誌格式標準（時間、誰、作了什麼操做、結果怎樣）
日誌訪問的限制
日誌中的敏感信息

他們是如何迭代的？日誌是否保存足夠長的時間？
日誌是如何被審查的？管理員可否經過審查出發現攻擊行爲？
日誌備份如何保存？
日誌記錄數據前是否進行驗證（最小最大長度，字符等）？
5.2.7.信息泄露 
數據庫版本泄露 
容器版本泄露
絕對路徑泄露
異常信息泄露
泄露服務器路徑
泄露容器版本
泄露程序詳細堆棧信息
源代碼泄露
檢測Web網絡是否存在源代碼泄露漏洞，若是存在此漏洞，攻擊者可直接下載網站的源代碼。
管理地址泄露
網站管理地址屬於內部使用的信息，公開增長了安全風險。
Bak信息泄露
搜索引擎發現和偵察信息泄露（暫時不涉及）
服務器指紋探測（使用指紋探測工具whatweb須要在linux上編譯運行，httprint--最新的signatures.txt否則識別到不許確）

【其餘關注項：】
枚舉web服務器上存在的應用程序
Whois信息收集
識別Web應用框架
Owasp測試指南4中文：https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/zh/web_application_security_testing/review_webserver_metafiles_for_information_leakage_otg-info-003.html
拖庫撞庫http://blog.nsfocus.net/information-leakage-thinking-library-collision/
5.2.8.輸入校驗
前臺後臺都必須校驗（「移除已知的惡意數據」不如移除「良好數據以外的全部數據」）
5.2.8.1.XSS（跨站點腳本攻擊）
XSS-1反射型跨站點腳本編制
XSS-2存儲型跨站點腳本編制（http://xxxxx0000sssss.lofter.com/post/14b1dc_50023e）
XSS-3 DOM型跨站點腳本編制
dom xss並不複雜，他也屬於反射型xss的一種，domxss取決於輸出位置，並不取決於輸出環境，所以domxss既有多是反射型的，也有多是存儲型的)，簡單去理解就是由於他輸出點在DOM，因此在道哥的《白帽子講Web安全裏》也有詳細介紹。dom - xss是經過url傳入參數去控制觸發的。
HPP（HTTP參數污染[同名參數]http://blog.csdn.net/eatmilkboy/article/details/6761407）
漏洞危害： 
一、釣魚欺騙：最典型的就是利用目標網站的反射型跨站腳本漏洞將目標網站重定向到釣魚網站，或者注入釣魚JavaScript以監控目標網站的表單輸入，甚至發起基於DHTML更高級的釣魚攻擊方式。
二、網站掛馬：跨站時利用IFrame嵌入隱藏的惡意網站或者將被攻擊者定向到惡意網站上，或者彈出惡意網站窗口等方式均可以進行掛馬攻擊。
三、身份盜用：Cookie是用戶對於特定網站的身份驗證標誌，XSS能夠盜取到用戶的Cookie，從而利用該Cookie盜取用戶對該網站的操做權限。若是一個網站管理員用戶Cookie被竊取，將會對網站引起巨大的危害。
四、盜取網站用戶信息：當可以竊取到用戶Cookie從而獲取到用戶身份使，攻擊者能夠獲取到用戶對網站的操做權限，從而查看用戶隱私信息。
五、垃圾信息發送：好比在SNS社區中，利用XSS漏洞借用被攻擊者的身份發送大量的垃圾信息給特定的目標羣。
六、劫持用戶Web行爲：一些高級的XSS攻擊甚至能夠劫持用戶的Web行爲，監視用戶的瀏覽歷史，發送與接收的數據等等。
七、XSS蠕蟲：XSS 蠕蟲能夠用來打廣告、刷流量、掛馬、惡做劇、破壞網上數據、實施DDoS攻擊等。
參考：
https://help.aliyun.com/knowledge_detail/37444.html?spm=5176.7837442.2.11.F8ceHg
http://blog.csdn.net/change518/article/details/51024706 隱藏域XSS（藉助accesskey屬性）
5.2.8.2.SQL注入
(一、java預處理preparestatement；二、正則表達式過濾參數；三、嚴格字符串過濾；四、參數化的sql)
例子：參數date=if(now()=sysdate(),sleep(0),0)/*'XOR(if(now()=sysdate(),sleep(0),0))OR'"XOR(if(now()=sysdate(),sleep(0),0))OR"*/
Sql語句中的/斜槓：表示執行，把以前時間內的緩存中的語句再執行一遍
\斜槓：表示語句未完換行
單行註釋：--
多行註釋：/* */
If(now()=sysdate(),sleep(2),0)表示若是now()=sysdate(),爲真執行sleep(2),不然執行0
當前形勢下，新開發的網站，大部分採用新框架都已經能夠預防sql注入了，只有手動拼接的sql語句易被sql注入。
生成注入用例時注意：
1）’ 單引號閉合
2）‘OR 單引號也能夠有結束開始下一元素的效果
3）-- - 註釋後面跟空格實現註釋不跟後面語句鏈接，後面實際被註釋掉效果
4）Select CONCAT_WS(0x3A, USER, PASSWORD) FROM mysql.user 獲取數據庫用戶
5）union all 鏈接兩個select查詢結果，合union的區別不去重複；兩個select查詢的字段同樣
6）insert into mysql.user(Host,User,Password) values("%","Sectest",password("111111")) 給數據庫添加用戶 %：遠程用戶，localhost：本地用戶

系統使用了MyBatis動態SQL框架組裝sql，注意配置文件中的$和#的使用，使用$可能致使sql注入
拼接後的語句再放入預編譯對象是徒勞的，由於在預編譯以前拼接的SQL語句執行邏輯已經被破壞，原 SQL語句的本意已經被改變了。

概念：
https://help.aliyun.com/knowledge_detail/37450.html?spm=5176.7837442.2.10.ZotsLv
Sql注入經常使用語句：
http://www.111cn.net/database/mysql/58518.htm
http://wenku.baidu.com/link?url=sK_daSqJFJt3KsCuYQOjCkuGldDJSJQbATiRX42UEocanxFejYSjVESnyHPhvDP___hGAbKSLMhh4020TOP9wItRr1YWiq8OQ1HzYItXc6q

 

5.2.8.3.XML注入測試
（藉助XXE,攻擊者能夠實現任意文件讀取,DOS拒絕服務攻擊以及代理掃描內網等）
日誌注入（\r,\n換行，僞造日誌）
命令注入（操縱系統命令）
Email Header Injection(郵件標頭注入) 
/*（咱們在暫時不涉及）
Email Header Injection：若是表單用於發送email,表單中可能包括「subject」輸入項（郵件標題），咱們要驗證subject中應能escape掉「\n」標識。
<!--[if !supportLists]--> <!--[endif]-->由於「\n」是新行，若是在subject中輸入「hello\ncc:spamvictim@example.com」，可能會造成如下
Subject: hello
cc: spamvictim@example.com
<!--[if !supportLists]--> <!--[endif]-->若是容許用戶使用這樣的subject，那他可能會給利用這個缺陷經過咱們的平臺給其它用戶發送垃圾郵件。
*/
5.2.8.4.代碼執行
代碼執行是指應用程序對傳入命令的參數過濾不嚴致使惡意用戶能控制最終執行的命令，進而入侵系統，致使嚴重破壞的高危漏洞。
https://help.aliyun.com/knowledge_detail/37446.html?spm=5176.7837442.2.2.nCzE5s

5.2.8.5.CRLF漏洞
CRLF，carriage-return-line-feed,回車換行漏洞。
案例參考：https://www.leavesongs.com/PENETRATION/Sina-CRLF-Injection.html（對header進行注入）

5.2.9.上傳下載 
跨目錄文件下載
任意文件下載

任意文件上傳（後綴）
任意目錄文件上傳（目錄）
超大文件上傳（大小）
上傳文件廢棄後處理（堆積）
上傳文件名xss（重命名）
上傳文件名截斷（0x00或者0x58,burp也能夠修改二進制，url中%00）
上傳文件權限限制
壓縮炸彈
Include包含上傳（shtml）
上傳zip文件名中包含../
本地文件包含的概念：
https://help.aliyun.com/knowledge_detail/37472.html?spm=5176.7837442.2.2.2NdNhY
5.2.10.CSRF

CSRF【cross site request forgery】跨站點請求僞造。
原理：利用瀏覽器內存共享原理，利用用戶身份僞造用戶動做發送到服務端。（從惡意站點模擬用戶發送正常的請求攜帶cookie，見7.1）
5.2.10.1.URL重定向（跳轉）漏洞：
（參考http://drops.wooyun.org/papers/154）
一、問題點
在頁面跳轉的地方，URL中包含另外的網址，例如：
第一類 簡單URL過濾
www.xxx.com?a=http://www.yyy.com
第二類 底層操做類庫支持其餘協議致使讀取本地或探測網絡信息
http://h2w.iask.cn/h5.php?u=file:///etc/passwd
因爲底層適用類curl庫,而沒有正確過濾URL致使，能夠讀取內網諸多信息.還有其餘相似的形式：
如file://, ftp://, telnet://等
第三類 不支持其餘協議可是沒有設置網絡邊界（SSRF漏洞的姿式啊）
http://wap.sogou.com/tc?url=http%3A%2F%2Fno.sohu.com%2F
使用域之間的信任，突破到系統的內網

二、分析
理論上講，url跳轉屬於CSRF的一種，咱們須要對傳入的URL作有效性的認證，保證該URL來自於正確的地方，限制的方式同防止csrf同樣能夠包括：
1）referer的限制
2）加入有效性驗證Token
三、對跳轉的地址沒有作嚴格的校驗
5.2.11.CORS漏洞
CORS【cross origin resouse-sharing】跨域資源共享。
工具：shell of the future
理解參考：http://www.2cto.com/Article/201209/154081.html
5.2.12.SSRF漏洞（服務端請求僞造）
行爲特色：從其餘服務器獲取數據資源的功能，而且此功能獲取資源的請求是從服務端發起的。
能夠實現的攻擊：
能夠對服務器所在的內網、本地端口進行掃描、獲取banner等
攻擊運行在內網或者本地的應用程序（好比溢出）
對內網WEB應用進行指紋識別，訪問默認文件的方式
攻擊內網WEB服務器，get請求方式
利用file協議讀取本地文件：例如http://192.168.1.119/pm/www/index.php?m=bug&f=view&bugID=4052

http://netsecurity.51cto.com/art/201312/424038.htm
5.2.13.Google黑客
一、搜索站點看是否能發現敏感的信息或不應公佈的信息
搜索命令，例如：
site:yizhen.cn
site:yizhen.cn yizhen.cn:password
site:yizhen.cn inurl:session
site:yizhen inanchor:修改密碼
cache：www.yizhen.cn

參考：http://www.cnblogs.com/xuanhun/p/3910134.html
5.2.14.其餘
http開放方法測試
不安全的方法：put、delete、trace、connect
TRACE: 這個方法簡單返回客戶端發送給服務器的全部信息，主要用於調試目的。這個方法最初被認爲沒有危害，被Jermiah Grossman發現能被用於實施XST
CONNECT: 這個方法容許客戶端使用web服務器做爲代理。
DELETE: 這個方法容許客戶端刪除web服務器上的一個文件。攻擊者能利用他簡單直接破壞網站或者實施拒絕服務攻擊。
這個方法容許客戶端向web服務器上傳新的文件。攻擊者能夠利用他來上傳惡意文件（好比一個asp文件經過調用cmd.exe來執行命令），或者簡單使用受害者服務器做爲文件倉庫。
banner信息檢查
HTTP方法篡改(已驗證，沒有此問題；問題案例https://www.sobug.com/article/detail/25)
JavaScript DDOS（切換https後問題解決）
緩衝器溢出漏洞，java的不涉及
管理接口暴力枚舉（DirBuster）
測試HEAD訪問控制繞過
跨域策略測試
數值溢出
無論整數，浮點數，長整數等都是有一個能夠表示的最大值，若是一個該類型變量被賦予超過其最大值的時候就會出現溢出，而找出該變量的值異常。

5.2.15.重放攻擊
重放屢次請求消耗系統資源的請求，形成dos。篩選出較爲消耗資源的請求，檢查系統是否有防重放策略或者機制。
5.2.16.容器的安全
5.2.16.1.Apache tomcat
1）官網公佈的安全漏洞補丁升級
http://tomcat.apache.org/security-7.html#Apache_Tomcat_7.x_vulnerabilities
2）運行帳戶
創建獨立用戶，用戶名和組名均爲tomcat，不設置密碼（即禁止SSH登陸），tomcat進程以此賬號身份運行，嚴禁以root權限運行tomcat，禁止以我的賬號或其餘有shell權限的賬號運行tomcat。
3）刪除Tomcat自帶項目
4）檢查tomcat已知的帶有風險的配置
a)禁用應用程序自動部署功能（待考慮）
b)禁用webdav
c)定製Tomcat出錯信息
d)關閉Tomcat的目錄列表功能
e)限制http請求的消息主體的大小
f)禁止配置Tomcat的網絡鏈接超時時間爲0或-1
g)可執行文件只能由Tomcat屬主用戶修改
h)配置文件只能由Tomcat屬主用戶修改
i)日誌文件只能由Tomcat屬主用戶修改和執行
j)配置虛擬目錄，用以隱藏後臺路徑
k)禁用SSI和CGI功能
l)不容許使用SetUID程序，尤爲是root身份的SetUID程序
m)開啓Tomcat的日誌功能：正常的訪問日誌和錯誤請求日誌。日誌文件的記錄中包含訪問時間、內容、結果及請求用戶的ip等關鍵信息

影響較大的漏洞：
CVE-2016-1240 tomcat地權用戶提權漏洞。（2016-10）
5.2.17.其餘組件安全
5.2.17.1.Nginx
官網安全漏洞先關連接：http://nginx.org/en/security_advisories.html

影響較大的漏洞：
CVE-2016-1247 提權漏洞，藉助nginx日誌，提取到root。（2016-10）
5.2.17.2.Jquery
http://192.168.1.120:8080/amol-hospital/js/jquery-1.9.1.min.js
http://192.168.1.120:8080/amol-hospital/js/ueditor/third-party/jquery-1.10.2.min.js

在官網上沒有找到相應的安全漏洞列表
https://blog.jquery.com/2013/02/04/jquery-1-9-1-released/

Jquery兩個版本間更新日誌，其中有兩處vulnerable字樣
https://github.com/jquery/jquery/compare/1.9.1...1.12.3
5.2.17.3.Java漏洞
（放到操做系統部分，nessus能夠很好的檢查這個）
5.2.17.4.百度Ueditor（1.4.3）
5.2.17.5.Node.js(超聲視頻使用)
node -v
v0.10.42

5.2.17.6.Spring
5.2.17.7.Mybitas
5.2.17.8.Druid
數據庫鏈接池組件，包括四部分：DruidDriver、DruidDataSource、SQLParsr、擴展組件。
能夠監控數據庫訪問性能，Druid內置提供了一個功能強大的StatFilter插件，可以詳細統計SQL的執行性能，這對於線上分析數據庫訪問性能有幫助。替換DBCP和C3P0。Druid提供了一個高效、功能強大、可擴展性好的數據庫鏈接池。SQL執行日誌，Druid提供了不一樣的LogFilter，可以支持Common-Logging、Log4j和JdkLog，你能夠按須要選擇相應的LogFilter，監控你應用的數據庫訪問狀況。擴展JDBC，若是你要對JDBC層有編程的需求，能夠經過Druid提供的Filter機制，很方便編寫JDBC層的擴展插件。
一、訪問沒有權限控制

5.2.17.9.Turnserver
TurnServer 是一個TURN協議的開源實現。
該協議容許一個客戶端以relay方式得到IP地址和端口。這對於symmetric 類型的NAT或者防火牆兩邊設備的通訊很是有用。
TurnServer項目旨在兼容地處理 TURN 和 STUN請求 (RFC 5766 , RFC 5389)，同時也支持 RFC6156 即 TURN-IPV6 (relay between IPv4-IPv6, IPv6-IPv4 and IPv6-IPv6 addresses) 和 RFC6062 即TURN-TCP (relay data with TCP)

5.2.17.10.Terracotta(session共享)
5.2.17.11.phpMyAdmin
http://www.phpmyadmin.net/security/

5.2.17.12.Redis
一、指定redis服務使用的網卡 （須要重啓redis才能生效）
在 redis.conf 文件中找到 「# bind 127.0.0.1」 ，把前面的#號去掉，而後保存。注：修改後只有本機才能訪問Redis。
二、設置訪問密碼 （須要重啓redis才能生效）
在 redis.conf 中找到「requirepass」字段，在後面填上你須要的密碼，Redis客戶端也須要使用此密碼來訪問Redis服務。
三、修改Redis服務運行帳號 （須要重啓redis才能生效）
請以較低權限帳號運行Redis服務，且禁用該帳號的登陸權限。另外能夠限制攻擊者往敏感寫入文件，可是Redis數據仍是能被黑客訪問到，或者被黑客惡意刪除。
四、設置防火牆策略

若是正常業務中Redis服務須要被其餘服務器來訪問，能夠設置iptables策略僅容許指定的IP來訪問Redis服務。
參考：
https://help.aliyun.com/knowledge_detail/37447.html?spm=5176.7837442.2.10.nCzE5s

5.2.17.13.Fastjson開源jar
https://github.com/alibaba/fastjson/wiki/security_update_20170315
fastjson最新遠程代碼執行高危安全漏洞，當前涉及1.2.24以前版本
咱們用的1.1.41
5.2.18.Web木馬
常見的簡單形式--誘導優化打開具備網頁木馬的頁面，通常是寫入js引用大馬的代碼網頁，用戶打開誘導網頁後在電腦上實際上已經默認運行了下載大馬和執行大馬的操做

5.3.敏感數據保護
5.3.1.加密算法
算法列表能用，不能用
弱算法：md2，md4，md5（2004年的國際密碼學會議（Crypto’2004）王小云證實了MD5能夠被碰撞，至此，MD5再也不安全） ，sha1，blowfish
推薦算法：sha256，aes128
可逆的加密算法：des 3des aes128
可逆加密算法又分爲兩大類：「對稱式」和「非對稱式」。
對稱式加密特色：加密和解密使用同一個密鑰，一般稱之爲「Session Key 」。
DES、3DES、DESX、Blowfish、IDEA、RC四、RC五、RC6和AES
非對稱式加密特色：加密和解密所使用的不是同一個密鑰，而是兩個密鑰：一個稱爲「公鑰」，另外一個稱爲「私鑰」；它們兩個必須配對使用，不然不能打開加密文件。這裏的「公鑰」是指能夠對外公佈的，「私鑰」則只能由持有人本人知道。
常見的非對稱加密算法：RSA、ECC（移動設備用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）
不可逆加密算法：sha256 sha512 md5
不可逆加密算法的特徵是，加密過程當中不須要使用密鑰，輸入明文後由系統直接通過加密算法處理成密文。這種加密後的數據是沒法被解密的，只有從新輸入明文。
常見的Hash算法：MD二、MD四、MD五、HAVAL、SHA、SHA-一、HMAC、HMAC-MD五、HMAC-SHA1
參考：
http://www.360doc.com/content/13/0402/15/3862791_275529254.shtml
http://book.51cto.com/art/201109/294599.htm
MD5輸出128bit
SHA1輸出160bit
SHA256輸出256bit
另外還有SHA244,SHA512
分別輸出244bit，512bit

問題分析
數據庫中的密碼的機密算法推薦：
一、使用不可逆加密算法
二、使用加鹽（避免預先計算彩虹表）

建議的用戶密碼加密形式：
http：若通道未加密，密碼在客戶端使用可逆加密算法AES-256並加鹽（從服務端獲取挑戰碼即鹽值），傳輸到服務端再解密。
https：服務端接受到明文密碼後使用不可逆加密算法對密碼進行哈希加密SHA256並加鹽（使用安全隨機鹽值，長度建議跟密碼最長一致），再存入密碼密文和鹽值到數據庫。
5.3.2.證書
咱們通常說的證書都是服務端證書，即瀏覽器使用的驗證服務器身份的證書。
咱們的證書是自生成的證書。
證書：證實身份的憑據，證書中心用本身的私鑰對信息發送者的公鑰和一些信息一塊兒的加密，證書能夠保證公鑰的安全性和有效新，公鑰能夠驗證私鑰持有方的身份。常規信息有：頒發給的通用名、組織、組織單元、序列號和頒發者的通用名、組織、組織單元，有效時間開始於、過時時間，指紋SHA-256指紋和SHA1指紋。詳細信息還有證書的簽名算法、公鑰算法、公鑰等。

簽名哈希算法：證書編碼完整性保證的哈希算法
簽名算法：私鑰對證書編碼的哈希加密的算法；證書籤名使用的算法是發佈者本身規定的
上面兩個是發佈機構搞得，用來CA驗證的

指紋算法：計算出指紋的哈希的算法，就是哈希算法，通常就是sha1
指紋：證書的哈希值並用私鑰加密。

鑑別用戶的真僞能夠經過鑑別用戶的私鑰的真僞來確認，就是看加密的信息服務端是否能夠解密。
公鑰：鏈接創建時瀏覽器端加密時使用的祕鑰。
私鑰：鏈接創建時服務器端加密時使用的祕鑰。
使用時：
步驟一：
一、瀏覽器輸入網址訪問yizhen.cn（應用層的）
二、瀏覽器底層的TSL協議發送明文的Hello信息給服務器（網絡層）
三、服務器響應一個Hello信息給瀏覽器
步驟二：
服務器端發送它的證書給瀏覽器（圖中的三，圖中的二是以前就生成好的，存儲在服務端的公鑰、私鑰、證書）
步驟三：
一、客戶端驗證服務端發來的證書
二、驗證證書的簽名、完整性等信息
三、去瀏覽器證書管理中心驗證證書是否可信，是否爲可信機構的證書或者子證書
四、若是不可信，瀏覽器拋出警告，提示用戶，須要用戶確認選擇是否繼續
步驟四：
一、瀏覽器產生一個隨機的值，做爲祕鑰，對稱加密的祕鑰，此處就稱爲祕鑰。
二、使用證書中的公鑰對產生的祕鑰進行加密生成密文串
步驟五：
一、發送密文串給服務器
二、服務器接受到密文串，使用證書的私鑰進行解密，得到對稱加密的祕鑰。
三、服務器使用對稱祕鑰加密響應報文內容發送給瀏覽器。
步驟六：
服務器和瀏覽器能夠通信了。
瀏覽器發送的數據都是公鑰加密，使用對稱祕鑰解密收到的數據。
服務器發送的數據都是對稱祕鑰加密的，收到的數據使用私鑰解密。
簡單示意圖以下：

證書介紹和攻擊
Pem格式的證書詳細信息查看：
https://www.trustasia.com/tools/cert-decoder.htm
SSL證書被攻擊、假冒的風險分析
http://wenku.baidu.com/link?url=LkghTfA11JWJBLFJrgBZfCrIBFJoqfcH1q4xBEbzt3xmGtkR7mdkV91mUnRobYQKYz2ekVTo7XNQdOMHIuOpWZv4TBDBVsBo52dYNeX1zRi
一個合法有效的SSL證書誤簽發給了假冒者（--）
破解SSL證書籤發CA的私鑰（關注簽名算法）
SSL證書籤發CA的私鑰泄露（若是是自簽名證書須要關注）
破解SSL證書的私鑰（關注指紋算法）
SSL證書的私鑰泄露（服務器端私鑰的存貯）
認證機構主動爲假冒網站簽發合法有效的證書（--）
利用可信的SSL服務器證書進行中間人攻擊（--）
在用戶主機中植入僞造的根CA證書（或一個完整的CA證書鏈）（--）
旁路證書的可信性的驗證（--瀏覽器操做系統漏洞）

---若是證書的跟證書沒有，第一次訪問會去證書網站獲取根證書或者中間證書

5.3.2.1.證書加密算法的檢查
一、證書的指紋算法是否安全，不安全的算法形成證書加密傳輸的信息能夠被解密
二、證書的簽名算法是否安全，不安全的簽名算法可能形成證書被僞造
5.3.2.2.證書對應的祕鑰保存檢查
一、證書私鑰在服務器端存儲是否加密
二、證書私鑰在服務器端的存儲文件權限是否只有全部者能夠訪問
----瀏覽器端客戶的CA根證書是否安全可信，這個沒法保證（不涉及）
5.3.3.明文密碼
客戶端
一、瀏覽器Cookie中存儲，瀏覽器Cookie中記錄密文密碼
二、瀏覽器記錄密碼保存明文密碼
服務端明文密碼檢查
一、 配置文件明文密碼
二、日誌中記錄明文密碼
三、程序中硬編碼密碼、密鑰
（針對祕鑰場景的理解，主要針對當前的弱算法祕鑰爆破的場景，原理是經過對屢次的加密後的密文對比差別嘗試推倒祕鑰，有些場景能夠認爲是分問題的，如數據庫密碼以DES加密密文存儲在配置文件中，密鑰在代碼中硬編碼，這種場景的密鑰硬編碼就是沒有問題的，他的密鑰在配置文件和代碼中其實沒有多大區別。）
5.3.4.源代碼敏感信息檢查
使用search and replace搜索代碼中的關鍵字、敏感字，查看是否有不當使用的地方
一、passwd、password、pword等
二、使用過的密碼111111,123456，admin，amol等
5.4.協議與接口攻防
5.4.1.端口掃描
一、遠端掃描工具Nmap
端口掃描命令
TCP，Nmap -sS -T4 -p 1-65535 -oX filename.xml IP
UDP，Nmap -sU -T4 -p 1-65535 -oX filename.xml IP
二、系統檢測
檢查服務器的操做系統類型及版本
Nmap –O IP
三、近端端口信息檢查
登陸服務器，查看端口詳細信息
lsof –i:port 
ps –ef|grep pid
四、整理系統開放端口的詳細列表
5.4.2.端口服務探測
一、使用命令nmap -sV -Pn -p port IP，探測端口的詳細服務及版本
-Pn：在掃描以前，不發送ICMP echo請求測試目標是否活躍。
-sV：探索開放的端口，肯定服務器/版本信息

5.4.3.REST WEB Service（接口協議）
5.4.4.SOAP
Soap注入

5.4.5.SSH協議
放到操做系統部分，這個組件和操做系統強相關
5.4.6.IM服務-XMPP協議
http://wiki.xmpp.org/web/Securing_XMPP
IM服務檢查：https://xmpp.net
Tigase用戶指南：http://docs.tigase.org/tigase-server/snapshot/Administration_Guide/html_chunk/index.html
Tigase XMPP (Jabber) server ver 7.0.2

IM服務器如何測試？？？
http://my.oschina.net/greki/blog/210393
Tigase-server
Tigase-client
http://localhost:8080/setup/進入tigase後臺
5.4.7.外部接口安全
獲取token：http://192.168.1.120:8080/amol-back/oauth/token?client_id=amol_client_mbox&client_secret=amol_secret_mbox&grant_type=password&username=mbox&password=123456

一、鏈路加密 
二、參數校驗 -
三、訪問數限制-
參數：
使用burp遍歷用例payload
1)特殊字符
英文字符
~!@#$%^&*()____+{}|:」<>?-=;’,./`
中文字符
~！@#￥%……&*（）——+：「《》？，。、‘；、】【·
中文漢字
哈哈
2）sql注入
3）XSS
4）純數字、純英文、組合、大小寫、
5）換行
6）超長
7）空
5.4.8.SSL/TSL
https等其餘協議使用的加密協議SSL/TSL是不是安全的，使用開源工具sslsplit檢測，工具下載地址https://github.com/droe/sslsplit/tree/7677fe06557509e95e548318909c1a328b6f6069。
檢查加協議版本及套件的辦法Nmap -sV -p port --script ssl-enum-ciphers ip

一、加密協議SSLv2v3須要所有禁用
二、TSL的加密密套件部分已經不安全須要配置刪除
5.4.9.WiFi安全
對象（Wep、Wpa）、原理、工具

5.5.操做系統安全
http://www.centoscn.com/CentosSecurity/

工具：openvas、nessus

測試方式：可在本地安裝nessus home版完來測試

影響較大的漏洞
CVE-2016-5195：Linux系統本地提權漏洞，髒牛漏洞。（2016-10）【通吃型】。

5.5.1.本地提權
1）Windows下提權（咱們是linux服務器，這個暫時不關注）
2）Linux下提權----
利用系統漏洞提權（主動提權）
配置不當提權（被動提權）
Sudo提權---/etc/sudoers文件配置
Crontab提權--定時執行的腳本的權限配置
Init.d提權--/etc/init.d此目錄下的文件的寫權限要嚴格禁止
Environment提權--用戶的profile、environment等的權限設置、還有su命令而不是su - 方式切換到root用戶
Setuid提權--經過給腳本或者bash添加s權限獲取root權限

 

5.5.2.各類木馬
鍵盤記錄木馬
綁定端口木馬
回連木馬
端口複用木馬
遠程控制木馬

5.5.3.密碼破解
本地破解--md五、linux shadow、ntlm/lm
遠程破解--ssh、httpauth、webform、pop/Smtp

5.6.數據庫安全
Mysql
http://www.w3resource.com/mysql/mysql-security.php
Redis

影響較大的漏洞：
CVE-2016-6662 mysql本地提權漏洞。（2016-9）
5.7.軟件的發佈與安裝安全
一、下載的軟件有沒有提供簽名
二、下載後安裝是否有校驗機制

5.8.手機端的安全
一、app的簽名、反逆向
（apk加固步驟：http://jingyan.baidu.com/article/b2c186c8cd1a71c46ef6ffcd.html，數字簽名：http://blog.csdn.net/kickxxx/article/details/18252881）
二、用戶隱私
本地保存用戶密碼、不管加密與否
敏感信息隱私信息，如聊天記錄、關係鏈、銀行卡號等是否加密保存
配置文件等是否保存到外部設備上
保存到外部設備的信息加載前判斷是否被篡改
三、文件權限
App所在目錄不容許其餘組成員讀寫
四、網絡通信
重要敏感數據傳輸加密
五、運行時解釋保護
嵌有解釋器的軟件XSS、SQL注入等
外部鏈接的是否有URL欺騙等漏洞
六、組件權限保護
禁止App內部組件被任意第三方程序調用
調用外部組件先驗證簽名
七、升級
升級包完整性、合法性校驗，避免被劫持
八、3rd庫
跟進第三方庫的更新
http://blog.nsfocus.net/mobile-app-security-security-test/
http://www.zhihu.com/question/24083362

5.9.靜態代碼分析（純白盒）
一、危險函數、方法、關鍵字
二、工具檢測 findbugs
三、邏輯漏洞
5.10.抓包走讀代碼（灰盒測試）
一、前臺功能執行、中間工具抓包、後端代碼走讀的形式（過程：結合業務思路查看中間參數、走讀後端代碼跟蹤參數處理，結合常見WEB安全漏洞形式匹配問題，抓包重放驗證問題。）
二、可發現的常見漏洞形式：越權、XSS、sql注入、參數合理性等

6.安全測試的原則
攻擊面最小化
默認安全
最小權限原則
深度防護原則（多角度、冗餘的）
安全的失敗
外部系統是不安全的
職責分離（權值分離）
不依賴隱晦的安全性
簡單
正確的修復安全性問題
客戶端的輸入是不可信的

個人理解的判斷依據：
一、咱們設計的程序的動做是肯定的，而程序運行中產生了超出這個預期動做的部分，咱們均可認爲它是不安全的，須要改正的。
二、問題產生在咱們的設計得程序動做自己就是不符合現有的大環境下的安全標準。
7.參考資料
http://www.owasp.org.cn/ OWASP 測試指南
http://www.wooyun.org/
http://bbs.51cto.com/thread-1039046-1.html
8.系統結構簡圖

9.涉及的經常使用工具
一、Burpsuit
二、Watchweb
三、Httprint
四、Httpwatch
五、Appscan
六、Awvs
七、Nmap
八、Search and replace
九、Sqlmap
十、secureCAT
十一、--驗證碼識別工具
十二、--Whois查詢
1三、DirBuster
1四、Fiddler
1五、Wireshark
1六、Firefox hackbar
1七、在線js執行（http://js.do/）

9.1.文件名上傳XSS
一、此種問題的特色：首先，是上傳點；第二，在上傳後使用了上傳的文件名（可能又更名，可是記錄了文件名）；
二、系統問題發生點醫生系統-終審報告-附件

三、此處符合了1，查看顯示文件名的界面的代碼
<a href="javascript:void(0);" onclick="downloadFile('hospital/0100101/2016/06/03/DR/369/20160603140244.gif','aaa.gif')">aaa.gif</a>
以上語句2處出現了文件名，即有兩個地方是咱們可能注入代碼的地方
先看後一個位置，超連接內的文字，普通文本
考慮嘗試最簡單的<script>alert(1)</script>，嘗試設置文件名爲<script>alert(1)</script>a.gif

發現字符/後的部分被做爲了文件名，考慮後臺代碼有字符截斷或者限制長度。而且確認咱們的字符<>是接受的。
下一步設置文件名爲aaaaaaaaaaa.gif，發送屢次嘗試確認文件名能夠的最長長度爲24個字符，也就是後綴前面的代碼只能有20個字符。
再嘗試</script>b.gif，確認/

失敗，什麼緣由？再嘗試a/b.gif

確認/是有特殊處理的，會被截斷，那麼其餘編碼試試？
<script>alert(1)</script>
<script>alert(2)<%2Fscript> <%2Fscript>可上傳，但是總體超長
<script>alert(3)<&#x2f;script> 可上傳，但是總體超長
<script>alert(4)<&#47;script> 可上傳，但是總體超長
<script>alert(5)<\u2fscript> \和/一樣的效果
<script>alert(6)<\u002fscript> \和/一樣的效果
好吧，換個思路；這個地方有多個文件上傳，能不能用兩個文件名組合？試試
上傳<script>a.gif
再上傳<alert(2)<%2Fscript>b.gif

刷新界面看下

仍是不能執行，後面的腳本都被當成javascript腳本內容解析了，%2F不會被瀏覽器編碼反解析回來；只能是屏蔽了下面的到</script>前的全部代碼，其實這裏能夠說已是有問題了，改變了原來界面的語義

這個位置的文件名貌似行不通啊，咱們再來看原始的代碼，再看看第一處
<a href="javascript:void(0);" onclick="downloadFile('hospital/0100101/2016/06/03/DR/369/20160603140244.gif','aaa.gif')">aaa.gif</a>
兩種思路：A）閉合a，在後面造成代碼；B）在標籤內造成屬性事件
先看B思路，onclick="downloadFile('hospital/0100101/2016/06/03/DR/369/20160603140244.gif','aaa.gif')"，着力點在這裏，要閉合’)」，再給一個事件屬性如onmouseover=」」
試試文件名’)」onmouseover=」alert(1)」，嘗試後發現」和’，都是問題啊會被處理，這個沒辦法規避啊
再看看A思路一樣避不開’」啊
在回頭看看，誰說執行腳本不須要<scritp>標籤啊
<a href="javascript:void(0);" onclick="downloadFile('hospital/0100101/2016/06/03/DR/369/20160603140244.gif','aaa.gif')">aaa.gif</a>
文件名不包含’」/ \，能夠考慮的仍是標籤的屬性，因而看二位置換成<a onclick=alert(1)>a.gif如何

再看界面

OK，XSS成功，全部查看這份報告的，點擊了這個附件的都會執行這個事件。
固然也能夠換成其餘屬性觸發事件啦，有興趣能夠試試。
請不要忽略這個斷字符的僅能alert(1)的問題，這個問題也可能和其餘漏洞結合發揮大的威力哦（好比值同域而後釣魚）
9.2.XXE漏洞詳解
什麼是XXE ? 就是咱們所說的所謂xml實體注入。entity翻譯爲"實體"。它的做用相似word中的"宏"，也能夠理解爲DW中的模板，你能夠預先定義一個entity，而後在一個文檔中屢次調用，或者在多個文檔中調用同一個entity(XML定義了兩種類型的entity。一種是咱們這裏說的普通entity，在XML文檔中使用；另外一種是參數entity，在DTD文件中使用。)。
<!DOCTYPE filename
[ 
<!ENTITY entity-name "entity-content" 
]>
參考：
http://blog.csdn.net/dongfengkuayue/article/details/50240157
http://drops.wooyun.org/papers/1911
9.2.1.XXE任意文件讀取
構造以下xml文件
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE file [
<!ENTITY file SYSTEM "file:///C:/Windows/System32/drivers/etc/hosts"> 
]>
<body>
<username>&file;</username> 
<select id="chartForConsultation" resultMap="BaseResultMap">
&file; 
</select>
</body>
一、使用最原始的javax.xml.parsers，標準的jdk api

在解析結果總解析出了hosts文件的內容。
二、使用dom4j後程序變得更簡單

三、使用JDOM

9.2.2.XXE拒絕服務攻擊
一、sax解析類已經作了處理

 

二、循環調用

10.名詞解釋
WAF
Web應用防禦系統（也稱：網站應用級入侵防護系統。英文：Web Application Firewall，簡稱： WAF）。利用國際上公認的一種說法：Web應用防火牆是經過執行一系列針對HTTP/HTTPS的安全策略來專門爲Web應用提供保護的一款產品。
單點登錄
單點登陸（Single Sign On），簡稱SSO，是目前比較流行的企業業務整合解決方案之一。SSO的定義是在多個應用系統中，用戶只須要登陸一次就能夠訪問全部有相互信任的應用系統。
PR7
PR值全稱爲PageRank(網頁級別)，取自Google的創始人LarryPage。它是Google排名運算法則（排名公式）的一部分，是Google用於用來標識網頁的等級/重要性的一種方法，是Google用來衡量一個網站的好壞的惟一標準。在揉合了諸如Title標識和Keywords標識等全部其它因素以後，Google經過PageRank來調整結果，使那些更具「等級/重要性」的網頁在搜索結果中令網站排名得到提高，從而提升搜索結果的相關性和質量。級別從1到10級，10級爲滿分。PR值越高說明該網頁越受歡迎（越重要）
OAuth受權
OAuth(開放受權)是一個開放標準。
容許第三方網站在用戶受權的前提下訪問在用戶在服務商那裏存儲的各類信息。
而這種受權無需將用戶提供用戶名和密碼提供給該第三方網站。
OAuth容許用戶提供一個令牌給第三方網站，一個令牌對應一個特定的第三方網站，同時該令牌只能在特定的時間內訪問特定的資源.
詳細參考：http://justcoding.iteye.com/blog/1950270

REST WebService
REST（Representational State Transfer）是一種輕量級的Web Service架構風格，其實現和操做明顯比SOAP和XML-RPC更爲簡潔，能夠徹底經過HTTP協議實現，還能夠利用緩存Cache來提升響應速度，性能、效率和易用性上都優於SOAP協議。
隱寫術
隱寫術是關於信息隱藏，即不讓計劃的接收者以外的任何人知道信息的傳遞事件（而不僅是信息的內容）的一門技巧與科學。隱寫術英文做「Steganography」，來源於約翰尼斯·特里特米烏斯的一本看上去是有關黑魔法，其實是講密碼學與隱寫術的一本書Steganographia中。此書書名來源於希臘語，意爲「隱祕書寫」。
CTF
CTF（Capture the Flag）奪旗比賽。
MIME編碼
MIME（Multipurpose Internet Mail Extensions）多部分(multi-part)、多媒體電子郵件和WWW超文本的一種編碼標準，用於傳送諸如圖形、聲音和傳真等非文本數據。
PKCS
The Public-Key Cryptography Standards (PKCS)是由美國RSA數據安全公司及其合做夥伴制定的一組公鑰密碼學標準，其中包括證書申請、證書更新、證書做廢表發佈、擴展證書內容以及數字簽名、數字信封的格式等方面的一系列相關協議。
PKCS#1：定義RSA公開密鑰算法加密和簽名機制，主要用於組織PKCS#7中所描述的數字簽名和數字信封。
WASC
Web Application Security Consortium（WASC），是一個由安全專家、行業顧問和諸多組織的表明組成的國際團體。WASC 組織的關鍵項目之一是「Web 安全威脅分類」，也就是將 Web 應用所受到的威脅、攻擊進行說明並概括成具備共同特徵的分類。該項目的目的是針對 Web 應用的安全隱患，制定和推廣行業標準術語。
OWASP
Open Web Application Security Project（OWASP），該組織致力於發現和解決不安全 Web 應用的根本緣由。它們最重要的項目之一是「Web 應用的十大安全隱患」，總結了目前 Web 應用最常受到的十種攻擊手段，而且按照攻擊發生的機率進行了排序。這個項目的目的是統一業界最關鍵的 Web 應用安全隱患，而且增強企業對 Web 應用安全的意識。
CORS
CORS(Cross Origin Resourse-Sharing)，跨域資源共享。
Node.js
Node.js是一個Javascript運行環境(runtime)。 實際上它是對Google V8引擎進行了封裝。V8引 擎執行Javascript的速度很是快，性能很是好。Node.js對一些特殊用例進行了優化，提供了替代的API，使得V8在非瀏覽器環境下運行得更 好。
[1]  Node.js是一個基於Chrome JavaScript運行時創建的平臺， 用於方便地搭建響應速度快、易於擴展的網絡應用。Node.js 使用事件驅動， 非阻塞I/O 模型而得以輕量和高效，很是適合在分佈式設備上運行的數據密集型的實時應用。
SSRF
SSRF(Server-Side Request Forgery:服務器端請求僞造) 是一種由攻擊者構造造成由服務端發起請求的一個安全漏洞。通常狀況下，SSRF攻擊的目標是從外網沒法訪問的內部系統。（正是由於它是由服務端發起的，因此它可以請求到與它相連而與外網隔離的內部系統）
滲透攻擊、攻擊載荷payload、shellcode
CWE
CWE(Common Weakness Enumeration),通用弱點枚舉。軟件弱點分類，更好地識別缺陷、修復阻止缺陷實現自動化。 
CDN
CDN(ConTent Deliver network)內容分發網絡。以負載均衡爲核心。
Maven
Maven項目對象模型（POM），能夠經過一小段描述信息來管理項目的構建，報告和文檔的軟件項目管理工具。
WebRTC
WebRTC（Web Real-Time Commutication）Web實時通信的縮寫，就是使用Web瀏覽器完成實時的語音對話和視屏對話的技術。
APT
APT（Advance Persistent Thread）高級可持續性攻擊。APT是黑客以竊取核心資料爲目的，針對客戶所發動的網絡攻擊和侵襲行爲，是一種蓄謀已久的「惡意商業間諜威脅」。這種行爲每每通過長期的經營與策劃，並 具有高度的隱蔽性。APT的攻擊手法，在於隱匿本身，針對特定對象，長期、有計劃性和組織性地竊取數據，這種發生在數字空間的偷竊資料、蒐集情報的行爲， 就是一種「網絡間諜」的行爲。
CVSS
Common Vulnerability Scoring System，即「通用漏洞評分系統」，是一個「行業公開標準，其被設計用來評測漏洞的嚴重程度，並幫助肯定所需反應的緊急度和重要度」。
CVSS是安全內容自動化協議（SCAP）[2]的一部分，一般CVSS同CVE一同由美國國家漏洞庫（NVD）發佈，由美國國家基礎建設諮詢委員會（NIAC）委託製做，是一套公開的評測標準，常常被用來評比企業資訊科技系統的安全性，並受到eBay、(Symantec)、思科(Cisco)、甲古文(Oracle)等衆多廠商支援。
CVSS的目標是爲全部軟件安全漏洞提供一個嚴重程度的評級
 這就意味着CVSS旨在爲一個已知的安全漏洞的嚴重程度提供一個數值(分數)，而無論這個安全漏洞影響的軟件類型是什麼，無論它是操做系統、殺毒軟件、數據庫、郵件服務器、桌面仍是商務應用程序。因爲這個評分範圍很是廣，這個評分系統把可以徹底攻破操做系統層的已知安全漏洞評爲基準分數10.0分。換句話說，CVSS基準分數爲10.0分的安全漏洞通常指可以徹底攻破系統的安全漏洞，典型的結果是攻擊者徹底控制一個系統，包括操做系統層的管理或者「根」權限。例如，國家安全漏洞數據庫中一個第三方產品中的這種安全漏洞被解釋爲，攻擊者可以安裝程序;觀看、修改或者刪除數據;或者建立擁有用戶所有權利的新帳戶。
它的主要目的是幫助人們創建衡量漏洞嚴重程度的標準，使得人們能夠比較漏洞的嚴重程度，從而肯定處理它們的優先級。CVSS得分基於一系列維度上的測量結果，這些測量維度被稱爲量度（Metrics）。漏洞的最終得分最大爲10，最小爲0。得分7~10的漏洞一般被認爲比較嚴重，得分在4~6.9之間的是中級漏洞，0~3.9的則是低級漏洞
CVSS系統包括三種類型的分數
　　- 基準分數，暫時的和環境的。每個分數都要衡量這個安全漏洞的不一樣屬性。甲骨文在嚴重補丁更新文件中提供這個「基準分數」。這個基準分數有以下特色：
   　- 這個基準分數具體指一個指定的安全漏洞。
　　- 這個基準分數是不變的。
　　- 它不是具體針對一個客戶的技術IT環境的

11.那些網絡大牛們的語句以安全防護方的角度來看，防護的廣度比深度更具優先級，這也是信息安全中木桶原理的體現。網絡世界如此的年輕，尚未發展出本身獨立的行爲規範。我認爲安全的核心理念只有兩種：一是對無序的內外環境執行線性秩序化策略，構建強韌的防禦體系，爲系統提供「免疫」能力。二是對無序的內外環境執行非線性秩序化策略，構建反脆弱性防禦體系，爲系統提供「進化」能力。--------安在安全的三要素：機密性、完整性、可用性防護的一些思想：白名單思想、深度防護、數據與代碼分離、不可預測性、縮小攻擊面12.其餘個人一些理解：一、安全中總談到作安全須要首先確認信任域與信任邊界，信任邊界的概念主要是從這個網絡物理結構體系的形式來體現的，好比通常在網閘或者防火牆之類的的設備處做爲邊界，內部造成一個個安全域。而咱們的互聯網系統是以云爲依託，打破了原來的那種概念。物理層對咱們來講是不透明的，以服務提供商的邏輯服務形式體現爲8臺服務器，2臺數據庫服務器，2臺負載均衡服務器。而且這些服務器之間並無配置相互的信任關係，這就造成了咱們的安全實際形態爲多處單點形式。仔細來看這12個單點，首先2臺負載均衡，只提供負載均衡服務其餘均不須要咱們看護，其作了哪些措施除了分配鏈接外一律不知，因此能夠從咱們的安全形態圈摒棄掉。剩下的10臺服務器，彼此獨立，互相不該該信任，彼此交互均應該有有效認證行爲。固然，其彼此的交互也被分爲了兩種，一是大網交互，二是內網交互。這裏的大網內網咱們就須要和阿里的網絡相結合。內網交互就在阿里的相對安全的一個域，不防叫內域，相對的大網交互就在阿里的相對不安全的域和互聯網上了，這是一個不可信的不安全的區域，不防叫外域。這種結構就應該和咱們的業務相結合，好比咱們的10臺服務器要彼此訪問，同時此訪問服務不須要提供給互聯網，咱們就能夠把業務單獨配置到內域，若是業務是提供給互聯網的，那麼配置到外域或者內域和外域。