Web常见漏洞汇总

Web常见漏洞汇总

Web漏洞核心

• 可控变量（攻击者通过改变变量的值，来达到攻击目的）
• 特定函数-函数多样化（不同的功能导致不同的函数，不同的函数导致不同的漏洞）
• Web攻防主要在以下五个方面出现问题：
  • 网站源码
  • 中间件
  • 数据库
  • 开发语言
  • 第三方插件或软件

SQL注入

代码里包含数据库的相关操作，可能会存在此漏洞，具体：

• 增
• 删
• 改
• 查
• 通过SQL注入，会产生"万能密码"的安全隐患，核心问题就是服务端没有采用预编译的SQL语句。用户输入不是作为参数而是直接拼接在了SQL语句当中。

文件类

代码里包含文件的相关操作，可能会存在此漏洞，具体：

• 任意文件上传
  • 引入外部的编辑器（测试核心在于：编辑器）
  • 框架自带（测试核心在于：框架）
  • 自写代码（测试核心在于：代码）
• 任意文件下载
  • 直连URL下载（更安全）
  • 参数下载
• 任意文件包含（包含文件实际上就是执行该文件）
  • 本地文件包含
  • 远程文件包含
• 任意文件读取/写入
  • 文件读取
  • 文件写入
• 任意文件删除
  • 文件删除
  • 文件夹删除

输入/输出类

• XSS跨站脚本
  • 反射型XSS跨站脚本（js代码没有存储到数据库）（搜索框）
  • 存储型XSS跨站脚本（js代码存入数据库，每刷新页面就会执行植入的js代码）（留言板）
• XSS跨站脚本的根本条件
  • 你在页面上输入的内容，一定要在这个页面上显示
  • 更通俗：网站获取你的内容，在页面上显示
  • 你可以控制页面显示的内容

CSRF

• CSRF跨站点请求伪造

登录验证类

• cookie：用于身份验证，存储到客户端浏览器内
• session：也用于身份验证，存储到服务端服务器内
• 上述两个身份验证方式都有安全隐患，具体可以表现为：
  • cookie修改（通过修改数据包中的cookie值，来达到绕过验证的目的）
    • 这种方式从根本上说就是服务端在设置验证的时候，对于其他页面只验证了cookie中的指定参数是否有值，而不进行数据库的判断，因此我们只需要修改cookie值，就可以绕过验证。
  • cookie伪造
  • cookie盗取
    • 这种方式就是：攻击者通过xss脚本等其他的方式获取了用户浏览器中的cookie，从而绕过验证。
  • session劫持（会话劫持）
    • 由于session在成功建立连接后，会依靠sessionID来进行验证。每次重新建立连接后，sessionID都会发生变化。因此，攻击者可以劫持用户登录成功之后的sessionID，依靠此sessionID来绕过验证。（前提：该用户没有断开与服务器的连接）
• 验证码：验证码设计的根本目的就是：防止爆破攻击。但是，验证码如果设计不当，也会存在绕过的可能性。
  • 验证码复用问题导致绕过。验证码复用问题指：每一次登录的时候，验证码没有进行改变，导致攻击者第一次登录，输入了正确的验证码，但是之后的登录中，服务端的验证码一直没有发生变化，因此攻击者就可以复用这个验证码来实现爆破攻击。
  • 验证码识别问题。有些验证码非常简单，因此攻击者每一次登录的时候，可以通过插件来识别验证码的内容，从而实现绕过。
• 如何判断用户的身份？
• 由于后台本身有多个功能文件页面
  • 在每个文件里面添加判断代码
  • 创建一个文件专门用来判断，其他文件包含调用它
• 如何寻找未授权访问？
  • 找哪些文件没有包含验证代码文件？
  • 验证代码文件有没有可以绕过的可能？（你得白盒测试，看代码逻辑）

Ajax-前后端分离

• 对文件上传的后缀名进行验证，符合要求的才能上传。
  • 这个功能的实现可以在前端验证也可以在后端验证。但是这两种验证存在一定区别：
    • 如果后端验证，那么验证的代码是看不到的，只能黑盒测试。
    • 如果前端验证，那么验证的代码可以看到，可以白盒测试。
    • 如果采用前端验证，那么会有绕过的风险。攻击者可以在浏览器中禁用该JS验证的代码（通过调整浏览器的设置来禁用JS），来实现绕过。
• Ajax方式实现用户登录验证。
  • 这种验证方式可能会存在中间人攻击，重放数据包实现绕过的风险。（具体场景请查看源代码）
• 这里需要总结一下：
  • 如果在进行业务验证的时候，如果都以前端为准，那么相比于后端，绕过的可能性会变大。
  • 因此，在编写代码的时候，业务验证最好都放在后端处理。

框架

• 如果在分析某程序漏洞的时候，该程序使用某一个框架书写，我们主要关注：
  • 是否使用了框架的安全写法（基于框架的开发手册），一般框架的安全写法，不太可能进行绕过。
  • 该框架是否存在历史漏洞（看版本），如果存在，那么可能存在绕过的可能（前提没有进行修复）。
• 其实可以简单做一个总结：如果某一个程序是采用框架来写的，那么都不太可能进行绕过。（采用框架写安全性很高）
• 我们可以采用如下方法来查看某框架的历史漏洞：
  • SeeBug平台
  • ThinkPHP框架历史漏洞：https://github.com/Mochazz/ThinkPHP-Vuln
• 如何查看框架的历史版本？
  • 黑盒：先判断框架（框架判断：数据包参数、插件、指纹搜索、经验判断等），再判断版本（版本判断：借助于报错，指纹搜集等）
  • 白盒：看源码即可

致谢

    https://www.bilibili.com/video/BV1pQ4y1s7kH/?spm_id_from=333.1007.top_right_bar_window_custom_collection.content.click

免责声明

    本博客中的内容仅供学习之用，不用于商业用途，也不可以用于任何非法用途，否则后果自负，本人不承担任何责任！