服务人工
漏洞检测项目所有
优势服务好
APP漏洞检测支持
服务地区全国
许多客户在网站，以及APP上线的同时，都会提前的对网站进行全面的渗透测试以及安全检测，提前检测出存在的网站漏洞，以免后期网站发展过程中出现重大的经济损失，前段时间有客户找到我们SINE安全公司做渗透测试服务，在此我们将把对客户的整个渗透测试过程以及安全测试，发现的漏洞都记录下来，分享给大家，也希望大家更深地去了解渗透测试。
同样地，由于可用的参数太多，收集数据将成为显而易见的下一步行动。许多企业的系统支持匿名连接，并且倾向泄漏普通用户不需要的额外数据。另外，许多企业倾向于存储可以直接访问的数据。安全人员正在努力应对API请求经常暴露数据存储位置的挑战。例如，当我查看安全摄像机中的视频时，可以看到该信息来自AmazonS3存储库。通常，那些S3存储库的保护并不周全，任何人的数据都可以被检索。
另一个常见的数据挑战是数据过载，很多企业都像入冬前的花栗鼠，存储的数据量远远超出了需要。很多过期用户数据已经没有商业价值和保存价值，但是如果发生泄密，则会给企业带来巨大的和合规风险。解决方法：对于存储用户数据的企业，不仅仅是PII或PHI，都必须进行彻底的数据审查。在检查了存储的数据之后，应制定数据访问规则并进行测试。确保能够匿名访问的数据不涉及任何敏感数据。
当攻击者通过API调用遍历攻击系统时，他们必须弄清楚可以发送些什么来获取数据。攻击者“信奉”这样的一个事实：即越复杂的系统，出错的地方越多。攻击者识别出API后，他们将对参数进行分类，然后尝试访问管理员（垂直特权升级）或另一个用户（水平特权升级）的数据以收集其他数据。通常，太多不必要的参数被暴露给了用户。
在近的研究项目中，我们对目标服务的API调用返回了大量数据，很多都是不必要的数据信息，例如付款网关的处理器密钥和可用的折扣信息等。这些“奖励信息”使攻击者可以更好地理解这些API调用的上下文和语法。攻击者不需要太多的想象力就能弄清楚下一步该怎么做。这些额外的参数为攻击者提供了丰富的攻击数据集。解决方法：如果将用户看到的内容范围限制为必需内容，限制关键数据的传输，并使数据查询结构未知，那么攻击者就很难对他们知道的参数进行爆密。
假如你是hack，准备攻击一家企业，那么首先要做的件事就是识别尽可能多的API。我首先按常规方式使用目标应用程序，在浏览器中打开Web应用程序或者在手机端安装移动应用程序，然后使用代理监视通信。代理能够捕获浏览器或移动应用程序对后端Web服务器发出的所有请求，从而使攻击者可以对所有可用的API端点进行分类。例如，大多数API都将API/V1/login作为身份验证端点。
如果目标也是移动应用程序，则将应用程序包拆开，并查看应用程序内部可用的API调用。考虑到所有可能的活动，攻击者可以搜索无确保护用户数据的常见配置错误或API。后，攻击者寻找API文档。一些组织为第三方发布API文档，但为所有用户使用相同的API端点。有了一个不错的端点清单，攻击者就可以测试标准用户行为和异常行为测试，可以通过两种方法找到有趣的漏洞。
讨论回顾完上次整改的问题之后，理清了思路。然后我登录了网站查看一下原因，因为网站只有一个上传图片的地方，我进行抓包尝试，使用了repeater重放包之后，发现返回包确实没有返回文档上传路径，然后我又尝试了各种绕过，结果都不行。后苦思冥想得不到结果，然后去问一下这个云平台给他们提供的这个告警是什么原因。看了云平台反馈的结果里面查杀到有图片码，这个问题不大，上传文档没有执行权限，而且没有返回文档路径，还对文档名做了随机更改，但是为啥会有这个jsp上传成功了，这让我百思不得其解。
当我仔细云平台提供的发现webshel数据的时候，我细心的观察到了文档名使用了base编码，这个我很疑惑，都做了随机函数了还做编码干嘛，上次测试的时候是没有做编码的。我突然想到了问题关键，然后使用burpsuite的decoder模块，将文档名“1jsp”做了base编码成“MS5Kc1A=”，然后发送成功反馈状态码200，再不是这个上传失败反馈500状态码报错了。
所以，这个问题所在是，在整改过程中研发人员对这个文档名使用了base编码，导致文档名在存储过程中会使用base解析，而我上传文档的时候将这个后缀名.jsp也做了这个base编码，在存储过程中.jsp也被成功解析，研发没有对解析之后进行白名单限制。其实这种编码的更改是不必要的，毕竟原来已经做了随机数更改了文档名了，再做编码有点画蛇添足了，这就是为啥程序bug改一个引发更多的bug原因。
SINE安全网站漏洞检测时必须要人工去审计漏洞和查找漏洞找出问题所在并修复漏洞，对各项功能都进行了全面的安全检测。
http://www.qdshtddzkj.com
