哈尔滨网站渗透测试项目

许多客户在网站，以及APP上线的同时，都会提前的对网站进行全面的渗透测试以及安全检测，提前检测出存在的网站漏洞，以免后期网站发展过程中出现重大的经济损失，前段时间有客户找到我们SINE安全公司做渗透测试服务，在此我们将把对客户的整个渗透测试过程以及安全测试，发现的漏洞都记录下来，分享给大家，也希望大家更深地去了解渗透测试。
下面开始我们的整个渗透测试过程，首先客户授权我们进行网站安全测试，我们才能放开手的去干，首先检测的是网站是否存在SQL注入漏洞，我们SINE安全在检测网站是否有sql注入的时候都会配合查看mysql数据库的日志来查询我们提交的SQL语句是否成功的执行，那么很多人会问该如何开启数据库的日志，如何查看呢？首先连接linux服务器的SSH端口，利用root的账号密码进服务器，打开mysql的配置文件f编辑general_log_file=（log日志的），general_log=1，在服务器里输入tail -f （log），来查看实时的数据库语句执行日志。当我们SINE安全技术在测试SQL注入漏洞的时候，就会实时的看到是否有恶意的SQL语句执行成功，如果有那么数据库日志就会出现错误提示，在渗透测试中是很方便的，也更利于查找漏洞。

其实从开发的角度，如果要保证代码至少在逻辑方面没有明显的漏洞，还是有些繁琐的。举个简单的例子，如网站的数据检验功能，不允许前端提交不符合当前要求规范的数据（比如年龄文本框部分不能提交字母）。那么为了实现这个功能，首先开发者肯定要在前端实现该功能，直接在前端阻止用户提交不符规范的数据，否则用户体验会很差，且占用服务器端的资源。
但是没有安全意识或觉得麻烦的开发者就会仅仅在前端用Js进行校验，后端没有重复进行校验。这样就很*给恶意用户机会：比如不通过前端页面，直接向后端接口发送数据：或者，前端代码编写不规范，用户可以直接在浏览器控制台中用自己写的Js代码覆盖原有的Js代码；或者，用户还可以直接在浏览器中禁用Js；等等。总之，前端的传过来的数据可信度基本上可以认为比较低，太*被利用了。
而我的思路都是很简单的，就是关注比较重要的几个节点，看看有没有可乘之机。如登录、权限判定、数据加载等前后，对方是怎么做的，用了什么样的技术，有没有留下很明显的漏洞可以让我利用。像这两个网站，加载的Js文档都没有进行混淆，注释也都留着，还写得很详细。比较凑巧的是，这两个网站都用到了比较多的前端的技术，也都用到了sessionStorage。

据估计，每个每天都会受到22次攻击，这就是为什么需要在上线之前制定安全计划的原因。否则，也许会成为加密劫持、勒索软件、DDoS、网络或更糟糕的网络威胁情况的受害者。

讨论回顾完上次整改的问题之后，理清了思路。然后我登录了网站查看一下原因，因为网站只有一个上传图片的地方，我进行抓包尝试，使用了repeater重放包之后，发现返回包确实没有返回文档上传路径，然后我又尝试了各种绕过，结果都不行。后苦思冥想得不到结果，然后去问一下这个云平台给他们提供的这个告警是什么原因。看了云平台反馈的结果里面查杀到有图片码，这个问题不大，上传文档没有执行权限，而且没有返回文档路径，还对文档名做了随机更改，但是为啥会有这个jsp上传成功了，这让我百思不得其解。
当我仔细云平台提供的发现webshel数据的时候，我细心的观察到了文档名使用了base编码，这个我很疑惑，都做了随机函数了还做编码干嘛，上次测试的时候是没有做编码的。我突然想到了问题关键，然后使用burpsuite的decoder模块，将文档名“1jsp”做了base编码成“MS5Kc1A=”，然后发送成功反馈状态码200，再不是这个上传失败反馈500状态码报错了。
所以，这个问题所在是，在整改过程中研发人员对这个文档名使用了base编码，导致文档名在存储过程中会使用base解析，而我上传文档的时候将这个后缀名.jsp也做了这个base编码，在存储过程中.jsp也被成功解析，研发没有对解析之后进行白名单限制。其实这种编码的更改是不必要的，毕竟原来已经做了随机数更改了文档名了，再做编码有点画蛇添足了，这就是为啥程序bug改一个引发更多的bug原因。
SINE安全网站漏洞检测时必须要人工去审计漏洞和查找漏洞找出问题所在并修复漏洞，对各项功能都进行了全面的安全检测。