常见漏洞原理及防护方法
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
转义替换这些敏感字符|;&$><'\! 使用转义 API
任意文件读取
漏洞原理
在 Linux 系统中 ".."代表的是向上级目录 跳转 ,如果程序在处 理到诸 如../../../../../../../../../../../etc/passwd 的文件名时没有进行防护, 则会跳转出当前工作目录,跳转到到其他目录中；从而返回系统敏感文件给用户。
所有将不可信的数据输出到 HTML 页面时的场景： ➢ 将 GAT 参数值按原值输出到页面中（包括 HTTP 包头、HTML 标签、
JavaScript、CSS 等处），必须做反射 XSS 防护。
➢ 将用户提交的文本内容存储在后台并在前端展示的场景。如用户注册 （姓名、产品名、签名、个人简介）、评论、反馈、UGC 发表、文件名、 必须做存储型 XSS 防护。
➢ 涉及对页面内容进行多次编码的处理注意避免由于反编码等操作而导 致的 mXSS，即将原本无害编码内容又反编码为有害内容而导致的 XSS。
➢ 注意避免使用存在 XSS 漏洞前端 JS 组件，如小于等于 1.11.3 的 Jquery 版本。
反射型 XSS 防护
对输入参数进行类型、字符集、长度的限制
通过限制用户合法输入，可以避免反射，存储、DOM XSS 等各种复杂场景的 过滤和转义，最大限度避免了恶意脚本传入，校验方法参考第三章。
防护方案
在可能有危险的场景调用前,必须要循环过滤参数里的.. 陷阱：如果只是过滤一次../ 字符,则黑客可以通过./.././ 最终达到./../ 的效果。 过滤需要注意 Windows 和 Linux 路径的差异化,如过滤../情况,但 Windows
环境下使用..\可实现绕过
文件上传漏洞
漏洞原理
防护方案
为避免滥用资源和骚扰用户,发送短信验证码时后台需要限制每分钟只能发 送一条,并且对每个号码每天下发的次数做限制。发送验证邮件亦同理。
验证码爆破漏洞。验证码验证过一次无论成功或者失败, 都应当在后台清空 失效这个验证码。以防止攻击者使用一个正确验证码可以成功发起无数个请求。
支付场景需要后台对待支付金额做校验和签名防止篡改数据包的支付金额 低价购买商品。
服务器会对内网进行端口扫描、对内网发起攻击 payload ,轻则触发入侵检 测系统警报,重则导致内网信息泄漏甚至内网入侵。
需防护场景
服务器会接受外部 URL 或域名,并且会发起访问的场景。
防护方案
提取访问目标的 hostname ,进行 DNS 解析,判断 IP 是否处于内网。 需要防范短链接指向内网,或者 302 跳转到内网的情况。因此需设置循环次 数,在循环次数内,每次跳转跟进都要对目标 URL 提取主机名解析 IP ,判断 IP 是 否在内网,禁止对内网访问。 若业务场景需访问目的地址可控,则对访问地址进行限制 使用 squid 搭建外网代理,设置 ACL 禁止目的地址为公司内网网段的访问。 所有出口外网的请求都经 squid 代理,可以完整地规避代码防范不周导致的 SSRF 漏洞。
SQL 注入
漏洞原理
如果程序根据用户输入的参数动态生产 SQL 语句并执行，黑客可以通过传入 恶意参数值注入自己定义的语句，使数据库执行任意自己需要的指令，实现数据 窃取或入侵破坏。
安全威胁
➢ 导致拖裤，敏感信息泄露 பைடு நூலகம் 数据被篡改、删除 ➢ 数据库主机服务器被入侵
需防护场景
所有用户输入参数并进行数据库操作的场景。除了常见的 select、insert 场景，也必须警惕拼接参数使用 like、having、group by、order by、limited、 offset 等子句场景，必须进行过滤转义。
添加校验 token
服务器生成一个伪随机数作为 token ,附加在表单的隐藏字段下发给用户。 当客户端通过表单提交请求时,这个 token 也-并提交上去以供后台校验,拒绝掉 校验不通过的请求；注意避免 token 可构造情况。
任意 URL 跳转漏洞
风险说明
某些业务场景(例如登录跳转、导航前进后退)会接受不信任的用户输入,并 返回一个 302 响应或者 URL 重定向。因此攻击者通过操控输入的 URL,可以欺骗 用户跳转到不安全的页面,造成钓鱼攻击。
CSRF 漏洞
漏洞原理
CSRF ( Cross-site request forgery )跨站请求伪造，是指挟持用户在当 前已登录的 Web 应用程序上执行非本意的操作。恶意网站通过一些技术手段(例 如插入一张图片，src 地址是操作请求)欺骗用户的浏览器去访问一个自己曾经 认证过的网站并执行一些操作(如发消息、删消息、点赞关注,甚至财产操作如转 账和购买商品)。
防护方法
➢ 对于 SQL 注入，最稳妥和保险的方法只有使用预编译语句然后绑定变量。 通过使用占位符，保持查询语句和数据相分离。查询语句结构由占位符 定义，SQL 语句发送给数据库并做好准备，然后准备好的语句与参数值 相结合。这样就防止了查询被篡改，因为参数值与已编辑好的语句相结 合，而不是 SQL 字符串。从根本上避免了用户输入的恶意参数当作 SQL 语句执行。
SSRF 漏洞
漏洞原理
SSRF(Server-Side Request Forgery)服务端请求伪造。在服务器访问网页 或者 HTTP 服务的场景,如果接收到的目标 URL 是解析到内网的,则服务器会尝试 访问内网。因此黑客通过提交解析到内网的 URL ,服务器会帮黑客对内网进行攻 击、扫描。
安全威胁
安全威胁
利用跨站脚本攻击实现的攻击危害： ✓ 窃取用户 cookie，伪造用户身份登录。 ✓ 控制用户浏览器 ✓ 结合浏览器及其插件漏洞，下载木马病毒到浏览者的计算机上执行 ✓ 衍生 URL 跳转漏洞 ✓ 让官方网站出现钓鱼页面 ✓ 蠕虫攻击 总而言之，前端脚本能实现的所有功能都会被跨站脚本利用
5.3 需防护场景
➢ 当实在是有 like、having、group by、order by、limited、offset 等 动态查询时才考虑白名单输入过滤，转义等方法。
➢ 弱类型语言，使用变量之前声明变量类型。
XSS 跨站脚本
漏洞原理
如果 web 页面在动态展示数据时使用了用户输入的内容，但是未做输入过滤 和输出转义，导致黑客可以通过参数传入恶意代码，当用户浏览页面时恶意代码 会被执行。
安全威胁
用户在不知情的情况被挟持操作,或者数据被泄漏。
需防护场景
对用户数据进行查询、操作的接口。
防护方案
检查 Referer 字段
通过检查 HTTP 请求的 Referer 字段是否属于本站域名,非本站域名的请求 进行拒绝。陷阱： 一是要需要处理 Referer 为空的情况,二是要处理例如 qq.com.evil.com 部分匹配的情况。
安全威胁
泄漏源码、泄漏系统敏感文件。
需防护场景
1. 下载服务场景：用户输入文件名,可以下载文件。 2. 文件读取场景：用户输入文件名,后台服务读取相应文件内容然后返回
显示给用户。 3. 爬取场景：使用 curl 或者 libcurl 时,支持 file://协议可能下载到系
统文件 4. 危险函数场景 ➢ PHP 危险函数 fread(),readfile(),file_ get_content() ➢ Python 危险函数 read(),readline(),readlines() ➢ Node.js 危险函数 read(),readFile(),readFileSync() ➢ JAVA 危险函数 read()，readLine()
防护方案
尽量避免这种提供 URL 跳转、重定向的功能 尽量不要根据用户输入的 URL 参数拼接,进行跳转、重定向。 根据业务场景,后台配置允许跳转的目录和信任的域名列表,仅允许在白名 单里跳转。 如果无法限制用户输入 ,建议提供中间页面明确告知用户将离开本站。
逻辑漏洞
风险说明
某些业务场景(例如发送短信验证码或邮件、支付金额) , 由于没有考虑到 频率限制、参数签名,存在被绕过、滥用的漏洞。
跨站脚本攻击有三种形式 1. 反射型跨站脚本攻击 攻击者会通过社会工程手段，发送一个 URL 链接给用户打开，在用户打开页 面的同时，浏览器会执行页面中嵌入的恶意脚本。 2. 存储型跨站脚本攻击 攻击者利用 web 应用程序提供的录入或修改数据功能，将数据存储到服务器 或用户 cookie 中，当其他用户流量展示该数据的页面时，浏览器会执行页面中 嵌入的恶意代码。所有浏览器都会受到攻击。 3. DOM 型跨站脚本攻击 由于 HTML 页面中，定义了一段 JS，根据用户的输入，显示一段 HTML 代码， 攻击者可以在输入时，插入一段恶意脚本，最终展示时，会执行恶意脚本。 DOM 跨站和以上两个跨站攻击的差别是，DOM 跨站是纯页面脚本的输出，只 有规范使用 JavaScript，才可以防御。
防护方案
功能设计应避免直接执行命令,能不直接执行命令,就不直接执行命令 如果功能需要执行命令执行命令应尽量使用 mqq/webdev/user_X 等普通权 限账户，避免使用 root 权限而引入本地提权问题。
对参数可输入的字符范围做白名单限制。比如允许[a-z][A-Z][0-9]._-等有 限安全的字符。
点击劫持
漏洞原理
攻击者在恶意站点实现了一个和信任站点极其相似的恶意页面,然后在恶意 页面的上层覆盖了一个信任站点的合法页面(通常采用 iframe 的方式) , 并将 合法页面设置成透明态,诱导用户点击页面,这时实际触发的是合法页面上的事 件
安全威胁
用户的操作被劫持到攻击者事先设计好的恶意按钮或链接上,从而导致用户
由于没有限制上传文件的类型、后缀，导致任意类型文件可上传存储在服务 器。
安全威胁
危险的木马、病毒会存储在服务器,导致入侵检测系统报警。 若用户上传 HTML、SWF 等网页/flash 文件,可导致钓鱼攻击、XSS 攻击。 若用户上传 WebShell 且可执行,可导致服务器被入侵。
防护方案
1. 以下必须全部执行 ➢ 使用白名单对文件后缀进行校验 ➢ 检测 MIME 头和文件头是否与文件后缀匹配 ➢ 对保存的文件名强制随机化命名 2. 额外建议执行 ➢ 使用 Ceph 或者对象存储存放用户上传的文件,与 Web 容器隔离 ➢ 用户隐私相关的文件不可无访问控制上传到 CDN ➢ 用户隐私文件应设置权限只有属主用户才能访问 ➢ 在 Nginx 配置 urlrewrite 规则，只允许合法的 url 访问。
增加 HTTP 安全头字段：X-Content-Options 和 X-XSSProtection
增加 X-Content-Options:nosniff 的 HTTP 安全头字段，可避免部分版本 IE 浏览器无视 Content-Type 设置执行 XSS Payload。
增加 X-XSS-Protection:1;mode=block 的 HTTP 安全头字段可提示浏览器发 现 XSS Payload 时不要渲染文档。
支付场景需要考虑负数限制,购买数量和支付金额必须大于等于 0。 权限和用户校验应保持字段和阶段的一致性 a.某业务用户名和邮箱字段均为邮箱,字段值相同,修改邮箱操作在不同阶 段分别使用了用户名和邮箱字段导致任意邮箱绑定问题。 b.某业务找回密码功能校验了用户名和邮箱绑定关系,但往绑定邮箱发送找 回链接阶段未做校验,导致可修改请求将找回链接发送到指定邮箱 相关功能接口调用应避免前端调用 ，如找回密码功能前端调用发送邮件接 口导致可抓包修改收件邮件从而导致任意重置密码 能从服务器缓存(Session、 Redis 等)获取的数据就不要从客户端获取避免 越权漏洞! 重要的逻辑计算放在服务器进行，不要相信客户端的计算结果 对复杂步骤的业务逻辑中的每一步进行状态绑定，并严格按照状态机进行
命令注入
漏洞原理
如果程序根据用户输入的参数动态生成系统命令并执行,黑客可通过传入恶 意参数值注入自己定义的命令,从而控制服务器
安全威胁
执行黑客控制的系统命令,可能造成服务器被入侵控制、对内网进行渗透。
需防护场景
使用输入参数拼接系统命令进行执行的场景包括但不限于 system(),eval(),exec()等函数,需要对输入的参数进行转义或者白名单过滤。
敏感信息泄露、实施转账、添加权限或者删除记录等敏感操作
6.3 需防护场景
自己页面应当避免被嵌入到其他网页内,或者仅允许嵌入指定网页内
6.4 防护方案
检测自己的网页是否为顶层页面,否则跳转 设置 http 头部 X- Frame-0ptions 选项
设置允许网页嵌套的范围: 浏览器会拒绝当前页面加载任何 frame 页面; frame 页面的地址只能为同源域名下的页面; 允许 frame 加载的页面地址;
任意文件读取
漏洞原理
在 Linux 系统中 ".."代表的是向上级目录 跳转 ,如果程序在处 理到诸 如../../../../../../../../../../../etc/passwd 的文件名时没有进行防护, 则会跳转出当前工作目录,跳转到到其他目录中；从而返回系统敏感文件给用户。
所有将不可信的数据输出到 HTML 页面时的场景： ➢ 将 GAT 参数值按原值输出到页面中（包括 HTTP 包头、HTML 标签、
JavaScript、CSS 等处），必须做反射 XSS 防护。
➢ 将用户提交的文本内容存储在后台并在前端展示的场景。如用户注册 （姓名、产品名、签名、个人简介）、评论、反馈、UGC 发表、文件名、 必须做存储型 XSS 防护。
➢ 涉及对页面内容进行多次编码的处理注意避免由于反编码等操作而导 致的 mXSS，即将原本无害编码内容又反编码为有害内容而导致的 XSS。
➢ 注意避免使用存在 XSS 漏洞前端 JS 组件，如小于等于 1.11.3 的 Jquery 版本。
反射型 XSS 防护
对输入参数进行类型、字符集、长度的限制
通过限制用户合法输入，可以避免反射，存储、DOM XSS 等各种复杂场景的 过滤和转义，最大限度避免了恶意脚本传入，校验方法参考第三章。
防护方案
在可能有危险的场景调用前,必须要循环过滤参数里的.. 陷阱：如果只是过滤一次../ 字符,则黑客可以通过./.././ 最终达到./../ 的效果。 过滤需要注意 Windows 和 Linux 路径的差异化,如过滤../情况,但 Windows
环境下使用..\可实现绕过
文件上传漏洞
漏洞原理
防护方案
为避免滥用资源和骚扰用户,发送短信验证码时后台需要限制每分钟只能发 送一条,并且对每个号码每天下发的次数做限制。发送验证邮件亦同理。
验证码爆破漏洞。验证码验证过一次无论成功或者失败, 都应当在后台清空 失效这个验证码。以防止攻击者使用一个正确验证码可以成功发起无数个请求。
支付场景需要后台对待支付金额做校验和签名防止篡改数据包的支付金额 低价购买商品。
服务器会对内网进行端口扫描、对内网发起攻击 payload ,轻则触发入侵检 测系统警报,重则导致内网信息泄漏甚至内网入侵。
需防护场景
服务器会接受外部 URL 或域名,并且会发起访问的场景。
防护方案
提取访问目标的 hostname ,进行 DNS 解析,判断 IP 是否处于内网。 需要防范短链接指向内网,或者 302 跳转到内网的情况。因此需设置循环次 数,在循环次数内,每次跳转跟进都要对目标 URL 提取主机名解析 IP ,判断 IP 是 否在内网,禁止对内网访问。 若业务场景需访问目的地址可控,则对访问地址进行限制 使用 squid 搭建外网代理,设置 ACL 禁止目的地址为公司内网网段的访问。 所有出口外网的请求都经 squid 代理,可以完整地规避代码防范不周导致的 SSRF 漏洞。
SQL 注入
漏洞原理
如果程序根据用户输入的参数动态生产 SQL 语句并执行，黑客可以通过传入 恶意参数值注入自己定义的语句，使数据库执行任意自己需要的指令，实现数据 窃取或入侵破坏。
安全威胁
➢ 导致拖裤，敏感信息泄露 பைடு நூலகம் 数据被篡改、删除 ➢ 数据库主机服务器被入侵
需防护场景
所有用户输入参数并进行数据库操作的场景。除了常见的 select、insert 场景，也必须警惕拼接参数使用 like、having、group by、order by、limited、 offset 等子句场景，必须进行过滤转义。
添加校验 token
服务器生成一个伪随机数作为 token ,附加在表单的隐藏字段下发给用户。 当客户端通过表单提交请求时,这个 token 也-并提交上去以供后台校验,拒绝掉 校验不通过的请求；注意避免 token 可构造情况。
任意 URL 跳转漏洞
风险说明
某些业务场景(例如登录跳转、导航前进后退)会接受不信任的用户输入,并 返回一个 302 响应或者 URL 重定向。因此攻击者通过操控输入的 URL,可以欺骗 用户跳转到不安全的页面,造成钓鱼攻击。
CSRF 漏洞
漏洞原理
CSRF ( Cross-site request forgery )跨站请求伪造，是指挟持用户在当 前已登录的 Web 应用程序上执行非本意的操作。恶意网站通过一些技术手段(例 如插入一张图片，src 地址是操作请求)欺骗用户的浏览器去访问一个自己曾经 认证过的网站并执行一些操作(如发消息、删消息、点赞关注,甚至财产操作如转 账和购买商品)。
防护方法
➢ 对于 SQL 注入，最稳妥和保险的方法只有使用预编译语句然后绑定变量。 通过使用占位符，保持查询语句和数据相分离。查询语句结构由占位符 定义，SQL 语句发送给数据库并做好准备，然后准备好的语句与参数值 相结合。这样就防止了查询被篡改，因为参数值与已编辑好的语句相结 合，而不是 SQL 字符串。从根本上避免了用户输入的恶意参数当作 SQL 语句执行。
SSRF 漏洞
漏洞原理
SSRF(Server-Side Request Forgery)服务端请求伪造。在服务器访问网页 或者 HTTP 服务的场景,如果接收到的目标 URL 是解析到内网的,则服务器会尝试 访问内网。因此黑客通过提交解析到内网的 URL ,服务器会帮黑客对内网进行攻 击、扫描。
安全威胁
安全威胁
利用跨站脚本攻击实现的攻击危害： ✓ 窃取用户 cookie，伪造用户身份登录。 ✓ 控制用户浏览器 ✓ 结合浏览器及其插件漏洞，下载木马病毒到浏览者的计算机上执行 ✓ 衍生 URL 跳转漏洞 ✓ 让官方网站出现钓鱼页面 ✓ 蠕虫攻击 总而言之，前端脚本能实现的所有功能都会被跨站脚本利用
5.3 需防护场景
➢ 当实在是有 like、having、group by、order by、limited、offset 等 动态查询时才考虑白名单输入过滤，转义等方法。
➢ 弱类型语言，使用变量之前声明变量类型。
XSS 跨站脚本
漏洞原理
如果 web 页面在动态展示数据时使用了用户输入的内容，但是未做输入过滤 和输出转义，导致黑客可以通过参数传入恶意代码，当用户浏览页面时恶意代码 会被执行。
安全威胁
用户在不知情的情况被挟持操作,或者数据被泄漏。
需防护场景
对用户数据进行查询、操作的接口。
防护方案
检查 Referer 字段
通过检查 HTTP 请求的 Referer 字段是否属于本站域名,非本站域名的请求 进行拒绝。陷阱： 一是要需要处理 Referer 为空的情况,二是要处理例如 qq.com.evil.com 部分匹配的情况。
安全威胁
泄漏源码、泄漏系统敏感文件。
需防护场景
1. 下载服务场景：用户输入文件名,可以下载文件。 2. 文件读取场景：用户输入文件名,后台服务读取相应文件内容然后返回
显示给用户。 3. 爬取场景：使用 curl 或者 libcurl 时,支持 file://协议可能下载到系
统文件 4. 危险函数场景 ➢ PHP 危险函数 fread(),readfile(),file_ get_content() ➢ Python 危险函数 read(),readline(),readlines() ➢ Node.js 危险函数 read(),readFile(),readFileSync() ➢ JAVA 危险函数 read()，readLine()
防护方案
尽量避免这种提供 URL 跳转、重定向的功能 尽量不要根据用户输入的 URL 参数拼接,进行跳转、重定向。 根据业务场景,后台配置允许跳转的目录和信任的域名列表,仅允许在白名 单里跳转。 如果无法限制用户输入 ,建议提供中间页面明确告知用户将离开本站。
逻辑漏洞
风险说明
某些业务场景(例如发送短信验证码或邮件、支付金额) , 由于没有考虑到 频率限制、参数签名,存在被绕过、滥用的漏洞。
跨站脚本攻击有三种形式 1. 反射型跨站脚本攻击 攻击者会通过社会工程手段，发送一个 URL 链接给用户打开，在用户打开页 面的同时，浏览器会执行页面中嵌入的恶意脚本。 2. 存储型跨站脚本攻击 攻击者利用 web 应用程序提供的录入或修改数据功能，将数据存储到服务器 或用户 cookie 中，当其他用户流量展示该数据的页面时，浏览器会执行页面中 嵌入的恶意代码。所有浏览器都会受到攻击。 3. DOM 型跨站脚本攻击 由于 HTML 页面中，定义了一段 JS，根据用户的输入，显示一段 HTML 代码， 攻击者可以在输入时，插入一段恶意脚本，最终展示时，会执行恶意脚本。 DOM 跨站和以上两个跨站攻击的差别是，DOM 跨站是纯页面脚本的输出，只 有规范使用 JavaScript，才可以防御。
防护方案
功能设计应避免直接执行命令,能不直接执行命令,就不直接执行命令 如果功能需要执行命令执行命令应尽量使用 mqq/webdev/user_X 等普通权 限账户，避免使用 root 权限而引入本地提权问题。
对参数可输入的字符范围做白名单限制。比如允许[a-z][A-Z][0-9]._-等有 限安全的字符。
点击劫持
漏洞原理
攻击者在恶意站点实现了一个和信任站点极其相似的恶意页面,然后在恶意 页面的上层覆盖了一个信任站点的合法页面(通常采用 iframe 的方式) , 并将 合法页面设置成透明态,诱导用户点击页面,这时实际触发的是合法页面上的事 件
安全威胁
用户的操作被劫持到攻击者事先设计好的恶意按钮或链接上,从而导致用户
由于没有限制上传文件的类型、后缀，导致任意类型文件可上传存储在服务 器。
安全威胁
危险的木马、病毒会存储在服务器,导致入侵检测系统报警。 若用户上传 HTML、SWF 等网页/flash 文件,可导致钓鱼攻击、XSS 攻击。 若用户上传 WebShell 且可执行,可导致服务器被入侵。
防护方案
1. 以下必须全部执行 ➢ 使用白名单对文件后缀进行校验 ➢ 检测 MIME 头和文件头是否与文件后缀匹配 ➢ 对保存的文件名强制随机化命名 2. 额外建议执行 ➢ 使用 Ceph 或者对象存储存放用户上传的文件,与 Web 容器隔离 ➢ 用户隐私相关的文件不可无访问控制上传到 CDN ➢ 用户隐私文件应设置权限只有属主用户才能访问 ➢ 在 Nginx 配置 urlrewrite 规则，只允许合法的 url 访问。
增加 HTTP 安全头字段：X-Content-Options 和 X-XSSProtection
增加 X-Content-Options:nosniff 的 HTTP 安全头字段，可避免部分版本 IE 浏览器无视 Content-Type 设置执行 XSS Payload。
增加 X-XSS-Protection:1;mode=block 的 HTTP 安全头字段可提示浏览器发 现 XSS Payload 时不要渲染文档。
支付场景需要考虑负数限制,购买数量和支付金额必须大于等于 0。 权限和用户校验应保持字段和阶段的一致性 a.某业务用户名和邮箱字段均为邮箱,字段值相同,修改邮箱操作在不同阶 段分别使用了用户名和邮箱字段导致任意邮箱绑定问题。 b.某业务找回密码功能校验了用户名和邮箱绑定关系,但往绑定邮箱发送找 回链接阶段未做校验,导致可修改请求将找回链接发送到指定邮箱 相关功能接口调用应避免前端调用 ，如找回密码功能前端调用发送邮件接 口导致可抓包修改收件邮件从而导致任意重置密码 能从服务器缓存(Session、 Redis 等)获取的数据就不要从客户端获取避免 越权漏洞! 重要的逻辑计算放在服务器进行，不要相信客户端的计算结果 对复杂步骤的业务逻辑中的每一步进行状态绑定，并严格按照状态机进行
命令注入
漏洞原理
如果程序根据用户输入的参数动态生成系统命令并执行,黑客可通过传入恶 意参数值注入自己定义的命令,从而控制服务器
安全威胁
执行黑客控制的系统命令,可能造成服务器被入侵控制、对内网进行渗透。
需防护场景
使用输入参数拼接系统命令进行执行的场景包括但不限于 system(),eval(),exec()等函数,需要对输入的参数进行转义或者白名单过滤。
敏感信息泄露、实施转账、添加权限或者删除记录等敏感操作
6.3 需防护场景
自己页面应当避免被嵌入到其他网页内,或者仅允许嵌入指定网页内
6.4 防护方案
检测自己的网页是否为顶层页面,否则跳转 设置 http 头部 X- Frame-0ptions 选项
设置允许网页嵌套的范围: 浏览器会拒绝当前页面加载任何 frame 页面; frame 页面的地址只能为同源域名下的页面; 允许 frame 加载的页面地址;