Server Security

Transcript

1. 服务端安全 所有的可输⼊参数，都是不可信任的。 “ “ 1
2. 通⽤的安全加固⽅法 通道安全：HTTPS ，WSS ，MQTT+SSL 加密： DES 、3DES 、AES ，RSA 、DSA 、ECC ，密钥管理 验签：DSA 、RSA ，MD5 、SHA1 、Bcrypt 业务防护：业务层需要对传⼊的参数进⾏验证，进⾏真正业务意义上 的判断。MVCC+CAS 2
3. 常⻅的攻击类型 XSS （Cross Site Script ，跨站脚本攻击） ClickJacking （点击劫持） CSRF （Cross-site request forgery ，跨站请求伪造） ⽂件上传漏洞、⽂件下载漏洞 ( ⽬录遍历攻击) 注⼊漏洞（SQL 、Command 、Code ··· ） 框架低版本漏洞 整数溢出 其他 3
4. XSS Cross Site Script 跨站脚本攻击，是最常 ⻅的⼀种攻击⽅式。 4
5. XSS 攻击是指攻击者在⽹站上注⼊恶意的客户端代码，通过恶意脚本对 客户端⽹⻚进⾏篡改，从⽽在⽤户浏览⽹⻚时，对⽤户浏览器进⾏控制 或者获取⽤户隐私数据的⼀种攻击⽅式。 攻击者对客户端⽹⻚注⼊的恶意脚本⼀般包括 JavaScript ，有时也会包 含 HTML 和 Flash 。有很多种⽅式进⾏ XSS 攻击，但它们的共同点为： 将⼀些隐私数据像 cookie 、session 发送给攻击者，将受害者重定向到 ⼀个由攻击者控制的⽹站，在受害者的机器上进⾏⼀些恶意操作。 XSS 攻击的前提： Web ⻚⾯ 且 前端使⽤ v-html （Vue ） 或产⽣ DOMXSS 。 5
6. XSS 攻击的种类 反射型 XSS 不可信内容提交到服务器，⽴即在响应中被返回。 ⽐如：有⼀个登陆⻚⾯需要输⼊⽤户名，提交后会显示 “ 你好，XXX” ，这⾥的 XXX 即有可能存在反 射型 XSS 攻击漏洞。 持久型 XSS 不可信内容提交到服务器，被保存到服务器数据库，下次需要时被当做可信内容被返回。 ⽐如：恶意代码写⼊个⼈资料⻚，所有访问我的资料的朋友都会遭到攻击 DOM XSS 通过恶意脚本修改⻚⾯的 DOM 结构，是纯粹发⽣在客户端的攻击。 存储型与反射型为服务器端安全漏洞；DOM 型为前端安全漏洞。 6
7. XSS 示例 Submit '' onclick=alert(/xss/) ⾕歌搜索被曝 XSS 漏洞， 且已存在数⽉之久 7
8. XSS 危害 Cookie 劫持（窃取 Cookie ） 后台增删改等操作（类似于 CSRF 骗取⽤户点击，利⽤ js 模拟浏览器 发包，借助 xmlhttprequest 类） 钓⻥，利⽤ XSS 构造出⼀个登录框，骗取⽤户账户密码 修改⽹⻚代码 利⽤⽹站重定向 获取⽤户信息（如浏览器信息、IP 、截屏、经纬度、电池状态等） XSS Worm （XSS 蠕⾍，XSS 漏洞利⽤的终极武器，2005 MySpace 、2019 Twitter ） 8
9. 防范 XSS 攻击 XSS 攻击的本质是不安全的 HTML 注⼊，可通过在 HTML 、CSS 、JS 或 HTTP 协议层次上进⾏防范。 预防存储型和反射型 XSS 攻击 输⼊过滤 输出检查 Cookie 中设置 HttpOnly CSP 策略 预防 DOM 型 XSS 攻击 9
10. 预防存储型和反射型 XSS 攻击 输⼊过滤 在⽤户提交时，由前端过滤输⼊，然后提交到后端。这样做是否可⾏呢？ 答案是不可⾏。⼀旦攻击者绕过前端过滤，直接构造请求，就可以提交恶意代码了。 输⼊侧过滤能够在某些情况下解决特定的 XSS 问题，但会引⼊很⼤的不确定性和乱码问题。在防范 XSS 攻击时应避免此类⽅法。 当然，对于明确的输⼊类型，例如数字、URL 、电话号码、邮件地址等等内容，进⾏输⼊过滤还是必要 的。另外，富⽂本建议使⽤⽩名单机制进⾏过滤。 注意：转义后字串⻓度会增加，可能超出数据库字段的预期⻓度导致被截断。 10
11. 输出检查 ⼀般来说，除了富⽂本的输出外，在变量输出到 HTML ⻚⾯时，可以使⽤编码或转义的⽅式来防御 XSS 攻击。 安全的编码函数： HTML 代码的编码⽅式是 HtmlEncode ，要求⾄少转换 &<>"'/ 。 JavaScript 的编码⽅式可以使⽤ JavascriptEncode 。 在 CSS 中输出在 CSS 和 style 、style attribute 中形成 XSS 使⽤ encodeForCSS() 。 在地址中输出： 在 URL 的 path （路径）或者 search （参数）中输出，使⽤ URLEncode 。 针对不同位置的输出，使⽤不同的处理⽅式。 思考：是否⽤转义就可以⾼枕⽆忧了？ 11
12. Cookie 中设置 HttpOnly HttpOnly 并⾮为了对抗 XSS——HttpOnly 解决的是 XSS 后的 Cookie 劫持攻击。 因为设置 HttpOnly 的⽅法⽐较简单，使⽤也很灵活，并且对防御 Cookie 劫持⾮常有⽤，因此已经渐渐成为⼀种默认的标准。 response.setHeader("Set-Cookie", SESSION_ID+"="+session_id+";Path=/;HttpOnly;"); cookie.setHttpOnly(true); add_header Set-Cookie "HttpOnly"; proxy_cookie_path / "/; HTTPOnly; Secure"; 12
13. CSP 策略 Content Security Policy ，实质就是⽩名单制度，开发者明确告诉客户 端，哪些外部资源可以加载和执⾏。在服务端使⽤ HTTP 的 Content- Security-Policy 头部来指定策略，或者在前端设置 meta 标签。 Content-Security-Policy: script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https: <meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:"> 脚本：只信任当前域名 <object> 标签：不信任任何 URL ，即不加载任何资源 样式表：只信任 http://cdn.example.org 和 http://third-party.org 框架（frame ）：必须使⽤ HTTPS 协议加载 其他资源：没有限制 13
14. CSP 作⽤ 严格的 CSP 在 XSS 的防范中可以起到以下的作⽤： 禁⽌加载外域代码，防⽌复杂的攻击逻辑。 禁⽌外域提交，⽹站被攻击后，⽤户的数据不会泄露到外域。 禁⽌内联脚本执⾏（规则较严格，⽬前发现 GitHub 使⽤）。 禁⽌未授权的脚本执⾏（新特性，Google Map 移动版在使⽤）。 合理使⽤上报可以及时发现 XSS ，利于尽快修复问题。 14
15. 预防 DOM 型 XSS 攻击 DOM 型 XSS 攻击，实际上就是⽹站前端 JavaScript 代码本身不够严谨，把不可信的数据当作代码执 ⾏了。 在使⽤ .innerHTML 、 .outerHTML 、 document.write() 时要特别⼩⼼，不要把不可信的数据作为 HTML 插到⻚⾯上，⽽应尽量使⽤ .textContent 、 .setAttribute() 等。 如果⽤ Vue/React 技术栈，并且不使⽤ v-html / dangerouslySetInnerHTML 功能，就在前端 render 阶段 避免 innerHTML 、outerHTML 的 XSS 隐患。 DOM 中的内联事件监听器，如 location 、 onclick 、 onerror 、 onload 、 onmouseover 等， 标签的 href 属性，JavaScript 的 eval() 、 setTimeout() 、 setInterval() 等，都能把字符串作为代码运⾏。 如果不可信的数据拼接到字符串中传递给这些 API ，很容易产⽣安全隐患，请务必避免。 驱散前端安全梦魇 ——DOMXSS 典型场景分析与修复指南 15
16. 防御 XSS 总结 HTTPS Cookie 中设置 HttpOnly 富⽂本在输⼊时使⽤⽩名单机制过滤 服务端与 H5 端配合，在输出渲染时进⾏转义 or 过滤 服务端转义、过滤⼯具：服务端- 防御 XSS 跨站脚本攻击 H5 端转义、过滤⼯具：H5-XSS 防御 H5 端⻚⾯梳理：涉及到安全问题的⻚⾯ CSP 策略 H5 端注意 DOMXSS 16
17. XSS 检测⼯具 XSStrike xssfork XSS 攻击⼩游戏 开发者在⽹站上故意留下了⼀些常⻅的 XSS 漏洞。玩家在⽹⻚上提交相 应的输⼊，完成 XSS 攻击即可通关。可以在玩游戏的过程中，加深对 XSS 攻击的理解。 alert(1) to win prompt(1) to win XSS game 17
18. ClickJacking ClickJacking （点击劫持），是⼀种视 觉上的欺骗⼿段。 攻击者使⽤⼀个透明的、不可⻅的 iframe ，覆盖在⼀个⽹⻚上，然后诱使 ⽤户在该⽹⻚上进⾏操作，此时⽤户将 在不知情的情况下点击透明的 iframe ⻚⾯。通过调整 iframe ⻚⾯的位置， 可以诱使⽤户恰好点击在 iframe ⻚⾯ 的⼀些功能性按钮上。 18
19. ClickJacking 危害 盗取⽤户资⾦ 获得⽤户的敏感信息 与 XSS 或 CSRF 等其他攻击⼿段配合 19
20. ClickJacking 防御⽅法 frame busting 通常可以写⼀段 JavaScript 代码，以禁⽌ iframe 的嵌套。这种⽅法叫 frame busting 。 但是 frame busting 也存在⼀些缺陷。由于它是⽤ JavaScript 写的，控制能⼒并不是特别强，因此有许 多⽅法可以绕过它。 HTTP 头 X-Frame-Options 它有三个可选的值： DENY ： 浏览器会拒绝当前⻚⾯加载任何 frame ⻚⾯； SAMEORIGIN ：frame ⻚⾯的地址只能为同源域名下的⻚⾯； ALLOW-FROM origin ：可以定义允许 frame 加载的⻚⾯地址。 不过这种⽅式在 HTTP 中不可靠，⿊客可以窃听篡改 HTTP 请求来修改 HTTP 头。 20
21. CSRF CSRF ，跨站请求伪造。也被称为 one-click attack 或者 session riding ，通常缩写为 CSRF 或者 XSRF 。是⼀种挟制⽤户在当前已登录的 Web 应⽤程序上执⾏⾮本意的操作的攻击⽅法。 CSRF 攻击的过程，往往是在⽤户不知情的情况下构造了⽹络请求。 它在 2007 年曾被列为互联⽹ 20 ⼤安全隐患之⼀。 即便是⼤名鼎鼎的 Gmail ，在 2007 年底也存在着 CSRF 漏洞，从⽽被 ⿊客攻击⽽使 Gmail 的⽤户造成巨⼤的损失。 21
22. CSRF 攻击原理 ⽤户登录存在漏洞的健康⽹ 站 A ； ⽹站 A 服务器验证了⽤户的 身份之后，响应该⽤户的 Cookie 作为身份凭证； 攻击⽹站 B 检查到⽹站 A 的 漏洞或者引诱⽤户在 A ⽹站 访问 B ⽹站，这样攻击⽹站 就可以带上⽤户的身份凭证 向 ⽹站 A 发起请求 ( 攻击) ； 22
23. ⼩明同学百⽆聊赖地刷着 Gmail 邮件。⼤部分都是没营养的通知、验证码、聊天记录之 类。但有⼀封邮件引起了⼩明的注意： 聪明的⼩明当然知道这种肯定是骗⼦，但还是抱着好奇的态度点了进去（请勿模仿）。 果然，这只是⼀个什么都没有的空⽩⻚⾯，⼩明失望的关闭了⻚⾯。⼀切似乎什么都没 有发⽣…… <form method="POST" action="https://mail.google.com/mail/h/ewt1jmuj4ddv/?v=prf" enctype="multipart/form-data"> <input type="hidden" name="cf2_emc" value="true"/> <input type="hidden" name="cf2_email" value="hacker@hakermail.com"/> ..... <input type="hidden" name="irf" value="on"/> <input type="hidden" name="nvp_bu_cftb" value="Create Filter"/> </form> <script> document.forms[0].submit(); </script> https://www.davidairey.com/google-gmail-security-hijack/ 甩卖⽐特币，⼀个只要 998 ！！ “ “ 23
24. CSRF 危害 攻击者盗⽤了你的身份，以你的名义发送恶意请求。 CSRF 能够做的事情包括：以你名义发送邮件，发消息，盗取你的账 号，甚⾄于购买商品，虚拟货币转账...... 造成的问题包括：个⼈隐私泄露以及财产安全。 24
25. CSRF 常⻅防御⽅法 同源策略 Origin 、 Referer ，都是⽤来表示请求源地址。在⼤多数场景中，会跟随着请求头发送到服务器，然后 服务器通过解析头部值，获取请求来源地址。⼀般来说，我们在服务器设置好允许请求地址通过的⽩名 单，然后当服务器拿到请求的来源地址，就可以进⾏过滤了。 Origin 说到 Origin ，就不得不提 CORS 了。CORS 需要浏览器和服务器同时⽀持。⽬前，所有浏览器 都⽀持该功能，~IE 浏览器不能低于 IE10~ 。⼀旦请求发⽣ CORS ，那么请求头部信息就会携带 Origin ，但是假如发⽣ 302 重定向，那么 Origin 也不会跟随着请求头部信息⼀起发送给服务器。 Referer Referer 的值是由浏览器提供的，每⼀次的 HTTP 请求⾸部中都会有该字段，不管是 Ajax 请 求，还是图⽚。既然由浏览器提供，那么就存在被攻击者刻意隐藏，甚⾄伪造 Referer 的值。 25
26. 验证码校验 ⽤户在请求的地⽅，会去请求服务器申请⼀个验证码，⼀般是图⽚； 服务器收到请求后，会随机⽣成验证码 captcha ，随后将其⽂本值以 及对应的⽤户信息缓存下来，并且将图⽚⼆进制信息响应回去； ⽤户得到图⽚验证码之后，将其⽂本信息跟随者请求⼀起带过去给服 务器； 服务器随后根据⽤户信息取出对应的验证码并且进⾏校验。 验证码实现虽然简单，但是我们不能让⽤户请求的时候都提交验证码， 这样会影响⽤户体验。因此，验证码只能作为防御 CSRF 的⼀种辅助⼿ 段，⽽不能作为最主要的解决⽅案。 26
27. CSRF Token 服务器需要⽣成⼀个通过加密算法加密的 Token ； 将该 Token 保存⾄ Cookie ，更安全⾼效的是应该保存在 Session 或 者 Redis ； 将该 Token 传给客户端，客户端在请求时要将其 Token ⼀并带上， 请求到服务器后，服务器就可以通过解密对⽐来判断该 Token 的有效 性了。 Token 虽然很有效的防御 CSRF ，但是实现复杂，不仅需要前端这边的 请求都带上 Token ，⽽且后端也需要对每个接⼝都进⾏校验，因此⼯作 量⽐较⼤。 27
28. Set-Cookie: SameSite SameSite-cookies 是 Google 开发的⽤于防御 CSRF 和 XSSI （Cross Site Script Inclusion ，跨域脚本包含）的新安全机制，只需在 Set- Cookie 中加⼊⼀个新的字段属性，浏览器会根据设置的安全级别进⾏对 应的安全 cookie 发送拦截，从 Chrome 51 开始可⽤。 SameSite Cookie 在⼦域不⽀持共享，也就是说⽗域登录后在⼦域还需 要重新登录，这显然不够友好，⽽且还存在兼容性问题。 28
29. 防御 CSRF 总结 总的来说，CSRF 危害很⼤，⽽且还跟 XSS ⼀样很难防范。 虽然说上⾯罗列的各种防御策略可以很⼤程度上防御 CSRF 攻击，但是 并⾮⼗全⼗美。所以需要根据实际情况来选择最合适的策略，这样才能 降低受到 CSRF 攻击的概率。 我们当前的策略：使⽤“ 简化版” CSRF Token 。客户端进 H5 时会换票， 顺便⽣成⼀个 CSRF Token ，之后 H5 在 1h 内拿着这个 Token 都可以请 求。 在防御 CSRF 之前，需要先防御 XSS 。 29
30. ⽂件上传漏洞 ⽂件上传漏洞是指由于程序在对⽤户⽂件上传部分的控制不⾜或者处理缺陷， ⽽导致的⽤户可以越过其本身权限向服务器上上传可执⾏的动态脚本⽂件。 这⾥上传的⽂件可以是⽊⻢，病毒，恶意脚本或者 WebShell 等。这种攻击⽅ 式是最为直接和有效的，“ ⽂件上传” 本身没有问题，有问题的是⽂件上传后， 服务器怎么处理、解释⽂件。如果服务器的处理逻辑做的不够安全，则会导致 严重的后果。 ⽂件上传漏洞本身就是⼀个危害巨⼤的漏洞，WebShell 更是将这种漏洞的利 ⽤⽆限扩⼤。⼤多数的上传漏洞被利⽤后攻击者都会留下 WebShell 以⽅便后 续进⼊系统。攻击者在受影响系统放置或者插⼊ WebShell 后，可通过该 WebShell 更轻松，更隐蔽的在服务中为所欲为。 30
31. ⽂件上传漏洞危害 上传⽂件是 Web 脚本语⾔，服务器的 Web 容器解释并执⾏了⽤户上 传的脚本，导致代码执⾏; 上传⽂件是 Flash 的策略⽂件 crossdomain.xml ，⿊客⽤以控制 Flash 在该域下的⾏为( 其他通过类似⽅式控制策略⽂件的情况类似); 上传⽂件是病毒、⽊⻢⽂件，⿊客⽤以诱骗⽤户或者管理员下载执⾏: 上传⽂件是钓⻥图⽚或为包含了脚本的图⽚，在某些版本的浏览器中 会被作为脚本执⾏，被⽤于钓⻥和欺诈。 除此之外，还有⼀些不常⻅的利⽤⽅法，⽐如将上传⽂件作为⼀个⼊⼝，溢出服务器的 后台处理程序，如图⽚解析模块；或者上传⼀个合法的⽂本⽂件，其内容包含了 PHP 脚 本，再通过“ 本地⽂件包含漏洞（Local File Include ）” 执⾏此脚本；等等。 31
32. ⽂件上传漏洞的防御⽅式 判断⽂件类型 使⽤随机数改写⽂件名和⽂件路径 ⽂件上传的⽬录设置为不可执⾏ 单独设置⽂件服务器的域名 32
33. ⽂件下载漏洞 ( ⽬录遍历攻击) ⽂件下载漏洞是因为服务器端某些程序对⽤户提交参数过滤不当造成 的，该程序⼀般具有以读取⽅式输出⽂件内容或者下载⽂件。 漏洞危害 下载服务器任意⽂件，如脚本代码、服务及系统配置⽂件等 可⽤得到的代码进⼀步代码审计，得到更多可利⽤漏洞 33
34. ⽂件下载漏洞示例 protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String root = request.getServletContext().getRealPath("/upload"); String filename = request.getParameter("filename"); File file = new File(root+"/"+filename); FileInputStream fis = new FileInputStream(file); response.addHeader("Content-Disposition", "attachment;filename=" + new String(filename.getBytes())); response.addHeader("Content-Length", "" + file.length()); byte[] b = new byte[fis.available()]; fis.read(b); response.getOutputStream().write(b); } filename = ../WEB-INF/web.xml 34
35. ⽂件下载漏洞防御 过滤 . ，使⽤户在 url 中不能回溯上级⽬录 正则严格判断⽤户输⼊参数的格式 限定⽂件访问范围（⿊名单、⽩名单） 35
36. 注⼊漏洞 常⻅的注⼊漏洞主要有以下三种 SQL 注⼊ 来⾃⽤户的数据通过字符串拼接的⽅式构筑到 SQL 语句中 代码注⼊ 来⾃⽤户的数据被⽤作程序代码执⾏ 命令注⼊ ⽤户可控的数据被直接作为系统命令在命令⾏执⾏ 36
37. SQL 注⼊ HttpServletRequest request = ...; String userName = request.getParameter("name"); Connection con = ... String query = "SELECT * FROM t_user WHERE name = '" + userName + "'"; con.execute (query); 以上代码段将⽤户输⼊的⽤户名作为 SQL 查询语句的条件 参数，在正常的⽤户名输⼊下，该查询将正确返回结果。 但当恶意⽤户能够完全控制 userName 的值，如其可设置 userName 的值为 ' OR 1 = 1; -- ，则查询语句变成 SELECT * FROM t_users WHERE name = '' OR 1=1; --' ，将 允许其访问数据库中的所有⽤户信息记录。 修复⽅案：使⽤带占位符的预编译执⾏⽅式的 SQL 语句。 37
38. 代码注⼊ 代码注⼊通过将恶意代码注⼊到应⽤程序，在应⽤程序的上下⽂中被执 ⾏恶意代码。 在 Java 应⽤程序中主要有两种⽅式可以将 Java 代码注⼊到应⽤程序 中，脚本 API 和动态 JSP ⽂件包含（include ）。如果攻击者能够知道 哪个脚本⽂件将被载⼊（load ），则恶意代码将能够被执⾏造成任意代 码执⾏漏洞。 38
39. 代码注⼊示例 右侧代码允许⽤户注⼊任意的代码，若其 中 args [0] 参数设置如下，则将允许恶意 ⽤户创建任意⽂件。 hallo'); var fImport = new JavaImporter(java.io.File); with(fImport) { var f = new File('new'); f.createNewFile(); } 修复⽅案 写死需要执⾏的命令，或通过⽩名单、预 设命令的⽅式，限制可以执⾏的命令。 39
40. 命令注⼊ 命令注⼊指应⽤程序所执⾏命令的内容或部分内容源于不可信赖的数据 源时，程序本身没有对这些不可信赖的数据进⾏正确、合理的验证和过 滤，导致程序执⾏了恶意命令，被执⾏命令拥有与 Java 应⽤具有相同 的权限等级。 命令注⼊利⽤⽤户的输⼊来执⾏ shell 命令，如 cmd.exe ，/bin/sh 等程 序被控制，可任意执⾏命令。 40
41. 命令注⼊示例 String btype = request.getParameter("test"); String cmds[] = {"/bin/bash ","test.sh"+btype}; System.Runtime.getRuntime().exec(cmds); 这时候如果传 ;rm -rf /* ，等同于 /bin/bash test.sh;rm -rf /* String btype = request.getParameter("inputparam"); String cmds[] = {"/bin/bash ","-c","sh script.sh"+btype}; 此时传⼊的参数是⽤于 bash 执⾏脚本⽂件的，但因为使⽤了 -c 参 数，使后续传⼊的参数⽤于命令执⾏，如果传⼊ ;rm -rf /* , 最后等效 于 /bin/bash –c "sh script.sh;rm -rf /*" 41
42. 命令注⼊修复⽅案 应尽量避免使⽤ Runtime 和 ProcessBuilder 来执⾏系统命令，可搜索系统是否提供 API 来完成同样的功能，如执⾏删除⽂件 rm /home/www/log.txt 的命令，可以使⽤ File.delete() 等函数来代替 ⽆法避免执⾏命令时，应当尽可能避免创建 shell 来执⾏系统命令，优先使⽤ Runtime 和 ProcessBuilder 的 字符串数组 String[] cmdarray 的 ⽅法，可⼀定程度上降低命令注⼊ 的产⽣。 最后，可考虑使⽤⽩名单的⽅式，限制可执⾏的命令和允许的参数值，或限制⽤户输⼊ 的所允许字符，如只允许字⺟数组、下划线 private static final Pattern FILTER_PATTERN = Pattern.compile("[0-9A-Za-z_]+"); if (!FILTER_PATTERN.matcher(input).matches()) { // Handle error } 42
43. 命令注⼊ 附 Java 程序中⽤来执⾏命令的 API 有： Runtime.public Process exec(String command) public Process exec(String command, String[] envp) public Process exec(String command, String[] envp, File dir) public Process exec(String[] cmdarray) public Process exec(String[] cmdarray, String[] envp) public Process exec(String[] cmdarray, String[] envp, File dir) System.exec(String str) 参考：Java OS 命令注⼊学习笔记 43
44. 框架低版本漏洞 在使⽤低版本 struts/spring/hibernate 开发的时候，低版本漏洞通常存 在任意代码执⾏、XSS 漏洞、信息泄露等其他漏洞，可能会因为低版本 漏洞问题导致业务安全问题。 漏洞示例： CVE-2018-1270 ：spring-messaging 远程代码执⾏漏洞分析预警 Apache 服务器存在⾼危提权漏洞，请升级⾄最新版本 2.4.39 修复⽅案：使⽤稳定的⾼版本框架进⾏开发，并密切关注该版本的漏洞 问题、漏洞修复规避⽅法。避免使⽤存在已知问题的低版本。 44
45. 整数溢出 整数溢出（被称为 silent killer ），包括上溢和下溢，上溢时整数会被转 化为负数，下溢时整数会变成正数。整数溢出能否被利⽤视溢出后续操 作有没改写额外的内存。 当溢出后的整数值作为数组索引（访问⾮法地址）或缓冲区⼤⼩（在 C/C++ 较常⻅）时，将导致不确定的⾏为，如程序崩溃、死循环等。在 某些情况下，整数溢出还可能引发缓冲区溢出（如通过本地⽅法调⽤ C/C++ 程序）。 45
46. 整数溢出通常源于以下三种情况： 进⾏数值间的运算（+ ，- ，× ，/ 等）时，⽐如最⼤值加 1 ； 在数值扩展或截断等类型转换后进⾏数值运算时； 符号扩展，特别是⼀个负数进⾏符号扩展到⼀个更⼤的数值类型时 通常造成以下危害： 异常的结果 / 访问⾮法地址 / 死循环 DOS （资源耗尽） 引发缓冲区溢出 （JNI 本地⽅法调⽤） 46
47. 整数溢出漏洞示例 public void update(byte[] b, int off, int len) { if (b == null) { throw new NullPointerException(); } if (off < 0 || len < 0 || off + len > b.length) { throw new ArrayIndexOutOfBoundsException(); } crc = updateBytes(crc, b, off, len); } 以上示例中，判断语句 offset + len > b.length 可能导致 offset + len 过⼤⽽溢出，从⽽不满⾜该条件，继续往下正常执⾏，可 能导致访问⾮法内存。将其改为 off > b.length – len 有效避免了整数 溢出问题。 47
48. 其他 XXE ，构造恶意的 XML 内容，进⾏读取任意⽂件、执⾏系统命令、探测内⽹端⼝、攻 击内⽹⽹站等攻击。 SSRF （Server Side Request Forgery ，服务端请求伪造），通常针对外部⽹络⽆法直 接访问的内部系统。 模版注⼊，攻击者控制要呈现的模板，注⼊可暴露上下⽂数据，甚⾄在服务器上运⾏ 任意命令的表达式。 Xpath 注⼊，利⽤恶意的 XPath 查询代码，以获得某些信息的访问权并更改这些信 息。 Web Cache 欺骗攻击 URL 重定向 配置安全 逻辑漏洞 / 业务漏洞 48
49. 安全资讯： https://www.freebuf.com/ https://www.anquanke.com/ https://www.sec-wiki.com/ https://bbs.pediy.com/ https://pivotal.io/security/ 安全学习： OWASP （Open Web Application Security Project ） https://websec.readthedocs.io/zh/latest/index.html Java 中常⻅的安全漏洞与规避⽅法 XSS 防御 防御 XSS 跨站脚本攻击 49
50. ⼯具 静态代码分析，找出安全漏洞：FindBugs 50
51. Q & A 51