//相关章节（第一章~第三章）
第一章 Web应用程序安全与风险
1.2.1 “本站点是安全的”
漏洞测试过程中出现频率（2007年~11年）：
- 跨站点脚本（XSS）（94%）
- 跨站点请求伪造（CSRF）（92%）
- 信息泄露（78%）：服务器返回的错误信息泄露配置信息等。
- 不完善的访问控制措施（71%）：未控制好用户访问数据的权限，导致用户跨权限访问数据。
- 不完善的身份认证措施（62%）：弱口令，暴力破解等。
（SSL不能抵御直接针对某个应用程序的服务器或客户端组件的攻击，也包括上述的漏洞。）
1.2.2 核心安全问题：用户可提交任意输入
核心安全问题：用户可提交任意输入
用户的干预的客户端到服务器之间的所有数据，包括请求参数、cookie、HTTP信息头等，同时还可以使用其他工具协助攻击。
（SSL无法阻止攻击者向服务器提交的专门设计输入，仅仅表示网络上其他用户无法查看或修改攻击者传送的数据）
1.2.3 关键问题因素
- 不成熟的安全意识：对安全的核心概念不了解
- 独立开发
- 欺骗性的简化
- 迅速发展的威胁形势
- 资源和时间限制
- 技术上强其所难：例仍然使用原来的技术来满足新的要求。
- 对功能的需求不断增强
第二章 核心防御机制
2.1 处理用户访问
（设计者希望是正常用户依次使用这三层安全机制，从而去实现对用户的安全用户访问； 由于设计者的设计缺陷，攻击者往往并非采用该顺序完成访问，从而形成漏洞，例如通过会话管理绕过身份验证（cookie劫持等））。
2.1.1 身份验证
处理用户访问的最基本机制，传统身份验证模型大多为要求用户提交用户名与密码，然后应用程序对其核实，确认其合法性，更为安全性的情况下，使用客户端证书，响应令牌等身份验证模型。
2.1.2 会话管理
会话本身是一组保存在服务器上的数据结构，用于追踪用户与应用程序的交互状态。
应用程序将令牌（唯一的字符串）映射到会话中。
令牌生成过程中存在的缺陷是主要的漏洞来源，使攻击者能推测出发布给其他用户的令牌，随后，攻击者再利用令牌中的缺陷接获其他用户的令牌。
2.1.3 访问控制
在确定用户身份确认的基础上，应用程序需要决定是否授权用户执行其所请求的操作或访问相关的数据。根据用户角色的不同，对其角色权限加以不同的限制。由于实现该功能的复杂性，因此该机制存在大量安全漏洞。
2.2 处理用户输入
2.2.2 输入处理方法
1. “拒绝已知的不良输入”——黑名单
对已知的非法字符串或模式进行拦截阻止，接受正常数据。
弊端：
（1）此方法是确认用户输入效率最低的方法。恶意输入可通过各类放式进行编码，或者其他不同的表现形式（大小写绕过，多重字符串等）。
（2）攻击技术的不断发展，黑名单无法防御利用现有漏洞的新型方法。
绕过举例：
SELECT被阻止，可尝试SeLeCt;（大小写绕过）
alert('xss')被阻止，可尝试prompt('xss');（非法字符替换）（prompt为js中用户交互的提示框，可达到与alert同等效果）
补充：
<script>被阻止，可尝试<scr<script>ipt>；（多重字符串绕过）
""引号被阻止,可尝试%22；（字符串编码）（如果第一层编码同样被过滤，可尝试多层绕过即对编码后的数据再次编码）
2. “接受已知的正常输入”——白名单
确认机制接受任何与白名单匹配的数据，并阻止其他数据。
在切实可行的情况下，白名单是处理潜在恶意输入的最有效的方法。
但由于应用程序需求的多样性，白名单也不是处理用户输入的万能办法。
3. 净化——编码“转义”
此方法用于需要接受无法保证其安全的数据。
目的：对数据中可能存在的恶意字符进行删除，只留下已知的安全字符，或者在进一步处理前对它进行编码或者“转义”。
基于数据净化的方法一般都非常有效，但很难应对一个输入项中容纳几种可能的恶意数据，这时，采用边界确认方法处理用户输入。
4. 安全数据处理
以不安全的放式处理用户提交的数据，是许多Web应用程序漏洞形成的根本原因。
此方法无需确认输入本身，只需确保处理过程绝对安全，即可以避免漏洞。
此方法不适用Web应用程序需要执行的每项任务，如果适用，就是一种有效的处理用户输入的方法。
5. 语法检查
攻击者正常输入数据，动机不同，通过正常的输入数据去非授权访问其他数据。（如短信验证码绕过）
2.2.3 边界确认
服务器端应用程序第一次接收用户数据的地方是一个重要的信任边界，需在此采取措施防止恶意输入。
（可理解为：提交的数据为每到达一个服务器前，对其进行处理。举例：用户查询数据，提交数据过后，在web应用程序服务器会对数据进行处理，然后提交查询语句到数据库服务器，然后对sql语句进行净化处理传到服务器，最后返回结果。）
2.3 处理攻击者
2.3.1 处理错误
过于详细的错误信息非常有利于恶意用户向应用程序发动进一步攻击。
攻击者能够利用存在缺陷的错误处理方法从错误消息中获得敏感信息。
2.3.2 维护审计日志
有效的审计日志功能应能够帮助应用程序所有者了解实际发生的情况，有效的审计日志功能一般会记录每个事件的发生时间、发出请求的ip地址和用户账户（如果通过验证）。
同时，保护不严谨的审计日志可能为攻击者提供大量信息，披露许多敏感信息，如会话令牌和请求参数等等。
2.3.3 向管理员发出警报
对入侵者攻击采取应急响应。（web应用程序防火墙的作用）
警报监控的反常事件一般包括一下几种：
- 应用反常，如收到又单独一个ip地址或用户发出的大量请求。
- 交易反常，如单独一个银行账户所转入或转出的资金数量出现异常。
- 包含已知攻击字符串的请求。
- 请求中普通用户无法查看的数据被修改。
进行实时警报的最有效方法是将其与应用程序的输入确认机制和其他控制方法紧密结合起来。
2.3.4 应对攻击
攻击无法避免，可对攻击者进行一些必要措施，如变慢攻击者提交的求请响应速度、终止会话重新登录等。
目的：为必要时采取更加严厉的措施赢得时间，阻止随意的攻击者，减少攻击危害。
阻止显而易见的攻击并不如修复应用程序中存在的所有漏洞重要。
第三章 Web应用程序技术
3.1 HTTP
3.1.1 HTTP请求
HTTP消息由一行或多行消息头(header)、强制空白行、消息主体（可选）组成。
请求行构成：
- 一个请求方法：get/post，get无请求主体，因此消息头后空白行中没其他数据。
- 请求的url：请求的资源路径，查询字符串以？标识。
- HTTP版本：HTTP1.1版本与1.0版本区别在与1.1版本必须加入host（即主机）请求头。
其他请求头要点：
Referer消息头：表示发出请求的原始URL地址（从哪里来的）。
User-Agent消息头：表示用户浏览器的客户端软件相关信息，由于历史原因，大部分浏览器均有Mozilla前缀。
Host消息头：表示指定出现在被访问的完整URL中的主机名称。
Cookie消息头：用于提交服务器向客户端发布的其他参数。
3.1.2 HTTP响应
响应行构成：
- 使用的HTTP版本。
- 请求结果的状态码。如200，表示成功提交了请求，正在返回请求资源。
- 一段文本形式的“原因短语”，说明响应状态，如OK。
其他响应头要点：
Server:表面使用的Web服务器软件。
Set-Cookie:向浏览器发送另一个cookie，它将随后向服务器发送请求中由Cookie响应头返回。
pragma:指示浏览器要不要将响应保存在缓存中。
Expires:指出响应内容过期时间，因此不应保存在缓存中。
Content-Type:表明响应返回资源的文件类型格式。
Content-Length:规定消息主体的字节长度。
3.1.3 HTTP方法
GET:获取资源，用于url查询字符串的形式向所请求的资源发送参数。
POST:执行操作。可以在URL查询字符串与消息主体中发送请求参数。
HEAD：查询资源是否存在，方法与GET相似，但不会返回消息主体。
TRACE:用于诊断，检测客户端与服务器之间是否存在任何操纵请求的代理服务器。
OPTIONS:获取服务器支持的http方法，也可以用来检查服务器性能。
PUT：上传指定资源，比较危险。
DELECT:删除指定资源，危险方法，服务器端一般会禁用该方法。
3.1.4 URL
URL：统一资源定位符，是标识Web资源的唯一标识符。
3.1.6 HTTP消息头
1.常用消息头：
- Connection:告诉通讯另一端在http传输完成后是断开TCP连接还是继续保持连接。
- Content-Encoding:指定消息主体中的内容的指定编码格式。
- Content-Length:规定消息主体的字节长度。
- Content-Type:规定消息主体的内容类型。
- Transfer-Encoding:指定为方便其通过HTTP传输而对消息主体使用的任何编码。
2.请求消息头：
- Accept:用于告诉服务器，客户端愿意接受哪些内容，如图像类型，办公文档格式等。
- Accept-Encoding:用于告诉服务器，客户端愿意接受哪些内容编码。
- Authorization:为一种内置HTTP身份验证向服务器提交证书。
- Cookie：向服务器提交它之前发布的cookie。
- Host:用于指定出现在所请求的完整URL中的主机名称。
- If-Modified-Since:浏览器最后一次收到请求的资源的时间，如果自那以后资源无变化，服务器会发送一个304响应，指向客户端使用资源的缓存副本。目的是提高性能，节约资源，不用每一次都建立TCP连接返回资源。
- If-None-match:用于指定一个实体标签。实体标签是一个说明消息主体内容的标识符。同样，最后一次收到请求的资源时，浏览器想服务器提交实体标签，服务器根据标签确定浏览器是否使用资源的缓存副本。
- Origin:用于跨域Ajax请求中。
- Referer：指示提出当前请求的原始URL。
- User-Agent：用户浏览器客户端软件的相关信息。
- X-Forwarded-For:用来指示是什么代理ip发来的。
3. 响应消息头：
- Access-Control-Allow-Origin:是否通过跨域Ajax请求获取资源。
- Cache-Control:用于向浏览器传达缓存指令（如no-cache表示不缓存）。
- ETag:指定一个实体标签，是If-None-Match消息头中提交的同一个资源,告诉服务器浏览器当前缓存中保存的是那个版本的资源。
- Expires：消息主体内容的有效时间，在这时间前，浏览器可通过缓存获取该资源。
- Location:重定向的目标地址。
- pragma：想浏览器传送缓存指令（如no-cache 不缓存）
- Server：Web服务器软件的相关信息。
- Set-cookie：向浏览器发布的cookie信息，浏览器在随后的请求中将该cookie提交给服务器。
- WWW-Authenticate:用于带401状态码的响应中，提供与服务器所支持的身份验证类型相关信息。
- X-Frame-Options:指示浏览器框架是否及如何加载当前响应。
3.1.7 Cookie
cookie一般由键值对构成，但也可包含任何不含空格的字符串。
set-cookie可选属性：
expires:设定cookie的有效时间。
domain:指定cookie的有效域，这个域必须和收到cookie的域相同，或是它的父域。
path:指定cookie的有效URL路径。
secure：要求仅能在https请求中提交cookie。
HttpOnly:设置该属性，将无法通过客户端javascript直接访问cookie。
3.1.8 状态码
100 Continue：客户端提交一个包含主体请求时发送该响应，表示已经收到请求消息头，客户端继续发送主体。
200 Ok：表示请求已经成功提交。
201 Created：PUT请求的响应返回的状态码，表示请求已经成功提交。
301 Moved Permanently：永久重定向到Location消息头中指定的URL。
302 Found：临时重定向到Location消息头中指定的URL，随后恢复原始URL。
304 Not Modified：指示浏览器使用缓存中保存的所请求资源的副本。
400 Bad Request：客户端提交无效的HTTP请求。
401 Unauthorized：服务器在许可请求前要求HTTP进行身份验证。
403 Forbidden：资源被隐藏，不允许任何人访问被请求的资源（但是该资源存在）。
404 Not Found：请求的资源不存在。
413 Request Entity Too Large：请求主体过长，服务器无法处理。
414 Request URL Too Large：请求的URL过长，服务器无法处理。
500 Internal Server Error：内部服务器错误。
503 Server Unavailable：服务不可用。
3.1.9 HTTPS
HTTPS通过安全传输机制—安全套接层（SSL）传输数据，用于保护网络传输的所有数据的隐秘性与完整性，如今SSL实际由TLS（传输层安全）代替，仍使用的SSL名称。
3.1.11 HTTP身份验证
Basic：请求消息头中随每条消息以Base64编码字符串形式发送用户证书。
NTLM：质询-响应式机制，使用Windows NTLM协议版本。
Digest：质询-响应式机制，同用户证书使用一个随机值MD5校验和。
3.2 Web 功能
3.2.1 服务器端功能
脚本语言：如PHP、VBScript和Perl。
Web应用程序平台：如ASP.NET和JAVA。
Web服务器：如Apache、IIS和Netscape Enterprise。
数据库：如MS-SQL、Oracle、Mysql。
其他后端组件：如文件系统、基于SOAP的Web服务和目录服务。