安全漏洞

文章主目录

XSS
越权
关于验证码
csrf
钓鱼网站
铭感的操作应该加白名单
请求重放
防篡改
一些设计

回到顶部

XSS

保存数据要过滤掉XSS攻击的相关脚本,或者在服务端模板渲染的时候增加对html标签进行转义

案例1

攻击者利用注册或者报错数据按钮将服务商名字注入一段脚本,比如将用户的信息上传到攻击者的服务器(比如将网页地址,cookie、token发到他的服务器),或者让普通用户无法正常使用

当我们用服务端渲染就会让攻击者将他的js代码侵入

反给客户端代码

解析加载并运行的js脚本

案例2

注入的脚本大量写cookie导致用户端不可用

回到顶部

越权

未登录访问越权、跨用户越权、未校验权限越权、跨租户越权、权限相关业务参数交给前前端控制(比如用户可以查A类型的文章客服可以查看B类型,增加了一个类型参数由前端传)

这个漏洞很常见,比如我们的update 根据id delete根据id

比如sass系统如果id是有序的id 那么就可以出现越权修改和删除,雪花的话成本会高一点但是别人也可以试出比如posman 频繁累加雪花id尝试

表现形式,攻击者注册一个试用服务商,拿到token id递增有序进行删除修改,批量删除篡改了其他服务商的数据

解决方式:

1.应用层校验

2.针对findById 或者 updateById deleteById 操作 where条件除了带上id 还要带上操作人的企业id

3.还有update user set user_group_id={前端传值} where id=#{userId} and providerId=#{currentUserProviderId} 这种情况虽然带了providerId但是还是要注意修改关联数据的id也要去校验数据所属

像我遇到的主要分为跨服务商越权,用户越权

回到顶部

关于验证码

现在在系统中验证码往往做一些铭感操作，人机识别，登录，绑定，支付，解绑等。

含有漏洞逻辑

1.根据邮箱/手机生成验证码

2.根据用户输入的手机或者验证码判断是否正确

3.过期提示过期/输入错误则提示错误

大部分都是验证码都是固定6位或者4位，会有人利用漏洞不断重试

1.错误重试

2.重新获取重试,或者爆破用户

解决漏洞

增加容错机制，某个时间段可重新获取验证码次数(防止爆破用户)，验证码可输入错误次数（防止重试试错）

回到顶部

csrf

CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种常见的网络攻击方式，攻击者通过诱骗用户点击恶意链接或发送恶意邮件等方式，使用户在受信任的网站上执行非自愿性操作。在这种攻击方式下，攻击者可以在用户不知情的情况下窃取受害者的COOKIE，伪造合法请求，危害用户账户和个人隐私的安全。

例子

假设用户 A 在银行网站上登录了账号，并且在浏览器中也保存了 Cookie。攻击者 B 发现了一篇含有恶意代码的博客文章，并通过社交媒体等方式引诱用户 A 点击该文章。

当用户 A 点击该文章时，代码会自动向银行网站发起一个 POST 请求，请求中包含了银行网站需要的信息和用户 A 的 Cookie，这样银行网站就会认为这是用户 A 的合法请求，并执行这个操作。攻击者 B 就这样成功地操作了用户 A 的账户，偷取了其银行资金，而用户 A 对此毫不知情。

比如攻击这做一个a.html文件诱导用户点,或者一个网站利用cookie 同源自动提交特性,如果将token存放在cookie就会有很大风险

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="http://pay.com/api2/transfer_token=&_provider_id=7904" method="POST" enctype="text/plain">
      <input type="hidden" name="money" value="1000">
      <input type="hidden" name="toUserId" value="10">
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

修复方案

1.不要将身份认证信息放到cookie 可以放到head 头。

2.继续使用cookie的话name需要在每个post写操作，需要用户先利用当前身份获取一个corfToken 在表单加上仅能使用一次，因为攻击者本质是使用伪造链接或者脚本跳转来实现跳转只会请求一个接口他拿不到csrfToken 获取csrftoken需要身份验证

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="http://pay.com/api2/transfer_token=&_provider_id=7904" method="POST" enctype="text/plain">
    <input type="hidden" name="_csrf" value="{{csrfToken}}">
      <input type="hidden" name="money" value="1000">
      <input type="hidden" name="toUserId" value="10">
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>