❶ 您的internet安全設置阻止打開一個或多個文件。。
windows7：「您的 internet 安全設置阻止打開一個或多個文件 」的修復步驟如下：
1.看到這個提示，應該是IE安全策略問題，於是打開IE點擊設置。
❷ 什麼是手機越獄
]什麼是越獄？為何要越獄？
入手iPhone 3GS以來，從3.1.2到3.1.3，再到如今的4.1，一路跟下來，積累了很多越獄、軟體使用方面的經驗。分享一下自己使用iPhone的心得體會。本篇文章主要談論一下iPhone很多基礎的破解概念。
一、什麼是iOS？
iOS就是iPhone OS。iPhone是一部智能手機，在硬體之上部署了一套iPhone OS操作系統。這個操作系統如同windows CE和windows Mobile一樣。用一個對比就能非常容易地描述它們，即：iPhone OS（操作系統）之於iPhone（硬體平台），相當於Windows XP之於我們的x86、x64家用PC機，當然也相當於WinCE之於嵌入式硬體。
二、有鎖版和無鎖版有什麼區別？
iPhone分成兩種類型，有鎖版和無鎖版。有鎖版就是加了網路鎖，也就是綁定了運營商，比如美版的AT&T，英國的O2。這樣的手機只能插入相應運營商的SIM卡才能使用，插入其他的卡則無法使用，大家通常管這種機器叫做小白。通常情況下，購買這種類型的iPhone是通過和某運營商簽訂一份為期1–2年的入網協議，綁定信用賬戶承諾月消費多少多少元，折價購機或免費送機。這種方式iPhone的手機費用已經折算到相應運營商的話費中了。如果想使用別的卡，那麼iPhone就需要先越獄，再解鎖。只有通過這兩部過程，一部有鎖版的iPhone才可以使用別家運營商的卡。關於解鎖，也分為硬解鎖和軟解鎖，我們後面談起。
無鎖版也叫官方解鎖版，比如港行或是阿聯酋的無鎖版（香港另有和記的「3」定製版iPhone）。這種手機一般價格都會比較高，但好處就在於任何一家運營商的SIM卡都可以順利地幫助iPhone激活，並能夠正常使用。它們只需要越獄，不需要解鎖。
iPhone 2G（一代）全部都為有鎖版
三、什麼是越獄？為什麼要越獄？
越獄是指利用iOS系統的某些漏洞，通過指令取得到iOS的root許可權，然後改變一些程序使得iPhone的功能得到加強，突破iPhone的封閉式環境。iPhone在剛剛買來的時候，是封閉式的。作為我們普通的用戶，是無法取得到iPhoneOS的root許可權的，更無法將一些軟體自己安裝到手機中。我們只能通過iTunes里的iTunes Store購買一些軟體（當然也有免費的），然後通過Apple認可的方式（iTunes連接iPhone並同步），將我們合法得到的軟體復制如手機。但這種方式就把我們廣大用戶牢牢地桎梏在蘋果的管轄范圍內。一些好用的軟體，但並不一定符合Apple利益，它們就無法進入iTunes Store。比如我們無法在iOS上安裝SSH，無法復制iOS中的文件，更無法安裝更適合我們的輸入法。這些軟體，都需要用到更高級別的許可權，蘋果是不允許的。
為了能夠更好地使用我們的iPhone，我們要越獄。越獄不是必須的，但越了獄的手機使用起來會更爽、更方便、更好玩。越獄後，能夠免費使用很多軟體，更能夠使手機的易用性進一步增強。
四、什麼是解鎖？為什麼要解鎖？
因為有鎖版iPhone的存在，我們如果想用其他運營商的SIM卡，就必須要解鎖。如果不需要換運營商，當然不用解鎖。但比如，對流到中國大陸的美版水貨來說，不解鎖那也不可能用AT&T，只能解鎖。
解鎖有兩種方法，硬解或軟解，軟解的方法沒放出來之前，都是硬解，最常見的硬解便是使用卡貼。如果不適用卡貼，還有一種終極的解鎖方法，但這種方法只能由Apple官方來完成，因為我們不知道密鑰。就像我們沒有鑰匙是進不去房間的原理一樣，我們沒有密鑰，就無法全面而完美地解鎖。在逐漸了解了iPhone基帶、NOR、固件等屬於後，我們再來更加深入地討論完美解鎖這個問題。
通常說的破解，當是「解鎖+越獄」的合稱，對很多iPhone用戶（尤其是中國大陸的美版iPhone使用者）來說，這兩個都是需要（當然還是那句話，越獄不是必須，只是更好玩）的，所以很多破解方式就將解鎖和越獄的方法放在一塊，提供給大家。
五、什麼是固件？怎樣更新固件？
固件是iPhone存儲基礎iOS和通訊模塊實現軟體的載體，相當於電腦的操作系統（如windows xp）或功能更高級BIOS。沒有固件，iPhone只是一部沒有大腦的硬體，就相當於我們買來一台電腦沒有操作系統。固件可以認為是操作系統。
更深入地看，iPhone的固件分為應用部分和基帶部分。應用部分主要指的iOS的iPhone OS操作系統，而基帶主要就是iPhone通訊系統。兩部分加起來，合成為一個xxxx.ispw文件存在，行程了一個iPhone的固件。
更新固件就相當於重新安裝操作系統，是通過iTunes裡面的「iPhone固件恢復」的方式來完成的。在3GS之前的iPhone一代、二代手機，由於沒有足夠的安全措施，我們可以直接下載Apple的固件軟體（xxx.ipsw）然後恢復。但是在3GS及以後的版本，就不能這樣恢復了。因為對於一個從網路上下載的固件來說，我們完全可以修改它們內部的內容直接越獄，這樣蘋果當然是不幹的。在3GS加入了加密方式後，我們如果想恢復固件（或稱之為更新固件），那麼就先要到蘋果的激活伺服器上去檢查，我們即將要恢復的固件軟體（xxx.ipsw）是否來自於蘋果官方。他們會檢查這個固件的簽名。如果不是官方的，那麼對不起，用戶不能恢復該固件。這就印出了下一個話題，及SHSH及自己搭建蘋果固件恢復認證伺服器。
六、什麼是ECID？什麼是SHSH？如何備份SHSH？怎樣能恢復到原先的iOS版本？
引入這個話題的根本原因是：，蘋果公司禁止你使用老版本的固件。一旦你「升級」後，就不能「降級」了。他們一般會在你選擇恢復老版本固件的時候，讓iTunes收到一個拒絕實施這項恢復操作的命令，從而阻止你這么做。要知道，現在的固件都是簽過名的，並且使用只有你的設備才具有的、全球唯一的標識符(也就是ECID)來簽名。蘋果公司使用「僅此一家」的方式將對應版本的固件文件以及你的ECID一起生成一個哈希值。iTunes會收到這個哈希值，並發送給你的設備。當你的設備收到後會立即檢查並核實簽名(確保這個固件的確來自於蘋果公司官方。加密演算法非常繁雜，實踐上暫時無法被破解)。如果簽名匹配，才會繼續進行固件恢復操作；如果不匹配，設備就會報錯，恢復操作也就中止了。
不過，我們要膜拜Saurik大神(Jay Freeman)，現在我們知道該怎麼「忽悠」iTunes了。蘋果公司只提供「活躍」版本固件的簽名。因此，一旦新版本固件發布，他就停止對老版本固件的簽名。這就是你為何再也無法獲得3.1.2版本的簽名的緣故。現在蘋果公司只為3.1.3版本（iPad是3.2版本）簽名，直至下個版本固件的發布。很快，3.1.3(以及3.2)版本的固件簽名將會成為歷史，因為蘋果只會為新版本固件簽名(也就是只為iOS4簽名，譯者注)。當前這個版本很重要。如果你沒有為你的設備(ECID)准備好對應版本固件的有效簽名，你就沒法再恢復到那個版本的固件了。這個問題會周期性地出現(每次固件更新後都會出現，譯者注)。
因此，如果有一種機制，能夠保存這個簽名，我們就能繞過蘋果公司而隨意恢復各個版本的固件。如果你的設備越獄了，使用cydia，你的SHSH文件就可以保存好了。反之，如果你的設備沒有越獄或者當前未能越獄，那真是天大的不幸，因為cydia只能越獄後才能使用。
ECID，即Exclusive Chip ID，就是iPhone3GS/iPhone4的身份證號，每一個iPhone3GS/iPhone4都有自己的獨特的ECID。有了這個ECID，就能唯一確定一部iPhone。而ECID和我們按手機*#06#得到的序列號不太一樣，雖然都能唯一確定一部手機。ECID是iPhone的唯一編號，而後者則只是針對iPhone的通訊模塊的唯一編號。
SHSH實際上是ECID+iOS某個特定版本加起來行程的一個特徵碼。對於一部iPhone 3GS或是iPhone 4，想升級到某一版本，就需要到蘋果的激活伺服器去下載一個文件，來判斷這個版本針對這部手機是否合法。而這個文件就是xxxx.shsh。
這個文件對與我們越獄十分重要，一定要將針對每個iOS版本的SHSH文件備份好，才能在某天蘋果不讓我們恢復到這個版本時候，自行搭建認證伺服器，然後恢復老的、有漏洞的版本來越獄。
再啰嗦一句，ECID和SHSH的概念僅僅適用於3GS及其以上版本，iPhone一代和二代就不需要考慮了。
如何備份SHSH目前主要有兩種方法。一種是手機越獄了有了Cydia，進入Cydia首頁就能看到備份SHSH的內容（不過是英文的）。另外就是通過TinyUmbrella這款軟體。目前這款軟體已經做得很出色了，iPhone連上電腦，就能夠自動讀取ECID編號，然後從Cydia或是蘋果官方獲取特定版本的SHSH。
關於固件的恢復，也就是iOS的降級，我們仍然需要使用TinyUmbrella這款軟體。導入相應的SHSH後，即可在自己本地的電腦上模擬蘋果的認證伺服器，也就可以恢復被蘋果禁掉的固件了。
七、什麼是基帶？什麼是NOR？什麼是Seczone？什麼是NCK？
基帶就是iPhone的通訊系統，是用來控制手機通訊的程序，控制電話通訊，WiFi無線通訊，還有藍牙通訊。iPhone有相關的通訊硬體，是需要靠基帶這個通訊系統來驅動的，有了正常工作的基帶，才能打電話、收發簡訊、使用3G功能。
當然WIFI除外。基帶版本可以從iphone中設置->「關於本機」的數據機使用的版本號中查詢到。iOS和基帶相對******，協同工作。基帶升級後，很多軟解就會失效，有鎖版的iPhone便無法使用。而最嚴重的是，基帶幾乎無法降級。所以對於有鎖版的手機來說，基帶升級一定要慎重，一定要等破解後再升級。當然無鎖版也要慎重對待基帶升級。
NOR是flash內存晶元的一種。區別於Flash NAND. 但都是內存晶元。iPhone 的Baseband就使用這種flash。NOR就是存儲基帶所用的媒介。
Seczone是baseband的一個內部驗證模塊。是屬於這個通信系統的。這個認證模塊很厲害，除非是使用蘋果特定私鑰加密後生成的代碼，其他內容一律會被阻止。這樣基帶便很難被破解。而且不能暴力破解。
NCK是一個解鎖計數器。內部有一個有計數值。達到一定的數值。它將會把iPhone永久變成只能使用AT&T或其它國家合約運營商（註：這取決於你購買的國家）。
有了這些概念，我們就可以討論完美越獄了。
關於完美解鎖更深入的討論：
八、怎麼樣才能實現完美解鎖？
iPhone中baseband（基帶）的資料都存在NOR里，是的，NOR里保存了目前baseband的狀態，其中就有目前iPhone的解鎖狀態，iPhone出廠的時候，都給鎖在ATT的網路里了。 到這里有些人想問了：那麼我們把這個狀態改成解鎖，不就完美了么，是的，但是，問題是：
1，只有通過baseband的firmware，也就是baseband的操作系統，才能讀寫NOR，而且NOR中seczone的控制及其嚴格，想要直接發指令寫入，是不可能的。
2，baseband的firmware是Apple數字簽名過的，意思就是說，只有Apple自己的1024位的私匙簽名過的firmware，baseband才會運行。
3，最重要的一點，我們不知道要往NOR seczone裡面寫入什麼，才能解鎖，因為NOR seczone里數據都是加密過的，不是0就是鎖，1就是解鎖這么簡單，每台iPhone的NOR在加密前可以是一樣的，但是加密後每台都是不一樣的，而且這個加密機制，也只有通過Apple的私匙才能算出來。
那麼，想要達到完美解鎖，需要怎麼做？
實際上，你可以通過iPhone的minicom對iPhone的baseband發送指令，其中有一條指令，就是用來解鎖的，而且我們明確知道這條指令是什麼，就是： AT+CLCK=「PN」,0,「xxxxxxxx」
注意到後面那8個x了嗎？那些x就是你的解鎖碼，unlock code，或者專業說法，叫做NCK、Network Control Key，這個key每個iphone都不一樣，相信蘋果應該是用某種隨機機制生成了這些解鎖碼，然後和IMEI或者序列號掛鉤，放在自己的資料庫里，在將來，蘋果官方提供解鎖的時候，他們會通過你的IMEI或者序列號告訴你的unlock code，達到完美解鎖。
但是你發送指令的時候，你的iPhone又怎麼知道這個解鎖碼是對還是錯的？如果iPhone需要知道對錯，那麼說明iPhone自己知道unlock code，所以我們能從iPhone里某個地方找到這個code，然後完美解鎖，對嗎？不對！
實際上iPhone NOR上保存的，是這個code經過某個特殊的演算法生成的一個hash值，hash(code) ，而這個演算法是不可逆的（就像MD5）。
通俗點說，我們可以這么想，Apple教會了iPhone一套暗號，告訴iPhone 1 = 鴨子 2 = 雞 3 = 鵝，然後把暗號123這個unlock code編碼成「鴨子雞鵝」存放在Phone NOR里，這時候iPhone並不知道unlock code是123，它只知道如果別人告訴我123，我按照Apple的暗號算一下，如果算出來和」鴨子雞鵝」一樣，那麼別人告訴我的code就是對的了。當然實際上這個過程不是這么簡單，否則你一猜就能破譯這個密碼了，按照目前的計算機水平，把這個unlock code通過hash過的值逆算回來，幾乎是不可能的。
那麼，我們窮舉行嗎？不就是一個8位數嘛？我們從00000000試到99999999，總有一個對吧？這個方法理論上可以，但是實際上行不通，原因又兩個：
1，按照粗略結算，關把這些1億個指令發給iPhone嘗試，就要35天，並且還不考慮iPhone算需要多久。
2，最關鍵的，iPhone的baseband NOR seczone中，有一個NCK計數器，一旦你嘗試3–10次失敗，你的baseband將會硬體燒死在AT&T上。
所以，目前來說，iPhone完美解鎖，還沒有，相信如果Apple不出大錯誤，也不會有，除非Apple到時候官方推出解鎖，那才是完美解鎖。
九、寫在最後
這篇文章很多內容不僅僅是在介紹，更多是在告訴大家蘋果對iPhone的封閉做了多大的工作。有了這些工作，iPhone才會被限制在一個大牆內，而這堵牆讓蘋果不僅出售iPhone賺爽了，而且通過iTunes Store售賣了大量iPhone應用。而為了讓我們能夠用上更好的軟體，更開放地使用iPhone，我們需要越獄解鎖。最後，再匯總一下整個破解的流程：
提前備份好特定版本的SHSH
連接iPhone到電腦，在iTunes上做好同步
下載所需版本的固件（xxxx.ipsw）
恢復固件（對於老版本固件需要使用shsh文件和TinyUmbrella）
運行越獄軟體
在Cydia上安裝解鎖軟體
在Cydia上安裝AppSync軟體，保證所有iPhone應用能夠通過iTunes同步到iPhone中
在iTunes上恢復第二步同步了的iPhone數據
最後做一次同步，將所有存儲在iTunes里的iPhone應用同步到iPhone中
❸ Web應用安全威脅與防治——基於OWASP Top 10與ESAPI的目錄
第1篇 引子
故事一：家有一IT，如有一寶 2
故事二：微博上的蠕蟲 3
故事三：明文密碼 5
故事四：IT青年VS禪師 5
第2篇 基礎篇
第1章 Web應用技術 8
1.1 HTTP簡介 8
1.2 HTTPS簡介 10
1.3 URI 11
1.3.1 URL 11
1.3.2 URI/URL/URN 12
1.3.3 URI比較 13
1.4 HTTP消息 13
1.4.1 HTTP方法14
1.4.2 HTTP狀態碼 19
1.5 HTTP Cookie20
1.5.1 HTTP Cookie的作用22
1.5.2 HTTP Cookie的缺點23
1.6 HTTP session23
1.7 HTTP的安全 24
第2章 OWASP 27
2.1 OWASP簡介27
2.2 OWASP風險評估方法28
2.3 OWASP Top 10 34
2.4 ESAPI（Enterprise Security API） 35
第3篇 工具篇
第3章 Web伺服器工具簡介 38
3.1 Apache 38
3.2 其他Web伺服器 39
第4章 Web瀏覽器以及調試工具 42
4.1 瀏覽器簡介 42
4.1.1 基本功能 42
4.1.2 主流瀏覽器 43
4.1.3 瀏覽器內核 44
4.2 開發調試工具 45
第5章 滲透測試工具 47
5.1 Fiddler 47
5.1.1 工作原理 47
5.1.2 如何捕捉HTTPS會話 48
5.1.3 Fiddler功能介紹 49
5.1.4 Fiddler擴展功能 56
5.1.5 Fiddler第三方擴展功能 56
5.2 ZAP 58
5.2.1 斷點調試 60
5.2.2 編碼/解碼 61
5.2.3 主動掃描 62
5.2.4 Spider63
5.2.5 暴力破解 64
5.2.6 埠掃描 65
5.2.7 Fuzzer66
5.2.8 API 66
5.3 WebScrab 67
5.3.1 HTTP代理67
5.3.2 Manual Request 69
5.3.3 Spider70
5.3.4 Session ID分析71
5.3.5 Bean Shell的支持 71
5.3.6 Web編碼和解碼 73
第6章 掃描工具簡介 74
6.1 萬能的掃描工具——WebInspect 74
6.1.1 引言 74
6.1.2 WebInspect特性 74
6.1.3 環境准備 74
6.1.4 HP WebInspect總覽 76
6.1.5 Web網站測試 79
6.1.6 企業測試 86
6.1.7 生成報告 88
6.2 開源掃描工具——w3af 91
6.2.1 w3af概述 91
6.2.2 w3af環境配置 92
6.2.3 w3af使用示例 93
6.3 被動掃描的利器——Ratproxy 94
6.3.1 Ratproxy概述 94
6.3.2 Ratproxy環境配置 95
6.3.3 Ratproxy運行 96
第7章 漏洞學習網站 98
7.1 WebGoat 98
7.2 DVWA 99
7.3 其他的漏洞學習網站 99
第4篇 攻防篇
第8章 代碼注入 102
8.1 注入的分類 104
8.1.1 OS命令注入 104
8.1.2 XPath注入109
8.1.3 LDAP注入114
8.1.4 SQL注入 118
8.1.5 JSON注入131
8.1.6 URL參數注入 133
8.2 OWASP ESAPI與注入問題的預防 135
8.2.1 命令注入的ESAPI預防 135
8.2.2 XPath注入的ESAPI預防 138
8.2.3 LDAP注入的ESAPI預防 138
8.2.4 SQL注入的ESAPI預防 141
8.2.5 其他注入的ESAPI預防 143
8.3 注入預防檢查列表 143
8.4 小結 144
第9章 跨站腳本（XSS）146
9.1 XSS簡介 146
9.2 XSS分類 146
9.2.1 反射式XSS 146
9.2.2 存儲式XSS 148
9.2.3 基於DOM的XSS 149
9.2.4 XSS另一種分類法 151
9.3 XSS危害 154
9.4 XSS檢測 156
9.4.1 手動檢測 156
9.4.2 半自動檢測 158
9.4.3 全自動檢測 158
9.5 XSS的預防 159
9.5.1 一刀切 159
9.5.2 在伺服器端預防 160
9.5.3 在客戶端預防 168
9.5.4 富文本框的XSS預防措施 170
9.5.5 CSS 172
9.5.6 FreeMarker174
9.5.7 OWASP ESAPI與XSS的預防 177
9.6 XSS檢查列表 183
9.7 小結 184
第10章 失效的身份認證和會話管理 185
10.1 身份認證和會話管理簡介185
10.2 誰動了我的琴弦——會話劫持186
10.3 請君入瓮——會話固定 188
10.4 我很含蓄——非直接會話攻擊191
10.5 如何測試 199
10.5.1 會話固定測試 199
10.5.2 用Web Scrab分析會話ID 200
10.6 如何預防會話攻擊 202
10.6.1 如何防治固定會話 202
10.6.2 保護你的會話令牌 204
10.7 身份驗證 208
10.7.1 雙因子認證流程圖 209
10.7.2 雙因子認證原理說明 210
10.7.3 隱藏在QR Code里的秘密 211
10.7.4 如何在伺服器端實現雙因子認證 212
10.7.5 我沒有智能手機怎麼辦 216
10.8 身份認證設計的基本准則216
10.8.1 密碼長度和復雜性策略 216
10.8.2 實現一個安全的密碼恢復策略 217
10.8.3 重要的操作應通過HTTPS傳輸 217
10.8.4 認證錯誤信息以及賬戶鎖定 219
10.9 檢查列表 219
10.9.1 身份驗證和密碼管理檢查列表 219
10.9.2 會話管理檢查列表 220
10.10 小結 221
第11章 不安全的直接對象引用 222
11.1 坐一望二——直接對象引用 222
11.2 不安全直接對象引用的危害 224
11.3 其他可能的不安全直接對象引用 224
11.4 不安全直接對象引用的預防 225
11.5 如何使用OWASP ESAPI預防 227
11.6 直接對象引用檢查列表 230
11.7 小結 230
第12章 跨站請求偽造（CSRF） 232
12.1 CSRF簡介 232
12.2 誰動了我的乳酪232
12.3 跨站請求偽造的攻擊原理233
12.4 剝繭抽絲見真相235
12.5 其他可能的攻擊場景236
12.5.1 家用路由器被CSRF攻擊 236
12.5.2 別以為用POST你就躲過了CSRF 238
12.5.3 寫一個自己的CSRF Redirector 241
12.5.4 利用重定向欺騙老實人 243
12.6 跨站請求偽造的檢測245
12.6.1 手工檢測 245
12.6.2 半自動CSRFTester 246
12.7 跨站請求偽造的預防250
12.7.1 用戶需要知道的一些小技巧 250
12.7.2 增加一些確認操作 250
12.7.3 重新認證 250
12.7.4 加入驗證碼（CAPTCHA） 250
12.7.5 ESAPI解決CSRF 250
12.7.6 CSRFGuard 256
12.8 CSRF檢查列表 260
12.9 小結 261
第13章 安全配置錯誤 262
13.1 不能說的秘密——Google hacking 262
13.2 Tomcat那些事 264
13.3 安全配置錯誤的檢測與預防 264
13.3.1 系統配置 264
13.3.2 Web應用伺服器的配置 268
13.3.3 資料庫 282
13.3.4 日誌配置 284
13.3.5 協議 285
13.3.6 開發相關的安全配置 291
13.3.7 編譯器的安全配置 302
13.4 安全配置檢查列表 305
13.5 小結 307
第14章 不安全的加密存儲 308
14.1 關於加密 310
14.1.1 加密演算法簡介 310
14.1.2 加密演算法作用 312
14.1.3 加密分類 313
14.2 加密數據分類 314
14.3 加密數據保護 315
14.3.1 密碼的存儲與保護 315
14.3.2 重要信息的保護 323
14.3.3 密鑰的管理 336
14.3.4 數據的完整性 339
14.3.5 雲系統存儲安全 342
14.3.6 數據保護的常犯錯誤 343
14.4 如何檢測加密存儲數據的安全性 344
14.4.1 審查加密內容 344
14.4.2 已知答案測試（Known Answer Test）344
14.4.3 自發明加密演算法的檢測 345
14.4.4 AES加密演算法的測試 345
14.4.5 代碼審查 346
14.5 如何預防不安全的加密存儲的數據347
14.6 OWASP ESAPI與加密存儲 348
14.6.1 OWASP ESAPI與隨機數 353
14.6.2 OWASP ESAPI 與FIPS 140-2 354
14.7 加密存儲檢查列表 355
14.8 小結 355
第15章 沒有限制的URL訪問357
15.1 掩耳盜鈴——隱藏（Disable）頁面按鈕357
15.2 許可權認證模型 358
15.2.1 自主型訪問控制 360
15.2.2 強制型訪問控制 360
15.2.3 基於角色的訪問控制 361
15.3 繞過認證 363
15.3.1 網路嗅探 364
15.3.2 默認或者可猜測用戶賬號 364
15.3.3 直接訪問內部URL364
15.3.4 修改參數繞過認證 365
15.3.5 可預測的SessionID365
15.3.6 注入問題 365
15.3.7 CSRF 365
15.3.8 繞過認證小結 366
15.4 繞過授權驗證 367
15.4.1 水平越權 368
15.4.2 垂直越權 369
15.5 文件上傳與下載373
15.5.1 文件上傳 373
15.5.2 文件下載和路徑遍歷 377
15.6 靜態資源 382
15.7 後台組件之間的認證383
15.8 SSO 385
15.9 OWASP ESAPI與授權 386
15.9.1 AccessController的實現387
15.9.2 一個AccessController的代碼示例390
15.9.3 我們還需要做些什麼 391
15.10 訪問控制檢查列表 393
15.11 小結 393
第16章 傳輸層保護不足 395
16.1 卧底的故事——對稱加密和非對稱加密395
16.2 明文傳輸問題 396
16.3 有什麼危害398
16.3.1 會話劫持 398
16.3.2 中間人攻擊 399
16.4 預防措施 399
16.4.1 密鑰交換演算法 400
16.4.2 對稱加密和非對稱加密結合 401
16.4.3 SSL/TLS 406
16.5 檢查列表 423
16.6 小結 423
第17章 未驗證的重定向和轉發 425
17.1 三角借貸的故事——轉發和重定向425
17.1.1 URL轉發425
17.1.2 URL重定向 426
17.1.3 轉發與重定向的區別 429
17.1.4 URL 重定向的實現方式 430
17.2 危害 438
17.3 如何檢測 439
17.4 如何預防 440
17.4.1 OWASP ESAPI與預防 441
17.5 重定向和轉發檢查列表 443
17.6 小結 443
第5篇 安全設計、編碼十大原則
第18章 安全設計十大原則 448
設計原則1——簡單易懂 448
設計原則2——最小特權 448
設計原則3——故障安全化450
設計原則4——保護最薄弱環節451
設計原則5——提供深度防禦 452
設計原則6——分隔 453
設計原則7——總體調節 454
設計原則8——默認不信任454
設計原則9——保護隱私 455
設計原則10——公開設計，不要假設隱藏秘密就是安全 455
第19章 安全編碼十大原則 457
編碼原則1——保持簡單 457
編碼原則2——驗證輸入 458
編碼原則3——注意編譯器告警459
編碼原則4——框架和設計要符合安全策略 459
編碼原則5——默認拒絕 460
編碼原則6——堅持最小許可權原則 462
編碼原則7——凈化發送到其他系統的數據 463
編碼原則8——深度預防 464
編碼原則9——使用有效的質量保證技術464
編碼原則10——採用一個安全編碼規范 465
媒體評論
這是一本帶點酷酷的工程師范兒和人文氣質的「硬貨」。作為一名資深IT文藝老人，特別喜歡這種帶著思想氣息卻又有著豐富案例娓娓道來的實用信息安全書，過去卻往往只在國外作者中讀到。正如書中開頭的引子說的那樣：「家有IT，如有一寶。」那麼在Web安全日益火爆的今天，你會不會在讀完這本書後的未來也成為傳說中讓我們頂禮膜拜的大牛呢^-^
——IDF威懾防禦實驗室益雲（公益互聯網）社會創新中心聯合創始人萬濤@黑客老鷹
伴隨互聯網的高速發展，基於B/S架構的業務系統對安全要求越來越高，安全從業人員面臨空前的壓力。如何讓安全從業人員快速掌握Web應用安全？本書以詼諧、幽默的語言，精彩、豐富的實例，幫助安全從業人員從端到端理解Web應用安全。不失為近幾年Web應用安全書籍的上佳之作。
——OWASP中國區主席SecZone高級安全顧問 RIP
很樂意看到有人將自身的資深安全積累和OWASP的最佳實踐出版成書，內容嚴謹細致卻不乏生動。這本信息安全領域的實用手冊將成為銀基安全致力於互聯網安全的參考指導書目之一，我們廣泛的電信、銀行、保險、證券和政府部門等客戶都會從中受益。
——上海銀基信息安全技術有限公司首席技術官胡紹勇（Kurau）
隨著安全訪問控制策略ACL的普及應用，互聯網企業目前面臨的安全風險面主要集中在Web服務層。其中Web應用系統在架構設計、開發編碼過程中是安全漏洞和風險引入的主要階段，而普遍地我們的架構、開發、測試崗位在安全技能與意識上恰恰是相對比較欠缺的。本書詳細介紹了Web安全基礎知識、測試平台與方法，常見漏洞形式與原理，並結合OWASP最佳實踐經驗給出預防建議、設計和編碼原則等。書中舉例生動形象，圖文代碼並茂，步驟歸納清晰。特別推薦給廣大Web開發、測試、安全崗位的朋友們。
—— 中國金山軟體集團信息安全負責人程沖
在網路攻擊愈加復雜，手段日益翻新的今天，Web攻擊依然是大多數攻擊者首選的入侵手段。反思CSDN泄密及新浪微博蠕蟲事件，Web應用的安全突顯其重要性。OWASP作為全球領先的Web應用安全研究團隊，透過本書將Web應用安全的威脅、防禦以及相關的工具進行了詳細的探討和研究。詳盡的操作步驟說明是本書的亮點之一，這些詳實且圖文並茂的內容為逐步深入學習Web應用安全提供了很好的幫助。我衷心希望這本書能夠成為信息安全專業的在校生以及應用安全相關從業人員的學習指導書。
-- 上海交通大學信息安全工程學院施勇(CISSP CISA)
❹ iPhone有鎖機原理
在這里就應當了解幾個知識。
SIM卡：SIM卡是一個GSM用戶的身份證，而其中起到驗證運營商的一組字串稱為IMSI，中文意思是國際移動用戶識別碼，籠統來講就是通過這組字串可以識別出來SIM卡對應的用戶信息，包括運營商、國家、手機號碼等等。
ICCID：中文意思集成電路卡識別碼，作用是標明SIM卡的物理信息，不參與用戶進行身份信息的驗證。
IMSI：國際移動用戶識別碼。這個是區別移動用戶的標志，儲存在SIM卡中，可用於區別移動用戶的有效信息。
KI：KI的作用是SIM卡與運營商之間加密數據傳遞的密鑰，如果KI和IMSI二者匹配那麼運營商就允許用戶在網路中注冊並返回相關信息，換言之就是來信號，反之則不能使用。
如果認真閱讀會發現，整個過程中完全沒有提到手機號碼這一項。這是因為對於一張SIM卡來說裡面並沒有包含手機號碼這個欄位，手機號碼是SIM卡在網路注冊成功之後運營商返回的信息之一，也就是說手機號碼是根據IMSI來匹配給的。每次關閉信號，再重新開啟信號之後都要進行一次驗證並重新返回手機號碼，只不過一般情況下來講手機號碼和IMSI的關系是固定的。
❺ 您的internet安全設置阻止打開一項或多項文件
解決方法: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\ 該鍵值下正常情況下只有0,1,2之類的子鍵, 如果出現 0x01-0x29之間的怪異字元,就會導致某些程序無法啟動的問題. 刪除這些鍵值即可. Ref: http://surfthenetsafely.com/ieseczone3.htm =============================== Internet屬性-高級-重置IE 這個錯誤信息應該是由一個IE安全設置引起的。最簡單的解決辦法，就是重置IE。 如果想要查，可以看看HKLM和HKCU下面\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones裡面的各項下面的1806這個項。解釋為： # 1806 其他：啟動應用程序和不安全文件 1806 Miscellaneous: Launching applications and unsafe files 也有可能是Zone的設置不正確造成的。注冊表為：HKLM和HKCU下面的\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains。 英文的錯誤信息為："These files can't be opened. Your Internet security settings prevented one or more files from being opened." Ref: http://social.answers.microsoft.com/Forums/zh-CN/w7programszhcn/thread/e77c4b08-effc-4107-848e-81226d00a5ea