交易安全

涉及交易安全的网站

  • 购物网站
  • 金融网站
  • 保险网站
  • 积分商城

    一般的交易流程

    商户平台交易订单校验：电商等商户平台的用户将页面表单提交到服务器，服务器必须对订单信息进行计算、校验，包括金额、数量、商品信息、用户身份、session中的信息等。
    支付请求订单签名：商户平台将支付请求信息提交给支付平台时候，需要同时带上签名信息，一般是用与支付平台约定的商户密钥串及签名算法对订单关键进行进行签名，例如md5（订单，id+金额+商户id+商品id+密钥串）。支付平台接收到支付请求后，首先对请求验证签名。
    此部分一般有两种方式：a、网页页面重定向方案b、后台接口调用方案（直连接口）。
    支付结果验证签名：商户平台在接收到支付平台请求后，一方面要对支付结果的签名进行验签，以避免被伪造支付结果。

    如何去审计

    查看敏感功能点，正向追踪变量传递过程。
    是在价格本身出问题还是在第三方支付的时候出问题。找到一切可能更改或者说控制价格的参数，查看是否可控比如：
    价格
    优惠券价格
    折扣
    积分抵扣物品数量
    定金
    还可以：
    购买商品数量为无限大，使程序出现错误，实现0金额购买；
    购买商品数量为负数，使程序出错，实现越买钱越多这种情况

    验证码安全

全自动区分计算机和人类的公开图灵测试（英语：Completely Automated Public Turing test to tell Computers and Humans Apart，简称CAPTCHA），俗称验证码，是一种区分用户是计算机或人的公共全自动程序。在CAPTCHA测试中，作为服务器的计算机会自动生成一个问题由用户来解答。这个问题可以由计算机生成并评判，但是必须只有人类才能解答。由于计算机无法解答CAPTCHA的问题，所以回答出问题的用户就可以被认为是人类。
在安全领域，验证码主要分为两大类：操作验证码和身份验证码
操作验证码，比如登录验证码，主要用来区分人与机器，在某种程度上属于图灵测试身份验证码，主要用来判断账号归属人，解决信任问题，所以更恰当的叫法是认证码由于两者的分工和定位不同，所衍生出的安全问题、所关注的安全点也有所不同。
操作验证码，主要是为了解决三个问题：

  1. 账户暴力破解
  2. 高频次的接口访问
  3. 敏感操作二次确认（CSRF）

实际上这三个问题，都属于人机区分问题，即这个操作、请求到底是不是人为地、自愿地发出的？
验证码安全，围绕下面几点展开：

  1. 1、验证码可重用
  2. 2、验证码可识别
  3. 3、验证码在客户端生成、显示、校验
  4. 4、空验证码绕过
  5. 5、验证码数量有限
  6. 6、是否校验客户端可控
  7. 7、验证码可预测
  8. 8、错误超过一定次数才开启验证码（撞库）

身份验证码安全

身份验证码主要是为了验证操作人身份，然后进行密码修改、账户变更、重要操作等功能。
而这类验证码主要牵扯到5类安全问题：

  1. 1、验证码返回给客户端
  2. 2、业务流程缺陷
  3. 3、验证码无时间间隔限制
  4. 4、验证码可爆破
  5. 5、验证码在客户端生成

session/Cookie安全

Cookie，有时也用其复数形式Cookies。类型为“小型文本文件”，是某些网站为了辨别用户身份，进行Session跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息
Cookie并不是它的原意“甜饼”的意思，而是一个保存在客户机中的简单的文本文件，这个文件与特定的Web文档关联在一起，保存了该客户机访问这个Web文档时的信息，当客户机再次访问这个Web文档时这些信息可供该文档使用。由于“Cookie”具有可以保存在客户机上的神奇特性，因此它可以帮助我们实现记录用户个人信息的功能，而这一切都不必使用复杂的CGI等程序举例来说，一个Web站点可能会为每一个访问者产生一个唯一的ID，然后以Cookie文件的形式保存在每个用户的机器上。如果使用浏览器访问Web，会看到所有保存在硬盘上的Cookie。在这个文件夹里每一个文件都是一个由“名/值”对组成的文本文件，另外还有一个文件保存有所有对应的Web站点的信息。在这里的每个Cookie文件都是一个简单而又普通的文本文件。透过文件名，就可以看到是哪个Web站点在机器上放置了Cookie（当然站点信息在文件里也有保存）
基于Cookie的认证过程，主要由以下三个阶段组成：

  • 发布Cookie
  • 检索Cookie
  • 验证Cookie

    XSS窃取Cookie

    判断XSS的审计
    判断是否设置了HttpOnly

    Cookie：未经过SSL加密

    “Cookie：未经过SSL加密”是指在创建Cookie时未将secure标记设置为true，那么从通过未加密的通道发送Cookie将使其受到网络截取攻击。如果设置了该标记，那么浏览器只会通过HTTPS发送Cookie，可以确保Cookie的保密性。本文以JAVA语言源代码为例，分析”Cookie：未经过SSL加密”缺陷产生的原因以及修复方法。
    危害：攻击者可以利用”Cookie：未经过SSL加密”缺陷窃取或操纵客户会话和Cookie，它们可能被用于模仿合法用户，从而使攻击者能够以该用户身份查看或变更用户记录以及执行事务。

    Session与Cookie的区别

    cookie是一种发送到客户浏览器的文本串句柄，并保存在客户机硬盘上，可以用来在某个WEB站点会话间持久的保持数据。
    session其实指的就是访问者从到达某个特定主页到离开为止的那段时间。Session其实是利用Cookie进行信息处理的，当用户首先进行了请求后，服务端就在用户浏览器上创建了一个Cookie，当这个Session结束时，其实就是意味着这个Cookie就过期了。
    cookie 和session的区别是：cookie数据保存在客户端，session数据保存在服务器端。