作者：李晓健。PP云前端部门经理。拥有7年前端业务研发和架构经验，目前负责PP云视频前端研发和架构工作。
现在的系统都在往WEB方向迁移，很少以客户端的形式出现，这样不仅可以减少开发成本，也大大的减少用户的使用门槛，更新也更方便。用户只需要有一个浏览器就可以方便的使用一个系统或者网站，不需要去装一堆的客户端，当这些系统有更新时，也不需要重新下载再安装一次。人们就开始越来越多的接触到WEB，所以WEB安全一直是开发者非常关注的问题，也是一个系统中比较容易出现的问题。
前一段时间苏宁易购要求其体系下的IT总部的所有开发人员都学习WEB安全相关的知识，并为开人员人搭建了一套苏宁安全训练平台，供开发者们学习和训练使用。接下来我们就从这些训练题中选几道来分析一下WEB安全方面常见的问题及处理方法。我们的所有训练题都是只有发现和利用存在的漏洞，对服务器发信息，并让服务器返回一个通关密钥，只要能拿到服务器端的通关密钥，该训练就算通过。
案例一
该案例只有一个完成该课程的按钮，当我们点一个这个按钮，页面会出现一个 “LessonNot Complete” 的信息，看似没有什么头绪。然后我们通过浏览器的开发者工具的网络选项可以看到，当我们点一下这个按钮时，浏览器会发起一个请求到服务器，然后页面上显示的信息是服务器返回的。那就们就来分析一下这个网络的请求，依然是通过浏览器的开发者工具来抓包。
我们来分析一下这个请求，发现它是一个POST的请求，但是请求的时候没有带参数，所以应该不是参数上的问题。但是他是有发送Cookie给服务器的，那我们就来分析一下他发送过去的Cookie,发现它有一个lessonComplete=lessonNotComple的键值，我们就可以猜想一下，是不是就是这里来标志用户是不是已经完成了该课程，有了猜想，我们再来验证一下，就是把这个参数的值改掉，lessonNotComple是没有完成的意思，那我们就将not去掉，改成lessonComple，将请求重新发一次试试，这里改发送给后台的Cookie有两种方法，一种是直接修改浏览器的Cookie，然后再发送，另一种就是直接修改发送时的Cookie。因为我用的是火狐浏览器，它的开发者工具中的网络是可以直接编辑和重发一个请求的（上图中有一个编辑和重发的按钮），我们就点一下编辑和重发：
然后我们再来看一下，这个请求的返回值（可以通过开发者工具的网络中的响应信息），就发现服务器会的信息是“Lesson Complete”，并且还包含了一串通关密钥。
这里的Cookie里的值都是页面加载时，服务端返回给的WEB端的，数据提交时WEB端把数据更改了，传给服务端，服务端也不会去做验证，就将WEB传过去的数据当作最终数据。所以这里需要处理的就是服务端在接收一些WEB的数据时，需要做验证，并不能完全相信WEB传递过去的信息。
案例二
该案例也是只有一个按钮，题目的意思是只有用管理员的身份才可以获取通关密钥，当我们点一下这个按钮后发现页面上显示“You're not an Admin!!!”，说我们不是管理员，我们通过开发者管理工具，依然可以发现点了按钮以后浏览器给服务端发一个请求，那我们还是来分析一下这个请求：
还是一个没有参数的POST的请求，那我们还是来分析一下它的Cookie信息：
发现也没什么明显的信息可用，只有checksum的值‘dXNlclJvbGU9dXNlcg==’ 和JSESSIONID3的值 ‘YOQWj7D4HuQq8IryQdEysQ==’ 看起来比较像字符串是经过了base64编码后的结果，那我们就对这两个值进行base64解码试试看。最终可以发现
‘dXNlclJvbGU9dXNlcg==’
解出来的值是userRole=user，
‘YOQWj7D4HuQq8IryQdEysQ==’
解出来是乱码，或者说是解不出来。
这里我们就得到了一个userRole=user的可识别字符串，那是不是就是这里标明的用户身份呢。那我们就再来猜测一下，后面的user是用户的意思，但是题目要求是需要administrators的身份来请求，那我们就把
userRole=user换成userRole=administrators然后进行base64编码，得到的字符串就是‘dXNlclJvbGU9YWRtaW5pc3RyYXRvcnM=’，
那我们就把CooKie里的值
‘checksum=dXNlclJvbGU9dXNlcg==’
改成‘checksum=dXNlclJvbGU9YWRtaW5pc3RyYXRvcnM=’，
将请求重新发一次试试看。返回的依然是‘You're not an Admin!!!’。
也就是说我们猜测的是不对的。可是我们能找到的可用信息只有这么多，那是不是我们猜测的角色名称不对，比较常见的管理员角色大家比较喜欢用admin，不是administrators，那我们就把userRole=user换成userRole=admin然后进行base64编码，就得到了‘dXNlclJvbGU9YWRtaW4=’，然后替换Cookie里的值，再进行请求，结果依然不对。
那会不会是administrator呢？
换一下试试：
userRole=user经过base64编码得到‘dXNlclJvbGU9YWRtaW5pc3RyYXRvcg==’,然后替换Cookie，发送请求，最后发现请求里的消息是‘Admin Only Club，Welcome administrator.’ 和我们需要的通关密钥。
这里的主要问题就是，将比较敏感的用户身份信息用了比较简单和常用的编码处理后放到了WEB端，所以就很容易被篡改，出现冒用别人身份信息的问题。这应里对这种敏感的信息我们应该用一套私有的加密算法去处理，这样就算别人看到你加密后的内容，因为他不知道加密算法，也无法进行解密，所以也就无法去篡改了。
案例三
该案例就是需要我们可以免费的买到trolls。首先我们能看到一共是4个商品，上面都有价格，并且没有价格是0的商品，所以想免费买到看似是不可能的。虽然说只有图片没有商品名称，我们可以通过一个试验来确定每个商品是什么，首先我们在每一个商品后面都输入不同的数量，比如依次输入a，-1，3，4(这里输入字母和负数是为了检测，在发送请求之前针对不会对我们的输入做处理)。然后点击Place Order的按钮，就会发现它发出一个请求，
从图中可以看出，前端没有对提交的数据做验证和处理，都是按我们输入的原样直接发送给后台的，根据发送的数据也可以确定所有商品的名称价格45的是rage，因为我们输入的数量是a，发送的数据中有rageAmount: a,然后可以推断出价格3000的商品就是troll，也就是我们需要买到的商品。 接下来就来看怎么免费买到它。要想免费，就需要把我们的总价做到小于或等于0，因为所有商品的价格都是大于0的，那我们就把最容易想到就是数量全填成0，那总价就是0了，我们就都填0提交，服务端返回的数量确实是0，但是没有返回我们需要的通关密钥，也就是说并没有成功，并且我们需要买到的troll的数量一定要大于0,接下来我们可以试试填负数，把troll的数量填成1，把价格是30的商品数量填成-100，其他的都填0，这样总价就是3000 x 1 + 30 X (-100) = 0;然后提交，发现返回的总价是3000，并不是我们想的0，又失败了，也就是说服务端会过滤掉我们输入的负数，只有正数是有效的。
既然没有办法通过常规的运算去解决，那我就从程序的角度去考虑，了解程度的人都知道，在程序中数字的大小都是有范围的，比如比较常见的整形int，它的取值范围就是-2147483648～2147483647，我们就试试如果他超出了这个范围会怎么样。虽然说我们不知道服务端用的是什么类型，那我们就按照这个类型来试，不行再试其他的类型。
那我们就输入一总和是大于2147483647的值，比如troll我们输入一个1,价格是30的我们输入100000000，所以得到的总和是3000003000，是大于2147483647的，然后我们提交，发现后台返回的总价格是-1294964296，是一个负数，并且返回了通关密钥，也就是说我们的猜想是正确的，为了验证可能是和这个最大值有关，我们再试一下一个小一点的数字，我们给的数字最大位是3，允许范围内的数字最大位是2，我们为了简单就弄一个最大位是1，数字位数都是一样的试一下，我们把价格30的商品数量改回0.把价格15的商品数量改成100000000，这样的我们总价就是1500003000，在范围之内，提交后发现服务器返回了总价1500003000，并且没有通关密钥，所以说我们的猜想应该是正确的，当数字超出范围后就会出现我们意想不到的结果。
这里主要的问题就是服务没有对WEB端输入的数据范围做验证，导致出现了异常情况，给WEB端留下了可攻击的漏洞。