Web应用安全权威指南 笔记

Web应用安全权威指南

跳转至： 导航、 搜索

1. p41 每次会话认证完成后更改下一次的会话ID
2. p44 Cookie Monster Bug：应该指定a.co.jp的却指定成co.jp
3. php.ini：session.cookie_httponly=on（JS不能访问Cookie）
   1. 不显示错误信息：display_errors=off
4. 同源策略：外部网页JS无法访问iframe内部的内容
5. XSS：将外部JS注入到iframe内部执行（不用iframe也可以）
   1. XSS本质上是由于缺陷网站没有对用户输入做校验过滤导致的！
   2. 属性值用""括起来，并对< & "进行转义
   3. PHP htmlspecialchars
6. JS以外的跨域访问：
   1. X-Frame-Options: Deny/SameOrigin;
   2. img.src指定其他域名，请求图像时就会附带图像所在主机的Cookie（？靠）
   3. script.src：A网站嵌入B的js，则发送到B的js在A网站中执行后可附带A的cookie，从而泄露给B
      1. JSONP：不能用于传输隐私信息
   4. CSS：link元素／@import/JS addImport
   5. form.action
      1. CSRF：在用户不知情的情况下提交表单
7. PHP mb_check_encoding, mb_convert_encoding
   1. ereg --> preg/mb_ereg3
8. 二进制安全与空字节攻击（%00）
9. p88 XST：关闭TRACE方法：
   1. httpd.conf：TraceEnable Off
10. p90 script元素中的JS字符串字面量：不能出现</tag>！（JS的语法解析不是图灵完全的！）
11. URL：允许http: https: //，禁止javascript: ？
12. p94 数据先按JS字符串字面量转义（\-->\\），再按HTML转义（'-->&#39;）
    1. script元素中无需进行HTML转义，但需要注意</script>问题（我觉得这是当前浏览器实现的缺陷）
    2. p96 避免动态生成JS？
       1. 本质的困难：转义是基于正则字符串替换，而JS代码则是带有上下文结构的
       2. 将字母数字以外的字符进行Unicode转义（\uXXXX形式）——虽然安全了，但数据传输量增加了～
13. DOM based XSS（JS代码不会出现于服务器端生成的HTML中，而是在客户端浏览器上下文中执行）
14. 博客系统／ＳＮＳ：允许用户使用html标签和自定义CSS
    1. 需要能够解析HTML/CSS语法的完整解析器！
15. SQL注入
    1. ... WHERE name LIKE '%#%%' ESCAPE '#'（适用于PostgreSQL/MySQL）
       1. SQL LIKE查询最好还是换成外部独立的Lucene？
    2. 静态占位 vs 动态占位（？）
16. CSRF
    1. 原因：form.action可以指定任意URL；保存在Cookie中的会话ID会被自动发送（Referer字段不同！）
    2. 防御关键：确认请求是由用户发送的！（how？浏览器要实现“由用户意图的UI交互操作触发”比较困难）
       1. 嵌入安全Token（用POST，而不是直接GET）
       2. 让用户再次输入密码（这损害了可用性）
       3. 检查Referer
17. 不完善的会话管理
    1. 第三方获取会话ID：预测、窃取、劫持
    2. 会话ID嵌入到URL的问题（Tomcat/JSP早期就是这么做的！）：可能导致会话ID通过Referer泄露
       1. Web邮箱带有外链的邮件，诱使用户点击（现行手段：Web邮箱服务器端检测过滤，或者‘代为打开’）
    3. 将会话ID保存到Cookie？（禁用第三方Cookie，导致广告网站追踪用户）
    4. 会话固定攻击（如果会话是服务器端产生的，恶意攻击者如何预先得知这一信息呢？）
       1. 接受来源不明的会话ID是PHP的特性？（这个应该算PHP的漏洞吧）
       2. => 强制在用户登录时更换会话ID
18. 重定向相关的安全隐患
    1. 自由重定向：http://example.jp/?continue=http://trap.abc.com/ （说白了还是因为没有对外部输入进行校验）
       1. 外链警告页面
    2. HTTP消息头注入漏洞（基于外部输入产生消息响应头部？？？）
       1. st，服务器端不要这么做不就行了，扯
       2. 感觉漏洞都是因为那些PHP程序员太自由散漫了！
19. Cookie输出相关的安全隐患
    1. 不要把敏感信息存储在Cookie中，即使是加密过！
    2. p176 Padding Oracle攻击与MS10-070
20. 发送邮件的问题（不太重要，略）
    1. 邮件头注入漏洞
    2. 使用hidden参数保存收件人信息
    3. MTA的开放转发
21. 文件处理相关的问题
    1. 目录遍历（不要直接以路径指定服务器上的文件！不过PHP本身的机制确实容易导致这个问题）
       1. Options -Indexes ...
       2. 隐藏特定文件：<File "*.txt"> deny from all </Files>
    2. OS命令注入
22. 文件上传相关的问题
    1. DoS攻击
    2. 使上传文件作为脚本执行
    3. 诱使用户下载恶意文件（把js文件的MimeType设为html？或上传php/asp/jsp后缀的文件？）
       1. 图像文件中嵌入html/js代码？（这应该是IE的安全漏洞）正确设置Content-Type！
    4. 越权下载
23. include相关的问题（这又是PHP本身的漏洞吧，略）
24. eval
25. 共享资源
    1. 竞争条件漏洞（这个有点高级～）：不要使用共享变量（如Servlet成员变量）
26. 典型安全功能
    1. 隐藏邮件地址登录ID，显示公开昵称
    2. 自动登录
       1. 延长会话有效期
       2. 使用Token（注意，可将用户的多个登录视为多个会话）
       3. 使用Ticket（SSO/OpenID？）
    3. 账号管理
       1. CAPTCHA
    4. 授权
    5. 字符编码（这个部分的内容讲解很详细！！！）
       1. Shift_JIS(CP932)
          1. 非法编码：只有前置字节没有后置，如0x81；后置字节不在正确范围内，如0x81 0x21
       2. EUC_JP：US-ASCII＋2个字节的0xA1~0xFE
       3. ISO-2022-JP：7比特＋转义序列，不支持半角片假名？
       4. UTF-16：一开始就是USC-2，但后来Unicode范围扩大，也支持BMP之外的字符
          1. 代理对：预留0xD800～0xDBFF以及0xDC00～0xDFFF的区域，可表示2^20个字符
       5. UTF-8
          1. 给定任意字节，立即知道是首字节还是后置字节，不会像Shift_JIS那样发生"5C"问题
          2. ‘非最短形式’问题（引发服务器端可能不能正确过滤？但只要先字节流转到字符流码点，然后对字符做过滤就没问题）
             1. 安全检查的时候未能将0xC0 0xAF识别为0x2F，但后续处理又将它视为斜线
             2. RFC3629：将‘非最短形式’作为非法数据处理
       6. GB2312：略
          1. 问题：第一个字节和第二个字节的范围是重叠的（因此不能随机地确定字符位置）
       7. GBK
          1. 除去字节范围重叠外，第二个字节可能包含0x5C，导致PHP安全漏洞（addslashes）
          2. => 使用UTF-8
       8. GB18030
          1. 不会导致5C问题；但前2个字节和后2个可能重合，导致字符串匹配问题
       9. ‘尾骶骨’测试，避免编码自动检测