数据越权，数据一致性问题

越权定义

所谓越权即是越过权限，对系统本没有给予你权限的数据进行操作
一个用户登录进入系统后，应当只具备数据A的查看修改操作，但由于研发人员的疏忽，没有进行判断，则用户A可以采用一些特定手段访问数据B。这样就产生了数据越权。

横向越权定义

攻击者尝试访问与他拥有相同权限的用户的资源。Web应用程序接收到用户请求，修改某条数据时，没有判断数据的所属人，或者在判断数据所属人时从用户提交的表单参数中获取了userid。导致攻击者可以自行修改userid修改不属于自己的数据。所有的更新语句操作，都可能产生这个漏洞。
即在进行操作时，使用了伪造的用户信息，进行了越权操作。

纵向越权定义

低级别攻击者尝试访问高级别用户的资源。由于Web应用没有做权限控制，或仅仅在菜单上做了权限控制，导致恶意用户只要猜测其他管理页面的URL，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的。
此情况很有可能产生在数据主键自增的数据访问请求中，攻击者通过浏览器对请求的数据进行记录，猜忌请求URI，数据信息，从而通过工具或更改JavaScript伪造请求，从而达到越权访问数据。

部分场景和解决方案

1.比如用户在删除自己的信息时，恶意用户可以通过该接口删除掉别人的信息。这种情况为了防止横向越权，我们可以在SQL中把用户主键和数据主键同时带上。
2.某外部用户登录系统，在修改数据时，通过该接口修改内部系统特殊数据。同样这种情况也是带上用户主键和数据主键。在部门具备数据权限体系的系统中，通常采用部门控权，此时可以在SQL中带上部门。

数据一致性问题

单应用

比如在一个单应用系统中，两个用户(用户1和用户2)去访问了同一条数据A，此时用户1对数据A进行了修改。而用户2对应页面没有进行刷新，但此时他也需要对数据1进行修改。如果此时的修改具备一定互斥性，例如数据A是某一产品，该产品库存是1，已经被用户1买走了，则修改了数据A的库存为0。那此时便产生了超卖漏洞。
此时可以通过加锁，CAS思想解决

		ReentrantLock lock = new ReentrantLock();
        lock.lock();
        try {
            if ((int) session.selectOne("cancel.checkStatus", cancelDTO) == 0) {
                session.update("cancel.update", cancelDTO);
            } else {
                throw new Exception("数据状态已被修改");
            }
        } finally {
            lock.unlock();
        }

采用此思想可以解决该问题，使用redis lua脚本有更快的效率。

分布式多应用

在多应用的场景下，仅仅使用代码锁是解决不了问题。特别是在针对分库分表的情况，包括分布式缓存。
其中涉及的问题，包括 主缓存一致性问题，分布式数据库一致性，分布式缓存一致性。目前只能是针对实际场景，考虑综合效率和是否事务强一致等各种问题。
so 这种场景有多种情况要解释，就先撂这了，下次我再来