『壹』 WEB伺服器安全目前主要存在哪些問題如何增強web伺服器的安全
伺服器安全防護軟體可以使用伺服器數據保護鎖--MCK，是通過安全容器接管操作系統，讓應用在容器內運行，數據保存在容器內，容器內通過鏡像技術，實行工作場景白名單機制，並對核心數據進行加密保護，實現伺服器的最後一米安全----即使攻進來，什麼也做不了。
對外可防止木馬病毒入侵，防止核心數據被偷窺、被破壞、被篡改、被偷走！
對內可以對運維人員進行運維行為審計。
『貳』 如何讓web安全
伺服器是網路環境中為客戶機提供各種服務的、特殊的計算機系統，在網路中具有非常重要的地位，伺服器安全性顯得尤為重要。Web伺服器安全漏洞 Web伺服器上的漏洞可以從以下幾方面考慮： a.在Web伺服器上你不讓人訪問的秘密文件、目錄或重要數據。 b.從遠程用戶向伺服器發送信息時。特別是信用卡之類東西時，中途遭不法分子非法攔截。 c.Web伺服器本身存在一些漏洞，使得一些人能侵入到主機系統，破壞一些重要的數據，甚至造成系統癱瘓。 d.CGI安全方面的漏洞有： （1）有意或無意在主機系統中遺漏Bugs給非法黑客創造條件。 （2）用CGI腳本編寫的程序當涉及到遠程用戶從瀏覽器中輸入表格（Form），並進行檢索（Search index），或form-mail之類在主機上直接操作命令時，或許會給Web主機系統造成危險。提高系統安全性和穩定性 a.限制在Web伺服器開賬戶，定期刪除一些斷進程的用戶。 b.對在Web伺服器上開的賬戶，在口令長度及定期更改方面作出要求，防止被盜用。 c.盡量使FTP、MAIL等伺服器與之分開，去掉ftp,sendmail，tftp，NIS，NFS，finger，netstat等一些無關的應用。 d.在Web伺服器上去掉一些絕對不用的如SHELL之類的解釋器，即當在你的CGI的程序中沒用到PERL時。就盡量把PERL在系統解釋器中刪除掉。 e.定期查看伺服器中的日誌logs文件。分析一切可疑事件。
『叄』 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)
『肆』 WEB伺服器的安全
盜用賬號、緩沖區溢出以及執行任意命令是Web伺服器比較常見的安全漏洞。黑客攻擊、蠕蟲病毒以及木馬是網際網路比較常見的安全漏洞。口令攻擊、拒絕服務攻擊以及IP欺騙是黑客攻擊比較常見的類型。隨著網路技術的不斷發展，Web伺服器面臨著許多安全威脅，直接影響到Web伺服器的安全。因此，加強Web伺服器的安全防護是一項迫切需要的解決的時代課題。筆者結合多年的工作實踐，認為可從以下3個方面入手來加強Web伺服器的安全防護。第一，加強Web伺服器的安全設置。以Linux為操作平台的Web伺服器的安全設置策略，能夠有效降低伺服器的安全隱患，以確保Web伺服器的安全性，主要包括：登錄有戶名與密碼的安全設置、系統口令的安全設置、BIOS的安全設置、使用SSL通信協議、命令存儲的修改設置、隱藏系統信息、啟用日誌記錄功能以及設置Web伺服器有關目錄的許可權等[3]。第二，加強互聯網的安全防範。Web伺服器需要對外提供服務，它既有域名又有公網的網址，顯然存在一些安全隱患。所以，可給予Web伺服器分配私有的地址，並且運用防火牆來做NAT可將其進行隱藏；同時因為一些攻擊來源於內網的攻擊，比如把內網計算機和Web伺服器存放在相同的區域網之內，則在一定程度上會增加很多安全隱患，所以必須把它劃分為不同的虛擬區域網，運用防火牆的地址轉換來提供相互間的訪問，這樣就大大提高了Web伺服器的安全性和可靠性；把Web伺服器連接至防火牆的DMZ埠，將不適宜對外公布的重要信息的伺服器放於內部網路，進而在提供對外的服務的同時，可以最大限度地保護好內部網路[4]。第三，網路管理員要不斷加強網路日常安全的維護與管理。要對管理員用戶名與密碼定期修改；要對Web伺服器系統的新增用戶情況進行定時核對，並且需要認真仔細了解網路用戶的各種功能；要及時給予更新Web伺服器系統的殺毒軟體以及病毒庫，必要時可針對比較特殊的病毒給予安裝專門殺毒的程序，同時要定期查殺Web伺服器的系統病毒，定期查看CPU的正常工作使用狀態、後台工作進程以及應用程序，假若發現異常情況需要及時給予妥當處理[5]；因為很多木馬與病毒均是運用系統漏洞來進行攻擊的，所以需要不斷自動更新Web伺服器系統，以及定期掃描Web伺服器系統的漏洞。
Web伺服器已經成為了病毒、木馬的重災區。不但企業的門戶網站被篡改、資料被竊取，而且還成為了病毒與木馬的傳播者。有些Web管理員採取了一些措施，雖然可以保證門戶網站的主頁不被篡改，但是卻很難避免自己的網站被當作肉雞，來傳播病毒、惡意插件、木馬等等。這很大一部分原因是管理員在Web安全防護上太被動。他們只是被動的防禦。為了徹底提高Web伺服器的安全，Web安全要主動出擊。 已經檢查過網線。也試過了ping伺服器，依舊無法訪問伺服器。好消息是，已經可以將問題定位到物理伺服器或操作系統本身了。換句話說，已經可以開始集中經理對現存的問題進行排查。
接下來，才去從底層到高層的方式來逐層檢查問題，首先檢查網路介面和本地網路配置是否正常。DHCP是否啟動？Web伺服器是否指向正確的DNS伺服器？如果是這樣，可以根據使用的操作系統平台，檢查Web服務是否正常開啟。在Windows環境，需要檢查伺服器是否具有Web服務的角色。在Linux環境下，檢查會更復雜，可以試試查找http相關的文件或服務來確保伺服器是否正在運行。 如果以上方法都不奏效，檢查日誌並嘗試查明在Web伺服器宕機時日誌中記錄的那些信息。將這些信息發給在故障處理和解決領域更有經驗的專業人士，可能會獲得更多的幫助。同樣的，如果已經確認網路連接不是問題，就可以使用Wireshark抓包工具對網路中傳輸的數據進行抓取分析，以此協助處理問題。
總而言之，伺服器宕機的原因多種多樣。斷電、配置錯誤、防火牆設置錯誤、甚至是來自互聯網的惡意流量，都可能引發源站宕機並讓系統管理員們抓狂。所有這些問題都足以讓企業決策者對冗餘解決方案的設計和實施加以重視，同樣的針對故障處理流程的設計和制定，還需要根據企業自身網路的實際情況為依據。
『伍』 web安全要學什麼
Web安全的范圍實在太大，哪些先學，哪些後學,如果沒有系統的路線會降低大家效率，對於剛入門的同學們來說簡直就是「噩夢」。所以，這篇類似學習路線的文章，希望可以幫助剛入門的萌新們少走彎路。（文末附學習資料及工具領取）
首先我們來看看企業對Web安全工程師的崗位招聘需求是什麼？
1職位描述
對公司各類系統進行安全加固；
對公司網站、業務系統進行安全評估測試（黑盒、白盒測試）
對公司安全事件進行響應、清理後門、根據日誌分析攻擊途徑
安全技術研究，包括安全防範技術、黑客技術等；
跟蹤最新漏洞信息，進行業務產品的安全檢查。
熟悉Web滲透測試方法和攻防技術，包括SQL注入、XSS跨站、CSRF偽造請求、命令執行等OWSP TOP10 安全漏洞與防禦；
熟悉Linux、Windows不同平台的滲透測試，對網路安全、系統安全、應用安全有深入理解和自己的認識；
熟悉國內外安全工具，包括Kali、Linux、Metasploit、Nessus、Namp、AWVS、Burp等；
對Web安全整體有深刻理解，有一定漏洞分析和挖掘能力；
2崗位要求
根據崗位技能需求，再來制定我們的學習路徑，如下：
一、Web安全學習路徑
01 HTTP基礎
只有搞明白Web是什麼，我們才能對Web安全進行深入研究，所以你必須了解HTTP，了解了HTTP，你就會明白安全術語的「輸入輸出」。黑客通過輸入提交「特殊數據」，特殊數據在數據流的每個層處理，如果某個層沒處理好，在輸出的時候，就會出現相應層的安全問題。關於HTTP，你必須要弄明白以下知識：
HTTP/HTTPS特點、工作流程
HTTP協議（請求篇、響應篇）
了解HTML、Javascript
Get/Post區別
Cookie/Session是什麼？
02 了解如下專業術語的意思
Webshell
菜刀
0day
SQL注入
上傳漏洞
XSS
CSRF
一句話木馬
......
03 專業黑客工具使用
熟悉如何滲透測試安全工具，掌握這些工具能大大提高你在工作的中的效率。
Vmware安裝
Windows/kali虛擬機安裝
Phpstudy、LAMP環境搭建漏洞靶場
Java、Python環境安裝
子域名工具 Sublist3r
Sqlmap
Burpsuite
Nmap
W3af
Nessus
Appscan
AWVS
04 XSS
要研究 XSS 首先了解同源策略 ，Javascript 也要好好學習一下 ，以及HTML實體 HTML實體的10 或16進制還有Javascript 的8進制和16進制編碼，最終掌握以下幾種類型的XSS：
反射型 XSS：可用於釣魚、引流、配合其他漏洞，如 CSRF 等。
存儲型 XSS：攻擊范圍廣，流量傳播大，可配合其他漏洞。
DOM 型 XSS：配合，長度大小不受限制 。
05 SQL注入
所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令。你需要了解以下知識：
SQL 注入漏洞原理
SQL 注入漏洞對於數據安全的影響
SQL 注入漏洞的方法
常見資料庫的 SQL 查詢語法
MSSQL,MYSQL,ORACLE 資料庫的注入方法
SQL 注入漏洞的類型：數字型注入 、字元型注入、搜索注入 、盲注(sleep注入) 、Sqlmap使用、寬位元組注入
SQL 注入漏洞修復和防範方法
一些 SQL 注入漏洞檢測工具的使用方法
06 文件上傳漏洞
了解下開源編輯器上傳都有哪些漏洞，如何繞過系統檢測上傳一句話木馬、WAF如何查殺Webshell，你必須要掌握的一些技能點：
1.客戶端檢測繞過（JS 檢測）
2.伺服器檢測繞過（目錄路徑檢測）
3.黑名單檢測
4.危險解析繞過攻擊
5..htaccess 文件
6.解析調用/漏洞繞過
7.白名單檢測
8.解析調用/漏洞繞過
9.服務端檢測繞過-文件內容檢測
10.Apache 解析漏洞
11.IIS 解析漏洞
12.Nginx 解析漏洞
07 文件包含漏洞
去學習下
include() include_once() require() require_once() fopen() readfile()
這些php函數是如何產生文件包含漏洞, 本地包含與遠程包含的區別，以及利用文件包含時的一些技巧如：截斷 /偽url/超長字元截斷等 。
08 命令執行漏洞
PHP代碼中常見的代碼執行函數有：
eval(), assert(), preg_replace(), call_user_func(), call_user_func_array(),create_function(), array_map()等。
了解這些函數的作用然後些搞清楚如何造成的代碼執行漏洞。
09 CSRF 跨站點請求
為什麼會造成CSRF，GET型與POST型CSRF 的區別, 如何防禦使用 Token防止CSRF？
010 邏輯漏洞
了解以下幾類邏輯漏洞原理、危害及學會利用這幾類漏洞：
信息轟炸、支付邏輯漏洞、任意密碼修改、越權訪問、條件競爭、任意注冊、任意登錄、順序執行缺陷、URL跳轉漏洞.
011 XEE（XML外部實體注入）
當允許XML引入外部實體時，通過構造惡意內容，可以導致文件讀取、命令執行、內網探測等危害。
012 SSRF
了解SSRF的原理,以及SSRF的危害。
SSRF能做什麼？當我們在進行Web滲透的時候是無法訪問目標的內部網路的，那麼這個時候就用到了SSRF漏洞，利用外網存在SSRF的Web站點可以獲取如下信息。
1.可以對外網、伺服器所在內網、本地進行埠掃描，獲取一些服務的banner信息;
2.攻擊運行在內網或本地的應用程序（比如溢出）;
3.對內網Web應用進行指紋識別，通過訪問默認文件實現;
4.攻擊內外網的Web應用，主要是使用get參數就可以實現的攻擊（比如struts2，sqli等）;
5.利用file協議讀取本地文件等。
如果上述漏洞原理掌握的都差不多那麼你就算入門Web安全了。
如果看了上面你還不知道具體如何學習？可參考合天網安實驗室Web安全工程師崗位培養路徑學習：網頁鏈接
『陸』 web攻擊有哪些怎麼防護
1、DoS和DDoS攻擊（DoS(Denial of Service)，即拒絕服務，造成遠程伺服器拒絕服務的行為被稱為DoS攻擊。其目的是使計算機或網路無法提供正常的服務。最常見的DoS攻擊有計算機網路帶寬攻擊和連通性攻擊）
防範：(1) 反欺騙：對數據包的地址及埠的正確性進行驗證，同時進行反向探測。(2) 協議棧行為模式分析：每個數據包類型需要符合RFC規定，這就好像每個數據包都要有完整規范的著裝，只要不符合規范，就自動識別並將其過濾掉。(3) 特定應用防護：非法流量總是有一些特定特徵的，這就好比即便你混進了顧客群中，但你的行為還是會暴露出你的動機，比如老重復問店員同一個問題，老做同樣的動作，這樣你仍然還是會被發現的。(4) 帶寬控制：真實的訪問數據過大時，可以限制其最大輸出的流量，以減少下游網路系統的壓力。
2、CSRF(Cross Site Request Forgery)，即跨站請求偽造，是一種常見的Web攻擊，但很多開發者對它很陌生。CSRF也是Web安全中最容易被忽略的一種攻擊。
防範：(1) 驗證碼。應用程序和用戶進行交互過程中，特別是賬戶交易這種核心步驟，強制用戶輸入驗證碼，才能完成最終請求。在通常情況下，驗證碼夠很好地遏制CSRF攻擊。但增加驗證碼降低了用戶的體驗，網站不能給所有的操作都加上驗證碼。所以只能將驗證碼作為一種輔助手段，在關鍵業務點設置驗證碼。(2) Referer Check。HTTP Referer是header的一部分，當瀏覽器向web伺服器發送請求時，一般會帶上Referer信息告訴伺服器是從哪個頁面鏈接過來的，伺服器籍此可以獲得一些信息用於處理。可以通過檢查請求的來源來防禦CSRF攻擊。正常請求的referer具有一定規律，如在提交表單的referer必定是在該頁面發起的請求。所以通過檢查http包頭referer的值是不是這個頁面，來判斷是不是CSRF攻擊。但在某些情況下如從https跳轉到http，瀏覽器處於安全考慮，不會發送referer，伺服器就無法進行check了。若與該網站同域的其他網站有XSS漏洞，那麼攻擊者可以在其他網站注入惡意腳本，受害者進入了此類同域的網址，也會遭受攻擊。出於以上原因，無法完全依賴Referer Check作為防禦CSRF的主要手段。但是可以通過Referer Check來監控CSRF攻擊的發生。(3) Anti CSRF Token。目前比較完善的解決方案是加入Anti-CSRF-Token，即發送請求時在HTTP 請求中以參數的形式加入一個隨機產生的token，並在伺服器建立一個攔截器來驗證這個token。伺服器讀取瀏覽器當前域cookie中這個token值，會進行校驗該請求當中的token和cookie當中的token值是否都存在且相等，才認為這是合法的請求。否則認為這次請求是違法的，拒絕該次服務。這種方法相比Referer檢查要安全很多，token可以在用戶登陸後產生並放於session或cookie中，然後在每次請求時伺服器把token從session或cookie中拿出，與本次請求中的token 進行比對。由於token的存在，攻擊者無法再構造出一個完整的URL實施CSRF攻擊。但在處理多個頁面共存問題時，當某個頁面消耗掉token後，其他頁面的表單保存的還是被消耗掉的那個token，其他頁面的表單提交時會出現token錯誤。
3、XSS(Cross Site Scripting)，跨站腳本攻擊。為和層疊樣式表(Cascading Style Sheets，CSS)區分開，跨站腳本在安全領域叫做「XSS」。
防範：(1) 輸入過濾。永遠不要相信用戶的輸入，對用戶輸入的數據做一定的過濾。如輸入的數據是否符合預期的格式，比如日期格式，Email格式，電話號碼格式等等。這樣可以初步對XSS漏洞進行防禦。上面的措施只在web端做了限制，攻擊者通抓包工具如Fiddler還是可以繞過前端輸入的限制，修改請求注入攻擊腳本。因此，後台伺服器需要在接收到用戶輸入的數據後，對特殊危險字元進行過濾或者轉義處理，然後再存儲到資料庫中。(2) 輸出編碼。伺服器端輸出到瀏覽器的數據，可以使用系統的安全函數來進行編碼或轉義來防範XSS攻擊。在PHP中，有htmlentities()和htmlspecialchars()兩個函數可以滿足安全要求。相應的JavaScript的編碼方式可以使用JavascriptEncode。(3) 安全編碼。開發需盡量避免Web客戶端文檔重寫、重定向或其他敏感操作，同時要避免使用客戶端數據，這些操作需盡量在伺服器端使用動態頁面來實現。(4) HttpOnly Cookie。預防XSS攻擊竊取用戶cookie最有效的防禦手段。Web應用程序在設置cookie時，將其屬性設為HttpOnly，就可以避免該網頁的cookie被客戶端惡意JavaScript竊取，保護用戶cookie信息。(5)WAF(Web Application Firewall)，Web應用防火牆，主要的功能是防範諸如網頁木馬、XSS以及CSRF等常見的Web漏洞攻擊。由第三方公司開發，在企業環境中深受歡迎。
4、SQL注入(SQL Injection)，應用程序在向後台資料庫傳遞SQL(Structured Query Language，結構化查詢語言)時，攻擊者將SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令。
防範：(1) 防止系統敏感信息泄露。設置php.ini選項display_errors=off，防止php腳本出錯之後，在web頁面輸出敏感信息錯誤，讓攻擊者有機可乘。(2) 數據轉義。設置php.ini選項magic_quotes_gpc=on，它會將提交的變數中所有的』(單引號)，」(雙引號)，\(反斜杠)，空白字元等都在前面自動加上\。或者採用mysql_real_escape()函數或addslashes()函數進行輸入參數的轉義。(3) 增加黑名單或者白名單驗證。白名單驗證一般指，檢查用戶輸入是否是符合預期的類型、長度、數值范圍或者其他格式標准。黑名單驗證是指，若在用戶輸入中，包含明顯的惡意內容則拒絕該條用戶請求。在使用白名單驗證時，一般會配合黑名單驗證。
5、上傳漏洞在DVBBS6.0時代被黑客們利用的最為猖獗，利用上傳漏洞可以直接得到WEBSHELL，危害等級超級高，現在的入侵中上傳漏洞也是常見的漏洞。該漏洞允許用戶上傳任意文件可能會讓攻擊者注入危險內容或惡意代碼，並在伺服器上運行。
防範： (1)檢查伺服器是否判斷了上傳文件類型及後綴。 (2) 定義上傳文件類型白名單，即只允許白名單裡面類型的文件上傳。 (3) 文件上傳目錄禁止執行腳本解析，避免攻擊者進行二次攻擊。 Info漏洞 Info漏洞就是CGI把輸入的參數原樣輸出到頁面，攻擊者通過修改輸入參數而達到欺騙用戶的目的。
『柒』 需要考慮的web安全問題具體有哪些
1、來自伺服器本身及網路環境的安全，這包括伺服器系統漏洞，系統許可權，網路環境（如ARP等）專、網屬絡埠管理等，這個是基礎。
2、來自WEB伺服器應用的安全，IIS或者Apache等，本身的配置、許可權等，這個直接影響訪問網站的效率和結果。
3、網站程序的安全，這可能程序漏洞，程序的許可權審核，以及執行的效率，這個是WEB安全中佔比例非常高的一部分。
4、WEB Server周邊應用的安全，一台WEB伺服器通常不是獨立存在的，可能其它的應用伺服器會影響到WEB伺服器的安全，如資料庫服務、FTP服務等。
『捌』 web伺服器可能存在的安全問題有哪些
1、來自伺服器本身及網路環境的安全，這包括伺服器系統漏洞，系統許可權，網路環境（如ARP等）專、網屬絡埠管理等，這個是基礎。
2、來自WEB伺服器應用的安全，IIS或者Apache等，本身的配置、許可權等，這個直接影響訪問網站的效率和結果。
3、網站程序的安全，這可能程序漏洞，程序的許可權審核，以及執行的效率，這個是WEB安全中佔比例非常高的一部分。
4、WEB Server周邊應用的安全，一台WEB伺服器通常不是獨立存在的，可能其它的應用伺服器會影響到WEB伺服器的安全，如資料庫服務、FTP服務等。