咸鱼翻身记

开发安全

1991/6/26 面试基础

# 1.开发中有哪些常见的Web安全漏洞

通过OWASP Top 10来回答

2013版至2017版，应用程序的基础技术和结构发生了重大变化：

  • 使用node.js和Spring Boot构建的微服务正在取代传统的单任务应用，微服务本身具有自己的安全挑战，包括微服务间互信、容器 工具、保密管理等等。原来没人期望代码要实现基于互联网的房屋，而现在这些代码就在API或RESTful服务的后面，提供给移动 应用或单页应用（SPA）的大量使用。代码构建时的假设，如受信任的调用等等，再也不存在了。
  • 使用JavaScript框架（如：Angular和React）编写的单页应用程序，允许创建高度模块化的前端用户体验；原来交付服务器端处理 的功能现在变为由客户端处理，但也带来了安全挑战。
  • JavaScript成为网页上最基本的语言。Node.js运行在服务器端，采用现代网页框架的Bootstrap、Electron、Angular和React则运 行在客户端。

# 2.什么是注入攻击？举例说明

  • 什么是注入攻击？从具体的SQL注入说？

重点看这条SQL，密码输入: ' OR '1'='1时，等同于不需要密码

String sql = "SELECT * FROM t_user WHERE username='"+userName+"' AND pwd='"+password+"'";
1
  • 如何解决注入攻击，比如SQL注入？
  1. 使用预编译处理输入参数：要防御 SQL 注入，用户的输入就不能直接嵌套在 SQL 语句当中。使用参数化的语句，用户的输入就被限制于一个参数当中， 比如用prepareStatement
  2. 输入验证：检查用户输入的合法性，以确保输入的内容为正常的数据。数据检查应当在客户端和服务器端都执行，之所以要执行服务器端验证，是因为客户端的校验往往只是减轻服务器的压力和提高对用户的友好度，攻击者完全有可能通过抓包修改参数或者是获得网页的源代码后，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器等等手段绕过客户端的校验。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。但是这些方法很容易出现由于过滤不严导致恶意攻击者可能绕过这些过滤的现象，需要慎重使用。
  3. 错误消息处理：防范 SQL 注入，还要避免出现一些详细的错误消息，恶意攻击者往往会利用这些报错信息来判断后台 SQL 的拼接形式，甚至是直接利用这些报错注入将数据库中的数据通过报错信息显示出来。
  4. 加密处理：将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入 SQL 命令。
  • 还有哪些注入？
  1. xPath注入，XPath 注入是指利用 XPath 解析器的松散输入和容错特性，能够在 URL、表单或其它信息上附带恶意的 XPath 查询代码，以获得权限信息的访问权并更改这些信息
  2. 命令注入，Java中System.Runtime.getRuntime().exec(cmd);可以在目标机器上执行命令，而构建参数的过程中可能会引发注入攻击
  3. LDAP注入
  4. CLRF注入
  5. email注入
  6. Host注入

# 3.什么是CSRF,举例说明并给出开发中解决方案

你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。

  • 黑客能拿到Cookie吗?

CSRF 攻击是黑客借助受害者的 cookie 骗取服务器的信任，但是黑客并不能拿到 cookie，也看不到 cookie 的内容。

对于服务器返回的结果，由于浏览器同源策略的限制，黑客也无法进行解析。因此，黑客无法从返回的结果中得到任何东西，他所能做的就是给服务器发送请求，以执行请求中所描述的命令，在服务器端直接改变数据的值，而非窃取服务器中的数据。

  • 什么样的请求是要CSRF保护?

为什么有些框架（比如Spring Security)里防护CSRF的filter限定的Method是POST/PUT/DELETE等，而没有限定GET Method?

我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务，则不需要进行 CSRF 的保护。通常而言GET请作为请求数据，不作为修改数据，所以这些框架没有拦截Get等方式请求。比如银行系统中转账的请求会直接改变账户的金额，会遭到 CSRF 攻击，需要保护。而查询余额是对金额的读取操作，不会改变数据，CSRF 攻击无法解析服务器返回的结果，无需保护。

  • 为什么对请求做了CSRF拦截，但还是会报CRSF漏洞?

为什么我在前端已经采用POST+CSRF Token请求，后端也对POST请求做了CSRF Filter，但是渗透测试中还有CSRF漏洞?

直接看下面代码。

// 这里没有限制POST Method，导致用户可以不通过POST请求提交数据。
@RequestMapping("/url")
public ReponseData saveSomething(XXParam param){
    // 数据保存操作...
}
1
2
3
4
5

PS：这一点是很容易被忽视的，在笔者经历过的几个项目的渗透测试中，多次出现

  • 有哪些CSRF 防御常规思路？
  1. 验证 HTTP Referer 字段， 根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。只需要验证referer
  2. 在请求地址中添加 token 并验证，可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。 这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。
  3. 在 HTTP 头中自定义属性并验证
  • 开发中如何防御CSRF？

可以通过自定义xxxCsrfFilter去拦截实现， 这里建议你参考 Spring Security - org.springframework.security.web.csrf.CsrfFilter.java。

# 4.什么是XSS,举例说明

通常XSS攻击分为：反射型xss攻击, 存储型xss攻击 和 DOM型xss攻击。同时注意以下例子只是简单的向你解释这三种类型的攻击方式而已，实际情况比这个复杂，具体可以再结合最后一节深入理解。

  • 反射型xss攻击？

反射型的攻击需要用户主动的去访问带攻击的链接，攻击者可以通过邮件或者短信的形式，诱导受害者点开链接。如果攻击者配合短链接URL，攻击成功的概率会更高。

在一个反射型XSS攻击中，恶意文本属于受害者发送给网站的请求中的一部分。随后网站又把恶意文本包含进用于响应用户的返回页面中，发还给用户。

  • 存储型xss攻击？

这种攻击方式恶意代码会被存储在数据库中，其他用户在正常访问的情况下，也有会被攻击，影响的范围比较大。

  • DOM型xss攻击？

基于DOM的XSS攻击是反射型攻击的变种。服务器返回的页面是正常的，只是我们在页面执行js的过程中，会把攻击代码植入到页面中。

  • XSS 攻击的防御？

XSS攻击其实就是代码的注入。用户的输入被编译成恶意的程序代码。所以，为了防范这一类代码的注入，需要确保用户输入的安全性。对于攻击验证，我们可以采用以下两种措施：

  1. 编码，就是转义用户的输入，把用户的输入解读为数据而不是代码
  2. 校验，对用户的输入及请求都进行过滤检查，如对特殊字符进行过滤，设置输入域的匹配规则等。

具体比如：

  1. 对于验证输入，我们既可以在服务端验证，也可以在客户端验证
  2. 对于持久性和反射型攻击，服务端验证是必须的，服务端支持的任何语言都能够做到
  3. 对于基于DOM的XSS攻击，验证输入在客户端必须执行，因为从服务端来说，所有发出的页面内容是正常的，只是在客户端js代码执行的过程中才发生可攻击
  4. 但是对于各种攻击方式，我们最好做到客户端和服务端都进行处理。

其它还有一些辅助措施，比如：

  1. 入参长度限制： 通过以上的案例我们不难发现xss攻击要能达成往往需要较长的字符串，因此对于一些可以预期的输入可以通过限制长度强制截断来进行防御。
  2. 设置cookie httponly为true（具体请看下文的解释）

# 5.一般的渗透测试流程

渗透测试就是利用我们所掌握的渗透知识，对网站进行一步一步的渗透，发现其中存在的漏洞和隐藏的风险，然后撰写一篇测试报告，提供给我们的客户。客户根据我们撰写的测试报告，对网站进行漏洞修补，以防止黑客的入侵！

  • 渗透测试流程举例？

我们现在就模拟黑客对一个网站进行渗透测试，这属于黑盒测试，我们只知道该网站的URL，其他什么的信息都不知道。

  • 确定目标

    • 确定范围：测试目标的范围、ip、域名、内外网、测试账户。
    • 确定规则：能渗透到什么程度，所需要的时间、能否修改上传、能否提权、等等。
    • 确定需求：web应用的漏洞、业务逻辑漏洞、人员权限管理漏洞、等等。

  • 信息收集

    • 方式：主动扫描，开放搜索等。
    • 开放搜索：利用搜索引擎获得：后台、未授权页面、敏感url、等等。
    • 基础信息：IP、网段、域名、端口。
    • 应用信息：各端口的应用。例如web应用、邮件应用、等等。
    • 系统信息：操作系统版本
    • 版本信息：所有这些探测到的东西的版本。
    • 服务信息：中间件的各类信息，插件信息。
    • 人员信息：域名注册人员信息，web应用中发帖人的id，管理员姓名等。
    • 防护信息：试着看能否探测到防护设备。

  • 漏洞探测

  • 漏洞验证

  • 内网转发

  • 内网横向渗透

  • 权限维持

  • 痕迹清除

  • 撰写渗透测试保告

单元测试