《白帽子讲web安全》读书笔记以及读后感

因为本书作于2010年前，书中所使用的部分技术版本已经过于老旧，很多书中提到的攻击方法和绕过思路都已经严重落后，但之所以本书会成为安全界的经典必读书目，就是因为本书所讨论的安全思想尤为精华，对于企业来说的安全建设十分有用，所以我打算读这本书的过程中主要记录下来一些重要的安全思路，绕过思想，重要的烧过姿势，不回去特意记录他所有的精工代码等等

对于IT这个领域来说10年的时间足矣改变整个行业的组织架构，走了很多，也来了很多

 

 

 

第一章  我的安全世界观

1.4    安全是一个持续的过程；破除迷信，没有银弹！

1.5    安全三要素：机密性（Confidentiality）、完整性（Integrity）、可用性（Availability）

1.6    实施前的安全评估    资产等级划分：“ 互联网的安全问题，使数据安全的问题 ” 威胁分析：“ 威胁建模 ”  -> STRIDE模型、DREAD模型

1.7    白帽子兵法    Secure by default  黑名单、白名单，最小权限原则    纵深防御原则    数据与代码分离原则    不可预测性原则    

 

 

 

第二章   浏览器安全

2.1    浏览器的同源策略     （CORS漏洞）

2.2    浏览器沙箱     Chrome的多进程：浏览器进程、渲染进程、插件进程、扩展进程

2.3    恶意网址拦截：提供恶意网址黑名单组织：PhishTank

2.4   浏览器自身拦截部分恶意代码、脚本（XSS，不安全的http协议或网址）

 

 

 

第三章   跨站脚本攻击（XSS）

3.1     XSS简介  Cross Site Script    反射型XSS、存储型XSS，Dom型XSS：通过网站功能修改html的本身构造，从而造成恶意JS被执行

3.2.1    cookie中的HttpOnly可以有效防止cookie劫持

3.2.2    构造恶意GET、POST请求：用js模拟浏览器发包，从而篡改网站数据（类似于csrf）

            利用XSS获取服务器的数据（QQ邮箱）：P51代码 

            利用XSS识别用户浏览器，从而根据版本进行攻击：P53~P55

            利用XSS识别用户所有安装的软件：P55~P57

            利用XSS识获取用户真实IP：P61~P62

3.2.3    集成的XSS攻击框架：BeEF

3.2.4    XSS Worm：XSS蠕虫病毒  P64~P73

3.2.6    XSS构造技巧    利用字符编码

                                      绕过长度限制：通过location.hash绕过web日志、注释符

                                      使用<base>标签：劫持所有当前页面中使用 “ 相对路径 ” 的标签

                                      使用windows.name实现跨域传值  构造XSS

3.2.7     将鸡肋XSS漏洞变废为宝

             FLASH对的部分漏洞

             Anehta的回旋镖：XSS跳板攻击：达到让A域的xss攻击B域的目标  P83、P84、P85

3.2.8    Flash XSS

            在Flash中嵌入ActionScript脚本：  getURL("javascript:alert(document.cookie)")   将Flash嵌入页面中

            Flash危险参数：allowNetWorking

3.2.9    JS框架存在XSS漏洞：

            常见的js框架：Dojo、YUI、jQuery

3.3    XSS的防御

         HTTPOnly：P90 Cookie的使用过程  四步骤    P91 部署HttpOnly的不同语言的方法

         Apache老版本中拥有一个绕过HttpOnly的姿势

3.3.2    输入检查：  XSS Filter   

3.3.3    输出检查：  使用安全的编码函数：unicode、htmlencode、XMLencode、JSONencode

                                在XSS payload中注入解码函数，使其变成代码从而执行恶意脚本

3.3.4    正确的防御XSS   前端代码

• 在html标签中输出：htmlencode
• 在HTML属性中输出：htmlencode
• 在<script>标签中输出：htmlencode
• 在事件中输出：JavascriptEncode
• 在CSS中输出：使用EncodeForCSS函数
• 在地址中输出：URLEncode
  • 绕过思路：使用DataURI伪协议构造XSS（javascript恶意伪协议构造脚本执行

URL注入防御整体思路：检查开头、变量编码

3.3.5    处理富文本

            使用白名单原则过滤威胁标签：禁止用户使用自定义的CSS和Style      对CSS进行智能分析过滤

3.3.6    防御DOM Based XSS     分语境使用不懂得过滤函数

                                                    P106   javascript输出到HTML页面的必经之路

3.3.7    换个角度看待XSS

            从攻击过程来说：存储型比反射型更加隐蔽，更加危险

            从风险角度来说：用户之间有互动界面，就是有可能发起Worm攻击的地方    通过网站访问量来判断XSS的攻击风险

 

XSS漏洞虽然复杂，但是是可以被彻底解决的

 

 

 

第四章   跨站请求伪造

4.1    CSRF简介

         统一浏览器中在用户不知情的情况下进行恶意操作

4.2    CSRF进阶

4.2.1    浏览器的Cookie策略

• SessionCookie：浏览器生命周期内有效
• Third-partyCookie：固定时间内有效

4.2.2    P3P头副作用

            P3P头允许跨域访问隐私数据，从而可以跨域请求Set-Cookie成功

4.2.3    Get/Post 请求的CSRF

4.2.4    Flash CSRF

4.2.5    CSRF Worm     CSRF蠕虫病毒

4.2    CSRF的防御

4.3.1    验证码

4.3.2    Referer Check     

            通过请求提交的逻辑顺序判断是否为CSRF攻击请求

4.3.3    Anti CSRF Token

4.3.3.1    CSRF的本质

               csrf攻击成功的本质是：重要操作的所有参数能够被攻击者猜测到

               1.参数加密    2.使用一些随机数

               Token作为一个隐藏的input字段，放在form后面      cookie中也包含一个token

4.3.3.2    Token的使用原则

               “不可预测性原则”

                XSRF：配合XSS的CSRF攻击可以先读取到页面内容的token，然后构造一个合法的请求，从而实施绕过token的CSRF攻击

 

 

 

 

第五章   点击劫持

5.1    什么是点击劫持

         点击劫持是一种视觉上的欺骗手段

5.2    Flash 点击劫持

         可以控制用户摄像头

5.3    图片覆盖攻击

5.4    拖拽劫持与数据窃取

         浏览器所支持的Drag&Drop的API是不受同源策略所限制的     从而可以完成数据窃取的操作

5.5    触屏劫持

         一次触屏操作对应的一下四个事件：

1. touchstart   手指触屏时
2. touchend   手指离开屏幕时
3. touchmove   手指滑动时
4. touchcancel   系统可取消touch事件

5.6    防御点击劫持（ClickJacking）

         一般通过禁止跨域的iframe来防御

5.6.1    frame busting

            通过一段JS代码禁止iframe的嵌套   >>   P136

5.6.2    X-Frame-Options

1. DENY
2. SAMEORIGIN
3. ALLOW-FROM origin

 

 

 

 

第六章   HTML5安全

6.1    HTML5的新标签

6.1.1    新标签的XSS

            <video>、<audio>等危险标签

6.1.2    iframe的sandbox

            <sandbox>新标签将极大地提高使用iframe的安全性，其属性如下：

1. allow-same-oringin：允许同源访问
2. allow-top-navigation：允许访问顶层窗口
3. allow-forms：允许提交表单
4. allow-scripts：允许提交脚本

6.1.3    Link Types：noreferrer

            指定了该标签之后，浏览器在请求该标签指定地址时将不再发送Referer

6.1.4    Canvas的妙用

            <Canvas>标签让JavaScript可以在页面中直接操作图片对象

            用js在Canvas中可以用来破解验证码：https://www.cnblogs.com/gdut-link/archive/2013/01/25/2876697.html

6.2    其他安全问题

6.2.1    CORS漏洞

             跨域脚本执行漏洞：https://blog.youkuaiyun.com/Alexz__/article/details/105592105

6.2.2    postMessage——跨窗口传递消息

            postMessage允许每一个window对象往其他窗口发送文本消息，这个功能不受同源策略限制

6.2.3    Web Storage

            用于浏览器进行离线浏览操作，本地存储的功能；其也收到同源策略的限制

6.3    小结

         攻击者可能利用H5中的一些新特性来绕过一些未更新的防御方案

 

 

 

 

第七章   注入攻击

注入攻击的本质：将用户输入数据当成代码执行！

1. 用户能够控制输入
2. 将用户输入内容拼接原本上下文中出现的代码

7.1    SQL注入

         SQL注入最早出现于1998年

7.1.1    盲注

            当web关闭了错误回显时进行的攻击 

            核心思想是利用了bool值来判断SQL注入参数是否正确

7.1.2    Timing Attack

             时间盲注（边信道攻击）

             通过服务器返回时间长短的变化来判断注入语句是否执行成功

7.2    数据库攻击技巧

7.2.1    常见的攻击技巧

            sqlmap

7.2.2    命令执行

             通过MYSQL创建表进行提权

7.2.3    攻击存储过程

7.2.4    编码问题

            要解决数据库存在编码的SQL注入，需要统一数据库，操作系统，webapp所使用的字符集，以避免各层对字符理解所存在的差异。

            如何采用安全的字符过滤：根据系统所使用的不同字符集来限制用户输入数据字符允许范围，从而实现安全过滤

7.3    正确的防御SQL注入

1. 找到所有的SQL注入点
2. 修补这些漏洞   （废话）

7.3.1    适用预编译语句

            使用预编译语句，绑定变量

            不同后端语言的预编译语句  >>  P171

7.3.2    使用存储过程

            存储过程中也存在注入问题，所以应该避免在存储过程中使用动态的SQL语句

7.3.3    检查数据类型

            检查输入数据的数据类型

7.3.4    使用安全的函数

            “最小权限原则”

7.4    其他的注入攻击

7.4.1    XML注入

            XML是一种常见的标记语言，通过标签对数据进行结构化的表示      >>      XXE攻击

7.4.2    代码注入

            挂马，留后门，注意一些危险函数

7.4.3    CRLF注入

            通过%0d%0a%0d%0a插入  日志、HTTP请求包头注入攻击

            只需要处理好：\r   \n   这两个保留字符即可解决

 

理论上通过设计和实施合理的安全解决方案，注入攻击是可以彻底杜绝的

 

 

 

第八章   文件上传漏洞

8.1    文件上传漏洞概述

         用户上传了一个可执行的脚本文件，不通过此脚本获得执行服务器命令的能力

• 上传web脚本语言文件
• 上传Flash的策略文件，控制flash在该域下的行为
• 上传病毒，木马文件
• 上传文件是钓鱼图片或为包含了脚本的图片

上传webshell并getshell成功的条件：

1. 上传的web脚本能够被web容器解释执行
2. 用户能够访问到此文件

8.1.1    从FCKEditor（某用脚写的富文本编辑器）文件上传漏洞讲起

8.1.2    绕过文件上传检查功能

            绕过判断文件名后缀：截断   

                                                %00  、  0x00  、  文本溢出截断

8.2    功能还是漏洞？

8.2.1    Apache文件解析漏洞

            Apache在某些版本的解析特性是从后往前解析的

8.2.2    IIS文件解析问题

            IIS6：截断字符变成了分号：  ；

            IIS6：/*.asp/目录下的所有文件被当成ASP文件进行解析

            通过PUT方法上传文件并成功解析：P185-P187

8.2.3    PHP CGI路径解析问题

            访问：http://xxxx.com/path/test.jpg/notexist.php时（notexist.php文件并不存在），便会将test.jpg当成php文件进行解析

            该问题出现的原因与PHP获取环境变量的方式有关

8.2.4    利用上传文件钓鱼

            利用XSS。302跳转等功能进行钓鱼操作

8.3    设计安全的文件上传功能

1. 文件上传目录设置为不可执行
2. 判断文件类型
3. 使用随机数改写文件名和文件路径
4. 单独设置文件服务器的域名

8.4    小结

         利用文件上传功能可以跨越信任边界，如果应用缺乏安全检查，或是安全检查出现问题，就有可能导致极其严重的后果

 

 

 

第九章   认证与会话管理

9.1    who am i 

         Authentication：认证

         Authorization：授权

         认证的目的是为了认出用户是谁，而授权的目的是为了决定用户能够做什么

         认证实际上就是一个验证凭证的过程        通过凭证数量可以划分为：单因素认证、多因素认证

9.2    密码那些事儿

         密码必须以不可逆的加密算法，或是单向散列函数算法，加密后存储在数据库中

9.3    多因素认证

         提高了攻击门槛

9.4    Session与认证

         不可能每次浏览器全球界面时都在使用密码认证一次，认证成功在之后需要替换一个对用户透明的凭证：Session ID

         用户登录之后，服务器端就会创建一个新的会话：Session，其中会保存用户的状态和相关信息，用于确定那个用户登录当前的页面；

         为了告诉服务器应该是用哪一个Session，浏览器需要吧当前用户持有的Session ID 告知服务器

         最常见的做法是吧Session ID加密后保存在Cookie中（也可以保存在URL之中，不安全的做法）

9.5    Session Fixation 攻击    （点击盗号）

         如果登陆前后用户的Session ID没有发生变化，则会存在Session Fixation的问题

         若此时SessionID保存在URL之中，点击该恶意的URL即可向服务器认证该恶意的SessionID，而服务器端Session未所改变，故此时黑客可以通过黑客已知的恶意Session登录到用户的账号

9.6    Session保持攻击

         服务器端对于活动的Session一直不销毁，攻击者可以通过此有效的Session一直使用用户的账户，成为永久的 “ 后门 ” 

         维持的方法：通过不停地发起访问请求，让Session一直活下去

         也可以通过发送带有自定义Cookie头的HTTP包保活

         通过JS代码实现XSS攻击后的Cookie设置为永不过时（重新赋值cookie的过期时间）  >>   P201

9.7    单点登录

         用户登录一次就可以访问所有的系统

 

 

 

第十章   访问控制

web安全中，权限控制都可以归结为访问控制的问题

10.1    What can i do 

           网络层的访问控制一般通过路由器或防火墙设备的，基于IP的访问控制实现      ACL

           r 读   w 写   x 执行    

           文件拥有者、文件拥有者所在的用户组、其他用户

10.2    垂直权限管理

           “ 基于角色的访问控制 ”

          系统所有用户被分配到不同的角色，一个用和可能拥有多个角色，每个角色拥有不同的权限（高低之分）；在系统认证权限时，只需要认证用户所属的角色就可以进行授权操作

10.3    水平权限管理

           “ 基于数据的访问控制 ”

          考虑实现某规则引擎，将访问控制规则写在配置文件之中，通过规则引擎的访问进行控制

10.4    OAuth

           OAuth致力于让授权访问使得互联网变得更加开放   >>   P214-P218

           P218  OAuth库的调用 

10.5    小结

          注意“ 最小权限原则 ”

 

 

 

第十一章   加密算法与随机数

涉及到浅显的密码学知识

11.1    概述

          常见的加密算法分为   

• 分组加密算法：基于“分组”进行加密操作，具有继承性和连贯性
• 流密码加密算法：每次只处理一个字节，秘钥独立于消息之外

           针对加密算法的攻击种类：

1. 唯密文攻击
2. 已知明文攻击
3. 选择明文攻击
4. 选择密文攻击

11.2    Stream Cipher Attack  流密码攻击

           流密码的加密是基于 异或

11.2.1    重复秘钥攻击

              使用同一个秘钥进行多次加密/解密，则会存在此威胁

              P222-P227   当使用重复秘钥进行加密时，我们可以通过XOR异或运算还原出密文

11.2.2    比特翻转攻击

              概念：攻击者在不知道明文的情况下，通过改变密文，使得明文按照需要的方式发生改变

              防御手段：验证密文的完整性

11.2.3    弱随机IV问题             IV是初始向量，用于加密算法中的初始值形成

             可以通过暴力破解加密函数的authcode()中使用的4字节的IV值，来找到重复的IV

11.3    WEP破解      wep：无线加密传输协议

          一种流密码攻击，破解无线网络秘钥

          wep采用RC4算法，24bit的IV；假设一个AP，以11Mbps发送1500bytes的数据，则 1500*8/(11*10^6)*2^24 = ~18000秒，约为5个小时，就会消耗光IV，从而出现重复数值的IV，一旦出现重复的IV，我们便可以通过重复秘钥攻击的算法找到相同的IV，构造出同样的CRC-32校验值，破接出该密文的明文       破解算法    >>   P233-P236

11.4    ECB模式的缺陷

           常见的加密模式：ECB（明文与密文的分组的位置一一对应）、CBC（一种链式加密，分组前后相互关联，一个字节变化会导致整个密文发生变化）、CFB、OFB、CTR

           ECB模式是一种最简单的加密模式，每一个加密的分组相互独立，前后不相关联，故只要攻击者对调任意分组的密文，在家过节米之后，所得到的明文的顺序也是经过对调的     BLOCK1未影响到BLOCK2的结果

          对于ECB模式来说,改变分组密文的顺序，也将改变解密后的明文顺序，替换某个分组密文，解密后该对应分组的明文也会被替换，而其他分组不受此影响

          所以，当需要加密的明文多余一个分组的长度是，应该避免使用ECB模式

11.5    Padding Oracle Attack

           这种攻击方式可以在不知道秘钥的情况之下，通过对Padding bytes的尝试，还原出明文，或者构造出明文的密文

           Padding：没一个分组最后面的填充字段（字段不满时）

          实质上是一种边信道攻击，攻击者只需要知道密文的解密结果是否正确即可   >>   P240-P245

          自动化破解CBC加密模式的工具  >>   P245-P251

11.6    密钥管理

          密码系统的安全性应该依赖于密钥的复杂性，而不该依赖于算法的保密性

          密钥管理中最常见的错误，就是将密钥硬编码在代码里     密钥应当保存在配置文件或是数据库中

          密钥管理的主要目的，是为了防止密钥从非正常的渠道泄露

11.7    伪随机数问题

11.7.1    弱伪随机数的麻烦

11.7.2    时间真的随机吗

11.7.3    破解伪随机数的种子（seed）

             种子一旦确定，通过统一伪随机数算法出来的随机数中，结果将会是相同的，顺序也是固定的

11.7.4    使用安全的随机数

11.8    小结

1. 用好加密算法
2. 做好密钥管理
3. 生成强壮的随机数

          加密算法的使用教条   >>   P266

 

 

 

第十二章   web框架安全

12.1    MVC框架安全

           MVC框架 = Model-View-Controller

1. View负责用户视图，页面展示等工作

2. Controller负责应用的逻辑实现，接受View层传入的用户请求，并转发给对应的Model做处理

3. Model层负责实现模型，完成数据处理

 

            在MVC框架中通常通过过滤、切片等方式对数据进行全局处理 

            一个优秀的安全方案，是在正确的地方做正确的事情

            web安全问题可以由一个框架去统一解决

12.2    模板引擎与XSS防御

           在VIEW层，可以解决XSS问题

           在使用框架时，不可盲从官方指导文档

12.3    Web框架与CSRF防御    

           在web框架中可以使用security token解决CSRF攻击的问题    

           security token的私密性、不可预测原则，是防御CSRF攻击的基础

1. 在session中绑定token

2. 在form表单中自动填入token字段

3. 在Ajax请求中自动添加token

4. 在服务器端对比POST提交参数的token与session中绑定的token是否一致，已验证CSRF攻击

12.4    HTTP HEADERS 管理            

           web框架可以通过封装，从而防御点击劫持

12.5    数据持久层与SQL注入

           使用ORM框架对SQL注入的防御是有积极的意义 

12.6    还能想到什么

           首先建立威胁模型，然后再判断那些威胁是可以在框架中得到解决

12.7    web框架自身安全

12.7.1    Strust 2 命令执行漏洞

              CVE-2010-1870

12.7.2    Strust 2 问题补丁

12.7.3    Spring MVC 命令执行漏洞

              CVE-2010-1622

12.7.4    Django 命令执行漏洞

 

 

 

第十三章   应用层拒绝服务攻击

13.1    DDOS简介

           分布式拒绝服务，全程：Distribution Denial of Service

           DDOS本是利用合理的请求造成请求资源过载，导致服务不可用 

           常见的网络层DDOS种类：SYN Flood、UDP Flood、ICMp Flood

           SYN Flood：攻击者大量发送这种伪造源地址的SYN请求，服务器端将会消耗非常多的资源（CPU和内存）来处理这种半连接，同时还要不断地对这些IP进行SYN+ACK重试。最后的结果将是服务器无暇理睬正常的连接请求，导致拒绝服务

           对抗SYN Flood：为每一个IP分配一个“cookie”，结合DDOS的攻击特征，对流量进行清洗、增加带宽、提高服务器的性能

13.2    应用层DDOS

          发起攻击的IP都是真实的

           当今所有的商业抗D设备对抗应用层攻击都缺乏有效的手段 

13.2.1    CC攻击           

              原理：对一些消耗资源大的应用界面不断发起正常的请求，已达到消耗服务端资源的目的

              或者是攻击一个大流量的网站，篡改界面，将巨大的流量分流到目标网站

              解决办法：优化服务区性能、将使用频率搞得请求放入memcache   

13.2.2    限制请求频率

             最常见的针对应用层的抗DDOS攻击措施，是在应用中针对每一个“客户端”做一个请求频率的限制 

             通过IP地址与Cookie定位一个客户端，若某时间段内的请求频率超过一个阈值，便会重定向到一个出错界面

13.2.3    道高一尺魔高一丈

1. 应用代码要做好性能优化

2. 网络架构上做好优化

3. 实现一些对抗手段，比如限制IP频率

13.3    验证码那些事儿

13.4    防御应用层DDOS

           通过让浏览器自己执行一端JS从而判断是否为真实的客户端浏览器

           在Apache的配置文件中也有专门的抗D模块

           Yahoo实现了一套算法：根据IP地址，Cookie等信息，可以计算出客户端的请求评率并进行拦截

13.5    资源耗尽攻击

13.5.1    Slowloris攻击

              原理：通过极低速率往服务器发送一个畸形的HTTP请求（\r\n），从而可以保持住这个连接

             拒绝服务攻击的本质，实际上是对有限资源的无限滥用

13.5.2    HTTP POST DOS

             通过制定一个非常大的Content-Length值，以很低的速率发包，占用住WebServer的所有可用连接，从而导致Dos攻击

13.2.3    Server Limit Dos

             一种Cookie造成的DOS攻击

13.6    一个正则引发的血案

           通过大量的正则查询消耗服务器的资源

           本质上是一种代码层面的缺陷

 

 

 

第十四章   PHP安全

14.1   文件包含漏洞

          PHP内常见的文件包含函数：

• include()

• require()

• include_once()

• require_once()

         当使用这四个函数包含文件时，PHP的内核不会在意被包含的文件是什么类型，会当做PHP代码进行执行

         要利用文件包含的条件：

1. include()等危险函数能通过动态变量方式引入需要包含的文件

2. 用户能够控制该动态变量 

14.1.1   本地文件包含

            LFI漏洞

            使用截断操作，让php不去执行后面的代码串：%00截断、0x00截断、字符溢出截断

            Windows下的目录应用分号隔开，Linux下的目录应用冒号隔开

            防御文件包含：应该尽量避免包含动态的变量

14.1.2 远程文件包含

          若PHP配置选项allow_url_include为ON的话，include()/require()函数是可以加载远程文件的 

14.1.3    本地文件包含利用技巧

• 包含用户上传文件

• 包含data://或php://input等协议

• 包含Session文件

• 包含日志文件，如：Web Server的access log等

• 包含/proc/self/environ 文件（通过UA写入脚本）

• 包含上传的临时文件

• 包含其他应用创建的文件，比如数据库文件，缓存文件，应用日志等

14.2    变量覆盖漏洞

14.3    代码执行漏洞

14.3.1    “危险函数”执行代码

14.3.1.1    PHPadmin3.4.3.1 远程代码执行漏洞

                CVE-2011-2505

14.3.1.2    MyBB1.4远程代码执行漏洞

14.3.2    “文件写入”执行代码

14.3.3    其他执行代码的方式

• 直接执行代码函数

• 文件包含

• 本地文件写入

• preg_replace()代码执行

• 动态函数执行

• Curly Syntax

• 回调函数执行代码

• unserialize()导致代码执行  反序列化漏洞

14.4    定制安全的PHP环境

 

 

 

 

第十五章   Web Server配置安全

15.1    Apache安全

           Web Server主要关心两点：webserver本身是否安全、webserver能否提供可使用的安全功能

           检查Apache的Module安装情况：最小权限原则

           Apache还提供了一些配置参数，可以用来优化服务器的性能，以对抗DDOS攻击

           保护好web log，最好做到云备份日志

15.2    Nginx安全

           及时升级至最新版本

           由于“破窗效应”未来发现的漏洞会越来越多

15.3    JBoss远程命令执行

          JBoss是J2EE环境中一个流行的web容器 

          及时删除后台导入war包配置界面：JMX-Console

15.4    Tomecat远程命令执行

          及时删除后台页面：Tomecat Manager 

15.5    HTTP Parameter Pollution HTTP参数污染

          在SQL注入中曾经使用到

          P364   >>>>  HPP规律表

 

 

 

第十六章   互联网业务安全

16.1    产品需要什么样的安全

          安全是产品的一个特性 

16.1.1    互联网产品对安全的需求

             当一个产品其他方面都做得很好的时候，安全就会成为这个产品的核心竞争力

16.1.2    什么是好的安全方案

            优秀的安全方案：良好的用户体验、优秀的性能

            如果我们的产品能够潜移默化的培养出用户的安全习惯，将用户往更安全的行为上面引导，那么这样的安全就是理想的产品安全

16.2    业务逻辑安全

16.2.1    永远改不掉的密码

16.2.4    关于密码取回流程

16.3    账户是如何被盗的

16.3.1    账户被盗的途径

• 无HTTPS

• 木马病毒

• 暴力破解

• 钓鱼网站

• 密码取回流程的逻辑漏洞

• XSS客户端脚本漏洞

• SQL注入服务器端漏洞  -> 信息泄露

16.3.2    分析账户被盗的原因

             客服、日志中取证、打入黑产内部

16.4    互联网的垃圾

16.4.1    垃圾的危害

16.4.2    垃圾的处理

16.5    关于网络钓鱼    

16.5.3    钓鱼网站的防控

16.5.3.3    用户教育

16.3.3.4    自动化识别钓鱼网站

16.6    用户隐私保护

16.6.2    如何保护用户隐私

             首先，用户应该拥有知情权和选择权 

             其次，网站应该妥善保管收集到的个人数据，不得将数据用于任何指定范围之外的用途 

16.6.3    Do-Not-Track

              不要追踪用户信息 

 

 

 

第十七章   安全开发流程

17.1    SDL简介

          微软提出的“安全开发生命周期”  >>   P402

          SDL试图从根源上解决安全问题

          项目发布后在执行漏洞修复计划将会是项目发布前的30倍成本

          微软的SDl细化的16个过程  >>  P403

17.2    敏捷SDL

          简化版的SDL流程    快速发布

17.3    SDL实战经验

• 准则一：与项目经理进行充分的沟通，排出足够的时间

• 准则二：规范公司的立项流程，确保所有的项目都能够通知到安全团队，避免遗漏

• 准则三：树立安全部门的权威，项目必须由安全部门审核完了之后才能够发布

• 准则四：将技术方案写入开发、测试的工作手册之中

• 准则五：给工程师培训安全的方案

• 准则六：记录所有的安全bug，激励程序员板鞋安全的代码

17.4    需求分析与设计阶段

           在需求逻辑处注意避免漏洞

17.5    开发阶段

          “ 安全是为业务服务 ”

17.5.1    提供安全的函数

              将安全方案写入开发规范之中，就真正的让安全方案落地

17.5.2    代码安全审计工具

17.6    测试阶段

           渗透测试对于代码审计的优点：

1. 有部分代码逻辑较为复杂，通过审计难以发现所有的问题

2. 有一些逻辑漏洞通过安全测试可能更快的得到结果

 

 

 

第十八章   安全运营

三分技术，七分管理

“ 安全是一个持续的过程 ”

18.1    把安全运营起来

           SDL  >>  防御手段  >>  应急响应 

18.2    漏洞修补流程

          适用于大型企业

          建立漏洞修补流程： 

• 建立类似于bugtracker的漏洞跟踪机制，并为漏洞的紧急程度选择优先级

• 建立漏洞分析机制，并与程序员一起指定修补方案，同时review补丁的代码实现

• 对曾经出现的漏洞进行归档，并定期统计漏洞的修补情况

18.3    安全监控   ->   态势感知

18.4    入侵检测

           IDS、IPS、DDOS监控

 

18.5    应急响应流程

• 邮件报警

• IM报警

• 短信报警

           简历应急响应小组  >>  P429

 

 

 

作者谈企业安全的发展方向：

• 第一个目标：让工程师写出的每一行代码都是安全的

• 第二个目标：让所有已知的，未知的攻击，都能在第一时间发现，并迅速报警和追踪

• 第三个目标：让安全成为公司的核心竞争力，深入到每一个产品特性之中，更好的引导用户使用互联网的习惯

• 最后一个目标：能够观测到整个互联网安全趋势的变化，最未来某一时间段的风险做出预警

 

 

 

 

 

 

之所以这么大费周折的吧书上涂涂画画的笔记，一个个字的手敲到这他妈该死的优快云上（之中有一次打了将近两个小时，然后突然给我强制退出了，Chrome无响应？MTF），主要还是因为这本书在我心中的重要程度

安全这条路除了那时候和王sir学了一个多月的时间，其余的大部分都是自己自学的，能够自学一门专业（偏门）到行业内的程度，不免的是不是在心中偷偷窃喜（请给我一巴掌）

但是野路子和学院派最大的区别还是在于，知识学习过程的由浅入深，成不成体系的问题。很明显，我这种自闭搞出来的水平深度和广度不能和各个高等院校的信息安全相关专业的同学相提并论，这个时候就非常需要一本能够概括整个行业领域内知识的“教材”，这本书就成为了我的教材

几乎每一个字的看过，从第一页到最后一页，整本书涂涂画画不堪入目，最后选择用电子版的方式，吧做过的标记都记录在赛博世界中，无非就是为了做到”看过一遍，在复习一遍”的效果

这看起来真的很低效率，很无用功的东西，我也不知道为什么拍那片执意要打出来，当然我也承认，在技术钻研的过程当然是要经历很多低效率，无用功的事情，就当是一步一个脚印，先把安全行业摸个门清儿，打好最坚实的基础吧（这本书讲的就是很基础，很多地方就是点到为止，而且也差不多10年的时间了）

 

永远都不知道未来将如何发展，总之踏踏实实的走下去，浪费大量的时间在这上面，坚信10000小时原则，总不会是错误的

“ 我要相信我所做的事情仍有意义，世界依然存在 ”

————Alexz  2020.6.23 22:05 于望京SOHO

 

 

 

 

 

————截自克里斯托弗·诺兰《记忆碎片》