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. 博客系统/SNS:允许用户使用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. ‘尾骶骨’测试,避免编码自动检测 
作者:cteng 发表于2014-10-24 18:53:15 原文链接
阅读:46 评论:0 查看评论

你可能感兴趣的:(Web,应用,权威)